On Fri, Dec 07, 2007 at 02:22:30PM +0200, Hiroshi DOYU wrote:
> > > +
> > > + /* zap pte */
> > > + end = pmd_page_vaddr(*pmdp);
> > > + ptep = end - PTRS_PER_PTE;
> > > + while (ptep < end) {
> > > + if (!pte_none(*ptep))
> > > + goto out;
> > > + ptep++;
> > > + }
> > > + pte_free_kernel(pmd_page_vaddr(*pmdp));
> >
> > So you free the PMD table.
> >
> > > +
> > > + invalidate_pmd:
> > > + pmd_clear(pmdp);
> > > + flush_pmd_entry(pmdp);
> >
> > and then remove it from the page tables. Two problems - if the entries
> > have been copied to another task, you'll be leaving the PMD table present
> > there. Secondly, if you're using this with SMP it's hellishly racy.
> > (which is why we don't support section mappings in ioremap on SMP.)
>
> For the first case, this pagetable is dedicated only to each
> coprocessor and the coprocessor's MMU is independent of ARM side MMU
> from H/W point of view. This code just manages the consistency between
> the kernel pagetable(init_mm) and the coprocessor's pagetable against
> real physical address at the same time. So this coprocessor's
> pagetable itself isn't duplicated even when forking.
You haven't understood the problem at all.
You are setting up kernel L1 table entries in the kernels init_mm page
tables.
When ever you perform an access to mappings setup there, and some other
thread is running, those page table entries get copied to the threads
private L1 tables.
If you then tear down the kernel L1 table entries, references to those
page tables persist from other threads private L1 tables.
So, if you NULL out the entry in the init_mm and free the page, you've
got a very real potential for something to access a page which has been
freed - possibly writing to it. Moreover, if that page gets re-used in
such a way that userspace can then access it, you've a security hole.
I would much rather you did NOT implement L1 table manipulation yourself;
it is a good way to introduce serious bugs into the kernel if you do not
properly and fully understand how the page tables and threads work.
Instead, I suggest you look around the kernel and see how you can re-use
code which already does this, possibly by modifying it. ioremap() would
be a good place to start because it already correctly deals with these
issues for the uniprocessor case.
-
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
