Bug 216784
Summary: | There is "ext4_xattr_block_set" WARNING in v6.1-rc8 guest kernel | ||
---|---|---|---|
Product: | File System | Reporter: | xupengfe (pengfei.xu) |
Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
Status: | NEW --- | ||
Severity: | normal | CC: | tytso |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | v6.1-rc8 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
xupengfe
2022-12-07 08:58:57 UTC
This is a high-level comment since I see you also filed a report via e-mail, and Jan has already responded to the report. (Thanks, Jan!) Are you running your own syzkaller instance or are you using the public syzkaller instance? If this is the public syzkaller, please include a link to the public syzkaller. There are a couple of reasons why this is useful. (a) That way we can add a reported-by link to the syzkaller id, which is something that that the syzkaller maintainers have requested. (b) The public syzkaller has useful information about whether a particular issue shows up on other kernels (including older LTS kernels) which can be useful. (c) The newest syzkaller updates has convenient ways of downloading the the file system involved with syzkaller reproducers, the strace log so it's easier to understand what the heck the reproducer is doing, etc. (d) The syzkaller dashboard now has clickable links in the stack trace which means that so it's much easier to determine what is going on. I suspect it's this one: https://syzkaller.appspot.com/bug?extid=98346927678ac3059c77 Can you confirm? In addition, please consider whether there is more you can do to add value. For example, can you simplify the reproducer, and translate it into C so it's more obvious what's going on? In this particular case, the repro.c is fairly straightforward, but there are many times when it is not so simple to understand what is going on, and the programatic minimalization of the reproducer is not ideal. In the ideal case, you'd actually identify the root cause and propose a patch, not just throw it to the upstream maintainers to look at. (This is especially true if this came from the public syzkaller instance, since we get e-mail notifications for them already.) Finally, I'd suggest that providing a pre-compiled reproducer in the git repo is not a great way to add value, since it's a security issue (we don't want to encourage people to use random binaries downloaded from the web) and it's not all that hard to compile the C reproducer in any case. It also bloats the git repo, which is not a great thing in the long term, if people decide it's easier to browse the files by cloning the repro. (Although in this case, if you had provided a link to the public Syzkaller dashboard, that would arguably be easier for those artifacts already provided by Syzkaller.) Thanks! |