On 06/03/2016 08:02 PM, Dave Chinner wrote: > On Fri, Jun 03, 2016 at 07:10:26PM -0400, Sasha Levin wrote: >> On 06/03/2016 07:05 PM, Dave Chinner wrote: >>> On Fri, Jun 03, 2016 at 05:35:03PM -0400, Sasha Levin wrote: >>>>> From: Dave Chinner <dchinner@xxxxxxxxxx> >>>>> >>>>> This patch has been added to the 4.1 stable tree. If you have any >>>>> objections, please let us know. >>> This should not go to the 4.1 tree. Check the stable notification >>> information, please: >>> >>>>> =============== >>>>> >>>>> [ Upstream commit ad747e3b299671e1a53db74963cc6c5f6cdb9f6d ] >>> .... >>>>> cc: <stable@xxxxxxxxxxxxxxx> # 4.4-4.5 >>> It says 4.4 and 4.5 only. >> >> That's correct, but the commit that this patch fixes was: >> >> commit 96f859d52bcb1c6ea6f3388d39862bf7143e2f30 >> Author: Darrick J. Wong <darrick.wong@xxxxxxxxxx> >> Date: Mon Jan 4 16:13:21 2016 +1100 >> >> libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct > .... >> >> cc: <stable@xxxxxxxxxxxxxxx> # 3.10 - 4.4 >> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> >> Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> >> Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx> >> >> Which, as you see, was marked for and backported to -stable versions >> prior to 4.4, which is why I've preferred to queue this commit even though >> it's not supposed to go in and see if anyone objects. > > Ugh, which means that you're going to have another major tranche of > fixes to backport once I fix the problem properly and handle the > problems automatically. The stable patxh for 4.4-4.5 was really just > meant as a stop-gap measure (i.e. prevent the reported vector) > while we fixed the problem once and for all. That means you're > looking at a another set of patches in the hundreds of lines needing > to be backported to the stable kernels. This doesn't sound like stable material though, for stable it should be trivially correct (and <100 LOC), which isn't the case here. > I get rather concerned about the stable kernel process when this > starts happening - no-one I know of on the XFS side does any testing > on *any* of the stable kernel releases, and now we're in the > dangerous territory of layered on-disk format fixes being backported > by developers without any specific XFS expertise and there's no > real safety net.... > > Maybe I'm being overly paranoid, but this *scares me*. The chance of > something going wrong and lots of users having problems is much > higher than I'm comfortable with.... I agree. This isn't true only for XFS and these cases where backports are less than trivial either because the code is complex, or because the commit dependency chain makes the combination tricky probably happen more often than they should. Maybe we need to put our foot down more often and not take anything that is not a strictly trivial fix? Thanks, Sasha -- 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