Re: WARNING in sysfs_warn_dup

2018-01-22 Thread Dmitry Vyukov 
On Mon, Jan 22, 2018 at 3:45 PM, Greg KH  wrote:
> On Mon, Jan 22, 2018 at 03:30:12PM +0100, Dmitry Vyukov wrote:
>> On Mon, Jan 22, 2018 at 3:00 PM, Greg KH  wrote:
>> > On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
>> >> On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov  
>> >> wrote:
>> >> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov  
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH  
>> >> >> wrote:
>> >> >>>
>> >> >>> On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
>> >> >>> > Hello,
>> >> >>> >
>> >> >>> > syzkaller hit the following crash on
>> >> >>> > 6084b576dca2e898f5c101baef151f7bfdbb606d
>> >> >>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> >> >>> > compiler: gcc (GCC) 7.1.1 20170620
>> >> >>> > .config is attached
>> >> >>> > Raw console output is attached.
>> >> >>> >
>> >> >>> > Unfortunately, I don't have any reproducer for this bug yet.
>> >> >>> >
>> >> >>> >
>> >> >>> > netlink: 9 bytes leftover after parsing attributes in process
>> >> >>> > `syz-executor3'.
>> >> >>> > sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- 
>> >> >>> > guessing
>> >> >>> > data in;
>> >> >>> >program syz-executor0 not setting count and/or reply_len properly
>> >> >>> > sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- 
>> >> >>> > guessing data
>> >> >>> > in;
>> >> >>> >program syz-executor0 not setting count and/or reply_len properly
>> >> >>> > WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 
>> >> >>> > sysfs_warn_dup+0x60/0x80
>> >> >>> > fs/sysfs/dir.c:30
>> >> >>> > Kernel panic - not syncing: panic_on_warn set ...
>> >> >>>
>> >> >>> Looks like a networking issue, it tried to create two sysfs 
>> >> >>> directories
>> >> >>> with the same name, which isn't a sysfs bug :)
>> >> >
>> >> >
>> >> > Now as plain text:
>> >> >
>> >> > +net/core/dev.c maintainers
>> >>
>> >>
>> >> Also happens for wiphy_register (on upstream
>> >> a8750ddca918032d6349adbf9a4b6555e7db20da):
>> >>
>> >> [ cut here ]
>> >> sysfs: cannot create duplicate filename
>> >> '/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá   ×ÝÊmô Be'
>> >
>> > That's a wonderful filename :)
>> >
>> >> WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
>> >> sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30
>> >
>> > As this is just sysfs saying "Hey dummy, you are trying to do something
>> > foolish here", what would be the better thing for it to do?
>> >
>> > Just printk(KERN_WARNING...) and then dump the stack?
>> >
>> > It seems the WARN_ON() that is currently being used is being treated as
>> > an "error" by your testing, when really it isn't, unless the caller can
>> > not handle the error being passed back up to it by the sysfs core.
>> > Which it should, but I don't think you are even giving it the chance as
>> > you are:
>> >
>> >> Kernel panic - not syncing: panic_on_warn set ...
>> >
>> > Yup, panic_on_warn :(
>> >
>> > ideas to make this easier for you?
>>
>>
>> pr_warn or pr_warn_once (optionally followed by dump_stack) would work
>> for syzbot.
>
> This shouldn't be a _once() call, as it is called by things all over the
> kernel, all with unique paths.
>
> I'll go make up a patch for this, thanks.

#syz fix: sysfs: turn WARN() into pr_warn()

Re: WARNING in sysfs_warn_dup

2018-01-22 Thread Greg KH 
On Mon, Jan 22, 2018 at 03:30:12PM +0100, Dmitry Vyukov wrote:
> On Mon, Jan 22, 2018 at 3:00 PM, Greg KH  wrote:
> > On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
> >> On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov  wrote:
> >> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov  
> >> > wrote:
> >> >>
> >> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH  
> >> >> wrote:
> >> >>>
> >> >>> On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
> >> >>> > Hello,
> >> >>> >
> >> >>> > syzkaller hit the following crash on
> >> >>> > 6084b576dca2e898f5c101baef151f7bfdbb606d
> >> >>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> >> >>> > compiler: gcc (GCC) 7.1.1 20170620
> >> >>> > .config is attached
> >> >>> > Raw console output is attached.
> >> >>> >
> >> >>> > Unfortunately, I don't have any reproducer for this bug yet.
> >> >>> >
> >> >>> >
> >> >>> > netlink: 9 bytes leftover after parsing attributes in process
> >> >>> > `syz-executor3'.
> >> >>> > sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- 
> >> >>> > guessing
> >> >>> > data in;
> >> >>> >program syz-executor0 not setting count and/or reply_len properly
> >> >>> > sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- 
> >> >>> > guessing data
> >> >>> > in;
> >> >>> >program syz-executor0 not setting count and/or reply_len properly
> >> >>> > WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 
> >> >>> > sysfs_warn_dup+0x60/0x80
> >> >>> > fs/sysfs/dir.c:30
> >> >>> > Kernel panic - not syncing: panic_on_warn set ...
> >> >>>
> >> >>> Looks like a networking issue, it tried to create two sysfs directories
> >> >>> with the same name, which isn't a sysfs bug :)
> >> >
> >> >
> >> > Now as plain text:
> >> >
> >> > +net/core/dev.c maintainers
> >>
> >>
> >> Also happens for wiphy_register (on upstream
> >> a8750ddca918032d6349adbf9a4b6555e7db20da):
> >>
> >> [ cut here ]
> >> sysfs: cannot create duplicate filename
> >> '/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá   ×ÝÊmô Be'
> >
> > That's a wonderful filename :)
> >
> >> WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
> >> sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30
> >
> > As this is just sysfs saying "Hey dummy, you are trying to do something
> > foolish here", what would be the better thing for it to do?
> >
> > Just printk(KERN_WARNING...) and then dump the stack?
> >
> > It seems the WARN_ON() that is currently being used is being treated as
> > an "error" by your testing, when really it isn't, unless the caller can
> > not handle the error being passed back up to it by the sysfs core.
> > Which it should, but I don't think you are even giving it the chance as
> > you are:
> >
> >> Kernel panic - not syncing: panic_on_warn set ...
> >
> > Yup, panic_on_warn :(
> >
> > ideas to make this easier for you?
> 
> 
> pr_warn or pr_warn_once (optionally followed by dump_stack) would work
> for syzbot.

This shouldn't be a _once() call, as it is called by things all over the
kernel, all with unique paths.

I'll go make up a patch for this, thanks.

greg k-h

Re: WARNING in sysfs_warn_dup

2018-01-22 Thread Dmitry Vyukov 
On Mon, Jan 22, 2018 at 3:00 PM, Greg KH  wrote:
> On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
>> On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov  wrote:
>> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov  wrote:
>> >>
>> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH  
>> >> wrote:
>> >>>
>> >>> On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
>> >>> > Hello,
>> >>> >
>> >>> > syzkaller hit the following crash on
>> >>> > 6084b576dca2e898f5c101baef151f7bfdbb606d
>> >>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> >>> > compiler: gcc (GCC) 7.1.1 20170620
>> >>> > .config is attached
>> >>> > Raw console output is attached.
>> >>> >
>> >>> > Unfortunately, I don't have any reproducer for this bug yet.
>> >>> >
>> >>> >
>> >>> > netlink: 9 bytes leftover after parsing attributes in process
>> >>> > `syz-executor3'.
>> >>> > sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- 
>> >>> > guessing
>> >>> > data in;
>> >>> >program syz-executor0 not setting count and/or reply_len properly
>> >>> > sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- 
>> >>> > guessing data
>> >>> > in;
>> >>> >program syz-executor0 not setting count and/or reply_len properly
>> >>> > WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 
>> >>> > sysfs_warn_dup+0x60/0x80
>> >>> > fs/sysfs/dir.c:30
>> >>> > Kernel panic - not syncing: panic_on_warn set ...
>> >>>
>> >>> Looks like a networking issue, it tried to create two sysfs directories
>> >>> with the same name, which isn't a sysfs bug :)
>> >
>> >
>> > Now as plain text:
>> >
>> > +net/core/dev.c maintainers
>>
>>
>> Also happens for wiphy_register (on upstream
>> a8750ddca918032d6349adbf9a4b6555e7db20da):
>>
>> [ cut here ]
>> sysfs: cannot create duplicate filename
>> '/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá   ×ÝÊmô Be'
>
> That's a wonderful filename :)
>
>> WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
>> sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30
>
> As this is just sysfs saying "Hey dummy, you are trying to do something
> foolish here", what would be the better thing for it to do?
>
> Just printk(KERN_WARNING...) and then dump the stack?
>
> It seems the WARN_ON() that is currently being used is being treated as
> an "error" by your testing, when really it isn't, unless the caller can
> not handle the error being passed back up to it by the sysfs core.
> Which it should, but I don't think you are even giving it the chance as
> you are:
>
>> Kernel panic - not syncing: panic_on_warn set ...
>
> Yup, panic_on_warn :(
>
> ideas to make this easier for you?


pr_warn or pr_warn_once (optionally followed by dump_stack) would work
for syzbot.

Thanks!

Re: WARNING in sysfs_warn_dup

2018-01-22 Thread Greg KH 
On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
> On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov  wrote:
> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov  wrote:
> >>
> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH  
> >> wrote:
> >>>
> >>> On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
> >>> > Hello,
> >>> >
> >>> > syzkaller hit the following crash on
> >>> > 6084b576dca2e898f5c101baef151f7bfdbb606d
> >>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> >>> > compiler: gcc (GCC) 7.1.1 20170620
> >>> > .config is attached
> >>> > Raw console output is attached.
> >>> >
> >>> > Unfortunately, I don't have any reproducer for this bug yet.
> >>> >
> >>> >
> >>> > netlink: 9 bytes leftover after parsing attributes in process
> >>> > `syz-executor3'.
> >>> > sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- 
> >>> > guessing
> >>> > data in;
> >>> >program syz-executor0 not setting count and/or reply_len properly
> >>> > sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing 
> >>> > data
> >>> > in;
> >>> >program syz-executor0 not setting count and/or reply_len properly
> >>> > WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
> >>> > fs/sysfs/dir.c:30
> >>> > Kernel panic - not syncing: panic_on_warn set ...
> >>>
> >>> Looks like a networking issue, it tried to create two sysfs directories
> >>> with the same name, which isn't a sysfs bug :)
> >
> >
> > Now as plain text:
> >
> > +net/core/dev.c maintainers
> 
> 
> Also happens for wiphy_register (on upstream
> a8750ddca918032d6349adbf9a4b6555e7db20da):
> 
> [ cut here ]
> sysfs: cannot create duplicate filename
> '/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá   ×ÝÊmô Be'

That's a wonderful filename :)

> WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
> sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30

As this is just sysfs saying "Hey dummy, you are trying to do something
foolish here", what would be the better thing for it to do?

Just printk(KERN_WARNING...) and then dump the stack?

It seems the WARN_ON() that is currently being used is being treated as
an "error" by your testing, when really it isn't, unless the caller can
not handle the error being passed back up to it by the sysfs core.
Which it should, but I don't think you are even giving it the chance as
you are:

> Kernel panic - not syncing: panic_on_warn set ...

Yup, panic_on_warn :(

ideas to make this easier for you?

thanks,

greg k-h

Re: WARNING in sysfs_warn_dup

2018-01-22 Thread Dmitry Vyukov 
On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov  wrote:
> On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov  wrote:
>>
>> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH  wrote:
>>>
>>> On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
>>> > Hello,
>>> >
>>> > syzkaller hit the following crash on
>>> > 6084b576dca2e898f5c101baef151f7bfdbb606d
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>>> > compiler: gcc (GCC) 7.1.1 20170620
>>> > .config is attached
>>> > Raw console output is attached.
>>> >
>>> > Unfortunately, I don't have any reproducer for this bug yet.
>>> >
>>> >
>>> > netlink: 9 bytes leftover after parsing attributes in process
>>> > `syz-executor3'.
>>> > sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing
>>> > data in;
>>> >program syz-executor0 not setting count and/or reply_len properly
>>> > sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing 
>>> > data
>>> > in;
>>> >program syz-executor0 not setting count and/or reply_len properly
>>> > WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
>>> > fs/sysfs/dir.c:30
>>> > Kernel panic - not syncing: panic_on_warn set ...
>>>
>>> Looks like a networking issue, it tried to create two sysfs directories
>>> with the same name, which isn't a sysfs bug :)
>
>
> Now as plain text:
>
> +net/core/dev.c maintainers


Also happens for wiphy_register (on upstream
a8750ddca918032d6349adbf9a4b6555e7db20da):

[ cut here ]
sysfs: cannot create duplicate filename
'/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá   ×ÝÊmô Be'
WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 8233 Comm: syz-executor7 Not tainted 4.15.0-rc8+ #263
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x194/0x257 lib/dump_stack.c:53
 panic+0x1e4/0x41c kernel/panic.c:183
 __warn+0x1dc/0x200 kernel/panic.c:547
 report_bug+0x211/0x2d0 lib/bug.c:184
 fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
 fixup_bug arch/x86/kernel/traps.c:247 [inline]
 do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
 invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1085
RIP: 0010:sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30
RSP: 0018:8801d00def20 EFLAGS: 00010286
RAX: dc08 RBX: 8801c4ff2ac0 RCX: 8159dade
RDX: cb4f RSI: c9000192b000 RDI: 8801d00dec28
RBP: 8801d00def38 R08: 11003a01bd61 R09: 
R10:  R11:  R12: 8801d976fa80
R13: 8801d833e380 R14: 0001 R15: ffef
 sysfs_do_create_link_sd.isra.2+0xf3/0x110 fs/sysfs/symlink.c:51
 sysfs_do_create_link fs/sysfs/symlink.c:80 [inline]
 sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:92
 device_add_class_symlinks drivers/base/core.c:1603 [inline]
 device_add+0x74a/0x1650 drivers/base/core.c:1801
 wiphy_register+0x1468/0x2050 net/wireless/core.c:800
 ieee80211_register_hw+0x1162/0x3100 net/mac80211/main.c:1038
 mac80211_hwsim_new_radio+0x1b2e/0x2b90
drivers/net/wireless/mac80211_hwsim.c:2700
 hwsim_new_radio_nl+0x5b7/0x7c0 drivers/net/wireless/mac80211_hwsim.c:3152
 genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
 genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
 netlink_rcv_skb+0x224/0x470 net/netlink/af_netlink.c:2408
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
 netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
 netlink_unicast+0x4ee/0x700 net/netlink/af_netlink.c:1301
 netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
 sock_sendmsg_nosec net/socket.c:638 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:648
 ___sys_sendmsg+0x767/0x8b0 net/socket.c:2028
 __sys_sendmsg+0xe5/0x210 net/socket.c:2062
 SYSC_sendmsg net/socket.c:2073 [inline]
 SyS_sendmsg+0x2d/0x50 net/socket.c:2069
 entry_SYSCALL_64_fastpath+0x29/0xa0



If you fix this, please add:
Reported-by: 
syzbot+1fdad4e2731bf0c1bc19953ccc5061237ec92...@syzkaller.appspotmail.com
tag. It will help syzbot understand when the bug is fixed.