Re: kernel BUG at fs/namei.c:LINE!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux