Re: [PATCH 2/9] mm: arm ready for split ptlock

[Jesper Juhl]

On 10/31/05, Russell King <rmk+lkml@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Oct 31, 2005 at 11:19:21PM +0100, Jesper Juhl wrote:
> > On 10/26/05, Russell King <rmk+lkml@xxxxxxxxxxxxxxxx> wrote:
> > > No.  If we're emulating a cmpxchg() on a clean BSS page, this code
> > > as it stands today will write to the zero page making it a page which
> > > is mostly zero.  Bad news when it's mapped into other processes BSS
> > > pages.
> > >
> > > Changing this for pte_dirty() means that we'll refuse to do a cmpxchg()
> > > on a clean BSS page.  The data may compare correctly, but because it
> > > isn't already dirty, you'll fail.
> > >
> > > If we still had it, I'd say you need to use verify_area() to tell the
> > > kernel to pre-COW the pages.  However, that got removed a while back.
> > >
> >
> > Yes, I removed verify_area() since it was just a wrapper for access_ok().
> > If verify_area() was/is needed, then access_ok() should be just fine
> > as a replacement as far as I can see.
>
> Except verify_area() would pre-fault the pages in whereas access_ok()
> just verifies that the address is a user page.  That's quite important
> in this case because in order to fault the page in, we need to use
> put_user() to get the permission checking correct.
>
> However, we can't use put_user() because then the cmpxchg emulation
> becomes completely non-atomic.
>
Colour me stupid, but I don't see how that can be.

Looking at verify_area() from 2.6.13 - the arm version (
http://sosdg.org/~coywolf/lxr/source/include/asm-arm/uaccess.h?v=2.6.13#L81
) :

static inline int __deprecated verify_area(int type, const void __user
*addr, unsigned long size)
{
        return access_ok(type, addr, size) ? 0 : -EFAULT;
}

How will this cause pre-faulting if a call to access_ok() will not?
Please enlighten me.


--
Jesper Juhl <jesper.juhl@xxxxxxxxx>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/