Re: [PATCH] Fix OOPS in mmap_region() when merging adjacentVM_LOCKED file segments

[Greg KH]

On Fri, Jan 30, 2009 at 05:40:24PM +0000, Hugh Dickins wrote:
> On Fri, 30 Jan 2009, Linus Torvalds wrote:
> > On Thu, 29 Jan 2009, Greg KH wrote:
> > > 
> > > Which version was the "non-cleanup" version that should be added to the
> > > stable trees?
> > 
> > There were two different versions:
> > 
> > 	From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > 	Subject: Re: possible bug in mmap_region() in linux-2.6.28 kernel
> > 	Message-Id: <20090128134350.034ac6a7.akpm@xxxxxxxxxxxxxxxxxxxx>
> > 
> > 	From: Lee Schermerhorn <Lee.Schermerhorn@xxxxxx>
> > 	Subject: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED file segments
> > 	Message-Id: <1233259410.2315.75.camel@lts-notebook>
> > 
> > and I'm actually not at all sure which one should go into stable (or if we 
> > should just pick the same one that went into mainline). 
> > 
> ...
> > 
> > But none of the above really changes the fact that the patch I committed 
> > to mainline was really quite fundamentally more invasive than either of 
> > the "simple" patches. All three patches are small, with mine arguably the 
> > smallest of the lot, but mine actually changed semantics, while Andrew's 
> > and Lee's patch literally only fix the invalid pointer use.
> > 
> > I'll leave it to others to decide which one goes into -stable. I 
> > personally don't really think it matters. I argue above that mine is 
> > pretty safe and thus perfectly fine even for -stable, but reality has a 
> > habit of sometimes disagreeing with me. Dang.
> 
> I'd say one of the non-cleanup versions for -stable
> (but I've not compared them to see which one is better).

Ok, based on both of your comments about this, and the fact that the
in-tree one did break something, I'll go look at Andrew and Lee's
versions and pick one of them for -stable.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/