WARNING in lock_release

[syzbot]

Hello,

syzkaller hit the following crash on
5515cf16e270538121e4fa9283fed86c6cfd8c9c
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. See https://goo.gl/kgGztJ
for information about syzkaller reproducers


RBP: 0000000000000086 R08: 0000000020000000 R09: 65732f636f003031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401d60
R13: 0000000000401df0 R14: 0000000000000000 R15: 0000000000000000
DEBUG_LOCKS_WARN_ON(depth <= 0)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3043 at kernel/locking/lockdep.c:3766 __lock_release
kernel/locking/lockdep.c:3766 [inline]
WARNING: CPU: 0 PID: 3043 at kernel/locking/lockdep.c:3766
lock_release+0x5de/0xd90 kernel/locking/lockdep.c:4023
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 3043 Comm: syzkaller384967 Not tainted
4.14.0-rc8-next-20171109+ #39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1c4/0x1e0 kernel/panic.c:546
report_bug+0x211/0x2d0 lib/bug.c:184
fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:176
do_trap_no_signal arch/x86/kernel/traps.c:210 [inline]
do_trap+0x260/0x390 arch/x86/kernel/traps.c:259
do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:309
invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:926
RIP: 0010:__lock_release kernel/locking/lockdep.c:3766 [inline]
RIP: 0010:lock_release+0x5de/0xd90 kernel/locking/lockdep.c:4023
RSP: 0018:ffff8801ccfe7740 EFLAGS: 00010082
RAX: 000000000000001f RBX: 1ffff100399fceed RCX: 0000000000000000
RDX: 000000000000001f RSI: 1ffff100399fcea8 RDI: ffffed00399fcedc
RBP: ffff8801ccfe78b0 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8801cceac580 R11: fffffbfff0e8546b R12: ffff8801ccfe7788
R13: ffff8801ccfe7888 R14: ffff8801cc018b98 R15: ffffffff8746ad60
up_write+0x6b/0x120 kernel/locking/rwsem.c:131
destroy_unused_super.part.7+0x18/0xd0 fs/super.c:163
destroy_unused_super fs/super.c:505 [inline]
alloc_super fs/super.c:258 [inline]
sget_userns+0x905/0xe20 fs/super.c:503
sget+0xd2/0x120 fs/super.c:554
mount_nodev+0x37/0x100 fs/super.c:1157
devpts_mount+0x2c/0x40 fs/devpts/inode.c:481
mount_fs+0x66/0x2d0 fs/super.c:1219
vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:2509 [inline]
do_new_mount fs/namespace.c:2512 [inline]
do_mount+0xea1/0x2bb0 fs/namespace.c:2841
SYSC_mount fs/namespace.c:3057 [inline]
SyS_mount+0xab/0x120 fs/namespace.c:3034
entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x440439
RSP: 002b:00007ffdf34ca458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440439
RDX: 0000000020e3b000 RSI: 000000002059e000 RDI: 0000000020ae0ff4
RBP: 0000000000000086 R08: 0000000020000000 R09: 65732f636f003031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401d60
R13: 0000000000401df0 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.
Please credit me with: Reported-by: syzbot <syzk...@googlegroups.com>

syzbot will keep track of this bug report.
Once a fix for this bug is committed, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[Al Viro]

On Thu, Nov 16, 2017 at 02:56:00AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 5515cf16e270538121e4fa9283fed86c6cfd8c9c
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Hmm... That's alloc_super() buggering off on allocation failure and
hitting up_write(s->s_umount) in destroy_unused_super(), since it has
not done
init_rwsem(&s->s_umount);
lockdep_set_class(&s->s_umount, &type->s_umount_key);
down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
part yet. The sucker is just all-zeroes here. The easiest way to fix
that would probably be to move that bit of initialization in the very
beginning...

diff --git a/fs/super.c b/fs/super.c
index 8ca15415351a..2808aeaf5337 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -190,6 +190,24 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags,

INIT_LIST_HEAD(&s->s_mounts);
s->s_user_ns = get_user_ns(user_ns);
+ init_rwsem(&s->s_umount);
+ lockdep_set_class(&s->s_umount, &type->s_umount_key);
+ /*
+ * sget() can have s_umount recursion.
+ *
+ * When it cannot find a suitable sb, it allocates a new
+ * one (this one), and tries again to find a suitable old
+ * one.
+ *
+ * In case that succeeds, it will acquire the s_umount
+ * lock of the old one. Since these are clearly distrinct
+ * locks, and this object isn't exposed yet, there's no
+ * risk of deadlocks.
+ *
+ * Annotate this by putting this lock in a different
+ * subclass.
+ */
+ down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);

if (security_sb_alloc(s))
goto fail;
@@ -217,25 +235,6 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags,
goto fail;
if (list_lru_init_memcg(&s->s_inode_lru))
goto fail;
-
- init_rwsem(&s->s_umount);
- lockdep_set_class(&s->s_umount, &type->s_umount_key);
- /*
- * sget() can have s_umount recursion.
- *
- * When it cannot find a suitable sb, it allocates a new
- * one (this one), and tries again to find a suitable old
- * one.
- *
- * In case that succeeds, it will acquire the s_umount
- * lock of the old one. Since these are clearly distrinct
- * locks, and this object isn't exposed yet, there's no
- * risk of deadlocks.
- *
- * Annotate this by putting this lock in a different
- * subclass.
- */
- down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
s->s_count = 1;
atomic_set(&s->s_active, 1);
mutex_init(&s->s_vfs_rename_mutex);

[Dmitry Vyukov]

Testing patch testing:

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20171117210232.GP21978%40ZenIV.linux.org.uk.
> For more options, visit https://groups.google.com/d/optout.

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger
crash:

Tested-by: syzbot <syzk...@googlegroups.com>

Once the fix is committed, please reply to this email with:
#syz fix: exact-commit-title

Tested on commit c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master

compiler: gcc (GCC) 7.1.1 20170620

Patch is attached.
Kernel config is attached.


---
There is no WARRANTY for the result, to the extent permitted by applicable
law.
Except when otherwise stated in writing syzbot provides the result "AS IS"
without warranty of any kind, either expressed or implied, but not limited
to,
the implied warranties of merchantability and fittness for a particular
purpose.
The entire risk as to the quality of the result is with you. Should the
result
prove defective, you assume the cost of all necessary servicing, repair or
correction.

[Dmitry Vyukov]

On Fri, Nov 17, 2017 at 10:02 PM, Al Viro <vi...@zeniv.linux.org.uk> wrote:

Hi,

We are rolling out patch testing feature for syzbot:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
So if you are asking for testing, feel free to use it. If not, let's
still give it a try (it also needs testing):

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger
crash:

Tested-by: syzbot <syzk...@googlegroups.com>

Once the fix is committed, please reply to this email with:
#syz fix: exact-commit-title

Tested on commit c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master

compiler: gcc (GCC) 7.1.1 20170620

[Eric Biggers]

On Mon, Nov 20, 2017 at 05:24:00AM -0800, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch and the reproducer did not
> trigger crash:
>
> Tested-by: syzbot <syzk...@googlegroups.com>
>
> Once the fix is committed, please reply to this email with:
> #syz fix: exact-commit-title
>
> Tested on commit c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> Patch is attached.
> Kernel config is attached.
>

#syz fix: alloc_super(): do ->s_umount initialization earlier