* Re: WARNING in sysfs_warn_dup
@ 2018-01-22 14:30 ` Dmitry Vyukov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Vyukov @ 2018-01-22 14:30 UTC (permalink / raw)
To: Greg KH
Cc: syzbot, LKML, syzkaller-bugs, David Miller, Daniel Borkmann,
Eric Dumazet, jakub.kicinski, Willem de Bruijn, Rasmus Villemoes,
John Fastabend, Tobin C. Harding, netdev, linux-wireless
On Mon, Jan 22, 2018 at 3:00 PM, Greg KH <gregkh@linuxfoundation.org> 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@google.com> wrote:
>> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> >>
>> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH <gregkh@linuxfoundation.org> 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!
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: WARNING in sysfs_warn_dup
2018-01-22 14:30 ` Dmitry Vyukov
(?)
@ 2018-01-22 14:45 ` Greg KH
2018-01-22 15:04 ` Dmitry Vyukov
-1 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2018-01-22 14:45 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, LKML, syzkaller-bugs, David Miller, Daniel Borkmann,
Eric Dumazet, jakub.kicinski, Willem de Bruijn, Rasmus Villemoes,
John Fastabend, Tobin C. Harding, netdev, linux-wireless
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@linuxfoundation.org> 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@google.com> wrote:
> >> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> >> >>
> >> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH <gregkh@linuxfoundation.org> 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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: WARNING in sysfs_warn_dup
2018-01-22 14:45 ` Greg KH
2018-01-22 15:04 ` Dmitry Vyukov
@ 2018-01-22 15:04 ` Dmitry Vyukov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Vyukov @ 2018-01-22 15:04 UTC (permalink / raw)
To: Greg KH
Cc: syzbot, LKML, syzkaller-bugs, David Miller, Daniel Borkmann,
Eric Dumazet, jakub.kicinski, Willem de Bruijn, Rasmus Villemoes,
John Fastabend, Tobin C. Harding, netdev, linux-wireless
On Mon, Jan 22, 2018 at 3:45 PM, Greg KH <gregkh@linuxfoundation.org> 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 <gregkh@linuxfoundation.org> wr=
ote:
>> > 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@google.com> =
wrote:
>> >> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov <dvyukov@google.com=
> wrote:
>> >> >>
>> >> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH <gregkh@linuxfoundation.=
org> 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.g=
it/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 pro=
perly
>> >> >>> > 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 pro=
perly
>> >> >>> > 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 direc=
tories
>> >> >>> 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/=C5=A1=C2=A7"=C2=AD=C3=BBt{=C2=A7=C3=94=C2=AD=C3=B0=
=C3=B4 =C5=A0!=C3=97 =C5=BE 7=E2=80=A6 =C5=A0=E2=80=A0=C3=B5i=C3=B9S6 =C3=
=88< =C2=BB=C3=BE {_CK5=C3=A4=C3=A1 =C3=97=C3=9D=C3=8Am=C3=B4 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 somethin=
g
>> > 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 a=
s
>> > an "error" by your testing, when really it isn't, unless the caller ca=
n
>> > 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 a=
s
>> > 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()
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: WARNING in sysfs_warn_dup
@ 2018-01-22 15:04 ` Dmitry Vyukov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Vyukov @ 2018-01-22 15:04 UTC (permalink / raw)
To: Greg KH
Cc: syzbot, LKML, syzkaller-bugs-/JYPxA39Uh5TLH3MbocFFw, David Miller,
Daniel Borkmann, Eric Dumazet,
jakub.kicinski-wFxRvT7yatFl57MIdRCFDg, Willem de Bruijn,
Rasmus Villemoes, John Fastabend, Tobin C. Harding, netdev,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
On Mon, Jan 22, 2018 at 3:45 PM, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> 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 <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> 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-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>> >> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov <dvyukov-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>> >> >>
>> >> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH <gregkh@linuxfoundation.org> 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()
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: WARNING in sysfs_warn_dup
@ 2018-01-22 15:04 ` Dmitry Vyukov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Vyukov @ 2018-01-22 15:04 UTC (permalink / raw)
To: Greg KH
Cc: syzbot, LKML, syzkaller-bugs, David Miller, Daniel Borkmann,
Eric Dumazet, jakub.kicinski, Willem de Bruijn, Rasmus Villemoes,
John Fastabend, Tobin C. Harding, netdev, linux-wireless
On Mon, Jan 22, 2018 at 3:45 PM, Greg KH <gregkh@linuxfoundation.org> 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 <gregkh@linuxfoundation.org> 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@google.com> wrote:
>> >> > On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> >> >>
>> >> >> On Tue, Dec 19, 2017 at 10:01 AM, Greg KH <gregkh@linuxfoundation.org> 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()
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] sysfs: turn WARN() into pr_warn()
2018-01-22 14:30 ` Dmitry Vyukov
(?)
(?)
@ 2018-01-22 14:57 ` Greg KH
2018-01-22 15:04 ` Dmitry Vyukov
-1 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2018-01-22 14:57 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, LKML, syzkaller-bugs, David Miller, Daniel Borkmann,
Eric Dumazet, jakub.kicinski, Willem de Bruijn, Rasmus Villemoes,
John Fastabend, Tobin C. Harding, netdev, linux-wireless
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's not good to crash the machine if panic_on_warn() is set just
because someone made a stupid mistake of trying to create a sysfs file
with the same name of an existing one. This makes the automated testing
tools a lot harder to find the real bugs in the kernel.
So just print a warning out and dump the stack to get the attention of
the developer that they did something foolish. Then keep on trucking,
as this should not be a fatal error at all.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Dmitry, does this look good to you? If so, I'll queue it up for
4.16-rc1.
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 2b67bda2021b..3a36a48a4b3f 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -10,6 +10,7 @@
* Please see Documentation/filesystems/sysfs.txt for more information.
*/
+#define pr_fmt(fmt) "sysfs: " fmt
#undef DEBUG
#include <linux/fs.h>
@@ -27,8 +28,8 @@ void sysfs_warn_dup(struct kernfs_node *parent, const char *name)
if (buf)
kernfs_path(parent, buf, PATH_MAX);
- WARN(1, KERN_WARNING "sysfs: cannot create duplicate filename '%s/%s'\n",
- buf, name);
+ pr_warn("cannot create duplicate filename '%s/%s'\n", buf, name);
+ dump_stack();
kfree(buf);
}
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH] sysfs: turn WARN() into pr_warn()
2018-01-22 14:57 ` [PATCH] sysfs: turn WARN() into pr_warn() Greg KH
@ 2018-01-22 15:04 ` Dmitry Vyukov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Vyukov @ 2018-01-22 15:04 UTC (permalink / raw)
To: Greg KH
Cc: syzbot, LKML, syzkaller-bugs, David Miller, Daniel Borkmann,
Eric Dumazet, jakub.kicinski, Willem de Bruijn, Rasmus Villemoes,
John Fastabend, Tobin C. Harding, netdev, linux-wireless
On Mon, Jan 22, 2018 at 3:57 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> It's not good to crash the machine if panic_on_warn() is set just
> because someone made a stupid mistake of trying to create a sysfs file
> with the same name of an existing one. This makes the automated testing
> tools a lot harder to find the real bugs in the kernel.
>
> So just print a warning out and dump the stack to get the attention of
> the developer that they did something foolish. Then keep on trucking,
> as this should not be a fatal error at all.
>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>
> Dmitry, does this look good to you? If so, I'll queue it up for
> 4.16-rc1.
Perfect! Looks good. syzbot reacts on "WARNING:" string (+ if kernel
panic due to panic_on_warn that's also obviously a problem).
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index 2b67bda2021b..3a36a48a4b3f 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -10,6 +10,7 @@
> * Please see Documentation/filesystems/sysfs.txt for more information.
> */
>
> +#define pr_fmt(fmt) "sysfs: " fmt
> #undef DEBUG
>
> #include <linux/fs.h>
> @@ -27,8 +28,8 @@ void sysfs_warn_dup(struct kernfs_node *parent, const char *name)
> if (buf)
> kernfs_path(parent, buf, PATH_MAX);
>
> - WARN(1, KERN_WARNING "sysfs: cannot create duplicate filename '%s/%s'\n",
> - buf, name);
> + pr_warn("cannot create duplicate filename '%s/%s'\n", buf, name);
> + dump_stack();
>
> kfree(buf);
> }
^ permalink raw reply [flat|nested] 13+ messages in thread