From: Al Viro <viro@ZenIV.linux.org.uk>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: syzbot <syzbot+481ad819c717f6b78df9@syzkaller.appspotmail.com>,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
gregkh@linuxfoundation.org, tj@kernel.org
Subject: Re: general protection fault in kernfs_kill_sb (2)
Date: Mon, 14 May 2018 03:47:27 +0100 [thread overview]
Message-ID: <20180514024726.GB30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <14892403-d680-dc5d-1927-bc4a279514fb@I-love.SAKURA.ne.jp>
On Sun, May 13, 2018 at 11:19:46AM +0900, Tetsuo Handa wrote:
> This is what I reported at
> https://groups.google.com/d/msg/syzkaller-bugs/ISOJlV2I2QM/qHslGMi3AwAJ .
>
> We are currently waiting for comments from Al Viro.
1) the damn thing is unusable without javashit. Which gets about
the same reaction as sending something.doc in attachment. Please,
find a less obnoxious way to archive the thing (or to generate
URLs that would work without that garbage).
2) deactivate_locked_super() *WILL* be called when fill_super() fails.
Live with it; it allows to simplify a whole lot of cleanup logics
in various filesystems. Again, we are not going for a model where
->kill_sb() is not called for something returned by sget().
Rationale: rarely exercised paths tend to rot, so anything that increases
the duplication of bits and pieces of normal teardown into failure exits
of foo_fill_super() is a bloody bad idea. If anything, we want to take
a lot of stuff out of ->put_super() instances directly into ->kill_sb()
ones, precisely because ->put_super() is only called for fully set up
filesystems.
3) kernfs needs to be fixed. The rest of the dropped commits were
made redundant by 8e04944f0ea8; this one wasn't. Mea culpa.
next prev parent reply other threads:[~2018-05-14 2:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-12 17:01 general protection fault in kernfs_kill_sb (2) syzbot
2018-05-13 2:19 ` Tetsuo Handa
2018-05-14 2:47 ` Al Viro [this message]
[not found] ` <201805140320.w4E3KG2o056158@www262.sakura.ne.jp>
2018-05-14 4:04 ` Al Viro
2018-05-14 4:32 ` Al Viro
2018-05-15 0:17 ` Stephen Rothwell
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=20180514024726.GB30522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=syzbot+481ad819c717f6b78df9@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tj@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.