On Wed, Jan 20, 2016 at 08:47:29AM -0800, James Bottomley wrote: > On Wed, 2016-01-20 at 11:40 -0500, Martin K. Petersen wrote: > > > > > > > "James" == James Bottomley < > > > > > > > James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > > > > James> We should mark the commit causing the problems, which went > > into > > James> 4.4 if I remember correctly: > > > > James> Fixes: ca369d51b3e1649be4a72addd6d6a168cfb3f537 Cc: > > James> stable@xxxxxxxxxxxxxxx # 4.4+ Reviewed-by: James E.J. > > Bottomley > > James> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > > > > I'll add the tags. The reason I didn't explicitly put 4.4+ is that > > the original commit has made its way quite far in various stable > > trees by now. > > It has? It wasn't tagged for stable. However, if it got applied to > stable trees, then we should certainly backport further. I sort of > hope the stable process uses the Fixes: tag to decide when to backport > anyway, since the stable commit contains the original upstream sha256, > they can certainly identify it. > > Greg, are we OK not to bother with qualifying the cc: stable tag if we > have a Fixes tag, or do you still want to see both? Perhaps an > addition to stable_kernel_rules.txt mentioning Fixes: might be useful > as well. I want to see a stable tag if you know it is relevant. I do, when I have the time, dig through the fixes: tags to see if they should also be applied, but I don't always guarantee that I will get to them at all, so don't count on that as a way to get a patch into a stable release. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
