kernel virtual memory access (from app) does not generatesegfault

Jamie Lokier jamie at shareable.org
Thu Apr 22 11:59:31 EDT 2010


Dave P. Martin wrote:
> From: anfei [mailto:anfei.zhou at gmail.com] 
> > On Thu, Apr 22, 2010 at 11:56:09AM +0100, Dave P. Martin wrote:
> > >   * I haven't tested this on 926 myself
> > >   * On armv7, I have observed the problem only on *old* kernels 
> > > (<2.6.32; which lack any of the patches under discussion)
> > >   * Using 2.6.34-rc1 (from rmk's versatile branch) on 
> > armv7, I get the 
> > > expected SEGV when userspace tries to execute >= TASK_SIZE
> > > 
> > > so...
> > >   * Sasha's problem is caused by a problem in the current kernel
> > >   on 926.
> > >   * My problem relates to v7 and has already been fixed (but isn't 
> > > fixed in the Ubuntu kernels yet)
> > > 
> > > The test case was
> > > 
> > > int main(void)
> > > {
> > >   ((void (*)(void))0xc0000000)();
> > >   return 0;
> > > }
> > > 
> > I did a test on arm926 using QEMU with the latest kernel 
> > (just pull from git.kernel.org).  Without checking user_mode, 
> > this test case will continue to trigger do_translation_fault 
> > with address 0xc0000000, so I think that two-liner patch is 
> > necessary.  With it, the case will get SIGSEGV, and the 
> > system seems running well.
> 
> That matches my understanding--- it sounds like the two-liner is relevant
> for all pre-v6 platforms (including ARM926), so it probably makes sense to
> merge it.

Good. Both results are consistent with the earlier discussion about
the two patches (one already committed).

There are two different bugs with the same symptom on different
devices.  No wonder Russell's confused by this thread.

The two-liner is the least complicated solution for pre-v6.
Commit the damn thing already ;-)

Reviewed-By: Jamie Lokier <jamie at shareable.org>

-- Jamie



More information about the linux-arm-kernel mailing list