[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200114065854.GA3719@kadam>
Date: Tue, 14 Jan 2020 09:58:54 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: syzbot <syzbot+79eb0f3df962caf839ed@...kaller.appspotmail.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: kernel BUG at fs/namei.c:LINE!
On Mon, Jan 13, 2020 at 10:33:10PM -0800, syzbot wrote:
> ------------[ cut here ]------------
> kernel BUG at fs/namei.c:684!
> invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 9764 Comm: syz-executor.0 Not tainted
> 5.5.0-rc5-next-20200113-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:unlazy_walk+0x306/0x3b0 fs/namei.c:684
> path_mountpoint.isra.0+0x1d5/0x340 fs/namei.c:2788
> filename_mountpoint+0x181/0x380 fs/namei.c:2809
> user_path_mountpoint_at+0x3a/0x50 fs/namei.c:2839
> ksys_umount+0x164/0xef0 fs/namespace.c:1683
2289 static const char *path_init(struct nameidata *nd, unsigned flags)
2290 {
2291 int error;
2292 const char *s = nd->name->name;
2293
2294 if (!*s)
2295 flags &= ~LOOKUP_RCU;
^^^^^^^^^^^^^^^^^^^^
My guess is that LOOKUP_RCU gets cleared out here. Maybe the problem
was introduced in commit e56b43b971a7 ("reimplement path_mountpoint()
with less magic") because before we checked LOOKUP_RCU before calling
unlazy_walk().
- /* If we're in rcuwalk, drop out of it to handle last component */
- if (nd->flags & LOOKUP_RCU) {
- if (unlazy_walk(nd))
2296 if (flags & LOOKUP_RCU)
2297 rcu_read_lock();
2298
regards,
dan carpenter
Powered by blists - more mailing lists