On Thu, Apr 19, 2012 at 09:25:45AM -0700, Greg KH wrote:
> On Thu, Apr 19, 2012 at 09:22:02AM -0700, Greg KH wrote:
> > On Tue, Apr 17, 2012 at 12:27:53PM +0200, Johan Hovold wrote:
> > > On Mon, Apr 16, 2012 at 12:40:16PM -0700, [email protected]
> > > wrote:
> > > >
> > > > This is a note to let you know that I've just added the patch titled
> > > >
> > > > Bluetooth: hci_ldisc: fix NULL-pointer dereference on tty_close
> > > >
> > > > to the 3.3-stable tree which can be found at:
> > > >
> > > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > >
> > > This patch (which was also added to the 3.2 and 3.0 stable queues) has a
> > > dependency on commit 797fe796c4335b35d ("Bluetooth: uart-ldisc: Fix
> > > memory leak"). Unfortunately, the memory leak fix depends on another
> > > patch which changes internal interfaces. The fix also went in through
> > > bluetooth-next along with my fix so I couldn't refer to that commit.
> > > Neither was the memory leak fix marked for stable.
> > >
> > > The original discussion on how to best handle this can be found in these
> > > threads:
> > >
> > > http://marc.info/?l=linux-bluetooth&m=133130788128668&w=2
> > > http://marc.info/?l=linux-bluetooth&m=133113631130418&w=2
> > >
> > > Below is a minimal backport of the memory leak fix which the NULL-deref
> > > patch depends on. This one is needed in 3.0 and 3.2 as well.
> >
> > So if I just add this one patch to 3.0 and 3.2, that should be fine,
> > right? If so, great, I've now done that, if not, please give me a hint
> > as to what I should do :)
>
> Oh, this needs to be added to 3.3-stable as well, right? I've done that
> now also.
That's correct. All three trees look good.
One minor style issue though: the subject line of the mem leak fix
("[PATCH] Bluetooth: uart-ldisc: Fix memory leak") still has the
"[PATCH]"-prefix, but I guess we could live with that. ;)
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
