Re: kernel BUG at fs/inode.c:LINE! (2)
On Fri, Aug 28, 2020 at 06:54:13PM +0100, Al Viro wrote:
> On Fri, Aug 28, 2020 at 04:38:25PM +0100, Al Viro wrote:
> > On Fri, Aug 28, 2020 at 06:18:17AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:d012a719 Linux 5.9-rc2
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=15aa650e90
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=c92c93d1f1cdb9db
> > > compiler: clang version 10.0.0
> > > (https://github.com/llvm/llvm-project/
> > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12ecb93990
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=140a19a990
> >
> > Trying to reproduce...
>
> OK, I think I see what's going on. ep_loop_check_proc() runs into an already
> doomed file that has already committed to getting killed (->f_count is already
> at 0), but still hadn't gotten through its epitems removal (e.g. has its
> eventpoll_release_file() sitting there trying to get epmutex).
>
> Blindly bumping refcount here is worse than useless. Try this, to verify that
> this is what's going on; it's _not_ a proper fix, but it should at least tell
> if we have something else going on.
... and what I think is the right way to fix the original race is (on top of
mainline) this:
[PATCH] Use list_empty_careful() in eventpoll_release()
... to avoid races with list_del_init() in clear_tfile_check_list().
Get rid of pinning files on check list in eventpoll.c - it's not needed
there.
Signed-off-by: Al Viro
---
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index e0decff22ae2..39eae45bff18 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1995,7 +1995,6 @@ static int ep_loop_check_proc(void *priv, void *cookie,
int call_nests)
* during ep_insert().
*/
if (list_empty(>ffd.file->f_tfile_llink)) {
- get_file(epi->ffd.file);
list_add(>ffd.file->f_tfile_llink,
_check_list);
}
@@ -2042,7 +2041,6 @@ static void clear_tfile_check_list(void)
file = list_first_entry(_check_list, struct file,
f_tfile_llink);
list_del_init(>f_tfile_llink);
- fput(file);
}
INIT_LIST_HEAD(_check_list);
}
@@ -2206,7 +2204,6 @@ int do_epoll_ctl(int epfd, int op, int fd, struct
epoll_event *epds,
if (ep_loop_check(ep, tf.file) != 0)
goto error_tgt_fput;
} else {
- get_file(tf.file);
list_add(>f_tfile_llink,
_check_list);
}
diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
index 8f000fada5a4..e2bdefd90cf8 100644
--- a/include/linux/eventpoll.h
+++ b/include/linux/eventpoll.h
@@ -46,11 +46,9 @@ static inline void eventpoll_release(struct file *file)
* Fast check to avoid the get/release of the semaphore. Since
* we're doing this outside the semaphore lock, it might return
* false negatives, but we don't care. It'll help in 99.99% of cases
-* to avoid the semaphore lock. False positives simply cannot happen
-* because the file in on the way to be removed and nobody ( but
-* eventpoll ) has still a reference to this file.
+* to avoid the semaphore lock.
*/
- if (likely(list_empty(>f_ep_links)))
+ if (likely(list_empty_careful(>f_ep_links)))
return;
/*
Re: kernel BUG at fs/inode.c:LINE! (2)
On Fri, Aug 28, 2020 at 04:38:25PM +0100, Al Viro wrote:
> On Fri, Aug 28, 2020 at 06:18:17AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:d012a719 Linux 5.9-rc2
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15aa650e90
> > kernel config: https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650
> > dashboard link: https://syzkaller.appspot.com/bug?extid=c92c93d1f1cdb9db
> > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/
> > c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12ecb93990
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=140a19a990
>
> Trying to reproduce...
OK, I think I see what's going on. ep_loop_check_proc() runs into an already
doomed file that has already committed to getting killed (->f_count is already
at 0), but still hadn't gotten through its epitems removal (e.g. has its
eventpoll_release_file() sitting there trying to get epmutex).
Blindly bumping refcount here is worse than useless. Try this, to verify that
this is what's going on; it's _not_ a proper fix, but it should at least tell
if we have something else going on.
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index e0decff22ae2..4590223b2de9 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1995,7 +1995,7 @@ static int ep_loop_check_proc(void *priv, void *cookie,
int call_nests)
* during ep_insert().
*/
if (list_empty(>ffd.file->f_tfile_llink)) {
- get_file(epi->ffd.file);
+ if (get_file_rcu(epi->ffd.file))
list_add(>ffd.file->f_tfile_llink,
_check_list);
}
Re: kernel BUG at fs/inode.c:LINE! (2)
On Fri, Aug 28, 2020 at 06:18:17AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:d012a719 Linux 5.9-rc2 > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15aa650e90 > kernel config: https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650 > dashboard link: https://syzkaller.appspot.com/bug?extid=c92c93d1f1cdb9db > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12ecb93990 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=140a19a990 Trying to reproduce...
kernel BUG at fs/inode.c:LINE! (2)
Hello,
syzbot found the following issue on:
HEAD commit:d012a719 Linux 5.9-rc2
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15aa650e90
kernel config: https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650
dashboard link: https://syzkaller.appspot.com/bug?extid=c92c93d1f1cdb9db
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12ecb93990
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=140a19a990
The issue was bisected to:
commit a9ed4a6560b8562b7e2e2bed9527e88001f7b682
Author: Marc Zyngier
Date: Wed Aug 19 16:12:17 2020 +
epoll: Keep a reference on files added to the check list
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16a5051990
final oops: https://syzkaller.appspot.com/x/report.txt?x=15a5051990
console output: https://syzkaller.appspot.com/x/log.txt?x=11a5051990
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c92c93d1f1cdb...@syzkaller.appspotmail.com
Fixes: a9ed4a6560b8 ("epoll: Keep a reference on files added to the check list")
[ cut here ]
kernel BUG at fs/inode.c:1668!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 29571 Comm: syz-executor709 Not tainted 5.9.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:iput+0x6d8/0x6e0 fs/inode.c:1668
Code: ef ff e9 1a fc ff ff 44 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c c8 fe ff ff
4c 89 ef e8 a2 51 ef ff e9 bb fe ff ff e8 68 77 af ff <0f> 0b 66 0f 1f 44 00 00
55 41 57 41 56 53 48 89 f5 48 89 fb 49 bf
RSP: 0018:c9000e25fda8 EFLAGS: 00010293
RAX: 81c580b8 RBX: 888085112600 RCX: 8880a6eea200
RDX: RSI: 0040 RDI:
RBP: 0040 R08: 81c57a40 R09: ed10116fe44d
R10: ed10116fe44d R11: R12: 111010a224ac
R13: dc00 R14: 888085112600 R15: 888085112560
FS: 01665880() GS:8880ae80() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2000 CR3: 8f752000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
__sock_release net/socket.c:608 [inline]
sock_close+0x1c3/0x260 net/socket.c:1277
__fput+0x34f/0x7b0 fs/file_table.c:281
task_work_run+0x137/0x1c0 kernel/task_work.c:141
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_user_mode_loop kernel/entry/common.c:140 [inline]
exit_to_user_mode_prepare+0xfa/0x1b0 kernel/entry/common.c:167
syscall_exit_to_user_mode+0x5e/0x1a0 kernel/entry/common.c:242
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4058e1
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 19 00 00 c3 48 83
ec 08 e8 6a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8
b3 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:7ffc7ca575a0 EFLAGS: 0293 ORIG_RAX: 0003
RAX: RBX: 0006 RCX: 004058e1
RDX: RSI: RDI: 0005
RBP: 0007 R08: 000120080522 R09: 000120080522
R10: 000120080522 R11: 0293 R12: 006dbc5c
R13: 0001 R14: 006dbc50 R15: 0064
Modules linked in:
---[ end trace 35240c511479d576 ]---
RIP: 0010:iput+0x6d8/0x6e0 fs/inode.c:1668
Code: ef ff e9 1a fc ff ff 44 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c c8 fe ff ff
4c 89 ef e8 a2 51 ef ff e9 bb fe ff ff e8 68 77 af ff <0f> 0b 66 0f 1f 44 00 00
55 41 57 41 56 53 48 89 f5 48 89 fb 49 bf
RSP: 0018:c9000e25fda8 EFLAGS: 00010293
RAX: 81c580b8 RBX: 888085112600 RCX: 8880a6eea200
RDX: RSI: 0040 RDI:
RBP: 0040 R08: 81c57a40 R09: ed10116fe44d
R10: ed10116fe44d R11: R12: 111010a224ac
R13: dc00 R14: 888085112600 R15: 888085112560
FS: 01665880() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2000 CR3: 8f752000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for
Re: kernel BUG at fs/inode.c:LINE!
Hi Dmitry, On Fri, Apr 12, 2019 at 01:04:27PM +0200, 'Dmitry Vyukov' via syzkaller-bugs wrote: > On Thu, Apr 11, 2019 at 4:23 AM Al Viro wrote: > > > > On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent wrote: > > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro wrote: > > > > > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > > > seeking clarification on what linux-next to look at for the > > > > > > > sake of accuracy. > > > > > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > > > or one of the daily branches one would use to check for conflicts > > > > > > > before posting? > > > > > > > > > > > > Sorry those are tags not branches. > > > > > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > > > and master is rebased every day. Can it be reproduced with the > > > > > current > > > > > tree? > > > > > > > > From the info on the dashboard we know that it happened only once on > > > > d14b746c (the second one is result of reproducing the first one). So > > > > it was either fixed or just hard to trigger. > > > > > > Looking at the source of tag next-20181214 in linux-next-history I see > > > this is mistake I made due to incorrect error handling which I fixed > > > soon after (there was in fact a double iput()). > > > > Right - "autofs: fix possible inode leak in autofs_fill_super()" had been > > broken (and completely pointless), leading to double iput() in that failure > > case. And yes, double iput() can trigger that BUG_ON(), and with non-zero > > odds do so with that stack trace. > > > > As far as I'm concerned, case closed - bug had been in a misguided "fix" > > for inexistent leak (coming from misreading the calling conventions for > > d_make_root()), introduced in -next at next-20181130 and kicked out of > > there in next-20181219. Dropped by Ian's request in > > Message-ID: <66d497c00cffb3e4109ca0d5287c8277954d7132.ca...@themaw.net> > > which has fixed that crap. Moreover, that posting had been in reply to > > that very syzcaller report, AFAICS. > > > > I don't know how to tell the bot to STFU and close the report in this > > situation; up to you, folks. > > > Please see the following for this: > > > syzbot will keep track of this bug report. See: > > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > > syzbot. > > There are just 3 operations: mark as fixed by a commit, mark as > invalid, mark as duplicate. > I won't be always around. Tracking statuses of bug reports is in the > interests of kernel quality. > As I suggested before, syzbot should automatically invalidate old bug reports, especially on linux-next, that are unlikely to still be real problems. And, syzbot should send remainders about bugs that are still occurring. Instead, currently developers have to waste time debugging bugs caused by patches that were in linux-next for a few days/weeks and then dropped months ago, and have to argue with you every time about how to tell syzbot to close the bug when it never made it into git history. And meanwhile, no one is looking into the bugs that are being hit on mainline every hour or even every 10 minutes for the past year. That's not a great strategy to actually get bugs fixed. - Eric
Re: kernel BUG at fs/inode.c:LINE!
On Fri, Apr 12, 2019 at 12:59:30PM +0200, Dmitry Vyukov wrote: > Please don't ignore the bug status tracking part. Or we will only have > options of not testing kernel or dropping most of the bug reports on > the floor. Both are equally harmful for kernel quality. > > Let's mark it as fixed by the next commit in series (which already > made it into mainline): > > #syz fix: autofs: simplify parse_options() function call > > But I won't be around always. You might want to add something like "commit discarded"...
Re: kernel BUG at fs/inode.c:LINE!
On Thu, Apr 11, 2019 at 4:23 AM Al Viro wrote: > > On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent wrote: > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro wrote: > > > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > > seeking clarification on what linux-next to look at for the > > > > > > sake of accuracy. > > > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > > or one of the daily branches one would use to check for conflicts > > > > > > before posting? > > > > > > > > > > Sorry those are tags not branches. > > > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > > and master is rebased every day. Can it be reproduced with the current > > > > tree? > > > > > > From the info on the dashboard we know that it happened only once on > > > d14b746c (the second one is result of reproducing the first one). So > > > it was either fixed or just hard to trigger. > > > > Looking at the source of tag next-20181214 in linux-next-history I see > > this is mistake I made due to incorrect error handling which I fixed > > soon after (there was in fact a double iput()). > > Right - "autofs: fix possible inode leak in autofs_fill_super()" had been > broken (and completely pointless), leading to double iput() in that failure > case. And yes, double iput() can trigger that BUG_ON(), and with non-zero > odds do so with that stack trace. > > As far as I'm concerned, case closed - bug had been in a misguided "fix" > for inexistent leak (coming from misreading the calling conventions for > d_make_root()), introduced in -next at next-20181130 and kicked out of > there in next-20181219. Dropped by Ian's request in > Message-ID: <66d497c00cffb3e4109ca0d5287c8277954d7132.ca...@themaw.net> > which has fixed that crap. Moreover, that posting had been in reply to > that very syzcaller report, AFAICS. > > I don't know how to tell the bot to STFU and close the report in this > situation; up to you, folks. Please see the following for this: > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. There are just 3 operations: mark as fixed by a commit, mark as invalid, mark as duplicate. I won't be always around. Tracking statuses of bug reports is in the interests of kernel quality. > As an aside, the cause of that bug is that d_make_root() calling conventions > are insufficiently documented. All we have is > > ||[mandatory] > ||d_alloc_root() is gone, along with a lot of bugs caused by code > ||misusing it. Replacement: d_make_root(inode). The difference is, > ||d_make_root() drops the reference to inode if dentry allocation fails. > > in Documentation/filesystems/porting, and that's not good enough. Anyone > willing to take a shot at that? FWIW, the calling conventions are: > > d_make_root(inode) normally allocates and returns a new dentry. > On failure NULL is returned. A reference to inode is consumed in all > cases (on success it is transferred to new dentry, on failure it is > dropped), so failure handling does not need anything done to inode. > d_make_root(NULL) quietly returns NULL, which further simplifies the > error handling in typical caller. Usually it's something like > inode = foofs_new_inode(); > s->s_root = d_make_inode(inode); > if (!s->s_root) > bugger off, no need to undo inode allocation > success > We do not need to check if foofs_new_inode() has returned NULL and we > do not need any special cleanups in case of failure - not for the > undoing the inode allocation. > > If anyone cares to convert that into coherent (and printable) documentation, > patches are welcome...
Re: kernel BUG at fs/inode.c:LINE!
On Thu, Apr 11, 2019 at 2:50 AM Ian Kent wrote: > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro wrote: > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > seeking clarification on what linux-next to look at for the > > > > > sake of accuracy. > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > or one of the daily branches one would use to check for conflicts > > > > > before posting? > > > > > > > > Sorry those are tags not branches. > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > and master is rebased every day. Can it be reproduced with the current > > > tree? > > > > From the info on the dashboard we know that it happened only once on > > d14b746c (the second one is result of reproducing the first one). So > > it was either fixed or just hard to trigger. > > Looking at the source of tag next-20181214 in linux-next-history I see > this is mistake I made due to incorrect error handling which I fixed > soon after (there was in fact a double iput()). > > I'm pretty sure this never made it to a released kernel so unless > there's a report of this in a stable released kernel I'm going to > move on. Please don't ignore the bug status tracking part. Or we will only have options of not testing kernel or dropping most of the bug reports on the floor. Both are equally harmful for kernel quality. Let's mark it as fixed by the next commit in series (which already made it into mainline): #syz fix: autofs: simplify parse_options() function call But I won't be around always.
Re: kernel BUG at fs/inode.c:LINE!
On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent wrote: > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro wrote: > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > seeking clarification on what linux-next to look at for the > > > > > sake of accuracy. > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > or one of the daily branches one would use to check for conflicts > > > > > before posting? > > > > > > > > Sorry those are tags not branches. > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > and master is rebased every day. Can it be reproduced with the current > > > tree? > > > > From the info on the dashboard we know that it happened only once on > > d14b746c (the second one is result of reproducing the first one). So > > it was either fixed or just hard to trigger. > > Looking at the source of tag next-20181214 in linux-next-history I see > this is mistake I made due to incorrect error handling which I fixed > soon after (there was in fact a double iput()). Right - "autofs: fix possible inode leak in autofs_fill_super()" had been broken (and completely pointless), leading to double iput() in that failure case. And yes, double iput() can trigger that BUG_ON(), and with non-zero odds do so with that stack trace. As far as I'm concerned, case closed - bug had been in a misguided "fix" for inexistent leak (coming from misreading the calling conventions for d_make_root()), introduced in -next at next-20181130 and kicked out of there in next-20181219. Dropped by Ian's request in Message-ID: <66d497c00cffb3e4109ca0d5287c8277954d7132.ca...@themaw.net> which has fixed that crap. Moreover, that posting had been in reply to that very syzcaller report, AFAICS. I don't know how to tell the bot to STFU and close the report in this situation; up to you, folks. As an aside, the cause of that bug is that d_make_root() calling conventions are insufficiently documented. All we have is ||[mandatory] ||d_alloc_root() is gone, along with a lot of bugs caused by code ||misusing it. Replacement: d_make_root(inode). The difference is, ||d_make_root() drops the reference to inode if dentry allocation fails. in Documentation/filesystems/porting, and that's not good enough. Anyone willing to take a shot at that? FWIW, the calling conventions are: d_make_root(inode) normally allocates and returns a new dentry. On failure NULL is returned. A reference to inode is consumed in all cases (on success it is transferred to new dentry, on failure it is dropped), so failure handling does not need anything done to inode. d_make_root(NULL) quietly returns NULL, which further simplifies the error handling in typical caller. Usually it's something like inode = foofs_new_inode(); s->s_root = d_make_inode(inode); if (!s->s_root) bugger off, no need to undo inode allocation success We do not need to check if foofs_new_inode() has returned NULL and we do not need any special cleanups in case of failure - not for the undoing the inode allocation. If anyone cares to convert that into coherent (and printable) documentation, patches are welcome...
Re: kernel BUG at fs/inode.c:LINE!
On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > On Wed, Apr 10, 2019 at 2:12 PM Al Viro wrote: > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > seeking clarification on what linux-next to look at for the > > > > sake of accuracy. > > > > > > > > So I'm wondering if this testing done using the master branch > > > > or one of the daily branches one would use to check for conflicts > > > > before posting? > > > > > > Sorry those are tags not branches. > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > and master is rebased every day. Can it be reproduced with the current > > tree? > > From the info on the dashboard we know that it happened only once on > d14b746c (the second one is result of reproducing the first one). So > it was either fixed or just hard to trigger. Looking at the source of tag next-20181214 in linux-next-history I see this is mistake I made due to incorrect error handling which I fixed soon after (there was in fact a double iput()). I'm pretty sure this never made it to a released kernel so unless there's a report of this in a stable released kernel I'm going to move on. Thanks Ian
Re: kernel BUG at fs/inode.c:LINE!
On Wed, Apr 10, 2019 at 2:12 PM Al Viro wrote: > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > I'm unable to find a branch matching the line numbers. > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > seeking clarification on what linux-next to look at for the > > > sake of accuracy. > > > > > > So I'm wondering if this testing done using the master branch > > > or one of the daily branches one would use to check for conflicts > > > before posting? > > > > Sorry those are tags not branches. > > FWIW, that's next-20181214; it is what master had been in mid-December > and master is rebased every day. Can it be reproduced with the current > tree? >From the info on the dashboard we know that it happened only once on d14b746c (the second one is result of reproducing the first one). So it was either fixed or just hard to trigger.
Re: kernel BUG at fs/inode.c:LINE!
On Wed, Apr 10, 2019 at 2:07 PM Ian Kent wrote:
>
> On Wed, 2019-04-10 at 19:57 +0800, Ian Kent wrote:
> > On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote:
> > > On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
> > > >
> > > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > > > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > > > >
> > > > > > [snip the useless pile]
> > > > > >
> > > > > > > bisection log:
> > > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > > > > > > start commit: [unknown
> > > > > > > git tree: linux-next
> > > > > > > dashboard link:
> > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > > > > syz repro:
> > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > > > > > C reproducer:
> > > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > > > > > >
> > > > > > > For information about bisection process see:
> > > > > > > https://goo.gl/tpsmEJ#bisection
> > > > > >
> > > > > > If I'm not misreading the "crash report" there, it has injected an
> > > > > > allocation
> > > > > > failure in dentry allocation in d_make_root() from
> > > > > > autofs_fill_super()
> > > > > > (
> > > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > > > > > root = d_make_root(root_inode);
> > > > > > ) which has triggered iput() on the inode passed to d_make_root()
> > > > > > (as
> > > > > > it
> > > > > > ought
> > > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c,
> > > > > > but
> > > > > > I've
> > > > > > no idea which one it is - line numbers do not match anything in
> > > > > > linux-
> > > > > > next
> > > > > > or in mainline. Reported line 1566 is
> > > > > > if (inode->i_nlink && (inode->i_state &
> > > > > > I_DIRTY_TIME))
> > > > > > {
> > > > > > in all of them; as the matter of fact, the diff in fs/inode.c
> > > > > > between
> > > > > > -next and mainline is empty.
> > > > > >
> > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be
> > > > > > line
> > > > > > 1566,
> > > > > > so _probably_ that's what it is. With that assumption, it's
> > > > > > BUG_ON(inode->i_state & I_CLEAR);
> > > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root()
> > > > > > there. Which
> > > > > > should not happen - the inode must have come from new_inode(), which
> > > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And
> > > > > > I_CLEAR
> > > > > > is set only in clear_inode(). For autofs inodes that can come only
> > > > > > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > > > > > Which should never ever be called for inode with positive
> > > > > > ->i_count...
> > > > > >
> > > > > > It might be memory corruption; it might be a dangling inode pointer
> > > > > > somewhere, it might be something else.
> > > > > >
> > > > > > To get any further we really need a confirmation of the identity of
> > > > > > triggered BUG_ON().
> > > > > >
> > > > > > As an aside, your "sample crash reports" would've been much more
> > > > > > useful
> > > > > > if
> > > > > > they went with commit SHA1 in question, especially when they contain
> > > > > > line
> > > > > > numbers.
> > > > >
> > > > > Hi Al,
> > > > >
> > > > > This is the commit for matching lines:
> > > > >
> > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for
> > > > > > 20181214
> > > >
> > > > Are you sure?
> > > > what does 20181214 mean?
> > >
> > > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit
> > > hash. "Add linux-next specific files for 20181214" is the commit
> > > subject.
> > >
> > >
> > > > Looking at current next code (and several branches) it doesn't
> > > > appear the problem is possible?
> > > >
> > > > > > git tree: linux-next
> > > >
> > > > But which branch is it really, master (which doesn't match the
> > > > line numbers btw)?
> > >
> > > This is d14b746c6c1c commit hash. I don't know if there is a branch
> > > with HEAD pointing to this commit or not, but it seems unimportant.
> > > Tree+commit is the identity of code state.
> > >
> > >
> > > > > fs/inode.c:1566 points to:
> > > > >
> > > > > void iput(struct inode *inode)
> > > > > {
> > > > > ...
> > > > > BUG_ON(inode->i_state & I_CLEAR);
> > > > >
> > > > >
> > > > > The dashboard page provides kernel git repository and commit for each
> > > > > crash.
> > > >
> > > > Those links don't seem to make sense to me ...
> > > >
> > > > Help me out here!
> > >
> > > There is git repo name provided and commit hash. It's meant to be
> > > self-explanatory. What exactly is unclear?
> >
> > I'm unable to find a branch matching the line numbers.
> >
> > Given that, on the face of it, the
Re: kernel BUG at fs/inode.c:LINE!
On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > I'm unable to find a branch matching the line numbers. > > > > Given that, on the face of it, the scenario is impossible I'm > > seeking clarification on what linux-next to look at for the > > sake of accuracy. > > > > So I'm wondering if this testing done using the master branch > > or one of the daily branches one would use to check for conflicts > > before posting? > > Sorry those are tags not branches. FWIW, that's next-20181214; it is what master had been in mid-December and master is rebased every day. Can it be reproduced with the current tree?
Re: kernel BUG at fs/inode.c:LINE!
On Wed, 2019-04-10 at 19:57 +0800, Ian Kent wrote:
> On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote:
> > On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
> > >
> > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> > > > >
> > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > > >
> > > > > [snip the useless pile]
> > > > >
> > > > > > bisection log:
> > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > > > > > start commit: [unknown
> > > > > > git tree: linux-next
> > > > > > dashboard link:
> > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > > > syz repro:
> > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > > > > C reproducer:
> > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > > > > >
> > > > > > For information about bisection process see:
> > > > > > https://goo.gl/tpsmEJ#bisection
> > > > >
> > > > > If I'm not misreading the "crash report" there, it has injected an
> > > > > allocation
> > > > > failure in dentry allocation in d_make_root() from autofs_fill_super()
> > > > > (
> > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > > > > root = d_make_root(root_inode);
> > > > > ) which has triggered iput() on the inode passed to d_make_root() (as
> > > > > it
> > > > > ought
> > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but
> > > > > I've
> > > > > no idea which one it is - line numbers do not match anything in linux-
> > > > > next
> > > > > or in mainline. Reported line 1566 is
> > > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME))
> > > > > {
> > > > > in all of them; as the matter of fact, the diff in fs/inode.c between
> > > > > -next and mainline is empty.
> > > > >
> > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be
> > > > > line
> > > > > 1566,
> > > > > so _probably_ that's what it is. With that assumption, it's
> > > > > BUG_ON(inode->i_state & I_CLEAR);
> > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root()
> > > > > there. Which
> > > > > should not happen - the inode must have come from new_inode(), which
> > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
> > > > > is set only in clear_inode(). For autofs inodes that can come only
> > > > > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > > > > Which should never ever be called for inode with positive ->i_count...
> > > > >
> > > > > It might be memory corruption; it might be a dangling inode pointer
> > > > > somewhere, it might be something else.
> > > > >
> > > > > To get any further we really need a confirmation of the identity of
> > > > > triggered BUG_ON().
> > > > >
> > > > > As an aside, your "sample crash reports" would've been much more
> > > > > useful
> > > > > if
> > > > > they went with commit SHA1 in question, especially when they contain
> > > > > line
> > > > > numbers.
> > > >
> > > > Hi Al,
> > > >
> > > > This is the commit for matching lines:
> > > >
> > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for
> > > > > 20181214
> > >
> > > Are you sure?
> > > what does 20181214 mean?
> >
> > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit
> > hash. "Add linux-next specific files for 20181214" is the commit
> > subject.
> >
> >
> > > Looking at current next code (and several branches) it doesn't
> > > appear the problem is possible?
> > >
> > > > > git tree: linux-next
> > >
> > > But which branch is it really, master (which doesn't match the
> > > line numbers btw)?
> >
> > This is d14b746c6c1c commit hash. I don't know if there is a branch
> > with HEAD pointing to this commit or not, but it seems unimportant.
> > Tree+commit is the identity of code state.
> >
> >
> > > > fs/inode.c:1566 points to:
> > > >
> > > > void iput(struct inode *inode)
> > > > {
> > > > ...
> > > > BUG_ON(inode->i_state & I_CLEAR);
> > > >
> > > >
> > > > The dashboard page provides kernel git repository and commit for each
> > > > crash.
> > >
> > > Those links don't seem to make sense to me ...
> > >
> > > Help me out here!
> >
> > There is git repo name provided and commit hash. It's meant to be
> > self-explanatory. What exactly is unclear?
>
> I'm unable to find a branch matching the line numbers.
>
> Given that, on the face of it, the scenario is impossible I'm
> seeking clarification on what linux-next to look at for the
> sake of accuracy.
>
> So I'm wondering if this testing done using the master branch
> or one of the daily branches one would use to check for conflicts
> before posting?
Sorry those are tags not branches.
On a newly updated linux-next I get:
[raven@pluto linux-next.git]$
Re: kernel BUG at fs/inode.c:LINE!
On Wed, Apr 10, 2019 at 2:02 PM Dmitry Vyukov wrote:
>
> On Wed, Apr 10, 2019 at 1:57 PM Ian Kent wrote:
> > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > > > >
> > > > > > [snip the useless pile]
> > > > > >
> > > > > > > bisection log:
> > > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > > > > > > start commit: [unknown
> > > > > > > git tree: linux-next
> > > > > > > dashboard link:
> > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > > > > syz repro:
> > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > > > > > C reproducer:
> > > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > > > > > >
> > > > > > > For information about bisection process see:
> > > > > > > https://goo.gl/tpsmEJ#bisection
> > > > > >
> > > > > > If I'm not misreading the "crash report" there, it has injected an
> > > > > > allocation
> > > > > > failure in dentry allocation in d_make_root() from
> > > > > > autofs_fill_super() (
> > > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > > > > > root = d_make_root(root_inode);
> > > > > > ) which has triggered iput() on the inode passed to d_make_root()
> > > > > > (as it
> > > > > > ought
> > > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c,
> > > > > > but
> > > > > > I've
> > > > > > no idea which one it is - line numbers do not match anything in
> > > > > > linux-
> > > > > > next
> > > > > > or in mainline. Reported line 1566 is
> > > > > > if (inode->i_nlink && (inode->i_state &
> > > > > > I_DIRTY_TIME)) {
> > > > > > in all of them; as the matter of fact, the diff in fs/inode.c
> > > > > > between
> > > > > > -next and mainline is empty.
> > > > > >
> > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be
> > > > > > line
> > > > > > 1566,
> > > > > > so _probably_ that's what it is. With that assumption, it's
> > > > > > BUG_ON(inode->i_state & I_CLEAR);
> > > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there.
> > > > > > Which
> > > > > > should not happen - the inode must have come from new_inode(), which
> > > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And
> > > > > > I_CLEAR
> > > > > > is set only in clear_inode(). For autofs inodes that can come only
> > > > > > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > > > > > Which should never ever be called for inode with positive
> > > > > > ->i_count...
> > > > > >
> > > > > > It might be memory corruption; it might be a dangling inode pointer
> > > > > > somewhere, it might be something else.
> > > > > >
> > > > > > To get any further we really need a confirmation of the identity of
> > > > > > triggered BUG_ON().
> > > > > >
> > > > > > As an aside, your "sample crash reports" would've been much more
> > > > > > useful
> > > > > > if
> > > > > > they went with commit SHA1 in question, especially when they contain
> > > > > > line
> > > > > > numbers.
> > > > >
> > > > > Hi Al,
> > > > >
> > > > > This is the commit for matching lines:
> > > > >
> > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for
> > > > > > 20181214
> > > >
> > > > Are you sure?
> > > > what does 20181214 mean?
> > >
> > > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit
> > > hash. "Add linux-next specific files for 20181214" is the commit
> > > subject.
> > >
> > >
> > > > Looking at current next code (and several branches) it doesn't
> > > > appear the problem is possible?
> > > >
> > > > > > git tree: linux-next
> > > >
> > > > But which branch is it really, master (which doesn't match the
> > > > line numbers btw)?
> > >
> > > This is d14b746c6c1c commit hash. I don't know if there is a branch
> > > with HEAD pointing to this commit or not, but it seems unimportant.
> > > Tree+commit is the identity of code state.
> > >
> > >
> > > > > fs/inode.c:1566 points to:
> > > > >
> > > > > void iput(struct inode *inode)
> > > > > {
> > > > > ...
> > > > > BUG_ON(inode->i_state & I_CLEAR);
> > > > >
> > > > >
> > > > > The dashboard page provides kernel git repository and commit for each
> > > > > crash.
> > > >
> > > > Those links don't seem to make sense to me ...
> > > >
> > > > Help me out here!
> > >
> > > There is git repo name provided and commit hash. It's meant to be
> > > self-explanatory. What exactly is unclear?
> >
> > I'm unable to find a branch matching the line numbers.
> >
> > Given that, on the face of it, the scenario is impossible I'm
> > seeking clarification on what linux-next to look at for the
> > sake of accuracy.
> >
> > So I'm wondering if this testing done using the master branch
> > or one of the daily branches one would use to check for conflicts
> > before posting?
> >
> > Or perhaps the
Re: kernel BUG at fs/inode.c:LINE!
On Wed, Apr 10, 2019 at 1:57 PM Ian Kent wrote:
> > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > > >
> > > > > [snip the useless pile]
> > > > >
> > > > > > bisection log:
> > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > > > > > start commit: [unknown
> > > > > > git tree: linux-next
> > > > > > dashboard link:
> > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > > > syz repro:
> > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > > > > C reproducer:
> > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > > > > >
> > > > > > For information about bisection process see:
> > > > > > https://goo.gl/tpsmEJ#bisection
> > > > >
> > > > > If I'm not misreading the "crash report" there, it has injected an
> > > > > allocation
> > > > > failure in dentry allocation in d_make_root() from
> > > > > autofs_fill_super() (
> > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > > > > root = d_make_root(root_inode);
> > > > > ) which has triggered iput() on the inode passed to d_make_root() (as
> > > > > it
> > > > > ought
> > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but
> > > > > I've
> > > > > no idea which one it is - line numbers do not match anything in linux-
> > > > > next
> > > > > or in mainline. Reported line 1566 is
> > > > > if (inode->i_nlink && (inode->i_state &
> > > > > I_DIRTY_TIME)) {
> > > > > in all of them; as the matter of fact, the diff in fs/inode.c between
> > > > > -next and mainline is empty.
> > > > >
> > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be
> > > > > line
> > > > > 1566,
> > > > > so _probably_ that's what it is. With that assumption, it's
> > > > > BUG_ON(inode->i_state & I_CLEAR);
> > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there.
> > > > > Which
> > > > > should not happen - the inode must have come from new_inode(), which
> > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
> > > > > is set only in clear_inode(). For autofs inodes that can come only
> > > > > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > > > > Which should never ever be called for inode with positive ->i_count...
> > > > >
> > > > > It might be memory corruption; it might be a dangling inode pointer
> > > > > somewhere, it might be something else.
> > > > >
> > > > > To get any further we really need a confirmation of the identity of
> > > > > triggered BUG_ON().
> > > > >
> > > > > As an aside, your "sample crash reports" would've been much more
> > > > > useful
> > > > > if
> > > > > they went with commit SHA1 in question, especially when they contain
> > > > > line
> > > > > numbers.
> > > >
> > > > Hi Al,
> > > >
> > > > This is the commit for matching lines:
> > > >
> > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for
> > > > > 20181214
> > >
> > > Are you sure?
> > > what does 20181214 mean?
> >
> > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit
> > hash. "Add linux-next specific files for 20181214" is the commit
> > subject.
> >
> >
> > > Looking at current next code (and several branches) it doesn't
> > > appear the problem is possible?
> > >
> > > > > git tree: linux-next
> > >
> > > But which branch is it really, master (which doesn't match the
> > > line numbers btw)?
> >
> > This is d14b746c6c1c commit hash. I don't know if there is a branch
> > with HEAD pointing to this commit or not, but it seems unimportant.
> > Tree+commit is the identity of code state.
> >
> >
> > > > fs/inode.c:1566 points to:
> > > >
> > > > void iput(struct inode *inode)
> > > > {
> > > > ...
> > > > BUG_ON(inode->i_state & I_CLEAR);
> > > >
> > > >
> > > > The dashboard page provides kernel git repository and commit for each
> > > > crash.
> > >
> > > Those links don't seem to make sense to me ...
> > >
> > > Help me out here!
> >
> > There is git repo name provided and commit hash. It's meant to be
> > self-explanatory. What exactly is unclear?
>
> I'm unable to find a branch matching the line numbers.
>
> Given that, on the face of it, the scenario is impossible I'm
> seeking clarification on what linux-next to look at for the
> sake of accuracy.
>
> So I'm wondering if this testing done using the master branch
> or one of the daily branches one would use to check for conflicts
> before posting?
>
> Or perhaps the master branch has been updated and the testing was
> done on something different.
Ah, I see. syzbot continuously tests the master branch of linux-next.
So d14b746c6c1c was once the HEAD of the master branch.
I somehow have d14b746c6c1c locally, but if you don't have it you may
need to fetch
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git
Re: kernel BUG at fs/inode.c:LINE!
On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
> >
> > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> > > >
> > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > >
> > > > [snip the useless pile]
> > > >
> > > > > bisection log:
> > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > > > > start commit: [unknown
> > > > > git tree: linux-next
> > > > > dashboard link:
> > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > > syz repro:
> > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > > > C reproducer:
> > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > > > >
> > > > > For information about bisection process see:
> > > > > https://goo.gl/tpsmEJ#bisection
> > > >
> > > > If I'm not misreading the "crash report" there, it has injected an
> > > > allocation
> > > > failure in dentry allocation in d_make_root() from autofs_fill_super() (
> > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > > > root = d_make_root(root_inode);
> > > > ) which has triggered iput() on the inode passed to d_make_root() (as it
> > > > ought
> > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but
> > > > I've
> > > > no idea which one it is - line numbers do not match anything in linux-
> > > > next
> > > > or in mainline. Reported line 1566 is
> > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
> > > > in all of them; as the matter of fact, the diff in fs/inode.c between
> > > > -next and mainline is empty.
> > > >
> > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line
> > > > 1566,
> > > > so _probably_ that's what it is. With that assumption, it's
> > > > BUG_ON(inode->i_state & I_CLEAR);
> > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which
> > > > should not happen - the inode must have come from new_inode(), which
> > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
> > > > is set only in clear_inode(). For autofs inodes that can come only
> > > > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > > > Which should never ever be called for inode with positive ->i_count...
> > > >
> > > > It might be memory corruption; it might be a dangling inode pointer
> > > > somewhere, it might be something else.
> > > >
> > > > To get any further we really need a confirmation of the identity of
> > > > triggered BUG_ON().
> > > >
> > > > As an aside, your "sample crash reports" would've been much more useful
> > > > if
> > > > they went with commit SHA1 in question, especially when they contain
> > > > line
> > > > numbers.
> > >
> > > Hi Al,
> > >
> > > This is the commit for matching lines:
> > >
> > > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
> >
> > Are you sure?
> > what does 20181214 mean?
>
> Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit
> hash. "Add linux-next specific files for 20181214" is the commit
> subject.
>
>
> > Looking at current next code (and several branches) it doesn't
> > appear the problem is possible?
> >
> > > > git tree: linux-next
> >
> > But which branch is it really, master (which doesn't match the
> > line numbers btw)?
>
> This is d14b746c6c1c commit hash. I don't know if there is a branch
> with HEAD pointing to this commit or not, but it seems unimportant.
> Tree+commit is the identity of code state.
>
>
> > > fs/inode.c:1566 points to:
> > >
> > > void iput(struct inode *inode)
> > > {
> > > ...
> > > BUG_ON(inode->i_state & I_CLEAR);
> > >
> > >
> > > The dashboard page provides kernel git repository and commit for each
> > > crash.
> >
> > Those links don't seem to make sense to me ...
> >
> > Help me out here!
>
> There is git repo name provided and commit hash. It's meant to be
> self-explanatory. What exactly is unclear?
I'm unable to find a branch matching the line numbers.
Given that, on the face of it, the scenario is impossible I'm
seeking clarification on what linux-next to look at for the
sake of accuracy.
So I'm wondering if this testing done using the master branch
or one of the daily branches one would use to check for conflicts
before posting?
Or perhaps the master branch has been updated and the testing was
done on something different.
Ian
Re: kernel BUG at fs/inode.c:LINE!
On Wed, Apr 10, 2019 at 12:35 PM Ian Kent wrote:
>
> On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> > >
> > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > Bisection is inconclusive: the first bad commit could be any of:
> > >
> > > [snip the useless pile]
> > >
> > > > bisection log:
> > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > > > start commit: [unknown
> > > > git tree: linux-next
> > > > dashboard link:
> > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > syz repro:
> > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > > >
> > > > For information about bisection process see:
> > > > https://goo.gl/tpsmEJ#bisection
> > >
> > > If I'm not misreading the "crash report" there, it has injected an
> > > allocation
> > > failure in dentry allocation in d_make_root() from autofs_fill_super() (
> > > root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > > root = d_make_root(root_inode);
> > > ) which has triggered iput() on the inode passed to d_make_root() (as it
> > > ought
> > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've
> > > no idea which one it is - line numbers do not match anything in linux-next
> > > or in mainline. Reported line 1566 is
> > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
> > > in all of them; as the matter of fact, the diff in fs/inode.c between
> > > -next and mainline is empty.
> > >
> > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line
> > > 1566,
> > > so _probably_ that's what it is. With that assumption, it's
> > > BUG_ON(inode->i_state & I_CLEAR);
> > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which
> > > should not happen - the inode must have come from new_inode(), which
> > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
> > > is set only in clear_inode(). For autofs inodes that can come only
> > > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > > Which should never ever be called for inode with positive ->i_count...
> > >
> > > It might be memory corruption; it might be a dangling inode pointer
> > > somewhere, it might be something else.
> > >
> > > To get any further we really need a confirmation of the identity of
> > > triggered BUG_ON().
> > >
> > > As an aside, your "sample crash reports" would've been much more useful if
> > > they went with commit SHA1 in question, especially when they contain line
> > > numbers.
> >
> > Hi Al,
> >
> > This is the commit for matching lines:
> >
> > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
>
> Are you sure?
> what does 20181214 mean?
Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit
hash. "Add linux-next specific files for 20181214" is the commit
subject.
> Looking at current next code (and several branches) it doesn't
> appear the problem is possible?
>
> > > git tree: linux-next
>
> But which branch is it really, master (which doesn't match the
> line numbers btw)?
This is d14b746c6c1c commit hash. I don't know if there is a branch
with HEAD pointing to this commit or not, but it seems unimportant.
Tree+commit is the identity of code state.
> > fs/inode.c:1566 points to:
> >
> > void iput(struct inode *inode)
> > {
> > ...
> > BUG_ON(inode->i_state & I_CLEAR);
> >
> >
> > The dashboard page provides kernel git repository and commit for each crash.
>
> Those links don't seem to make sense to me ...
>
> Help me out here!
There is git repo name provided and commit hash. It's meant to be
self-explanatory. What exactly is unclear?
Re: kernel BUG at fs/inode.c:LINE!
On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> >
> > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > Bisection is inconclusive: the first bad commit could be any of:
> >
> > [snip the useless pile]
> >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > > start commit: [unknown
> > > git tree: linux-next
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340
> > >
> > > For information about bisection process see:
> > > https://goo.gl/tpsmEJ#bisection
> >
> > If I'm not misreading the "crash report" there, it has injected an
> > allocation
> > failure in dentry allocation in d_make_root() from autofs_fill_super() (
> > root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > root = d_make_root(root_inode);
> > ) which has triggered iput() on the inode passed to d_make_root() (as it
> > ought
> > to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've
> > no idea which one it is - line numbers do not match anything in linux-next
> > or in mainline. Reported line 1566 is
> > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
> > in all of them; as the matter of fact, the diff in fs/inode.c between
> > -next and mainline is empty.
> >
> > There is a BUG_ON() several lines prior, and in 4.20 it used to be line
> > 1566,
> > so _probably_ that's what it is. With that assumption, it's
> > BUG_ON(inode->i_state & I_CLEAR);
> > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which
> > should not happen - the inode must have come from new_inode(), which
> > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
> > is set only in clear_inode(). For autofs inodes that can come only
> > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > Which should never ever be called for inode with positive ->i_count...
> >
> > It might be memory corruption; it might be a dangling inode pointer
> > somewhere, it might be something else.
> >
> > To get any further we really need a confirmation of the identity of
> > triggered BUG_ON().
> >
> > As an aside, your "sample crash reports" would've been much more useful if
> > they went with commit SHA1 in question, especially when they contain line
> > numbers.
>
> Hi Al,
>
> This is the commit for matching lines:
>
> > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
Are you sure?
what does 20181214 mean?
Looking at current next code (and several branches) it doesn't
appear the problem is possible?
> > git tree: linux-next
But which branch is it really, master (which doesn't match the
line numbers btw)?
>
> fs/inode.c:1566 points to:
>
> void iput(struct inode *inode)
> {
> ...
> BUG_ON(inode->i_state & I_CLEAR);
>
>
> The dashboard page provides kernel git repository and commit for each crash.
Those links don't seem to make sense to me ...
Help me out here!
Ian
Re: kernel BUG at fs/inode.c:LINE!
On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
>
> On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > Bisection is inconclusive: the first bad commit could be any of:
>
> [snip the useless pile]
>
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> > start commit: [unknown
> > git tree: linux-next
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> If I'm not misreading the "crash report" there, it has injected an allocation
> failure in dentry allocation in d_make_root() from autofs_fill_super() (
> root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> root = d_make_root(root_inode);
> ) which has triggered iput() on the inode passed to d_make_root() (as it ought
> to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've
> no idea which one it is - line numbers do not match anything in linux-next
> or in mainline. Reported line 1566 is
> if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
> in all of them; as the matter of fact, the diff in fs/inode.c between
> -next and mainline is empty.
>
> There is a BUG_ON() several lines prior, and in 4.20 it used to be line 1566,
> so _probably_ that's what it is. With that assumption, it's
> BUG_ON(inode->i_state & I_CLEAR);
> IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which
> should not happen - the inode must have come from new_inode(), which
> gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
> is set only in clear_inode(). For autofs inodes that can come only
> from autofs_evict_inode(), called as ->evict() from evict_inode().
> Which should never ever be called for inode with positive ->i_count...
>
> It might be memory corruption; it might be a dangling inode pointer
> somewhere, it might be something else.
>
> To get any further we really need a confirmation of the identity of
> triggered BUG_ON().
>
> As an aside, your "sample crash reports" would've been much more useful if
> they went with commit SHA1 in question, especially when they contain line
> numbers.
Hi Al,
This is the commit for matching lines:
> HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
> git tree: linux-next
fs/inode.c:1566 points to:
void iput(struct inode *inode)
{
...
BUG_ON(inode->i_state & I_CLEAR);
The dashboard page provides kernel git repository and commit for each crash.
Re: kernel BUG at fs/inode.c:LINE!
On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> Bisection is inconclusive: the first bad commit could be any of:
[snip the useless pile]
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> start commit: [unknown
> git tree: linux-next
> dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
If I'm not misreading the "crash report" there, it has injected an allocation
failure in dentry allocation in d_make_root() from autofs_fill_super() (
root_inode = autofs_get_inode(s, S_IFDIR | 0755);
root = d_make_root(root_inode);
) which has triggered iput() on the inode passed to d_make_root() (as it ought
to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've
no idea which one it is - line numbers do not match anything in linux-next
or in mainline. Reported line 1566 is
if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
in all of them; as the matter of fact, the diff in fs/inode.c between
-next and mainline is empty.
There is a BUG_ON() several lines prior, and in 4.20 it used to be line 1566,
so _probably_ that's what it is. With that assumption, it's
BUG_ON(inode->i_state & I_CLEAR);
IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which
should not happen - the inode must have come from new_inode(), which
gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
is set only in clear_inode(). For autofs inodes that can come only
from autofs_evict_inode(), called as ->evict() from evict_inode().
Which should never ever be called for inode with positive ->i_count...
It might be memory corruption; it might be a dangling inode pointer
somewhere, it might be something else.
To get any further we really need a confirmation of the identity of
triggered BUG_ON().
As an aside, your "sample crash reports" would've been much more useful if
they went with commit SHA1 in question, especially when they contain line
numbers.
Re: kernel BUG at fs/inode.c:LINE!
Bisection is inconclusive: the first bad commit could be any of:
cd4f2a66 lib/genalloc.c: fix allocation of aligned buffer from non-aligned
chunk
df3f18d3 fls: change parameter to unsigned int
9067c8d5 lib/find_bit_benchmark.c: align test_find_next_and_bit with others
c2824829 include/linux/printk.h: drop silly "static inline asmlinkage" from
dump_stack()
26e88a47 checkpatch: warn on const char foo[] = "bar"; declarations
e98eceb8 drivers/dma-buf/udmabuf.c: convert to use vm_fault_t
5b6bf71d build_bug.h: remove most of dummy BUILD_BUG_ON stubs for Sparse
f34c9474 fs/epoll: remove max_nests argument from ep_call_nested()
56f6c16e build_bug.h: remove negative-array fallback for BUILD_BUG_ON()
cd2f11e6 fs/epoll: simplify ep_send_events_proc() ready-list loop
74a37b90 Documentation/process/coding-style.rst: don't use "extern" with
function prototypes
ab1909a8 fs/epoll: drop ovflist branch prediction
499aeb57 proc/sysctl: fix return error for proc_doulongvec_minmax()
b7fa8017 fs/epoll: robustify ep->mtx held checks
d877fd09 fs/proc/base.c: slightly faster /proc/*/limits
f2c37862 fs/epoll: reduce the scope of wq lock in epoll_wait()
860705c8 fs-epoll-reduce-the-scope-of-wq-lock-in-epoll_wait-fix
c62975fb fs/proc/inode.c: delete unnecessary variable in proc_alloc_inode()
9460069d fs/proc/util.c: include fs/proc/internal.h for name_to_int()
ea5f967a fs/epoll: avoid barrier after an epoll_wait(2) timeout
b61909d2 fs-epoll-avoid-barrier-after-an-epoll_wait2-timeout-fix
c768eca0 fs/proc/base.c: use ns_capable instead of capable for timerslack_ns
81553cde fs/epoll: rename check_events label to send_events
b6af7800 fs/buffer.c: add debug print for __getblk_gfp() stall problem
11193e16 mm/page_owner: align with pageblock_nr pages
349afd96 fs/epoll: deal with wait_queue only once
393af37c fs-epoll-deal-with-wait_queue-only-once-fix
c20187bf mm/page_owner: align with pageblock_nr_pages
20fbef31 mm: don't expose page to fast gup before it's ready
ad4f37b8 init/main.c: make "initcall_level_names[]" const char *
0bcbe611 autofs: improve ioctl sbi checks
69ab6b14 mm: fix race between swapoff and mincore
b783d261 autofs-improve-ioctl-sbi-checks-fix
de44564f mm, swap: fix race between swapoff and some swap operations
010a80ff mm, swap: fix race between swapoff and some swap operations
9c82e3b8 autofs: fix possible inode leak in autofs_fill_super()
855b7de1 mm/page_alloc.c: remove software prefetching in __free_pages_core()
cd4d5fa9 autofs: simplify parse_options() function call
e8fed666 memory_hotplug-free-pages-as-higher-order-fix-fix
f7aa1250 autofs: change catatonic setting to a bit flag
578f6458 autofs: add strictexpire mount option
71e7f022 memory_hotplug-free-pages-as-higher-order-fix
8286148b mm/page_alloc.c: memory hotplug: free pages as higher order
e5d8e894 hfsplus: return file attributes on statx
728804fa include/uapi/linux/msdos_fs.h: use MSDOS_NAME for volume label size
e93a0c0d include/linux/memory_hotplug.h: remove duplicate declaration of
offline_pages()
3d991a59 ptrace: take into account saved_sigmask in PTRACE_{GET,SET}SIGMASK
a7b16608 mm/mmu_notifier: contextual information for event triggering
invalidation v2
302092c9
mm-mmu_notifier-use-structure-for-invalidate_range_start-end-calls-v2-checkpatch-fixes
cdd7a0aa fork: fix some -Wmissing-prototypes warnings
137d92bd mm/mmu_notifier: use structure for invalidate_range_start/end
calls v2
b89cf731 exec: load_script: don't blindly truncate shebang string
42905641
mm-mmu_notifier-use-structure-for-invalidate_range_start-end-callback-fix-fix
ad2539c7 exec: increase BINPRM_BUF_SIZE to 256
0db734c6 mm/mmu_notifier: use structure for invalidate_range_start/end
callback
c09b6daf exec: separate MM_ANONPAGES and RLIMIT_STACK accounting
37ba86cc hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined
dc98b124 exec-separate-mm_anonpages-and-rlimit_stack-accounting-fix
28286054
exec-separate-mm_anonpages-and-rlimit_stack-accounting-checkpatch-fixes
b08acb20 mm-kmemleak-little-optimization-while-scanning-fix
27faeb70 bfs: extra sanity checking and static inode bitmap
79d0fd91 mm, kmemleak: little optimization while scanning
232619fc lib/ioremap: ensure break-before-make is used for huge p4d mappings
7a489f5d panic: add options to print system info when panic happens
784bedb5 kernel/sysctl: add panic_print into sysctl
e5dfd59e lib/ioremap: ensure phys_addr actually corresponds to a physical
address
5f8d4992 kernel/kcov.c: mark write_comp_data() as notrace
7bdcb055 x86/pgtable: drop pXd_none() checks from pXd_free_pYd_table()
0aa19fc1 arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table()
7ab8b68a scripts/gdb: fix lx-version string output
b2581b70 initramfs: cleanup incomplete rootfs
ee095458 ioremap: rework pXd_free_pYd_page() API
ce10bcf4 mm/page_alloc.c: calculate first_deferred_pfn directly
efae8091 ipc: allow boot time extension of IPCMNI from 32k to 8M
ab7db927
Re: kernel BUG at fs/inode.c:LINE!
On Tue, 2018-12-18 at 13:09 -0800, Andrew Morton wrote: > On Tue, 18 Dec 2018 19:34:57 +0800 Ian Kent wrote: > > > > See > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > Actually, looking at it again the above patch is plain not needed, > > dropping it and updating the patch which follows it in the series > > is what needs to be done. > > > > Andrew, what should I do to make this easiest for you to handle, > > a respost with v2 in the subject of the patch affected by dropping > > the above patch? > > I dropped the patch and fixed up the fallout. Thanks Andrew, much appreciated. > > The patch wasn't true anyway. "There is no check at all for a failure > to allocate the root inode in autofs_fill_super(), handle it." In fact, > d_make_root(NULL) will just return NULL and autofs_fill_super() handles > that appropriately. The not so funny thing is that I'm sure I looked at this some time in the distant past and saw how d_make_root() behaved. The lesson for me is don't try and fix other things seen while working on something else, return later and do it properly. > > However let's note that when autofs_get_inode() or d_make_root() fail, > autofs_fill_super() will return -EINVAL. Should have been -ENOMEM, I > guess? > That's right, but I don't think that's urgent so I'll send a patch for it after the coming merge window. The strictexpire option addition is urgent for me so I don't want to upset any chance of that being merged sooner rather than later. Ian
Re: kernel BUG at fs/inode.c:LINE!
On Tue, 18 Dec 2018 19:34:57 +0800 Ian Kent wrote: > > See > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > Actually, looking at it again the above patch is plain not needed, > dropping it and updating the patch which follows it in the series > is what needs to be done. > > Andrew, what should I do to make this easiest for you to handle, > a respost with v2 in the subject of the patch affected by dropping > the above patch? I dropped the patch and fixed up the fallout. The patch wasn't true anyway. "There is no check at all for a failure to allocate the root inode in autofs_fill_super(), handle it." In fact, d_make_root(NULL) will just return NULL and autofs_fill_super() handles that appropriately. However let's note that when autofs_get_inode() or d_make_root() fail, autofs_fill_super() will return -EINVAL. Should have been -ENOMEM, I guess?
Re: kernel BUG at fs/inode.c:LINE!
On Tue, 2018-12-18 at 14:19 +0100, Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 1:42 PM Ian Kent wrote: > > > > On Tue, 2018-12-18 at 13:27 +0100, Dmitry Vyukov wrote: > > > On Tue, Dec 18, 2018 at 12:35 PM Ian Kent wrote: > > > > > > > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > > > > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > > > > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > > > > Hello, > > > > > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for > > > > > > > 20181214 > > > > > > > git tree: linux-next > > > > > > > console output: > > > > > > > https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > > > > > > kernel config: > > > > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > > > > dashboard link: > > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > > > > syz repro: > > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > > > > > > C reproducer: > > > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > > > > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > > > > commit: > > > > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > > > > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > > > > slab_alloc mm/slab.c:3365 [inline] > > > > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > > > > [ cut here ] > > > > > > > kernel BUG at fs/inode.c:1566! > > > > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather > > > > > > misreported. > > > > > > iput() can be called by d_make_root(), provided that dentry > > > > > > allocation > > > > > > fails. So the most straightforward interpretation would be that we > > > > > > had an allocation failure (injected?), followed by iput() of the > > > > > > inode > > > > > > passed to d_make_root(). Which happened to find I_CLEAR in > > > > > > ->i_state > > > > > > of that inode somehow, which should be impossible short of seriously > > > > > > buggered inode refcounting somewhere - the inode has just been > > > > > > returned > > > > > > by new_inode(), which clears i_state, and it would have to have > > > > > > passed > > > > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > > > > > > > Sorry Al, that's my bad. > > > > > > > > > > See > > > > > > > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > > > > > Actually, looking at it again the above patch is plain not needed, > > > > dropping it and updating the patch which follows it in the series > > > > is what needs to be done. > > > > > > > > Andrew, what should I do to make this easiest for you to handle, > > > > a respost with v2 in the subject of the patch affected by dropping > > > > the above patch? > > > > > > > > Or I could repost the series with above patch dropped and the affected > > > > patch corrected? > > > > > > Hi Ian, > > > > > > If you going to amend any commits, please add: > > > Tested-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > otherwise: > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > I was thinking about how to handle loosing that information. > > > > I don't think this amounts amending commits since Andrews mmotm is > > based on patch series so dropping a patch and updating patches before > > being merged won't capture this. > > > > Adding the "Tested-by" attribution to the updated patch prior to syzbot > > actually performing the test might be ok since it will get tested along > > the way. Although the problem patch itself won't exist any more so ... ? > > I am a bit lost. > There should be some patch that will fix this (new or amended). Either > that patch needs to include Reporter/Tested-by tag, or we will need to > tell syzbot about the fix manually with the "#syz fix:" command. One of the patches that I forwarded to Andrew was plain wrong, it isn't actually needed so it needs to be dropped altogether (this one caused the breakage). Doing so then requires a minor (unrelated) change to the next of my patches in the series I sent. Andrew forwards certain patches in his patch queue to to the linux-next tree. I'm not sure if that is done via a cumulative pull request or via actual patches. Whether dropping a patch from Andrews mmotm tree when
Re: kernel BUG at fs/inode.c:LINE!
On Tue, Dec 18, 2018 at 06:42:35PM +0800, Ian Kent wrote: > Sorry Al, that's my bad. > > See > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > I think this will fix it, I'll forward it to Andrew if you agree: Just drop it and be done with that. d_make_root(NULL) returns NULL, no need to check that in the caller. There is no leak in the mainline; the calling conventions for d_make_root() are chosen that way just for that reason - to minimize the amount of cleanups needed.
Re: kernel BUG at fs/inode.c:LINE!
On Tue, Dec 18, 2018 at 1:42 PM Ian Kent wrote: > > On Tue, 2018-12-18 at 13:27 +0100, Dmitry Vyukov wrote: > > On Tue, Dec 18, 2018 at 12:35 PM Ian Kent wrote: > > > > > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > > > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > > > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > > > Hello, > > > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for > > > > > > 20181214 > > > > > > git tree: linux-next > > > > > > console output: > > > > > > https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > > > > > kernel config: > > > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > > > dashboard link: > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > > > syz repro: > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > > > > > C reproducer: > > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > > > commit: > > > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > > > slab_alloc mm/slab.c:3365 [inline] > > > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > > > [ cut here ] > > > > > > kernel BUG at fs/inode.c:1566! > > > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather > > > > > misreported. > > > > > iput() can be called by d_make_root(), provided that dentry allocation > > > > > fails. So the most straightforward interpretation would be that we > > > > > had an allocation failure (injected?), followed by iput() of the inode > > > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > > > of that inode somehow, which should be impossible short of seriously > > > > > buggered inode refcounting somewhere - the inode has just been > > > > > returned > > > > > by new_inode(), which clears i_state, and it would have to have passed > > > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > > > > > Sorry Al, that's my bad. > > > > > > > > See > > > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > > > Actually, looking at it again the above patch is plain not needed, > > > dropping it and updating the patch which follows it in the series > > > is what needs to be done. > > > > > > Andrew, what should I do to make this easiest for you to handle, > > > a respost with v2 in the subject of the patch affected by dropping > > > the above patch? > > > > > > Or I could repost the series with above patch dropped and the affected > > > patch corrected? > > > > Hi Ian, > > > > If you going to amend any commits, please add: > > Tested-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > otherwise: > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > I was thinking about how to handle loosing that information. > > I don't think this amounts amending commits since Andrews mmotm is > based on patch series so dropping a patch and updating patches before > being merged won't capture this. > > Adding the "Tested-by" attribution to the updated patch prior to syzbot > actually performing the test might be ok since it will get tested along > the way. Although the problem patch itself won't exist any more so ... ? I am a bit lost. There should be some patch that will fix this (new or amended). Either that patch needs to include Reporter/Tested-by tag, or we will need to tell syzbot about the fix manually with the "#syz fix:" command. > OTOH, if I repost the series I think I can send them to syzbot for testing > before forwarding to Andrew (I've done something like that before but can't > remember how now) and add the attribution to the series. > > But this all depends on what is best for Andrew and what Al would like to > see done.
Re: kernel BUG at fs/inode.c:LINE!
On Tue, 2018-12-18 at 13:27 +0100, Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 12:35 PM Ian Kent wrote: > > > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > > Hello, > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for > > > > > 20181214 > > > > > git tree: linux-next > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > > syz repro: > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > > > > C reproducer: > > > > > https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > > commit: > > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > > slab_alloc mm/slab.c:3365 [inline] > > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > > [ cut here ] > > > > > kernel BUG at fs/inode.c:1566! > > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather > > > > misreported. > > > > iput() can be called by d_make_root(), provided that dentry allocation > > > > fails. So the most straightforward interpretation would be that we > > > > had an allocation failure (injected?), followed by iput() of the inode > > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > > of that inode somehow, which should be impossible short of seriously > > > > buggered inode refcounting somewhere - the inode has just been returned > > > > by new_inode(), which clears i_state, and it would have to have passed > > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > > > Sorry Al, that's my bad. > > > > > > See > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > Actually, looking at it again the above patch is plain not needed, > > dropping it and updating the patch which follows it in the series > > is what needs to be done. > > > > Andrew, what should I do to make this easiest for you to handle, > > a respost with v2 in the subject of the patch affected by dropping > > the above patch? > > > > Or I could repost the series with above patch dropped and the affected > > patch corrected? > > Hi Ian, > > If you going to amend any commits, please add: > Tested-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > otherwise: > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com I was thinking about how to handle loosing that information. I don't think this amounts amending commits since Andrews mmotm is based on patch series so dropping a patch and updating patches before being merged won't capture this. Adding the "Tested-by" attribution to the updated patch prior to syzbot actually performing the test might be ok since it will get tested along the way. Although the problem patch itself won't exist any more so ... ? OTOH, if I repost the series I think I can send them to syzbot for testing before forwarding to Andrew (I've done something like that before but can't remember how now) and add the attribution to the series. But this all depends on what is best for Andrew and what Al would like to see done. > > Thanks > > > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > > > > > From: Ian Kent > > > > > > A previous change to handle a possible inode leak in autofs_fill_super() > > > added an iput() on d_make_root() failure but d_make_root() already puts > > > the passed in inode on failure. > > > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > Signed-off-by: Ian Kent > > > --- > > > fs/autofs/inode.c |4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > > > index 501833cc49a8..953f76b95172 100644 > > > --- a/fs/autofs/inode.c > > > +++ b/fs/autofs/inode.c > > > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void > > > *data, > > > int silent) > > > } > > > root = d_make_root(root_inode); > > > if (!root) > > > - goto
Re: kernel BUG at fs/inode.c:LINE!
On Tue, Dec 18, 2018 at 12:35 PM Ian Kent wrote: > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > Hello, > > > > > > > > syzbot found the following crash on: > > > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 > > > > git tree: linux-next > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > syz repro: > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > commit: > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > slab_alloc mm/slab.c:3365 [inline] > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > [ cut here ] > > > > kernel BUG at fs/inode.c:1566! > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > > iput() can be called by d_make_root(), provided that dentry allocation > > > fails. So the most straightforward interpretation would be that we > > > had an allocation failure (injected?), followed by iput() of the inode > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > of that inode somehow, which should be impossible short of seriously > > > buggered inode refcounting somewhere - the inode has just been returned > > > by new_inode(), which clears i_state, and it would have to have passed > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > Sorry Al, that's my bad. > > > > See > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > Actually, looking at it again the above patch is plain not needed, > dropping it and updating the patch which follows it in the series > is what needs to be done. > > Andrew, what should I do to make this easiest for you to handle, > a respost with v2 in the subject of the patch affected by dropping > the above patch? > > Or I could repost the series with above patch dropped and the affected > patch corrected? Hi Ian, If you going to amend any commits, please add: Tested-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com otherwise: Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com Thanks > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > > > From: Ian Kent > > > > A previous change to handle a possible inode leak in autofs_fill_super() > > added an iput() on d_make_root() failure but d_make_root() already puts > > the passed in inode on failure. > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > Signed-off-by: Ian Kent > > --- > > fs/autofs/inode.c |4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > > index 501833cc49a8..953f76b95172 100644 > > --- a/fs/autofs/inode.c > > +++ b/fs/autofs/inode.c > > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > } > > root = d_make_root(root_inode); > > if (!root) > > - goto fail_iput; > > + goto fail_ino; > > pipe = NULL; > > > > root->d_fsdata = ino; > > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > fail_dput: > > dput(root); > > goto fail_free; > > -fail_iput: > > - iput(root_inode); > > fail_ino: > > autofs_free_ino(ino); > > fail_free: > > >
Re: kernel BUG at fs/inode.c:LINE!
On Tue, 2018-12-18 at 13:01 +0200, Amir Goldstein wrote: > On Tue, Dec 18, 2018 at 12:43 PM Ian Kent wrote: > > > > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > Hello, > > > > > > > > syzbot found the following crash on: > > > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 > > > > git tree: linux-next > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > syz repro: > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > commit: > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > slab_alloc mm/slab.c:3365 [inline] > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > [ cut here ] > > > > kernel BUG at fs/inode.c:1566! > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > > iput() can be called by d_make_root(), provided that dentry allocation > > > fails. So the most straightforward interpretation would be that we > > > had an allocation failure (injected?), followed by iput() of the inode > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > of that inode somehow, which should be impossible short of seriously > > > buggered inode refcounting somewhere - the inode has just been returned > > > by new_inode(), which clears i_state, and it would have to have passed > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > Sorry Al, that's my bad. > > > > See > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > You realize you can just revert that patch. > d_make_root() can take NULL inode as argument. > At the very least, please mention the offending commit with Fixes tag. Thanks Amir, I did get that after looking again once the panic of my stupid mistake passed, ;) > > Thanks, > Amir. > > > > > From: Ian Kent > > > > A previous change to handle a possible inode leak in autofs_fill_super() > > added an iput() on d_make_root() failure but d_make_root() already puts > > the passed in inode on failure. > > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > Signed-off-by: Ian Kent > > --- > > fs/autofs/inode.c |4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > > index 501833cc49a8..953f76b95172 100644 > > --- a/fs/autofs/inode.c > > +++ b/fs/autofs/inode.c > > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > } > > root = d_make_root(root_inode); > > if (!root) > > - goto fail_iput; > > + goto fail_ino; > > pipe = NULL; > > > > root->d_fsdata = ino; > > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > fail_dput: > > dput(root); > > goto fail_free; > > -fail_iput: > > - iput(root_inode); > > fail_ino: > > autofs_free_ino(ino); > > fail_free: > >
Re: kernel BUG at fs/inode.c:LINE!
On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > slab_alloc mm/slab.c:3365 [inline] > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > [ cut here ] > > > kernel BUG at fs/inode.c:1566! > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > iput() can be called by d_make_root(), provided that dentry allocation > > fails. So the most straightforward interpretation would be that we > > had an allocation failure (injected?), followed by iput() of the inode > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > of that inode somehow, which should be impossible short of seriously > > buggered inode refcounting somewhere - the inode has just been returned > > by new_inode(), which clears i_state, and it would have to have passed > > clear_inode() (i.e. has been through inode eviction) since then... > > Sorry Al, that's my bad. > > See > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > I think this will fix it, I'll forward it to Andrew if you agree: Actually, looking at it again the above patch is plain not needed, dropping it and updating the patch which follows it in the series is what needs to be done. Andrew, what should I do to make this easiest for you to handle, a respost with v2 in the subject of the patch affected by dropping the above patch? Or I could repost the series with above patch dropped and the affected patch corrected? > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > From: Ian Kent > > A previous change to handle a possible inode leak in autofs_fill_super() > added an iput() on d_make_root() failure but d_make_root() already puts > the passed in inode on failure. > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > Signed-off-by: Ian Kent > --- > fs/autofs/inode.c |4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > index 501833cc49a8..953f76b95172 100644 > --- a/fs/autofs/inode.c > +++ b/fs/autofs/inode.c > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, > int silent) > } > root = d_make_root(root_inode); > if (!root) > - goto fail_iput; > + goto fail_ino; > pipe = NULL; > > root->d_fsdata = ino; > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, > int silent) > fail_dput: > dput(root); > goto fail_free; > -fail_iput: > - iput(root_inode); > fail_ino: > autofs_free_ino(ino); > fail_free: >
Re: kernel BUG at fs/inode.c:LINE!
On Tue, Dec 18, 2018 at 12:43 PM Ian Kent wrote: > > On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > slab_alloc mm/slab.c:3365 [inline] > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > [ cut here ] > > > kernel BUG at fs/inode.c:1566! > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > iput() can be called by d_make_root(), provided that dentry allocation > > fails. So the most straightforward interpretation would be that we > > had an allocation failure (injected?), followed by iput() of the inode > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > of that inode somehow, which should be impossible short of seriously > > buggered inode refcounting somewhere - the inode has just been returned > > by new_inode(), which clears i_state, and it would have to have passed > > clear_inode() (i.e. has been through inode eviction) since then... > > Sorry Al, that's my bad. > > See > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > I think this will fix it, I'll forward it to Andrew if you agree: > > autofs - fix handling of d_make_root() return in autofs_fill_super() You realize you can just revert that patch. d_make_root() can take NULL inode as argument. At the very least, please mention the offending commit with Fixes tag. Thanks, Amir. > > From: Ian Kent > > A previous change to handle a possible inode leak in autofs_fill_super() > added an iput() on d_make_root() failure but d_make_root() already puts > the passed in inode on failure. > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > Signed-off-by: Ian Kent > --- > fs/autofs/inode.c |4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > index 501833cc49a8..953f76b95172 100644 > --- a/fs/autofs/inode.c > +++ b/fs/autofs/inode.c > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, > int silent) > } > root = d_make_root(root_inode); > if (!root) > - goto fail_iput; > + goto fail_ino; > pipe = NULL; > > root->d_fsdata = ino; > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, > int silent) > fail_dput: > dput(root); > goto fail_free; > -fail_iput: > - iput(root_inode); > fail_ino: > autofs_free_ino(ino); > fail_free: >
Re: kernel BUG at fs/inode.c:LINE!
On Mon, 2018-12-17 at 07:21 +, Al Viro wrote: > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > slab_alloc mm/slab.c:3365 [inline] > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > [ cut here ] > > kernel BUG at fs/inode.c:1566! > > d_alloc_anon fs/dcache.c:1698 [inline] > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > iput() can be called by d_make_root(), provided that dentry allocation > fails. So the most straightforward interpretation would be that we > had an allocation failure (injected?), followed by iput() of the inode > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > of that inode somehow, which should be impossible short of seriously > buggered inode refcounting somewhere - the inode has just been returned > by new_inode(), which clears i_state, and it would have to have passed > clear_inode() (i.e. has been through inode eviction) since then... Sorry Al, that's my bad. See https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch I think this will fix it, I'll forward it to Andrew if you agree: autofs - fix handling of d_make_root() return in autofs_fill_super() From: Ian Kent A previous change to handle a possible inode leak in autofs_fill_super() added an iput() on d_make_root() failure but d_make_root() already puts the passed in inode on failure. Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com Signed-off-by: Ian Kent --- fs/autofs/inode.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c index 501833cc49a8..953f76b95172 100644 --- a/fs/autofs/inode.c +++ b/fs/autofs/inode.c @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, int silent) } root = d_make_root(root_inode); if (!root) - goto fail_iput; + goto fail_ino; pipe = NULL; root->d_fsdata = ino; @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, int silent) fail_dput: dput(root); goto fail_free; -fail_iput: - iput(root_inode); fail_ino: autofs_free_ino(ino); fail_free:
Re: kernel BUG at fs/inode.c:LINE!
On 2018/12/17 19:08, Dmitry Vyukov wrote: > On Mon, Dec 17, 2018 at 8:21 AM Al Viro wrote: >>> slab_pre_alloc_hook mm/slab.h:423 [inline] >>> slab_alloc mm/slab.c:3365 [inline] >>> kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 >>> __d_alloc+0xc8/0xb90 fs/dcache.c:1599 >>> [ cut here ] >>> kernel BUG at fs/inode.c:1566! >>> d_alloc_anon fs/dcache.c:1698 [inline] >>> d_make_root+0x43/0xc0 fs/dcache.c:1885 >>> autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 >> >> Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > Yes, it's a known problem that kernel is generally incapable of > producing parsable crash reports. I think Tetsuo is working on a > solution, but it takes very large amount of discussions and months of > time. The solution, CONFIG_PRINTK_FROM option (which will be renamed to CONFIG_PRINTK_CALLER option tomorrow), just arrived at linux-next-20181218. We can try it... But currently syzbot cannot boot using linux-next-20181218 due to "Kernel panic - not syncing: Can't create rootfs" presumably due to changes merged by "Merge branches 'work.mount', 'work.misc', 'misc.misc' and 'work.iov_iter' into for-next". I think that we need to examine this "Can't create rootfs" problem, for the merge window is approaching...
Re: kernel BUG at fs/inode.c:LINE!
On Mon, Dec 17, 2018 at 8:21 AM Al Viro wrote:
>
> On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740
> > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com
> >
> > slab_pre_alloc_hook mm/slab.h:423 [inline]
> > slab_alloc mm/slab.c:3365 [inline]
> > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539
> > __d_alloc+0xc8/0xb90 fs/dcache.c:1599
> > [ cut here ]
> > kernel BUG at fs/inode.c:1566!
> > d_alloc_anon fs/dcache.c:1698 [inline]
> > d_make_root+0x43/0xc0 fs/dcache.c:1885
> > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273
>
> Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported.
Yes, it's a known problem that kernel is generally incapable of
producing parsable crash reports. I think Tetsuo is working on a
solution, but it takes very large amount of discussions and months of
time.
> iput() can be called by d_make_root(), provided that dentry allocation
> fails. So the most straightforward interpretation would be that we
> had an allocation failure (injected?), followed by iput() of the inode
> passed to d_make_root(). Which happened to find I_CLEAR in ->i_state
> of that inode somehow, which should be impossible short of seriously
> buggered inode refcounting somewhere - the inode has just been returned
> by new_inode(), which clears i_state, and it would have to have passed
> clear_inode() (i.e. has been through inode eviction) since then...
Yes, there are injected failures in the log.
And the repro says:
#{..."fault":true,"fault_call":1,"fault_nth":36 ...}
mkdir(&(0x7f000140)='./file0\x00', 0x0)
mount(0x0, &(0x7f000100)='./file0\x00',
&(0x7f000180)='autofs\x00', 0x0, 0x0)
Since the repro is single-threaded, I would expect that the bug is
directly on the error handling path of the failure allocation.
Re: kernel BUG at fs/inode.c:LINE!
On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > slab_pre_alloc_hook mm/slab.h:423 [inline] > slab_alloc mm/slab.c:3365 [inline] > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > [ cut here ] > kernel BUG at fs/inode.c:1566! > d_alloc_anon fs/dcache.c:1698 [inline] > d_make_root+0x43/0xc0 fs/dcache.c:1885 > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. iput() can be called by d_make_root(), provided that dentry allocation fails. So the most straightforward interpretation would be that we had an allocation failure (injected?), followed by iput() of the inode passed to d_make_root(). Which happened to find I_CLEAR in ->i_state of that inode somehow, which should be impossible short of seriously buggered inode refcounting somewhere - the inode has just been returned by new_inode(), which clears i_state, and it would have to have passed clear_inode() (i.e. has been through inode eviction) since then...
kernel BUG at fs/inode.c:LINE!
Hello, syzbot found the following crash on: HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 __d_alloc+0xc8/0xb90 fs/dcache.c:1599 [ cut here ] kernel BUG at fs/inode.c:1566! d_alloc_anon fs/dcache.c:1698 [inline] d_make_root+0x43/0xc0 fs/dcache.c:1885 autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 6100 Comm: syz-executor637 Not tainted 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:iput+0x915/0xa90 fs/inode.c:1566 Code: e4 0f 84 a8 fe ff ff e8 e9 fe a6 ff 48 89 df e8 61 f4 ff ff 48 8b bd f0 fe ff ff e8 35 41 08 06 e9 69 fd ff ff e8 cb fe a6 ff <0f> 0b e8 c4 fe a6 ff 0f 0b e9 d5 fb ff ff e8 b8 fe a6 ff 0f 0b e9 RSP: 0018:8881c0ff76b8 EFLAGS: 00010293 RAX: 8881c0fdc100 RBX: 8881b25f44a0 RCX: 81d8fc14 RDX: RSI: 81d90455 RDI: 0007 RBP: 8881c0ff77f0 R08: 8881c0fdc100 R09: 0006 R10: R11: 8881c0fdc100 R12: 0040 R13: 8881c0ff7910 R14: ffea R15: 8881d0c4d200 mount_nodev+0x73/0x120 fs/super.c:1402 FS: 01e1a880() GS:8881dad0() knlGS: CS: 0010 DS: ES: CR0: 80050033 autofs_mount+0x34/0x40 fs/autofs/init.c:16 CR2: 006cd0a0 CR3: 0001b2c56000 CR4: 001406e0 DR0: DR1: DR2: legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 autofs_fill_super+0x15fb/0x1c30 fs/autofs/inode.c:352 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 mount_nodev+0x73/0x120 fs/super.c:1402 entry_SYSCALL_64_after_hwframe+0x49/0xbe autofs_mount+0x34/0x40 fs/autofs/init.c:16 RIP: 0033:0x441be9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 RSP: 002b:76330f88 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: RCX: 00441be9 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 RDX: 2180 RSI: 2100 RDI: RBP: 76330fe0 R08: R09: 0100 R10: R11: 0246 R12: do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 R13: 0003 R14: R15: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 6107 Comm: syz-executor637 Not tainted 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 fail_dump lib/fault-inject.c:51 [inline] should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe __should_failslab+0x124/0x180 mm/failslab.c:32 RIP: 0033:0x441be9 should_failslab+0x9/0x14 mm/slab_common.c:1576 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 RSP: 002b:76330f88 EFLAGS: 0246 ORIG_RAX:
