On Tue, 26 Mar 2013 21:44:12 -0400 Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2013-03-26 at 12:43 -0700, akpm@xxxxxxxxxxxxxxxxxxxx wrote: > > The patch titled > > Subject: revert "ipc: don't allocate a copy larger than max" > > has been added to the -mm tree. Its filename is > > revert-ipc-dont-allocate-a-copy-larger-than-max.patch > > > > Before you just go and hit "reply", please: > > a) Consider who else should be cc'ed > > b) Prefer to cc a suitable mailing list as well > > c) Ideally: find the original patch on the mailing list and do a > > reply-to-all to that, adding suitable additional cc's > > > > *** Remember to use Documentation/SubmitChecklist when testing your code *** > > > > The -mm tree is included into linux-next and is updated > > there every 3-4 working days > > > > ------------------------------------------------------ > > From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > Subject: revert "ipc: don't allocate a copy larger than max" > > > > Revert 88b9e456b164. Dave has confirmed that this was causing oopses > > during trinity testing. > > No, he didn't. hm, so perhaps he didn't run the test for long enough? > Here's a copy of Dave Jones's original report [1] on this very same bug > in linux-next on Feb 19, __6 days before__ I even submitted the series > that fixes this bug. > > Note that the faulting instruction is __identical__ to Dave's most > recent report on 3.9-rc4: Well bah. Why wasn't I told this (sufficiently clearly for it to sink in)? > My recommendation is to either: > 1) apply my entire 'ipc MSG_COPY fixes' series > --or-- > 2) revert the entire ipc MSG_COPY implementation that introduced this > bug to begin with. urgh. I really don't want to merge a pile of patches, one of which we think fixes a bug which we don't understand for reasons we don't understand. Not only does this generally suck, but it also creates a nightmare for maintainers of 3.8.x kernels - what patch should they merge to fix that bug? I'm about to disappear for 1.5 weeks. Stanislav, someone, please let's get this sorted out! -- 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