On Mon, Jan 22, 2018 at 03:30:12PM +0100, Dmitry Vyukov wrote:
> On Mon, Jan 22, 2018 at 3:00 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 <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?
>
>
> 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
