lkml.org 
[lkml]   [2010]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Fix 'flush_old_exec()/setup_new_exec()' split


On Thu, 4 Feb 2010, Ben Hutchings wrote:
> >
> > So you _should_ have a combination of
> > - 221af7f87 ("Split 'flush_old_exec' into two functions")
> > - 05d43ed8a ("x86: get rid of the insane TIF_ABI_PENDING bit")
> > - 7ab02af42 ("Fix 'flush_old_exec()/setup_new_exec()' split")
> >
> > (and there are also additional sparc/ppc versions of that TIF_ABI_PENDING
> > bit removal, but they shouldn't matter on your system)
>
> Thanks. If all the necessary patches are all in the stable queue then
> we can pick them from there.

Yeah, they are all there. Please do report if that fixes your 64-bit
kernel with 32-bit user space issues (I tested that case, but I don't have
a full 32-bit environment, so I only tested it on a fairly simple
test-case that showed the pre-patch problem that the series fixes).

Btw, that 221af7f87 commit (even with the fix) is kind of nasty in that it
changes semantics without then fixing up the users in the same commit.
Normally we wouldn't accept anything like that, but it was supposed to
only change semantics for a case that was already broken, and is pretty
rare (the transition from 32-bit to 64-bit and vice versa).

Splitting them up was supposed to make it clearer what was going on and
tint he original version the first patch didn't change semantics. And in
fact, the split-up did indeed then help me chase down the bug that showed
up on Microblaze, because it broke an architecture that shouldn't have
been affected at all ;)

But pretty it wasn't. My bad. It would have been much better if we'd have
fixed this earlier than -rc6, but the bugreport that reported this came in
around -rc5. Unlucky timing (because the problem has been around for a
looong time).

Linus


\
 
 \ /
  Last update: 2010-02-04 17:01    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site