On Fri, May 17, 2013, at 17:13, Greg KH wrote: > On Fri, May 17, 2013 at 12:04:08PM +0200, Alexander van Heukelum wrote: > > On Fri, May 17, 2013, at 0:05, Greg KH wrote: > > > On Fri, May 10, 2013 at 11:41:46PM +0200, Alexander van Heukelum wrote: > > > > Hi Greg, Al, > > > > > > > > The patch that went into mainline and was cc'ed to stable assumes that > > > > 2cf09666 "make SYSCALL_DEFINE<n>-generated wrappers do > > > > asmlinkage_protect... and switch i386 to HAVE_SYSCALL_WRAPPERS, > > > > killing open-coded uses of asmlinkage_protect() in a bunch of > > > > syscalls." is also included. I think my original patch would be better > > > > suited for the stable tree? It's tiny, independent, and it fixes the > > > > issue. See attached patch... Al, what do you think? > > > > > > > > Also: please note that the problem was introduced in v3.9, so this is > > > > the only stable tree that should get this patch. > > > > > > I really don't understand, should I not have included this patch in the > > > 3.9-stable tree? Should I use something else instead? If so, what is > > > the git commit id? Or should I add something on top of this one? > > > > > > totally confused, > > > > Sorry about that :-/. > > > > So... yes, I think the version that Al cc'ed to stable should not be applied. > > > > Instead, 3.9-stable should get the version that I originally sent to lkml (before v3.9 was released): > > https://lkml.org/lkml/2013/3/27/534 It's the minimal fix for v3.9. Releases before v3.9 didn't have the bug. > > > Please wrap your lines properly. > > Realize that I like to take the exact patch that is in Linus's tree for > a lot of good reasons. Taking different versions can cause different > bugs, that we don't want to track down or deal with at all. I understand. However, the patch in Linus' tree doesn't fully have the intended effect if applied on v3.9. > > The original version includes asmlinkage_protect directives. They are > > (at least theoretically) necessary, because i386 asmlinkage functions > > puts parameters of function calls on the stack and gcc could otherwise > > reuse this stack space. That would cause the vm86 syscall to return > > with changed registers. I did not check if this really happened, but > > the code generation was changed by adding the directives... I didn't > > cc that version to stable, because I hoped the fix would make it > > before the release of v3.9. > > > > In the mean time, for v3.10, Al changed the i386 syscall handling: He > > enabled the syscall wrapper code for i386 and added the > > asmlinkage_protect directive to the wrappers. He then removed the (now > > obsoleted) asmlinkage_protect directives from the patch and did the > > follow-on code simplification. He cc'ed this rebased version to > > stable, but this version depends on his changes for v3.10. Applying > > this version means that the stack is not protected for the vm86 > > syscall. > > So does that mean I just need to apply a different patch to 3.9-stable > as well? If so, what is that git commit id? I'm afraid it's not that easy :-( We need 2cf0966683430b6468f36ca20515a33ca7f2403c "make SYSCALL_DEFINE<n>-generated wrappers do asmlinkage_protect" and what it depends on. I had a look, and this commit in fact does not enable the syscall wrappers, because it came after 22d1a35da0e247a006c286842a1846acb4ffed4f "make HAVE_SYSCALL_WRAPPERS unconditional". This one touches more ARCHs than just i386. I think 4a0fd5bf0fd0795af8f1be3b261f5cf146a4cb9b "teach SYSCALL_DEFINE<n> how to deal with long long/unsigned long long" is also necessary. I think this is discouraging enough? Greetings, Alexander > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html