WARNING: kobject bug in sysfs_warn_dup

WARNING: kobject bug in sysfs_warn_dup

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
Merge tag 'ext4_for_linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=9118669095563550941
compiler: gcc (GCC) 7.1.1 20170620

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.
If you forward the report, please keep this part and the footer.

R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
------------[ cut here ]------------
kobject_add_internal failed for nodev( with -EEXIST, don't try to register  
things with the same name in the same directory.
sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238  
kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
Kernel panic - not syncing: panic_on_warn set ...

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+0x1a7/0x27d lib/dump_stack.c:53
  sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
  sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
  create_dir lib/kobject.c:69 [inline]
  kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
  kobject_add_varg lib/kobject.c:364 [inline]
  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
  mount_fs+0x66/0x2d0 fs/super.c:1222
  vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037
  vfs_kern_mount fs/namespace.c:2514 [inline]
  do_new_mount fs/namespace.c:2517 [inline]
  do_mount+0xea4/0x2b90 fs/namespace.c:2847
  ksys_mount+0xab/0x120 fs/namespace.c:3063
  SYSC_mount fs/namespace.c:3077 [inline]
  SyS_mount+0x39/0x50 fs/namespace.c:3074
  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x4432fa
RSP: 002b:00007ffda3d84538 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000020001a40 RCX: 00000000004432fa
RDX: 0000000020001a00 RSI: 0000000020001a40 RDI: 00007ffda3d84550
RBP: 0000000000000000 R08: 0000000020001f00 R09: 000000000000000a
R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
CPU: 1 PID: 4473 Comm: syzkaller533472 Not tainted 4.16.0+ #15
------------[ cut here ]------------
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+0x1a7/0x27d lib/dump_stack.c:53
kobject_add_internal failed for nodev( with -EEXIST, don't try to register  
things with the same name in the same directory.
  panic+0x1f8/0x42c kernel/panic.c:183
WARNING: CPU: 0 PID: 4474 at lib/kobject.c:238  
kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
Modules linked in:
  __warn+0x1dc/0x200 kernel/panic.c:547
CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
  report_bug+0x1f4/0x2b0 lib/bug.c:186
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
  fixup_bug.part.10+0x37/0x80 arch/x86/kernel/traps.c:178
RIP: 0010:kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
  fixup_bug arch/x86/kernel/traps.c:247 [inline]
  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
RSP: 0000:ffff8801addaf470 EFLAGS: 00010282
RAX: dffffc0000000008 RBX: ffff8801d9661110 RCX: ffffffff815b5d2e
RDX: 0000000000000000 RSI: 1ffff10035bb5e3e RDI: 1ffff10035bb5e13
RBP: ffff8801addaf568 R08: 1ffff10035bb5dd5 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: 1ffff10035bb5e94
R13: 00000000ffffffef R14: ffff8801d39ae348 R15: 1ffff10035bb5e98
FS:  0000000001db2880(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
  invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:991
RIP: 0010:kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000019657b0 CR3: 00000001ae0ca000 CR4: 00000000001406f0
RSP: 0018:ffff8801ade37470 EFLAGS: 00010282
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
RAX: dffffc0000000008 RBX: ffff8801d9459190 RCX: ffffffff815b5d2e
Call Trace:
RDX: 0000000000000000 RSI: 1ffff10035bc6e3e RDI: 1ffff10035bc6e13
RBP: ffff8801ade37568 R08: 1ffff10035bc6dd5 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 1ffff10035bc6e94
R13: 00000000ffffffef R14: ffff8801d39ae348 R15: 1ffff10035bc6e98
  kobject_add_varg lib/kobject.c:364 [inline]
  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
  kobject_add_varg lib/kobject.c:364 [inline]
  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
  mount_fs+0x66/0x2d0 fs/super.c:1222
  vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037
  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
  vfs_kern_mount fs/namespace.c:2514 [inline]
  do_new_mount fs/namespace.c:2517 [inline]
  do_mount+0xea4/0x2b90 fs/namespace.c:2847
  mount_fs+0x66/0x2d0 fs/super.c:1222
  vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037
  vfs_kern_mount fs/namespace.c:2514 [inline]
  do_new_mount fs/namespace.c:2517 [inline]
  do_mount+0xea4/0x2b90 fs/namespace.c:2847
  ksys_mount+0xab/0x120 fs/namespace.c:3063
  SYSC_mount fs/namespace.c:3077 [inline]
  SyS_mount+0x39/0x50 fs/namespace.c:3074
  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
  ksys_mount+0xab/0x120 fs/namespace.c:3063
  SYSC_mount fs/namespace.c:3077 [inline]
  SyS_mount+0x39/0x50 fs/namespace.c:3074
  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x4432fa
RSP: 002b:00007ffda3d84538 EFLAGS: 00000286
  ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000020001a40 RCX: 00000000004432fa
RDX: 0000000020001a00 RSI: 0000000020001a40 RDI: 00007ffda3d84550
RBP: 0000000000000000 R08: 0000000020001f00 R09: 000000000000000a
  entry_SYSCALL_64_after_hwframe+0x42/0xb7
R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
RIP: 0033:0x4432fa
RSP: 002b:00007ffda3d84538 EFLAGS: 00000286
Code:
  ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000020001a40 RCX: 00000000004432fa
00
RDX: 0000000020001a00 RSI: 0000000020001a40 RDI: 00007ffda3d84550
00
RBP: 0000000000000000 R08: 0000000020001f00 R09: 000000000000000a
00
R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 aa 00 00 00 48 8b 13 48 c7 c6 80  
8b d6 87 48 c7 c7 e0 88 d6 87 e8 3c 33 58 fa <0f> 0b e9 1d fb ff ff e8 60  
4c 88 fa 0f 0b e9 29 fe ff ff e8 54
---[ end trace 5eab46a9e10a0c8a ]---
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 syzkaller@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
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.

Re: WARNING: kobject bug in sysfs_warn_dup

[Greg KH]

On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
> Merge tag 'ext4_for_linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
> 
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> ------------[ cut here ]------------
> kobject_add_internal failed for nodev( with -EEXIST, don't try to register
> things with the same name in the same directory.
> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
> Kernel panic - not syncing: panic_on_warn set ...
> 
> 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+0x1a7/0x27d lib/dump_stack.c:53
>  sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>  sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>  create_dir lib/kobject.c:69 [inline]
>  kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>  kobject_add_varg lib/kobject.c:364 [inline]
>  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321

gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
usage of the api.

Now if we should turn this into a non-WARN message, that's a different
thing, I'll gladly take a patch for that.

thanks,

greg k-h

Re: WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>> Merge tag 'ext4_for_linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>> compiler: gcc (GCC) 7.1.1 20170620
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>> ------------[ cut here ]------------
>> kobject_add_internal failed for nodev( with -EEXIST, don't try to register
>> things with the same name in the same directory.
>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>  sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>  sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>  create_dir lib/kobject.c:69 [inline]
>>  kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>  kobject_add_varg lib/kobject.c:364 [inline]
>>  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>
> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> usage of the api.

Then +gfs2 maintainers.

> Now if we should turn this into a non-WARN message, that's a different
> thing, I'll gladly take a patch for that.

If it's API usage bug in higher level code, then I think WARN is a
proper thing. We already had similar ones and they were fixed.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>> Merge tag 'ext4_for_linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>> compiler: gcc (GCC) 7.1.1 20170620
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>> ------------[ cut here ]------------
>> kobject_add_internal failed for nodev( with -EEXIST, don't try to register
>> things with the same name in the same directory.
>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>  sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>  sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>  create_dir lib/kobject.c:69 [inline]
>>  kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>  kobject_add_varg lib/kobject.c:364 [inline]
>>  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>
> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> usage of the api.

Then +gfs2 maintainers.

> Now if we should turn this into a non-WARN message, that's a different
> thing, I'll gladly take a patch for that.

If it's API usage bug in higher level code, then I think WARN is a
proper thing. We already had similar ones and they were fixed.

Re: WARNING: kobject bug in sysfs_warn_dup

[Steven Whitehouse]

Hi,


On 05/04/18 09:19, Dmitry Vyukov wrote:
> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>> Hello,
>>>
>>> syzbot hit the following crash on upstream commit
>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>> Merge tag 'ext4_for_linus' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>> syzbot dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>
>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>> syzkaller reproducer:
>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>> Raw console output:
>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>> Kernel config:
>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>> compiler: gcc (GCC) 7.1.1 20170620
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>>> It will help syzbot understand when the bug is fixed. See footer for
>>> details.
>>> If you forward the report, please keep this part and the footer.
>>>
>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>> ------------[ cut here ]------------
>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to register
>>> things with the same name in the same directory.
>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>> Kernel panic - not syncing: panic_on_warn set ...
>>>
>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>   sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>   sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>   create_dir lib/kobject.c:69 [inline]
>>>   kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>   kobject_add_varg lib/kobject.c:364 [inline]
>>>   kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>   gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>   fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>   gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> usage of the api.
> Then +gfs2 maintainers.
>
>> Now if we should turn this into a non-WARN message, that's a different
>> thing, I'll gladly take a patch for that.
> If it's API usage bug in higher level code, then I think WARN is a
> proper thing. We already had similar ones and they were fixed.

I'm trying to figure out what the test is doing, but it is not very 
clear. At a guess I'd say that perhaps it is trying to mount multiple 
filesystems with the same label? If that is the case then it is not 
allowed, and it should be caught be the sysfs code and result in a 
refusal to mount, which is what I think I see here. Knowing which sysfs 
directory is involved would allow us to confirm, but I suspect that the 
test needs altering to give each gfs2 mount a different label at an 
initial guess,

Steve.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Steven Whitehouse]

Hi,


On 05/04/18 09:19, Dmitry Vyukov wrote:
> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>> Hello,
>>>
>>> syzbot hit the following crash on upstream commit
>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>> Merge tag 'ext4_for_linus' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>> syzbot dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>
>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>> syzkaller reproducer:
>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>> Raw console output:
>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>> Kernel config:
>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>> compiler: gcc (GCC) 7.1.1 20170620
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>>> It will help syzbot understand when the bug is fixed. See footer for
>>> details.
>>> If you forward the report, please keep this part and the footer.
>>>
>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>> ------------[ cut here ]------------
>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to register
>>> things with the same name in the same directory.
>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>> Kernel panic - not syncing: panic_on_warn set ...
>>>
>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>   sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>   sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>   create_dir lib/kobject.c:69 [inline]
>>>   kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>   kobject_add_varg lib/kobject.c:364 [inline]
>>>   kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>   gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>   fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>   gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> usage of the api.
> Then +gfs2 maintainers.
>
>> Now if we should turn this into a non-WARN message, that's a different
>> thing, I'll gladly take a patch for that.
> If it's API usage bug in higher level code, then I think WARN is a
> proper thing. We already had similar ones and they were fixed.

I'm trying to figure out what the test is doing, but it is not very 
clear. At a guess I'd say that perhaps it is trying to mount multiple 
filesystems with the same label? If that is the case then it is not 
allowed, and it should be caught be the sysfs code and result in a 
refusal to mount, which is what I think I see here. Knowing which sysfs 
directory is involved would allow us to confirm, but I suspect that the 
test needs altering to give each gfs2 mount a different label at an 
initial guess,

Steve.

Re: WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> Hi,
>
>
>
> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>
>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>> wrote:
>>>
>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>
>>>> Hello,
>>>>
>>>> syzbot hit the following crash on upstream commit
>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>>> Merge tag 'ext4_for_linus' of
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>> syzbot dashboard link:
>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>
>>>> C reproducer:
>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>> syzkaller reproducer:
>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>> Raw console output:
>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>> Kernel config:
>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>
>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>> commit:
>>>> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>> details.
>>>> If you forward the report, please keep this part and the footer.
>>>>
>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>> ------------[ cut here ]------------
>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>> register
>>>> things with the same name in the same directory.
>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>
>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>   sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>   sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>   create_dir lib/kobject.c:69 [inline]
>>>>   kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>   kobject_add_varg lib/kobject.c:364 [inline]
>>>>   kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>   gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>   fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>   gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>
>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> usage of the api.
>>
>> Then +gfs2 maintainers.
>>
>>> Now if we should turn this into a non-WARN message, that's a different
>>> thing, I'll gladly take a patch for that.
>>
>> If it's API usage bug in higher level code, then I think WARN is a
>> proper thing. We already had similar ones and they were fixed.
>
>
> I'm trying to figure out what the test is doing, but it is not very clear.
> At a guess I'd say that perhaps it is trying to mount multiple filesystems
> with the same label? If that is the case then it is not allowed, and it
> should be caught be the sysfs code and result in a refusal to mount, which
> is what I think I see here. Knowing which sysfs directory is involved would
> allow us to confirm, but I suspect that the test needs altering to give each
> gfs2 mount a different label at an initial guess,


Hi Steve,

But Greg claims that this is incorrect usage of sysfs API:

> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> usage of the api.

I think this means that sysfs callers must not try to create the same
thing twice.

Either way user-space code must not be able to triggers WARNINGs in
kernel. If it does than this is something to fix in kernel.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> Hi,
>
>
>
> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>
>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>> wrote:
>>>
>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>
>>>> Hello,
>>>>
>>>> syzbot hit the following crash on upstream commit
>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>>> Merge tag 'ext4_for_linus' of
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>> syzbot dashboard link:
>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>
>>>> C reproducer:
>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>> syzkaller reproducer:
>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>> Raw console output:
>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>> Kernel config:
>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>
>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>> commit:
>>>> Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>> details.
>>>> If you forward the report, please keep this part and the footer.
>>>>
>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>> ------------[ cut here ]------------
>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>> register
>>>> things with the same name in the same directory.
>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>
>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>   sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>   sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>   create_dir lib/kobject.c:69 [inline]
>>>>   kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>   kobject_add_varg lib/kobject.c:364 [inline]
>>>>   kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>   gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>   fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>   gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>
>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> usage of the api.
>>
>> Then +gfs2 maintainers.
>>
>>> Now if we should turn this into a non-WARN message, that's a different
>>> thing, I'll gladly take a patch for that.
>>
>> If it's API usage bug in higher level code, then I think WARN is a
>> proper thing. We already had similar ones and they were fixed.
>
>
> I'm trying to figure out what the test is doing, but it is not very clear.
> At a guess I'd say that perhaps it is trying to mount multiple filesystems
> with the same label? If that is the case then it is not allowed, and it
> should be caught be the sysfs code and result in a refusal to mount, which
> is what I think I see here. Knowing which sysfs directory is involved would
> allow us to confirm, but I suspect that the test needs altering to give each
> gfs2 mount a different label at an initial guess,


Hi Steve,

But Greg claims that this is incorrect usage of sysfs API:

> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> usage of the api.

I think this means that sysfs callers must not try to create the same
thing twice.

Either way user-space code must not be able to triggers WARNINGs in
kernel. If it does than this is something to fix in kernel.

Re: WARNING: kobject bug in sysfs_warn_dup

[Steven Whitehouse]

Hi,


On 05/04/18 09:52, Dmitry Vyukov wrote:
> On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>> Hi,
>>
>>
>>
>> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>> wrote:
>>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot hit the following crash on upstream commit
>>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>>>> Merge tag 'ext4_for_linus' of
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>>> syzbot dashboard link:
>>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>>
>>>>> C reproducer:
>>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>>> syzkaller reproducer:
>>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>>> Raw console output:
>>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>>> Kernel config:
>>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>>
>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>> commit:
>>>>> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>>> details.
>>>>> If you forward the report, please keep this part and the footer.
>>>>>
>>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>>> ------------[ cut here ]------------
>>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>>> register
>>>>> things with the same name in the same directory.
>>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>>
>>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>>    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>>    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>>    create_dir lib/kobject.c:69 [inline]
>>>>>    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>>    kobject_add_varg lib/kobject.c:364 [inline]
>>>>>    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>>    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>>    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>>    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>> usage of the api.
>>> Then +gfs2 maintainers.
>>>
>>>> Now if we should turn this into a non-WARN message, that's a different
>>>> thing, I'll gladly take a patch for that.
>>> If it's API usage bug in higher level code, then I think WARN is a
>>> proper thing. We already had similar ones and they were fixed.
>>
>> I'm trying to figure out what the test is doing, but it is not very clear.
>> At a guess I'd say that perhaps it is trying to mount multiple filesystems
>> with the same label? If that is the case then it is not allowed, and it
>> should be caught be the sysfs code and result in a refusal to mount, which
>> is what I think I see here. Knowing which sysfs directory is involved would
>> allow us to confirm, but I suspect that the test needs altering to give each
>> gfs2 mount a different label at an initial guess,
>
> Hi Steve,
>
> But Greg claims that this is incorrect usage of sysfs API:
>
>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> usage of the api.
> I think this means that sysfs callers must not try to create the same
> thing twice.
>
> Either way user-space code must not be able to triggers WARNINGs in
> kernel. If it does than this is something to fix in kernel.

I guess that this warning was added more recently as I've not seen it 
before. My expectation is that it will return -EEXIST and not print a 
warning there. To avoid that we would have to create a new list of GFS2 
superblocks, and check the list for each mount I think. We could do 
that, but it seems a bit odd to duplicate code that is already there and 
working.

So it sounds like a case of differing assumptions about what is a valid 
use of the sysfs api. Shouldn't be too hard to fix though,

Steve.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Steven Whitehouse]

Hi,


On 05/04/18 09:52, Dmitry Vyukov wrote:
> On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>> Hi,
>>
>>
>>
>> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>> wrote:
>>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot hit the following crash on upstream commit
>>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>>>> Merge tag 'ext4_for_linus' of
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>>> syzbot dashboard link:
>>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>>
>>>>> C reproducer:
>>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>>> syzkaller reproducer:
>>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>>> Raw console output:
>>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>>> Kernel config:
>>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>>
>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>> commit:
>>>>> Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>>> details.
>>>>> If you forward the report, please keep this part and the footer.
>>>>>
>>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>>> ------------[ cut here ]------------
>>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>>> register
>>>>> things with the same name in the same directory.
>>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>>
>>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>>    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>>    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>>    create_dir lib/kobject.c:69 [inline]
>>>>>    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>>    kobject_add_varg lib/kobject.c:364 [inline]
>>>>>    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>>    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>>    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>>    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>> usage of the api.
>>> Then +gfs2 maintainers.
>>>
>>>> Now if we should turn this into a non-WARN message, that's a different
>>>> thing, I'll gladly take a patch for that.
>>> If it's API usage bug in higher level code, then I think WARN is a
>>> proper thing. We already had similar ones and they were fixed.
>>
>> I'm trying to figure out what the test is doing, but it is not very clear.
>> At a guess I'd say that perhaps it is trying to mount multiple filesystems
>> with the same label? If that is the case then it is not allowed, and it
>> should be caught be the sysfs code and result in a refusal to mount, which
>> is what I think I see here. Knowing which sysfs directory is involved would
>> allow us to confirm, but I suspect that the test needs altering to give each
>> gfs2 mount a different label at an initial guess,
>
> Hi Steve,
>
> But Greg claims that this is incorrect usage of sysfs API:
>
>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> usage of the api.
> I think this means that sysfs callers must not try to create the same
> thing twice.
>
> Either way user-space code must not be able to triggers WARNINGs in
> kernel. If it does than this is something to fix in kernel.

I guess that this warning was added more recently as I've not seen it 
before. My expectation is that it will return -EEXIST and not print a 
warning there. To avoid that we would have to create a new list of GFS2 
superblocks, and check the list for each mount I think. We could do 
that, but it seems a bit odd to duplicate code that is already there and 
working.

So it sounds like a case of differing assumptions about what is a valid 
use of the sysfs api. Shouldn't be too hard to fix though,

Steve.

Re: WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 11:00 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> Hi,
>
>
>
> On 05/04/18 09:52, Dmitry Vyukov wrote:
>>
>> On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>>>
>>>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>>> wrote:
>>>>>
>>>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> syzbot hit the following crash on upstream commit
>>>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018
>>>>>> +0000)
>>>>>> Merge tag 'ext4_for_linus' of
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>>>> syzbot dashboard link:
>>>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>>>
>>>>>> C reproducer:
>>>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>>>> syzkaller reproducer:
>>>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>>>> Raw console output:
>>>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>>>> Kernel config:
>>>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>>>
>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>>> commit:
>>>>>> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>>>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>>>> details.
>>>>>> If you forward the report, please keep this part and the footer.
>>>>>>
>>>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>>>> ------------[ cut here ]------------
>>>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>>>> register
>>>>>> things with the same name in the same directory.
>>>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>>>
>>>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>>>    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>>>    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>>>    create_dir lib/kobject.c:69 [inline]
>>>>>>    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>>>    kobject_add_varg lib/kobject.c:364 [inline]
>>>>>>    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>>>    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>>>    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>>>    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>>>
>>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>>> usage of the api.
>>>>
>>>> Then +gfs2 maintainers.
>>>>
>>>>> Now if we should turn this into a non-WARN message, that's a different
>>>>> thing, I'll gladly take a patch for that.
>>>>
>>>> If it's API usage bug in higher level code, then I think WARN is a
>>>> proper thing. We already had similar ones and they were fixed.
>>>
>>>
>>> I'm trying to figure out what the test is doing, but it is not very
>>> clear.
>>> At a guess I'd say that perhaps it is trying to mount multiple
>>> filesystems
>>> with the same label? If that is the case then it is not allowed, and it
>>> should be caught be the sysfs code and result in a refusal to mount,
>>> which
>>> is what I think I see here. Knowing which sysfs directory is involved
>>> would
>>> allow us to confirm, but I suspect that the test needs altering to give
>>> each
>>> gfs2 mount a different label at an initial guess,
>>
>>
>> Hi Steve,
>>
>> But Greg claims that this is incorrect usage of sysfs API:
>>
>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> usage of the api.
>>
>> I think this means that sysfs callers must not try to create the same
>> thing twice.
>>
>> Either way user-space code must not be able to triggers WARNINGs in
>> kernel. If it does than this is something to fix in kernel.
>
>
> I guess that this warning was added more recently as I've not seen it
> before. My expectation is that it will return -EEXIST and not print a
> warning there. To avoid that we would have to create a new list of GFS2
> superblocks, and check the list for each mount I think. We could do that,
> but it seems a bit odd to duplicate code that is already there and working.
>
> So it sounds like a case of differing assumptions about what is a valid use
> of the sysfs api. Shouldn't be too hard to fix though,


Greg?

Should we go with your other option of demoting WARNING to pr_err
then? I don't how many real bugs that warning caught versus callers
just properly handle EEXIST.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 11:00 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> Hi,
>
>
>
> On 05/04/18 09:52, Dmitry Vyukov wrote:
>>
>> On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>>>
>>>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>>> wrote:
>>>>>
>>>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> syzbot hit the following crash on upstream commit
>>>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018
>>>>>> +0000)
>>>>>> Merge tag 'ext4_for_linus' of
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>>>> syzbot dashboard link:
>>>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>>>
>>>>>> C reproducer:
>>>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>>>> syzkaller reproducer:
>>>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>>>> Raw console output:
>>>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>>>> Kernel config:
>>>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>>>
>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>>> commit:
>>>>>> Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>>>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>>>> details.
>>>>>> If you forward the report, please keep this part and the footer.
>>>>>>
>>>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>>>> ------------[ cut here ]------------
>>>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>>>> register
>>>>>> things with the same name in the same directory.
>>>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>>>
>>>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>>>    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>>>    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>>>    create_dir lib/kobject.c:69 [inline]
>>>>>>    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>>>    kobject_add_varg lib/kobject.c:364 [inline]
>>>>>>    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>>>    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>>>    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>>>    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>>>
>>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>>> usage of the api.
>>>>
>>>> Then +gfs2 maintainers.
>>>>
>>>>> Now if we should turn this into a non-WARN message, that's a different
>>>>> thing, I'll gladly take a patch for that.
>>>>
>>>> If it's API usage bug in higher level code, then I think WARN is a
>>>> proper thing. We already had similar ones and they were fixed.
>>>
>>>
>>> I'm trying to figure out what the test is doing, but it is not very
>>> clear.
>>> At a guess I'd say that perhaps it is trying to mount multiple
>>> filesystems
>>> with the same label? If that is the case then it is not allowed, and it
>>> should be caught be the sysfs code and result in a refusal to mount,
>>> which
>>> is what I think I see here. Knowing which sysfs directory is involved
>>> would
>>> allow us to confirm, but I suspect that the test needs altering to give
>>> each
>>> gfs2 mount a different label at an initial guess,
>>
>>
>> Hi Steve,
>>
>> But Greg claims that this is incorrect usage of sysfs API:
>>
>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> usage of the api.
>>
>> I think this means that sysfs callers must not try to create the same
>> thing twice.
>>
>> Either way user-space code must not be able to triggers WARNINGs in
>> kernel. If it does than this is something to fix in kernel.
>
>
> I guess that this warning was added more recently as I've not seen it
> before. My expectation is that it will return -EEXIST and not print a
> warning there. To avoid that we would have to create a new list of GFS2
> superblocks, and check the list for each mount I think. We could do that,
> but it seems a bit odd to duplicate code that is already there and working.
>
> So it sounds like a case of differing assumptions about what is a valid use
> of the sysfs api. Shouldn't be too hard to fix though,


Greg?

Should we go with your other option of demoting WARNING to pr_err
then? I don't how many real bugs that warning caught versus callers
just properly handle EEXIST.

Re: WARNING: kobject bug in sysfs_warn_dup

[Greg KH]

On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
> Hi,
> 
> 
> On 05/04/18 09:52, Dmitry Vyukov wrote:
> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> > > Hi,
> > > 
> > > 
> > > 
> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
> > > > wrote:
> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > syzbot hit the following crash on upstream commit
> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
> > > > > > Merge tag 'ext4_for_linus' of
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> > > > > > syzbot dashboard link:
> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
> > > > > > 
> > > > > > C reproducer:
> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
> > > > > > syzkaller reproducer:
> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
> > > > > > Raw console output:
> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
> > > > > > Kernel config:
> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
> > > > > > compiler: gcc (GCC) 7.1.1 20170620
> > > > > > 
> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
> > > > > > commit:
> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
> > > > > > It will help syzbot understand when the bug is fixed. See footer for
> > > > > > details.
> > > > > > If you forward the report, please keep this part and the footer.
> > > > > > 
> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> > > > > > ------------[ cut here ]------------
> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
> > > > > > register
> > > > > > things with the same name in the same directory.
> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
> > > > > > Kernel panic - not syncing: panic_on_warn set ...
> > > > > > 
> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
> > > > > >    create_dir lib/kobject.c:69 [inline]
> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> > > > > usage of the api.
> > > > Then +gfs2 maintainers.
> > > > 
> > > > > Now if we should turn this into a non-WARN message, that's a different
> > > > > thing, I'll gladly take a patch for that.
> > > > If it's API usage bug in higher level code, then I think WARN is a
> > > > proper thing. We already had similar ones and they were fixed.
> > > 
> > > I'm trying to figure out what the test is doing, but it is not very clear.
> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
> > > with the same label? If that is the case then it is not allowed, and it
> > > should be caught be the sysfs code and result in a refusal to mount, which
> > > is what I think I see here. Knowing which sysfs directory is involved would
> > > allow us to confirm, but I suspect that the test needs altering to give each
> > > gfs2 mount a different label at an initial guess,
> > 
> > Hi Steve,
> > 
> > But Greg claims that this is incorrect usage of sysfs API:
> > 
> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> > > usage of the api.
> > I think this means that sysfs callers must not try to create the same
> > thing twice.
> > 
> > Either way user-space code must not be able to triggers WARNINGs in
> > kernel. If it does than this is something to fix in kernel.
> 
> I guess that this warning was added more recently as I've not seen it
> before.

No, it has been there since at least the 3.13 kernel release (back in
2013), which is where it got moved to a separate function, but the logic
has been around in the kernel tree for much longer than that as seen in
commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
separate function")

> My expectation is that it will return -EEXIST and not print a
> warning there. To avoid that we would have to create a new list of GFS2
> superblocks, and check the list for each mount I think. We could do that,
> but it seems a bit odd to duplicate code that is already there and working.

Don't you have a list of the "names" of the things you are creating
somewhere?  Or are you relying on sysfs to do your housekeeping for you?

Also, why did this trigger a syzbot report?  It's only a dump_stack()
reference, one showing that yes, this is something that should not be
done, but the kernel keeps on working afterward.

thanks,

greg k-h

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Greg KH]

On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
> Hi,
> 
> 
> On 05/04/18 09:52, Dmitry Vyukov wrote:
> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> > > Hi,
> > > 
> > > 
> > > 
> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
> > > > wrote:
> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > syzbot hit the following crash on upstream commit
> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
> > > > > > Merge tag 'ext4_for_linus' of
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> > > > > > syzbot dashboard link:
> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
> > > > > > 
> > > > > > C reproducer:
> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
> > > > > > syzkaller reproducer:
> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
> > > > > > Raw console output:
> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
> > > > > > Kernel config:
> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
> > > > > > compiler: gcc (GCC) 7.1.1 20170620
> > > > > > 
> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
> > > > > > commit:
> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
> > > > > > It will help syzbot understand when the bug is fixed. See footer for
> > > > > > details.
> > > > > > If you forward the report, please keep this part and the footer.
> > > > > > 
> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> > > > > > ------------[ cut here ]------------
> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
> > > > > > register
> > > > > > things with the same name in the same directory.
> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
> > > > > > Kernel panic - not syncing: panic_on_warn set ...
> > > > > > 
> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
> > > > > >    create_dir lib/kobject.c:69 [inline]
> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> > > > > usage of the api.
> > > > Then +gfs2 maintainers.
> > > > 
> > > > > Now if we should turn this into a non-WARN message, that's a different
> > > > > thing, I'll gladly take a patch for that.
> > > > If it's API usage bug in higher level code, then I think WARN is a
> > > > proper thing. We already had similar ones and they were fixed.
> > > 
> > > I'm trying to figure out what the test is doing, but it is not very clear.
> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
> > > with the same label? If that is the case then it is not allowed, and it
> > > should be caught be the sysfs code and result in a refusal to mount, which
> > > is what I think I see here. Knowing which sysfs directory is involved would
> > > allow us to confirm, but I suspect that the test needs altering to give each
> > > gfs2 mount a different label at an initial guess,
> > 
> > Hi Steve,
> > 
> > But Greg claims that this is incorrect usage of sysfs API:
> > 
> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> > > usage of the api.
> > I think this means that sysfs callers must not try to create the same
> > thing twice.
> > 
> > Either way user-space code must not be able to triggers WARNINGs in
> > kernel. If it does than this is something to fix in kernel.
> 
> I guess that this warning was added more recently as I've not seen it
> before.

No, it has been there since at least the 3.13 kernel release (back in
2013), which is where it got moved to a separate function, but the logic
has been around in the kernel tree for much longer than that as seen in
commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
separate function")

> My expectation is that it will return -EEXIST and not print a
> warning there. To avoid that we would have to create a new list of GFS2
> superblocks, and check the list for each mount I think. We could do that,
> but it seems a bit odd to duplicate code that is already there and working.

Don't you have a list of the "names" of the things you are creating
somewhere?  Or are you relying on sysfs to do your housekeeping for you?

Also, why did this trigger a syzbot report?  It's only a dump_stack()
reference, one showing that yes, this is something that should not be
done, but the kernel keeps on working afterward.

thanks,

greg k-h

Re: WARNING: kobject bug in sysfs_warn_dup

[Steven Whitehouse]

Hi,


On 05/04/18 14:34, Greg KH wrote:
> On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
>> Hi,
>>
>>
>> On 05/04/18 09:52, Dmitry Vyukov wrote:
>>> On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>>>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>>>> wrote:
>>>>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> syzbot hit the following crash on upstream commit
>>>>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>>>>>> Merge tag 'ext4_for_linus' of
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>>>>> syzbot dashboard link:
>>>>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>>>>
>>>>>>> C reproducer:
>>>>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>>>>> syzkaller reproducer:
>>>>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>>>>> Raw console output:
>>>>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>>>>> Kernel config:
>>>>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>>>>
>>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>>>> commit:
>>>>>>> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>>>>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>>>>> details.
>>>>>>> If you forward the report, please keep this part and the footer.
>>>>>>>
>>>>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>>>>> ------------[ cut here ]------------
>>>>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>>>>> register
>>>>>>> things with the same name in the same directory.
>>>>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>>>>
>>>>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>>>>     sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>>>>     sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>>>>     create_dir lib/kobject.c:69 [inline]
>>>>>>>     kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>>>>     kobject_add_varg lib/kobject.c:364 [inline]
>>>>>>>     kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>>>>     gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>>>>     fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>>>>     gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>>>> usage of the api.
>>>>> Then +gfs2 maintainers.
>>>>>
>>>>>> Now if we should turn this into a non-WARN message, that's a different
>>>>>> thing, I'll gladly take a patch for that.
>>>>> If it's API usage bug in higher level code, then I think WARN is a
>>>>> proper thing. We already had similar ones and they were fixed.
>>>> I'm trying to figure out what the test is doing, but it is not very clear.
>>>> At a guess I'd say that perhaps it is trying to mount multiple filesystems
>>>> with the same label? If that is the case then it is not allowed, and it
>>>> should be caught be the sysfs code and result in a refusal to mount, which
>>>> is what I think I see here. Knowing which sysfs directory is involved would
>>>> allow us to confirm, but I suspect that the test needs altering to give each
>>>> gfs2 mount a different label at an initial guess,
>>> Hi Steve,
>>>
>>> But Greg claims that this is incorrect usage of sysfs API:
>>>
>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>> usage of the api.
>>> I think this means that sysfs callers must not try to create the same
>>> thing twice.
>>>
>>> Either way user-space code must not be able to triggers WARNINGs in
>>> kernel. If it does than this is something to fix in kernel.
>> I guess that this warning was added more recently as I've not seen it
>> before.
> No, it has been there since at least the 3.13 kernel release (back in
> 2013), which is where it got moved to a separate function, but the logic
> has been around in the kernel tree for much longer than that as seen in
> commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
> separate function")
>
>> My expectation is that it will return -EEXIST and not print a
>> warning there. To avoid that we would have to create a new list of GFS2
>> superblocks, and check the list for each mount I think. We could do that,
>> but it seems a bit odd to duplicate code that is already there and working.
> Don't you have a list of the "names" of the things you are creating
> somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>
> Also, why did this trigger a syzbot report?  It's only a dump_stack()
> reference, one showing that yes, this is something that should not be
> done, but the kernel keeps on working afterward.
>
> thanks,
>
> greg k-h

Unfortunately, no. We don't have the list of names elsewhere. The names 
are used as a cluster-wide ID, so not having duplicates on a single node 
is a good thing :-) The name is effectively the same as the fs label. We 
could create a list - while sysfs does the job for us, we've not needed 
to do that though,

Steve.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Steven Whitehouse]

Hi,


On 05/04/18 14:34, Greg KH wrote:
> On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
>> Hi,
>>
>>
>> On 05/04/18 09:52, Dmitry Vyukov wrote:
>>> On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>>>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>>>> wrote:
>>>>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> syzbot hit the following crash on upstream commit
>>>>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>>>>>> Merge tag 'ext4_for_linus' of
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>>>>>> syzbot dashboard link:
>>>>>>> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>>>>>>
>>>>>>> C reproducer:
>>>>>>> https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>>>>>> syzkaller reproducer:
>>>>>>> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>>>>>> Raw console output:
>>>>>>> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>>>>>> Kernel config:
>>>>>>> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>>>>
>>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>>>> commit:
>>>>>>> Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>>>>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>>>>> details.
>>>>>>> If you forward the report, please keep this part and the footer.
>>>>>>>
>>>>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>>>>> ------------[ cut here ]------------
>>>>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>>>>> register
>>>>>>> things with the same name in the same directory.
>>>>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>>>>
>>>>>>> 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+0x1a7/0x27d lib/dump_stack.c:53
>>>>>>>     sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>>>>     sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>>>>     create_dir lib/kobject.c:69 [inline]
>>>>>>>     kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>>>>     kobject_add_varg lib/kobject.c:364 [inline]
>>>>>>>     kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>>>>     gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>>>>     fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>>>>     gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>>>> usage of the api.
>>>>> Then +gfs2 maintainers.
>>>>>
>>>>>> Now if we should turn this into a non-WARN message, that's a different
>>>>>> thing, I'll gladly take a patch for that.
>>>>> If it's API usage bug in higher level code, then I think WARN is a
>>>>> proper thing. We already had similar ones and they were fixed.
>>>> I'm trying to figure out what the test is doing, but it is not very clear.
>>>> At a guess I'd say that perhaps it is trying to mount multiple filesystems
>>>> with the same label? If that is the case then it is not allowed, and it
>>>> should be caught be the sysfs code and result in a refusal to mount, which
>>>> is what I think I see here. Knowing which sysfs directory is involved would
>>>> allow us to confirm, but I suspect that the test needs altering to give each
>>>> gfs2 mount a different label at an initial guess,
>>> Hi Steve,
>>>
>>> But Greg claims that this is incorrect usage of sysfs API:
>>>
>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>> usage of the api.
>>> I think this means that sysfs callers must not try to create the same
>>> thing twice.
>>>
>>> Either way user-space code must not be able to triggers WARNINGs in
>>> kernel. If it does than this is something to fix in kernel.
>> I guess that this warning was added more recently as I've not seen it
>> before.
> No, it has been there since at least the 3.13 kernel release (back in
> 2013), which is where it got moved to a separate function, but the logic
> has been around in the kernel tree for much longer than that as seen in
> commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
> separate function")
>
>> My expectation is that it will return -EEXIST and not print a
>> warning there. To avoid that we would have to create a new list of GFS2
>> superblocks, and check the list for each mount I think. We could do that,
>> but it seems a bit odd to duplicate code that is already there and working.
> Don't you have a list of the "names" of the things you are creating
> somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>
> Also, why did this trigger a syzbot report?  It's only a dump_stack()
> reference, one showing that yes, this is something that should not be
> done, but the kernel keeps on working afterward.
>
> thanks,
>
> greg k-h

Unfortunately, no. We don't have the list of names elsewhere. The names 
are used as a cluster-wide ID, so not having duplicates on a single node 
is a good thing :-) The name is effectively the same as the fs label. We 
could create a list - while sysfs does the job for us, we've not needed 
to do that though,

Steve.

Re: WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 3:34 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
>> Hi,
>>
>>
>> On 05/04/18 09:52, Dmitry Vyukov wrote:
>> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>> > > Hi,
>> > >
>> > >
>> > >
>> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
>> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>> > > > wrote:
>> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>> > > > > > Hello,
>> > > > > >
>> > > > > > syzbot hit the following crash on upstream commit
>> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>> > > > > > Merge tag 'ext4_for_linus' of
>> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>> > > > > > syzbot dashboard link:
>> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>> > > > > >
>> > > > > > C reproducer:
>> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>> > > > > > syzkaller reproducer:
>> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>> > > > > > Raw console output:
>> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>> > > > > > Kernel config:
>> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>> > > > > > compiler: gcc (GCC) 7.1.1 20170620
>> > > > > >
>> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
>> > > > > > commit:
>> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>> > > > > > It will help syzbot understand when the bug is fixed. See footer for
>> > > > > > details.
>> > > > > > If you forward the report, please keep this part and the footer.
>> > > > > >
>> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>> > > > > > ------------[ cut here ]------------
>> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
>> > > > > > register
>> > > > > > things with the same name in the same directory.
>> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>> > > > > > Kernel panic - not syncing: panic_on_warn set ...
>> > > > > >
>> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
>> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>> > > > > >    create_dir lib/kobject.c:69 [inline]
>> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
>> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> > > > > usage of the api.
>> > > > Then +gfs2 maintainers.
>> > > >
>> > > > > Now if we should turn this into a non-WARN message, that's a different
>> > > > > thing, I'll gladly take a patch for that.
>> > > > If it's API usage bug in higher level code, then I think WARN is a
>> > > > proper thing. We already had similar ones and they were fixed.
>> > >
>> > > I'm trying to figure out what the test is doing, but it is not very clear.
>> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
>> > > with the same label? If that is the case then it is not allowed, and it
>> > > should be caught be the sysfs code and result in a refusal to mount, which
>> > > is what I think I see here. Knowing which sysfs directory is involved would
>> > > allow us to confirm, but I suspect that the test needs altering to give each
>> > > gfs2 mount a different label at an initial guess,
>> >
>> > Hi Steve,
>> >
>> > But Greg claims that this is incorrect usage of sysfs API:
>> >
>> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> > > usage of the api.
>> > I think this means that sysfs callers must not try to create the same
>> > thing twice.
>> >
>> > Either way user-space code must not be able to triggers WARNINGs in
>> > kernel. If it does than this is something to fix in kernel.
>>
>> I guess that this warning was added more recently as I've not seen it
>> before.
>
> No, it has been there since at least the 3.13 kernel release (back in
> 2013), which is where it got moved to a separate function, but the logic
> has been around in the kernel tree for much longer than that as seen in
> commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
> separate function")
>
>> My expectation is that it will return -EEXIST and not print a
>> warning there. To avoid that we would have to create a new list of GFS2
>> superblocks, and check the list for each mount I think. We could do that,
>> but it seems a bit odd to duplicate code that is already there and working.
>
> Don't you have a list of the "names" of the things you are creating
> somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>
> Also, why did this trigger a syzbot report?  It's only a dump_stack()
> reference, one showing that yes, this is something that should not be
> done, but the kernel keeps on working afterward.

There is a WARN(), not just dump_stack():

                        WARN(1, "%s failed for %s with "
                             "-EEXIST, don't try to register things with "
                             "the same name in the same directory.\n",
                             __func__, kobject_name(kobj));

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 3:34 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
>> Hi,
>>
>>
>> On 05/04/18 09:52, Dmitry Vyukov wrote:
>> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>> > > Hi,
>> > >
>> > >
>> > >
>> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
>> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>> > > > wrote:
>> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>> > > > > > Hello,
>> > > > > >
>> > > > > > syzbot hit the following crash on upstream commit
>> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>> > > > > > Merge tag 'ext4_for_linus' of
>> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>> > > > > > syzbot dashboard link:
>> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>> > > > > >
>> > > > > > C reproducer:
>> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>> > > > > > syzkaller reproducer:
>> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>> > > > > > Raw console output:
>> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>> > > > > > Kernel config:
>> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>> > > > > > compiler: gcc (GCC) 7.1.1 20170620
>> > > > > >
>> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
>> > > > > > commit:
>> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>> > > > > > It will help syzbot understand when the bug is fixed. See footer for
>> > > > > > details.
>> > > > > > If you forward the report, please keep this part and the footer.
>> > > > > >
>> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>> > > > > > ------------[ cut here ]------------
>> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
>> > > > > > register
>> > > > > > things with the same name in the same directory.
>> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>> > > > > > Kernel panic - not syncing: panic_on_warn set ...
>> > > > > >
>> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
>> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>> > > > > >    create_dir lib/kobject.c:69 [inline]
>> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
>> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> > > > > usage of the api.
>> > > > Then +gfs2 maintainers.
>> > > >
>> > > > > Now if we should turn this into a non-WARN message, that's a different
>> > > > > thing, I'll gladly take a patch for that.
>> > > > If it's API usage bug in higher level code, then I think WARN is a
>> > > > proper thing. We already had similar ones and they were fixed.
>> > >
>> > > I'm trying to figure out what the test is doing, but it is not very clear.
>> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
>> > > with the same label? If that is the case then it is not allowed, and it
>> > > should be caught be the sysfs code and result in a refusal to mount, which
>> > > is what I think I see here. Knowing which sysfs directory is involved would
>> > > allow us to confirm, but I suspect that the test needs altering to give each
>> > > gfs2 mount a different label at an initial guess,
>> >
>> > Hi Steve,
>> >
>> > But Greg claims that this is incorrect usage of sysfs API:
>> >
>> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> > > usage of the api.
>> > I think this means that sysfs callers must not try to create the same
>> > thing twice.
>> >
>> > Either way user-space code must not be able to triggers WARNINGs in
>> > kernel. If it does than this is something to fix in kernel.
>>
>> I guess that this warning was added more recently as I've not seen it
>> before.
>
> No, it has been there since at least the 3.13 kernel release (back in
> 2013), which is where it got moved to a separate function, but the logic
> has been around in the kernel tree for much longer than that as seen in
> commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
> separate function")
>
>> My expectation is that it will return -EEXIST and not print a
>> warning there. To avoid that we would have to create a new list of GFS2
>> superblocks, and check the list for each mount I think. We could do that,
>> but it seems a bit odd to duplicate code that is already there and working.
>
> Don't you have a list of the "names" of the things you are creating
> somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>
> Also, why did this trigger a syzbot report?  It's only a dump_stack()
> reference, one showing that yes, this is something that should not be
> done, but the kernel keeps on working afterward.

There is a WARN(), not just dump_stack():

                        WARN(1, "%s failed for %s with "
                             "-EEXIST, don't try to register things with "
                             "the same name in the same directory.\n",
                             __func__, kobject_name(kobj));

Re: WARNING: kobject bug in sysfs_warn_dup

[Greg KH]

On Thu, Apr 05, 2018 at 03:59:58PM +0200, Dmitry Vyukov wrote:
> On Thu, Apr 5, 2018 at 3:34 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
> >> Hi,
> >>
> >>
> >> On 05/04/18 09:52, Dmitry Vyukov wrote:
> >> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> >> > > Hi,
> >> > >
> >> > >
> >> > >
> >> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
> >> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
> >> > > > wrote:
> >> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
> >> > > > > > Hello,
> >> > > > > >
> >> > > > > > syzbot hit the following crash on upstream commit
> >> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
> >> > > > > > Merge tag 'ext4_for_linus' of
> >> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> >> > > > > > syzbot dashboard link:
> >> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
> >> > > > > >
> >> > > > > > C reproducer:
> >> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
> >> > > > > > syzkaller reproducer:
> >> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
> >> > > > > > Raw console output:
> >> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
> >> > > > > > Kernel config:
> >> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
> >> > > > > > compiler: gcc (GCC) 7.1.1 20170620
> >> > > > > >
> >> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
> >> > > > > > commit:
> >> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
> >> > > > > > It will help syzbot understand when the bug is fixed. See footer for
> >> > > > > > details.
> >> > > > > > If you forward the report, please keep this part and the footer.
> >> > > > > >
> >> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> >> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> >> > > > > > ------------[ cut here ]------------
> >> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
> >> > > > > > register
> >> > > > > > things with the same name in the same directory.
> >> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
> >> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
> >> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> >> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
> >> > > > > > Kernel panic - not syncing: panic_on_warn set ...
> >> > > > > >
> >> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
> >> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
> >> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
> >> > > > > >    create_dir lib/kobject.c:69 [inline]
> >> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
> >> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
> >> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
> >> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
> >> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
> >> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
> >> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> >> > > > > usage of the api.
> >> > > > Then +gfs2 maintainers.
> >> > > >
> >> > > > > Now if we should turn this into a non-WARN message, that's a different
> >> > > > > thing, I'll gladly take a patch for that.
> >> > > > If it's API usage bug in higher level code, then I think WARN is a
> >> > > > proper thing. We already had similar ones and they were fixed.
> >> > >
> >> > > I'm trying to figure out what the test is doing, but it is not very clear.
> >> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
> >> > > with the same label? If that is the case then it is not allowed, and it
> >> > > should be caught be the sysfs code and result in a refusal to mount, which
> >> > > is what I think I see here. Knowing which sysfs directory is involved would
> >> > > allow us to confirm, but I suspect that the test needs altering to give each
> >> > > gfs2 mount a different label at an initial guess,
> >> >
> >> > Hi Steve,
> >> >
> >> > But Greg claims that this is incorrect usage of sysfs API:
> >> >
> >> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> >> > > usage of the api.
> >> > I think this means that sysfs callers must not try to create the same
> >> > thing twice.
> >> >
> >> > Either way user-space code must not be able to triggers WARNINGs in
> >> > kernel. If it does than this is something to fix in kernel.
> >>
> >> I guess that this warning was added more recently as I've not seen it
> >> before.
> >
> > No, it has been there since at least the 3.13 kernel release (back in
> > 2013), which is where it got moved to a separate function, but the logic
> > has been around in the kernel tree for much longer than that as seen in
> > commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
> > separate function")
> >
> >> My expectation is that it will return -EEXIST and not print a
> >> warning there. To avoid that we would have to create a new list of GFS2
> >> superblocks, and check the list for each mount I think. We could do that,
> >> but it seems a bit odd to duplicate code that is already there and working.
> >
> > Don't you have a list of the "names" of the things you are creating
> > somewhere?  Or are you relying on sysfs to do your housekeeping for you?
> >
> > Also, why did this trigger a syzbot report?  It's only a dump_stack()
> > reference, one showing that yes, this is something that should not be
> > done, but the kernel keeps on working afterward.
> 
> There is a WARN(), not just dump_stack():
> 
>                         WARN(1, "%s failed for %s with "
>                              "-EEXIST, don't try to register things with "
>                              "the same name in the same directory.\n",
>                              __func__, kobject_name(kobj));

Ah, that's a kobject warning, not a sysfs one.  Was looking too far down
the call chain.  We can change this to be dump_stack() as well if you
think that would help out.  Maybe remove it entirely as sysfs already
does dump the stack?

thanks,

greg k-h

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Greg KH]

On Thu, Apr 05, 2018 at 03:59:58PM +0200, Dmitry Vyukov wrote:
> On Thu, Apr 5, 2018 at 3:34 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 05, 2018 at 10:00:04AM +0100, Steven Whitehouse wrote:
> >> Hi,
> >>
> >>
> >> On 05/04/18 09:52, Dmitry Vyukov wrote:
> >> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> >> > > Hi,
> >> > >
> >> > >
> >> > >
> >> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
> >> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
> >> > > > wrote:
> >> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
> >> > > > > > Hello,
> >> > > > > >
> >> > > > > > syzbot hit the following crash on upstream commit
> >> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
> >> > > > > > Merge tag 'ext4_for_linus' of
> >> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> >> > > > > > syzbot dashboard link:
> >> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
> >> > > > > >
> >> > > > > > C reproducer:
> >> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
> >> > > > > > syzkaller reproducer:
> >> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
> >> > > > > > Raw console output:
> >> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
> >> > > > > > Kernel config:
> >> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
> >> > > > > > compiler: gcc (GCC) 7.1.1 20170620
> >> > > > > >
> >> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
> >> > > > > > commit:
> >> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
> >> > > > > > It will help syzbot understand when the bug is fixed. See footer for
> >> > > > > > details.
> >> > > > > > If you forward the report, please keep this part and the footer.
> >> > > > > >
> >> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> >> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> >> > > > > > ------------[ cut here ]------------
> >> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
> >> > > > > > register
> >> > > > > > things with the same name in the same directory.
> >> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
> >> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
> >> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> >> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
> >> > > > > > Kernel panic - not syncing: panic_on_warn set ...
> >> > > > > >
> >> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
> >> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
> >> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
> >> > > > > >    create_dir lib/kobject.c:69 [inline]
> >> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
> >> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
> >> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
> >> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
> >> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
> >> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
> >> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> >> > > > > usage of the api.
> >> > > > Then +gfs2 maintainers.
> >> > > >
> >> > > > > Now if we should turn this into a non-WARN message, that's a different
> >> > > > > thing, I'll gladly take a patch for that.
> >> > > > If it's API usage bug in higher level code, then I think WARN is a
> >> > > > proper thing. We already had similar ones and they were fixed.
> >> > >
> >> > > I'm trying to figure out what the test is doing, but it is not very clear.
> >> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
> >> > > with the same label? If that is the case then it is not allowed, and it
> >> > > should be caught be the sysfs code and result in a refusal to mount, which
> >> > > is what I think I see here. Knowing which sysfs directory is involved would
> >> > > allow us to confirm, but I suspect that the test needs altering to give each
> >> > > gfs2 mount a different label at an initial guess,
> >> >
> >> > Hi Steve,
> >> >
> >> > But Greg claims that this is incorrect usage of sysfs API:
> >> >
> >> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
> >> > > usage of the api.
> >> > I think this means that sysfs callers must not try to create the same
> >> > thing twice.
> >> >
> >> > Either way user-space code must not be able to triggers WARNINGs in
> >> > kernel. If it does than this is something to fix in kernel.
> >>
> >> I guess that this warning was added more recently as I've not seen it
> >> before.
> >
> > No, it has been there since at least the 3.13 kernel release (back in
> > 2013), which is where it got moved to a separate function, but the logic
> > has been around in the kernel tree for much longer than that as seen in
> > commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
> > separate function")
> >
> >> My expectation is that it will return -EEXIST and not print a
> >> warning there. To avoid that we would have to create a new list of GFS2
> >> superblocks, and check the list for each mount I think. We could do that,
> >> but it seems a bit odd to duplicate code that is already there and working.
> >
> > Don't you have a list of the "names" of the things you are creating
> > somewhere?  Or are you relying on sysfs to do your housekeeping for you?
> >
> > Also, why did this trigger a syzbot report?  It's only a dump_stack()
> > reference, one showing that yes, this is something that should not be
> > done, but the kernel keeps on working afterward.
> 
> There is a WARN(), not just dump_stack():
> 
>                         WARN(1, "%s failed for %s with "
>                              "-EEXIST, don't try to register things with "
>                              "the same name in the same directory.\n",
>                              __func__, kobject_name(kobj));

Ah, that's a kobject warning, not a sysfs one.  Was looking too far down
the call chain.  We can change this to be dump_stack() as well if you
think that would help out.  Maybe remove it entirely as sysfs already
does dump the stack?

thanks,

greg k-h

Re: WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 4:02 AM, syzbot
<syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
> Merge tag 'ext4_for_linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=9118669095563550941
> compiler: gcc (GCC) 7.1.1 20170620
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.

#syz dup: WARNING: kobject bug in gfs2_sys_fs_add

> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> ------------[ cut here ]------------
> kobject_add_internal failed for nodev( with -EEXIST, don't try to register
> things with the same name in the same directory.
> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
> Kernel panic - not syncing: panic_on_warn set ...
>
> 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+0x1a7/0x27d lib/dump_stack.c:53
>  sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>  sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>  create_dir lib/kobject.c:69 [inline]
>  kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>  kobject_add_varg lib/kobject.c:364 [inline]
>  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>  mount_fs+0x66/0x2d0 fs/super.c:1222
>  vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037
>  vfs_kern_mount fs/namespace.c:2514 [inline]
>  do_new_mount fs/namespace.c:2517 [inline]
>  do_mount+0xea4/0x2b90 fs/namespace.c:2847
>  ksys_mount+0xab/0x120 fs/namespace.c:3063
>  SYSC_mount fs/namespace.c:3077 [inline]
>  SyS_mount+0x39/0x50 fs/namespace.c:3074
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x4432fa
> RSP: 002b:00007ffda3d84538 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000020001a40 RCX: 00000000004432fa
> RDX: 0000000020001a00 RSI: 0000000020001a40 RDI: 00007ffda3d84550
> RBP: 0000000000000000 R08: 0000000020001f00 R09: 000000000000000a
> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> CPU: 1 PID: 4473 Comm: syzkaller533472 Not tainted 4.16.0+ #15
> ------------[ cut here ]------------
> 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+0x1a7/0x27d lib/dump_stack.c:53
> kobject_add_internal failed for nodev( with -EEXIST, don't try to register
> things with the same name in the same directory.
>  panic+0x1f8/0x42c kernel/panic.c:183
> WARNING: CPU: 0 PID: 4474 at lib/kobject.c:238
> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> Modules linked in:
>  __warn+0x1dc/0x200 kernel/panic.c:547
> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>  report_bug+0x1f4/0x2b0 lib/bug.c:186
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
>  fixup_bug.part.10+0x37/0x80 arch/x86/kernel/traps.c:178
> RIP: 0010:kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> RSP: 0000:ffff8801addaf470 EFLAGS: 00010282
> RAX: dffffc0000000008 RBX: ffff8801d9661110 RCX: ffffffff815b5d2e
> RDX: 0000000000000000 RSI: 1ffff10035bb5e3e RDI: 1ffff10035bb5e13
> RBP: ffff8801addaf568 R08: 1ffff10035bb5dd5 R09: 0000000000000001
> R10: 0000000000000001 R11: 0000000000000000 R12: 1ffff10035bb5e94
> R13: 00000000ffffffef R14: ffff8801d39ae348 R15: 1ffff10035bb5e98
> FS:  0000000001db2880(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:991
> RIP: 0010:kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000019657b0 CR3: 00000001ae0ca000 CR4: 00000000001406f0
> RSP: 0018:ffff8801ade37470 EFLAGS: 00010282
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> RAX: dffffc0000000008 RBX: ffff8801d9459190 RCX: ffffffff815b5d2e
> Call Trace:
> RDX: 0000000000000000 RSI: 1ffff10035bc6e3e RDI: 1ffff10035bc6e13
> RBP: ffff8801ade37568 R08: 1ffff10035bc6dd5 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 1ffff10035bc6e94
> R13: 00000000ffffffef R14: ffff8801d39ae348 R15: 1ffff10035bc6e98
>  kobject_add_varg lib/kobject.c:364 [inline]
>  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>  kobject_add_varg lib/kobject.c:364 [inline]
>  kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>  gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>  fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>  mount_fs+0x66/0x2d0 fs/super.c:1222
>  vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037
>  gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>  vfs_kern_mount fs/namespace.c:2514 [inline]
>  do_new_mount fs/namespace.c:2517 [inline]
>  do_mount+0xea4/0x2b90 fs/namespace.c:2847
>  mount_fs+0x66/0x2d0 fs/super.c:1222
>  vfs_kern_mount.part.26+0xc6/0x4a0 fs/namespace.c:1037
>  vfs_kern_mount fs/namespace.c:2514 [inline]
>  do_new_mount fs/namespace.c:2517 [inline]
>  do_mount+0xea4/0x2b90 fs/namespace.c:2847
>  ksys_mount+0xab/0x120 fs/namespace.c:3063
>  SYSC_mount fs/namespace.c:3077 [inline]
>  SyS_mount+0x39/0x50 fs/namespace.c:3074
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  ksys_mount+0xab/0x120 fs/namespace.c:3063
>  SYSC_mount fs/namespace.c:3077 [inline]
>  SyS_mount+0x39/0x50 fs/namespace.c:3074
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x4432fa
> RSP: 002b:00007ffda3d84538 EFLAGS: 00000286
>  ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000020001a40 RCX: 00000000004432fa
> RDX: 0000000020001a00 RSI: 0000000020001a40 RDI: 00007ffda3d84550
> RBP: 0000000000000000 R08: 0000000020001f00 R09: 000000000000000a
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> RIP: 0033:0x4432fa
> RSP: 002b:00007ffda3d84538 EFLAGS: 00000286
> Code:
>  ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000020001a40 RCX: 00000000004432fa
> 00
> RDX: 0000000020001a00 RSI: 0000000020001a40 RDI: 00007ffda3d84550
> 00
> RBP: 0000000000000000 R08: 0000000020001f00 R09: 000000000000000a
> 00
> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
> 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 aa 00 00 00 48 8b 13 48 c7 c6 80
> 8b d6 87 48 c7 c7 e0 88 d6 87 e8 3c 33 58 fa <0f> 0b e9 1d fb ff ff e8 60 4c
> 88 fa 0f 0b e9 29 fe ff ff e8 54
> ---[ end trace 5eab46a9e10a0c8a ]---
> 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 syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> 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.
>
> --
> 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-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/f4f5e80803d0503e760569105376%40google.com.
> For more options, visit https://groups.google.com/d/optout.

Re: WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 4:23 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> On 05/04/18 09:52, Dmitry Vyukov wrote:
>> >> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>> >> > > Hi,
>> >> > >
>> >> > >
>> >> > >
>> >> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
>> >> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>> >> > > > wrote:
>> >> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>> >> > > > > > Hello,
>> >> > > > > >
>> >> > > > > > syzbot hit the following crash on upstream commit
>> >> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>> >> > > > > > Merge tag 'ext4_for_linus' of
>> >> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>> >> > > > > > syzbot dashboard link:
>> >> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>> >> > > > > >
>> >> > > > > > C reproducer:
>> >> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>> >> > > > > > syzkaller reproducer:
>> >> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>> >> > > > > > Raw console output:
>> >> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>> >> > > > > > Kernel config:
>> >> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>> >> > > > > > compiler: gcc (GCC) 7.1.1 20170620
>> >> > > > > >
>> >> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
>> >> > > > > > commit:
>> >> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>> >> > > > > > It will help syzbot understand when the bug is fixed. See footer for
>> >> > > > > > details.
>> >> > > > > > If you forward the report, please keep this part and the footer.
>> >> > > > > >
>> >> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>> >> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>> >> > > > > > ------------[ cut here ]------------
>> >> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
>> >> > > > > > register
>> >> > > > > > things with the same name in the same directory.
>> >> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>> >> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>> >> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>> >> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>> >> > > > > > Kernel panic - not syncing: panic_on_warn set ...
>> >> > > > > >
>> >> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
>> >> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>> >> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>> >> > > > > >    create_dir lib/kobject.c:69 [inline]
>> >> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>> >> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
>> >> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>> >> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>> >> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>> >> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>> >> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> >> > > > > usage of the api.
>> >> > > > Then +gfs2 maintainers.
>> >> > > >
>> >> > > > > Now if we should turn this into a non-WARN message, that's a different
>> >> > > > > thing, I'll gladly take a patch for that.
>> >> > > > If it's API usage bug in higher level code, then I think WARN is a
>> >> > > > proper thing. We already had similar ones and they were fixed.
>> >> > >
>> >> > > I'm trying to figure out what the test is doing, but it is not very clear.
>> >> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
>> >> > > with the same label? If that is the case then it is not allowed, and it
>> >> > > should be caught be the sysfs code and result in a refusal to mount, which
>> >> > > is what I think I see here. Knowing which sysfs directory is involved would
>> >> > > allow us to confirm, but I suspect that the test needs altering to give each
>> >> > > gfs2 mount a different label at an initial guess,
>> >> >
>> >> > Hi Steve,
>> >> >
>> >> > But Greg claims that this is incorrect usage of sysfs API:
>> >> >
>> >> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> >> > > usage of the api.
>> >> > I think this means that sysfs callers must not try to create the same
>> >> > thing twice.
>> >> >
>> >> > Either way user-space code must not be able to triggers WARNINGs in
>> >> > kernel. If it does than this is something to fix in kernel.
>> >>
>> >> I guess that this warning was added more recently as I've not seen it
>> >> before.
>> >
>> > No, it has been there since at least the 3.13 kernel release (back in
>> > 2013), which is where it got moved to a separate function, but the logic
>> > has been around in the kernel tree for much longer than that as seen in
>> > commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
>> > separate function")
>> >
>> >> My expectation is that it will return -EEXIST and not print a
>> >> warning there. To avoid that we would have to create a new list of GFS2
>> >> superblocks, and check the list for each mount I think. We could do that,
>> >> but it seems a bit odd to duplicate code that is already there and working.
>> >
>> > Don't you have a list of the "names" of the things you are creating
>> > somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>> >
>> > Also, why did this trigger a syzbot report?  It's only a dump_stack()
>> > reference, one showing that yes, this is something that should not be
>> > done, but the kernel keeps on working afterward.
>>
>> There is a WARN(), not just dump_stack():
>>
>>                         WARN(1, "%s failed for %s with "
>>                              "-EEXIST, don't try to register things with "
>>                              "the same name in the same directory.\n",
>>                              __func__, kobject_name(kobj));
>
> Ah, that's a kobject warning, not a sysfs one.  Was looking too far down
> the call chain.  We can change this to be dump_stack() as well if you
> think that would help out.  Maybe remove it entirely as sysfs already
> does dump the stack?


kobject_add is called not only from sysfs, right?

I was just going to send a patch that changes WARN to
pr_err+dump_stack, but noticed that we have 4 active bugs on this
WARNING:

WARNING: kobject bug in gfs2_sys_fs_add
https://syzkaller.appspot.com/bug?id=057673a56dab61b3a447989b67f10b205111c8f4

WARNING: kobject bug in br_add_if
https://syzkaller.appspot.com/bug?id=3e0339080acd6a2a350a900bc6533b03f5498490

WARNING: kobject bug in netdev_queue_update_kobjects
https://syzkaller.appspot.com/bug?id=86a8e2ab50527d5a5eb4fad2fc15df609f22d86a

WARNING: kobject bug in device_add
https://syzkaller.appspot.com/bug?id=57eba87aff7669512fb68e56a932b01805342d13

We want to ignore all of them?
As a side signal none of them got any attention, except Eric noting
that, yes, it is noisy:
https://groups.google.com/d/msg/syzkaller-bugs/XDTC7Iv4IKY/Ab_tgZ4HAQAJ

So I guess I will still mail the patch.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Thu, Apr 5, 2018 at 4:23 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> On 05/04/18 09:52, Dmitry Vyukov wrote:
>> >> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>> >> > > Hi,
>> >> > >
>> >> > >
>> >> > >
>> >> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
>> >> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>> >> > > > wrote:
>> >> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>> >> > > > > > Hello,
>> >> > > > > >
>> >> > > > > > syzbot hit the following crash on upstream commit
>> >> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>> >> > > > > > Merge tag 'ext4_for_linus' of
>> >> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>> >> > > > > > syzbot dashboard link:
>> >> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>> >> > > > > >
>> >> > > > > > C reproducer:
>> >> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>> >> > > > > > syzkaller reproducer:
>> >> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>> >> > > > > > Raw console output:
>> >> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>> >> > > > > > Kernel config:
>> >> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>> >> > > > > > compiler: gcc (GCC) 7.1.1 20170620
>> >> > > > > >
>> >> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
>> >> > > > > > commit:
>> >> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>> >> > > > > > It will help syzbot understand when the bug is fixed. See footer for
>> >> > > > > > details.
>> >> > > > > > If you forward the report, please keep this part and the footer.
>> >> > > > > >
>> >> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>> >> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>> >> > > > > > ------------[ cut here ]------------
>> >> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
>> >> > > > > > register
>> >> > > > > > things with the same name in the same directory.
>> >> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>> >> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>> >> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>> >> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>> >> > > > > > Kernel panic - not syncing: panic_on_warn set ...
>> >> > > > > >
>> >> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
>> >> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>> >> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>> >> > > > > >    create_dir lib/kobject.c:69 [inline]
>> >> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>> >> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
>> >> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>> >> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>> >> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>> >> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>> >> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> >> > > > > usage of the api.
>> >> > > > Then +gfs2 maintainers.
>> >> > > >
>> >> > > > > Now if we should turn this into a non-WARN message, that's a different
>> >> > > > > thing, I'll gladly take a patch for that.
>> >> > > > If it's API usage bug in higher level code, then I think WARN is a
>> >> > > > proper thing. We already had similar ones and they were fixed.
>> >> > >
>> >> > > I'm trying to figure out what the test is doing, but it is not very clear.
>> >> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
>> >> > > with the same label? If that is the case then it is not allowed, and it
>> >> > > should be caught be the sysfs code and result in a refusal to mount, which
>> >> > > is what I think I see here. Knowing which sysfs directory is involved would
>> >> > > allow us to confirm, but I suspect that the test needs altering to give each
>> >> > > gfs2 mount a different label at an initial guess,
>> >> >
>> >> > Hi Steve,
>> >> >
>> >> > But Greg claims that this is incorrect usage of sysfs API:
>> >> >
>> >> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> >> > > usage of the api.
>> >> > I think this means that sysfs callers must not try to create the same
>> >> > thing twice.
>> >> >
>> >> > Either way user-space code must not be able to triggers WARNINGs in
>> >> > kernel. If it does than this is something to fix in kernel.
>> >>
>> >> I guess that this warning was added more recently as I've not seen it
>> >> before.
>> >
>> > No, it has been there since at least the 3.13 kernel release (back in
>> > 2013), which is where it got moved to a separate function, but the logic
>> > has been around in the kernel tree for much longer than that as seen in
>> > commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
>> > separate function")
>> >
>> >> My expectation is that it will return -EEXIST and not print a
>> >> warning there. To avoid that we would have to create a new list of GFS2
>> >> superblocks, and check the list for each mount I think. We could do that,
>> >> but it seems a bit odd to duplicate code that is already there and working.
>> >
>> > Don't you have a list of the "names" of the things you are creating
>> > somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>> >
>> > Also, why did this trigger a syzbot report?  It's only a dump_stack()
>> > reference, one showing that yes, this is something that should not be
>> > done, but the kernel keeps on working afterward.
>>
>> There is a WARN(), not just dump_stack():
>>
>>                         WARN(1, "%s failed for %s with "
>>                              "-EEXIST, don't try to register things with "
>>                              "the same name in the same directory.\n",
>>                              __func__, kobject_name(kobj));
>
> Ah, that's a kobject warning, not a sysfs one.  Was looking too far down
> the call chain.  We can change this to be dump_stack() as well if you
> think that would help out.  Maybe remove it entirely as sysfs already
> does dump the stack?


kobject_add is called not only from sysfs, right?

I was just going to send a patch that changes WARN to
pr_err+dump_stack, but noticed that we have 4 active bugs on this
WARNING:

WARNING: kobject bug in gfs2_sys_fs_add
https://syzkaller.appspot.com/bug?id=057673a56dab61b3a447989b67f10b205111c8f4

WARNING: kobject bug in br_add_if
https://syzkaller.appspot.com/bug?id=3e0339080acd6a2a350a900bc6533b03f5498490

WARNING: kobject bug in netdev_queue_update_kobjects
https://syzkaller.appspot.com/bug?id=86a8e2ab50527d5a5eb4fad2fc15df609f22d86a

WARNING: kobject bug in device_add
https://syzkaller.appspot.com/bug?id=57eba87aff7669512fb68e56a932b01805342d13

We want to ignore all of them?
As a side signal none of them got any attention, except Eric noting
that, yes, it is noisy:
https://groups.google.com/d/msg/syzkaller-bugs/XDTC7Iv4IKY/Ab_tgZ4HAQAJ

So I guess I will still mail the patch.

Re: WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Wed, Apr 11, 2018 at 5:04 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Thu, Apr 5, 2018 at 4:23 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>>> >> On 05/04/18 09:52, Dmitry Vyukov wrote:
>>> >> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>>> >> > > Hi,
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
>>> >> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>> >> > > > wrote:
>>> >> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>> >> > > > > > Hello,
>>> >> > > > > >
>>> >> > > > > > syzbot hit the following crash on upstream commit
>>> >> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>> >> > > > > > Merge tag 'ext4_for_linus' of
>>> >> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>> >> > > > > > syzbot dashboard link:
>>> >> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>> >> > > > > >
>>> >> > > > > > C reproducer:
>>> >> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>> >> > > > > > syzkaller reproducer:
>>> >> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>> >> > > > > > Raw console output:
>>> >> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>> >> > > > > > Kernel config:
>>> >> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>> >> > > > > > compiler: gcc (GCC) 7.1.1 20170620
>>> >> > > > > >
>>> >> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
>>> >> > > > > > commit:
>>> >> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5@syzkaller.appspotmail.com
>>> >> > > > > > It will help syzbot understand when the bug is fixed. See footer for
>>> >> > > > > > details.
>>> >> > > > > > If you forward the report, please keep this part and the footer.
>>> >> > > > > >
>>> >> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>> >> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>> >> > > > > > ------------[ cut here ]------------
>>> >> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>> >> > > > > > register
>>> >> > > > > > things with the same name in the same directory.
>>> >> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>> >> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>> >> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>> >> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>> >> > > > > > Kernel panic - not syncing: panic_on_warn set ...
>>> >> > > > > >
>>> >> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
>>> >> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>> >> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>> >> > > > > >    create_dir lib/kobject.c:69 [inline]
>>> >> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>> >> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
>>> >> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>> >> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>> >> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>> >> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>> >> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> >> > > > > usage of the api.
>>> >> > > > Then +gfs2 maintainers.
>>> >> > > >
>>> >> > > > > Now if we should turn this into a non-WARN message, that's a different
>>> >> > > > > thing, I'll gladly take a patch for that.
>>> >> > > > If it's API usage bug in higher level code, then I think WARN is a
>>> >> > > > proper thing. We already had similar ones and they were fixed.
>>> >> > >
>>> >> > > I'm trying to figure out what the test is doing, but it is not very clear.
>>> >> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
>>> >> > > with the same label? If that is the case then it is not allowed, and it
>>> >> > > should be caught be the sysfs code and result in a refusal to mount, which
>>> >> > > is what I think I see here. Knowing which sysfs directory is involved would
>>> >> > > allow us to confirm, but I suspect that the test needs altering to give each
>>> >> > > gfs2 mount a different label at an initial guess,
>>> >> >
>>> >> > Hi Steve,
>>> >> >
>>> >> > But Greg claims that this is incorrect usage of sysfs API:
>>> >> >
>>> >> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> >> > > usage of the api.
>>> >> > I think this means that sysfs callers must not try to create the same
>>> >> > thing twice.
>>> >> >
>>> >> > Either way user-space code must not be able to triggers WARNINGs in
>>> >> > kernel. If it does than this is something to fix in kernel.
>>> >>
>>> >> I guess that this warning was added more recently as I've not seen it
>>> >> before.
>>> >
>>> > No, it has been there since at least the 3.13 kernel release (back in
>>> > 2013), which is where it got moved to a separate function, but the logic
>>> > has been around in the kernel tree for much longer than that as seen in
>>> > commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
>>> > separate function")
>>> >
>>> >> My expectation is that it will return -EEXIST and not print a
>>> >> warning there. To avoid that we would have to create a new list of GFS2
>>> >> superblocks, and check the list for each mount I think. We could do that,
>>> >> but it seems a bit odd to duplicate code that is already there and working.
>>> >
>>> > Don't you have a list of the "names" of the things you are creating
>>> > somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>>> >
>>> > Also, why did this trigger a syzbot report?  It's only a dump_stack()
>>> > reference, one showing that yes, this is something that should not be
>>> > done, but the kernel keeps on working afterward.
>>>
>>> There is a WARN(), not just dump_stack():
>>>
>>>                         WARN(1, "%s failed for %s with "
>>>                              "-EEXIST, don't try to register things with "
>>>                              "the same name in the same directory.\n",
>>>                              __func__, kobject_name(kobj));
>>
>> Ah, that's a kobject warning, not a sysfs one.  Was looking too far down
>> the call chain.  We can change this to be dump_stack() as well if you
>> think that would help out.  Maybe remove it entirely as sysfs already
>> does dump the stack?
>
>
> kobject_add is called not only from sysfs, right?

Wait, it's the other way around.
I've already mailed a patch that does s/WARN/pr_err/. But can remove
it entirely, whichever you prefer.

> I was just going to send a patch that changes WARN to
> pr_err+dump_stack, but noticed that we have 4 active bugs on this
> WARNING:
>
> WARNING: kobject bug in gfs2_sys_fs_add
> https://syzkaller.appspot.com/bug?id=057673a56dab61b3a447989b67f10b205111c8f4
>
> WARNING: kobject bug in br_add_if
> https://syzkaller.appspot.com/bug?id=3e0339080acd6a2a350a900bc6533b03f5498490
>
> WARNING: kobject bug in netdev_queue_update_kobjects
> https://syzkaller.appspot.com/bug?id=86a8e2ab50527d5a5eb4fad2fc15df609f22d86a
>
> WARNING: kobject bug in device_add
> https://syzkaller.appspot.com/bug?id=57eba87aff7669512fb68e56a932b01805342d13
>
> We want to ignore all of them?
> As a side signal none of them got any attention, except Eric noting
> that, yes, it is noisy:
> https://groups.google.com/d/msg/syzkaller-bugs/XDTC7Iv4IKY/Ab_tgZ4HAQAJ
>
> So I guess I will still mail the patch.

[Cluster-devel] WARNING: kobject bug in sysfs_warn_dup

[Dmitry Vyukov]

On Wed, Apr 11, 2018 at 5:04 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Thu, Apr 5, 2018 at 4:23 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>>> >> On 05/04/18 09:52, Dmitry Vyukov wrote:
>>> >> > On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>>> >> > > Hi,
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > On 05/04/18 09:19, Dmitry Vyukov wrote:
>>> >> > > > On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <gregkh@linuxfoundation.org>
>>> >> > > > wrote:
>>> >> > > > > On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>> >> > > > > > Hello,
>>> >> > > > > >
>>> >> > > > > > syzbot hit the following crash on upstream commit
>>> >> > > > > > 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>> >> > > > > > Merge tag 'ext4_for_linus' of
>>> >> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>>> >> > > > > > syzbot dashboard link:
>>> >> > > > > > https://syzkaller.appspot.com/bug?extid=ff87a28e665c163aa7f5
>>> >> > > > > >
>>> >> > > > > > C reproducer:
>>> >> > > > > > https://syzkaller.appspot.com/x/repro.c?id=5104666266304512
>>> >> > > > > > syzkaller reproducer:
>>> >> > > > > > https://syzkaller.appspot.com/x/repro.syz?id=5683447737614336
>>> >> > > > > > Raw console output:
>>> >> > > > > > https://syzkaller.appspot.com/x/log.txt?id=5104818200772608
>>> >> > > > > > Kernel config:
>>> >> > > > > > https://syzkaller.appspot.com/x/.config?id=9118669095563550941
>>> >> > > > > > compiler: gcc (GCC) 7.1.1 20170620
>>> >> > > > > >
>>> >> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the
>>> >> > > > > > commit:
>>> >> > > > > > Reported-by: syzbot+ff87a28e665c163aa7f5 at syzkaller.appspotmail.com
>>> >> > > > > > It will help syzbot understand when the bug is fixed. See footer for
>>> >> > > > > > details.
>>> >> > > > > > If you forward the report, please keep this part and the footer.
>>> >> > > > > >
>>> >> > > > > > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>> >> > > > > > R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>> >> > > > > > ------------[ cut here ]------------
>>> >> > > > > > kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>> >> > > > > > register
>>> >> > > > > > things with the same name in the same directory.
>>> >> > > > > > sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>> >> > > > > > WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>> >> > > > > > kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>> >> > > > > > CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>> >> > > > > > Kernel panic - not syncing: panic_on_warn set ...
>>> >> > > > > >
>>> >> > > > > > 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+0x1a7/0x27d lib/dump_stack.c:53
>>> >> > > > > >    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>> >> > > > > >    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>> >> > > > > >    create_dir lib/kobject.c:69 [inline]
>>> >> > > > > >    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>> >> > > > > >    kobject_add_varg lib/kobject.c:364 [inline]
>>> >> > > > > >    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>> >> > > > > >    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>> >> > > > > >    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>> >> > > > > >    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>> >> > > > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> >> > > > > usage of the api.
>>> >> > > > Then +gfs2 maintainers.
>>> >> > > >
>>> >> > > > > Now if we should turn this into a non-WARN message, that's a different
>>> >> > > > > thing, I'll gladly take a patch for that.
>>> >> > > > If it's API usage bug in higher level code, then I think WARN is a
>>> >> > > > proper thing. We already had similar ones and they were fixed.
>>> >> > >
>>> >> > > I'm trying to figure out what the test is doing, but it is not very clear.
>>> >> > > At a guess I'd say that perhaps it is trying to mount multiple filesystems
>>> >> > > with the same label? If that is the case then it is not allowed, and it
>>> >> > > should be caught be the sysfs code and result in a refusal to mount, which
>>> >> > > is what I think I see here. Knowing which sysfs directory is involved would
>>> >> > > allow us to confirm, but I suspect that the test needs altering to give each
>>> >> > > gfs2 mount a different label at an initial guess,
>>> >> >
>>> >> > Hi Steve,
>>> >> >
>>> >> > But Greg claims that this is incorrect usage of sysfs API:
>>> >> >
>>> >> > > gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>> >> > > usage of the api.
>>> >> > I think this means that sysfs callers must not try to create the same
>>> >> > thing twice.
>>> >> >
>>> >> > Either way user-space code must not be able to triggers WARNINGs in
>>> >> > kernel. If it does than this is something to fix in kernel.
>>> >>
>>> >> I guess that this warning was added more recently as I've not seen it
>>> >> before.
>>> >
>>> > No, it has been there since at least the 3.13 kernel release (back in
>>> > 2013), which is where it got moved to a separate function, but the logic
>>> > has been around in the kernel tree for much longer than that as seen in
>>> > commit d1c1459e4594 ("sysfs: separate out dup filename warning into a
>>> > separate function")
>>> >
>>> >> My expectation is that it will return -EEXIST and not print a
>>> >> warning there. To avoid that we would have to create a new list of GFS2
>>> >> superblocks, and check the list for each mount I think. We could do that,
>>> >> but it seems a bit odd to duplicate code that is already there and working.
>>> >
>>> > Don't you have a list of the "names" of the things you are creating
>>> > somewhere?  Or are you relying on sysfs to do your housekeeping for you?
>>> >
>>> > Also, why did this trigger a syzbot report?  It's only a dump_stack()
>>> > reference, one showing that yes, this is something that should not be
>>> > done, but the kernel keeps on working afterward.
>>>
>>> There is a WARN(), not just dump_stack():
>>>
>>>                         WARN(1, "%s failed for %s with "
>>>                              "-EEXIST, don't try to register things with "
>>>                              "the same name in the same directory.\n",
>>>                              __func__, kobject_name(kobj));
>>
>> Ah, that's a kobject warning, not a sysfs one.  Was looking too far down
>> the call chain.  We can change this to be dump_stack() as well if you
>> think that would help out.  Maybe remove it entirely as sysfs already
>> does dump the stack?
>
>
> kobject_add is called not only from sysfs, right?

Wait, it's the other way around.
I've already mailed a patch that does s/WARN/pr_err/. But can remove
it entirely, whichever you prefer.

> I was just going to send a patch that changes WARN to
> pr_err+dump_stack, but noticed that we have 4 active bugs on this
> WARNING:
>
> WARNING: kobject bug in gfs2_sys_fs_add
> https://syzkaller.appspot.com/bug?id=057673a56dab61b3a447989b67f10b205111c8f4
>
> WARNING: kobject bug in br_add_if
> https://syzkaller.appspot.com/bug?id=3e0339080acd6a2a350a900bc6533b03f5498490
>
> WARNING: kobject bug in netdev_queue_update_kobjects
> https://syzkaller.appspot.com/bug?id=86a8e2ab50527d5a5eb4fad2fc15df609f22d86a
>
> WARNING: kobject bug in device_add
> https://syzkaller.appspot.com/bug?id=57eba87aff7669512fb68e56a932b01805342d13
>
> We want to ignore all of them?
> As a side signal none of them got any attention, except Eric noting
> that, yes, it is noisy:
> https://groups.google.com/d/msg/syzkaller-bugs/XDTC7Iv4IKY/Ab_tgZ4HAQAJ
>
> So I guess I will still mail the patch.