Hi all,
Following Dave Chinner's rant:
On Mon, Aug 22, 2016 at 02:21:08PM +1000, Dave Chinner wrote:
> AFAICT, stable kernel maintainers are not watching what happens with
> other stable kernels, nor are they talking to other stable kernel
> maintainers. I should not have to tell every single stable kernel
> maintainer that a specific patch needs to be changed after it's
> already been reported broken, triaged and fixed in other stable
> kernels. You've all got a record that the patch needs to be included
> in a stable kernel, but nobody is seems to notice when it comes to
> fixing problems with a stable patch even when that all happens on
> stable@xxxxxxxxxxxxxxx.
I've decided to automate the bits I had for tracking stable mailing list discussion and wrap it into the git notes interface to make it easy for stable maintainers to track discussions related to stable commits.
Dave has a very valid point: we don't actually investigate the history and correctness for patches that look sane as much as we should. The volume of commits is so big that we might miss comments given by reviewers that we should consider as well.
So now it's possible to see mailing list discussions as part of the 'git log [upstream commit id]' interface:
"""
$ git log 7bc9491645118c9461bd21099c31755ff6783593
commit 7bc9491645118c9461bd21099c31755ff6783593
Author: Vegard Nossum <vegard.nossum@xxxxxxxxxx>
Date: Fri Jul 15 00:22:07 2016 -0400
ext4: verify extent header depth
Although the extent tree depth of 5 should enough be for the worst
case of 2*32 extents of length 1, the extent tree code does not
currently to merge nodes which are less than half-full with a sibling
node, or to shrink the tree depth if possible. So it's possible, at
least in theory, for the tree depth to be greater than 5. However,
even in the worst case, a tree depth of 32 is highly unlikely, and if
the file system is maliciously corrupted, an insanely large eh_depth
can cause memory allocation failures that will trigger kernel warnings
(here, eh_depth = 65280):
JBD2: ext4.exe wants too many credits credits:195849 rsv_credits:0 max
------------[ cut here ]------------
WARNING: CPU: 0 PID: 50 at fs/jbd2/transaction.c:293 start_this_handle
CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ #508
Stack:
604a8947 625badd8 0002fd09 00000000
60078643 00000000 62623910 601bf9bc
62623970 6002fc84 626239b0 900000125
Call Trace:
[<6001c2dc>] show_stack+0xdc/0x1a0
[<601bf9bc>] dump_stack+0x2a/0x2e
[<6002fc84>] __warn+0x114/0x140
[<6002fdff>] warn_slowpath_null+0x1f/0x30
[<60165829>] start_this_handle+0x569/0x580
[<60165d4e>] jbd2__journal_start+0x11e/0x220
[<60146690>] __ext4_journal_start_sb+0x60/0xa0
[<60120a81>] ext4_truncate+0x131/0x3a0
[<60123677>] ext4_setattr+0x757/0x840
[<600d5d0f>] notify_change+0x16f/0x2a0
[<600b2b16>] do_truncate+0x76/0xc0
[<600c3e56>] path_openat+0x806/0x1300
[<600c55c9>] do_filp_open+0x89/0xf0
[<600b4074>] do_sys_open+0x134/0x1e0
[<600b4140>] SyS_open+0x20/0x30
[<6001ea68>] handle_syscall+0x88/0x90
[<600295fd>] userspace+0x3fd/0x500
[<6001ac55>] fork_handler+0x85/0x90
---[ end trace 08b0b88b6387a244 ]---
[ Commit message modified and the extent tree depath check changed
from 5 to 32 -- tytso ]
Cc: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
Signed-off-by: Vegard Nossum <vegard.nossum@xxxxxxxxxx>
Signed-off-by: Theodore Ts'o <tytso@xxxxxxx>
Notes (stable):
On Sun, Jul 31, 2016 at 12:37:27AM -0400, Theodore Ts'o wrote:
> On Sat, Jul 30, 2016 at 09:25:15PM +0200, Vegard Nossum wrote:
> >
> > It seems that most of them are indeed tagged for stable; for the patch
> > I submitted or reported for, it looks like the only one without a stab
> > tag is a warning about large memory allocations -- commit
> > 7bc9491645118c9461bd21099c31755ff6783593.
>
> ... and that's an oversight. Commit 7bc949164511 ("ext4: verify
> extent header depth") should have been marked for stable. I've added
> stable@xxxxxxxxxxxxxxx to the cc. Could you please it to the stable
> kernels? Many thanks!!
Now queued up, thanks.
greg k-h
"""
This means that any reviews/comments/complaints provided about a patch anywhere should appear inside all stable maintainers 'git log' output, making it very hard to miss it. Hopefully solving Dave's (and various others) concerns with collaboration between stable kernel maintainers.
Using it is simple. First add my stable tree as remote:
git remote add sasha-stable git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git
Now fetch the notes:
git fetch sasha-stable refs/notes/stable:refs/notes/stable
I've named the notes ref 'stable' so it won't conflict with existing notes, so we need to mark it as a notes ref. Either using git config:
git config core.notesref refs/notes/stable
Or env variable:
export GIT_NOTES_REF=refs/notes/stable
To verify it works, try looking at the original commit that Dave's rant was all about and make sure you see the mailing list correspondence:
git log b1438f477934f5a4d5a44df26f3079a7575d5946
Updating is just a matter of fetching again. I'll make sure to push updates on a daily basis.
--
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