Re: [PATCH 0/7] Input: fix NULL-derefs at probe

[Johan Hovold <johan@kernel.org>]

On Fri, Mar 17, 2017 at 02:03:15PM -0700, Dmitry Torokhov wrote:
> On Fri, Mar 17, 2017 at 11:53:37AM +0100, Johan Hovold wrote:
> > On Thu, Mar 16, 2017 at 03:37:28PM -0700, Dmitry Torokhov wrote:
> > > On Mon, Mar 13, 2017 at 04:45:52PM +0100, Johan Hovold wrote:
> > > > On Mon, Mar 13, 2017 at 04:15:18PM +0100, Oliver Neukum wrote:
> > > > > Am Montag, den 13.03.2017, 13:35 +0100 schrieb Johan Hovold:
> > > > > > This series fixes a number of NULL-pointer dereferences due to
> > > > > > missing endpoint sanity checks that can be triggered by a
> > > > > > malicious USB device.
> > 
> > > Applied the lot.
> > 
> > I noticed you dropped the Fixes tag from the patches that fix bugs which
> > predate git. While this is probably not much of an issue in this case, I
> > think it's generally a bad idea since we're loosing information this
> > way, and this specifically makes it harder for the stable maintainers to
> > figure out which tree to backport a fix to.
> 
> As far as I know the rule is: if no special markings then stable patch
> should be applied as far as it can go.

That's true for the stable tag itself, yes.

> There is no reason to say specify 2.6.12 commit, as in fact the
> offending change is likely to be even earlier, so the annotation would
> be effectively wrong.

It is still the first git commit which has the bug, and everyone
(dealing with code forensics) knows that 1da177e4c3f4
("Linux-2.6.12-rc2") is special.

Adding a Fixes-tag pointing to that initial commit, makes it clear that
bug has indeed been tracked as far back as reasonable. Omission of a
Fixes-tag could on the other hand be due to the submitter not bothering
to track the offending commit, thereby leaving it up to a stable
maintainer to do so (if only just be sure).

Thanks,
Johan