On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
> On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> >>
> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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
