From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@kernel.org, LKML <linux-kernel@vger.kernel.org>,
stable-review@kernel.org
Subject: Re: [PATCH] Fix 'flush_old_exec()/setup_new_exec()' split
Date: Thu, 4 Feb 2010 07:57:28 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.1002040749390.3707@localhost.localdomain> (raw)
In-Reply-To: <1265272174.2952.20.camel@localhost>
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
prev parent reply other threads:[~2010-02-04 15:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1265245849.3362.1.camel@localhost>
2010-02-04 4:02 ` Ben Hutchings
2010-02-04 5:39 ` Linus Torvalds
2010-02-04 8:29 ` Ben Hutchings
2010-02-04 14:38 ` [stable] " Greg KH
2010-02-04 18:46 ` Sven Joachim
2010-02-04 18:57 ` Greg KH
2010-02-04 19:32 ` Sven Joachim
2010-02-04 19:37 ` Linus Torvalds
2010-02-05 5:44 ` Sven Joachim
2010-02-06 8:49 ` Greg KH
2010-02-06 9:21 ` Sven Joachim
2010-02-06 9:31 ` [Stable-review] " Willy Tarreau
2010-02-06 9:55 ` [stable] [Stable-review] " Greg KH
2010-02-04 19:11 ` [stable] " Linus Torvalds
2010-02-04 19:45 ` Sven Joachim
2010-02-04 19:54 ` Linus Torvalds
2010-02-04 22:25 ` Ben Hutchings
2010-02-05 10:23 ` Sven Joachim
2010-02-04 15:57 ` Linus Torvalds [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.1002040749390.3707@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=ben@decadent.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=stable-review@kernel.org \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®