On Mon, Jan 22, 2018 at 03:30:12PM +0100, Dmitry Vyukov wrote:

On Mon, Jan 22, 2018 at 3:00 PM, Greg KH [off-list ref] wrote:

quoted

On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:

quoted

On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov [off-list ref] wrote:

quoted

On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov [off-list ref] wrote:

quoted

On Tue, Dec 19, 2017 at 10:01 AM, Greg KH [off-list ref] wrote:

quoted

On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:

quoted

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 :)

quoted

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:

quoted

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