From: Cong Wang <xiyou.wangcong@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: syzbot <syzbot+d5870a903591faaca4ae@syzkaller.appspotmail.com>,
Akinobu Mita <akinobu.mita@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>,
Dmitry Vyukov <dvyukov@google.com>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@kernel.org>, Netdev <netdev@vger.kernel.org>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: general protection fault in qdisc_put
Date: Mon, 9 Sep 2019 16:14:36 -0700 [thread overview]
Message-ID: <CAM_iQpU2Z0s8pJAa3AAMbq6S=MeuAAOVqRopVpmDnFLn9xU=UA@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgZneAegyitz7f+JLjB6=28ewtvT7M4xy_a-wqsTjOX_w@mail.gmail.com>
On Sun, Sep 8, 2019 at 10:19 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> I see two solutions:
>
> (a) move the
>
> q->qdisc = &noop_qdisc;
>
> up earlier in sfb_init(), so that qdisc is always initialized
> after sfb_init(), even on failure.
>
> (b) just make qdisc_put(NULL) just silently work as a no-op.
>
> (c) change all the semantics to not call ->destroy if ->init failed.
>
> Honestly, (a) seems very fragile - do all the other init routines do
> this? And (c) sounds like a big change, and very fragile too.
>
> So I'd suggest that qdisc_put() be made to just ignore a NULL pointer
> (and maybe an error pointer too?).
I think (a) is the best solution here.
(c) changes too much, we already rely on this behavior.
(b) is not bad either, just very slightly more risky.
Alternatively, we can add a quick NULL check inside
sfb_destroy().
I can send out a patch if you don't.
Thanks for looking at this!
prev parent reply other threads:[~2019-09-09 23:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-08 6:08 general protection fault in qdisc_put syzbot
2019-09-08 17:18 ` Linus Torvalds
2019-09-09 6:45 ` Dmitry Vyukov
2019-09-09 23:14 ` Cong Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM_iQpU2Z0s8pJAa3AAMbq6S=MeuAAOVqRopVpmDnFLn9xU=UA@mail.gmail.com' \
--to=xiyou.wangcong@gmail.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=syzbot+d5870a903591faaca4ae@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).