Kernel related (?) user space crash at ARM11 MPCore

[Russell King - ARM Linux]

On Wed, Sep 23, 2009 at 02:12:23PM +0200, Mikael Pettersson wrote:
> Catalin Marinas writes:
>  > On Wed, 2009-09-23 at 10:13 +0100, Catalin Marinas wrote:
>  > >      1. The patch I just posted which introduces flush_prot_range(). It
>  > >         affects generic code but if people here agree with the idea, I'm
>  > >         happy to try to push for it upstream. It allows mprotect(rx) to
>  > >         flush the caches as some people might expect and doesn't affect
>  > >         the fork or mmap performance
>  > >      2. Russell's (unposted) patch (or the one above) for flushing the
>  > >         D-cache during CoW (no I-cache invalidation necessary). There
>  > >         would be a (probably slight) performance drop for applications
>  > >         using intensive forking (apache?) but it shouldn't be that
>  > >         different from read-allocate caches. The common fork+exec
>  > >         combination shouldn't do much CoW so I don't expect this to be
>  > >         affected
>  > >      3. My initial patch for flush_cache_range but it would be better to
>  > >         disable read-implies-exec
>  > >      4. Handle the prefetch abort for exec permission and only to the
>  > >         flushing there (this patch would be a bit more complicated)
>  > 
>  > I did some tests with OABI_COMPAT disabled so that read-implies-exec is
>  > also disabled. Option 3 above has no noticeable performance drop
>  > compared to a vanilla kernel, also with OABI_COMPAT disabled.
>  > 
>  > Which would make me recommend workaround 3 if OABI compatibility is not
>  > required. I'm not sure what Debian or Ubuntu do (I think the latter has
>  > OABI_COMPAT disabled). If OABI is required, we should go with 2.
>  > 
>  > I've spent too much time already on this issue. There are several
>  > solutions available, all with drawbacks. If there are no other solutions
>  > to be proposed (other than modifying user-space), maybe we should vote
>  > on the favourite option.
>  > 
>  > My vote: 2 (until we no longer have OABI filesystems around)
> 
> OABI is obsolete legacy, so while it should (perhaps) be
> kept working, it should not be allowed to negatively affect
> the performance of pure EABI systems.
> 
> If option 3 is best for EABI then that's my vote.

However, Catalins benchmarks don't include testing my patch with EABI
executables with RIX disabled, so we really don't know how it would
behave.