linux-kernel - 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Aug 2016 16:35:46 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Ian Kent <raven@...maw.net>
Cc:     Al Viro <viro@...iv.linux.org.uk>, autofs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757"

Hi,

I noticed that a freshly booted 4.8-rc4 kernel gives the following
kernel messages a few times:

 BUG: sleeping function called from invalid context at fs/dcache.c:757
 in_atomic(): 1, irqs_disabled(): 0, pid: 8431, name: automount
 1 lock held by automount/8431:
  #0:  (&(&sbi->fs_lock)->rlock){+.+...}, at: [<ffffffff81345736>] autofs4_expire_indirect+0x136/0x2d0
 CPU: 4 PID: 8431 Comm: automount Not tainted 4.8.0-rc4-test2+ #210
 Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013
  0000000000000000 ffff8801843efc30 ffffffff813bbdd3 ffff88019e6500c0
  ffffffff81a330b6 ffff8801843efc58 ffffffff810a3052 ffffffff81a330b6
  00000000000002f5 0000000000000000 ffff8801843efc80 ffffffff810a3149
 Call Trace:
  [<ffffffff813bbdd3>] dump_stack+0x86/0xc3
  [<ffffffff810a3052>] ___might_sleep+0x142/0x1f0
  [<ffffffff810a3149>] __might_sleep+0x49/0x80
  [<ffffffff81260b17>] ? dput+0x37/0x400
  [<ffffffff81260b26>] dput+0x46/0x400
  [<ffffffff8126c96d>] ? lookup_mnt+0x14d/0x1d0
  [<ffffffff8124ff54>] ? follow_down_one+0x14/0x60
  [<ffffffff8124ff67>] follow_down_one+0x27/0x60
  [<ffffffff81344da2>] autofs4_mount_busy+0x32/0x110
  [<ffffffff81345081>] should_expire+0x51/0x3d0
  [<ffffffff81345790>] autofs4_expire_indirect+0x190/0x2d0
  [<ffffffff81345fa0>] ? autofs_dev_ioctl_askumount+0x30/0x30
  [<ffffffff81345bb4>] autofs4_do_expire_multi+0x94/0xb0
  [<ffffffff81345fa0>] ? autofs_dev_ioctl_askumount+0x30/0x30
  [<ffffffff81345fbf>] autofs_dev_ioctl_expire+0x1f/0x30
  [<ffffffff81346679>] _autofs_dev_ioctl+0x2b9/0x350
  [<ffffffff81346723>] autofs_dev_ioctl+0x13/0x20
  [<ffffffff8125af54>] do_vfs_ioctl+0x94/0x690
  [<ffffffff8126820d>] ? __fget+0x10d/0x200
  [<ffffffff81268105>] ? __fget+0x5/0x200
  [<ffffffff8125b5c9>] SyS_ioctl+0x79/0x90
  [<ffffffff8170ef00>] entry_SYSCALL_64_fastpath+0x23/0xc1


I don't remember of a similar stack trace in the past, so if any, it
can be a regression in 4.8 kernel.  But I cannot say it in 100%, as
this looks spontaneous, nor I would be able to reproduce it at the
next boot...


thanks,

Takashi