From: Al Viro <viro@zeniv.linux.org.uk>
To: Xiaoming Ni <nixiaoming@huawei.com>
Cc: bbrezillon@kernel.org, richard@nod.at, dilinger@queued.net,
linux-kernel@vger.kernel.org, daniel.santos@pobox.com,
linux-mtd@lists.infradead.org, houtao1@huawei.com,
dwmw2@infradead.org
Subject: Re: [PATCH] jffs2:freely allocate memory when parameters are invalid
Date: Fri, 20 Sep 2019 13:54:42 +0100 [thread overview]
Message-ID: <20190920125442.GA20754@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190920124532.GN1131@ZenIV.linux.org.uk>
On Fri, Sep 20, 2019 at 01:45:33PM +0100, Al Viro wrote:
> On Fri, Sep 20, 2019 at 08:21:53PM +0800, Xiaoming Ni wrote:
> >
> >
> > On 2019/9/20 19:43, Al Viro wrote:
> > > On Fri, Sep 20, 2019 at 02:54:38PM +0800, Xiaoming Ni wrote:
> > >> Use kzalloc() to allocate memory in jffs2_fill_super().
> > >> Freeing memory when jffs2_parse_options() fails will cause
> > >> use-after-free and double-free in jffs2_kill_sb()
> > >
> > > ... so we are not freeing it there. What's the problem?
> >
> > No code logic issues, no memory leaks
> >
> > But there is too much code logic between memory allocation and free,
> > which is difficult to understand.
>
> Er? An instance of jffs2 superblock might have a related object
> attached to it; it is created in jffs2 superblock constructor and
> freed in destructor.
>
> > The modified code is easier to understand.
>
> You are making the cleanup logics harder to follow.
PS: the whole point of ->kill_sb() is that it's always called on
superblock destruction, whether that instance had been fully set
up of failed halfway through.
In particular, anything like foofs_fill_super() *will* be followed
by ->kill_sb(). Always. Which allows for simpler logics in
failure exits. And the main thing about those is that they are
always the bitrot hot spots - they are systematically undertested,
so that's the last place where you want something non-trivial.
As for "too much code between"... Huh? We fail jffs2_fill_super()
immediately, which has get_tree_mtd() (or mount_mtd() in slightly
earlier kernels) destroy the superblock there and then...
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Xiaoming Ni <nixiaoming@huawei.com>
Cc: dwmw2@infradead.org, dilinger@queued.net, richard@nod.at,
houtao1@huawei.com, bbrezillon@kernel.org,
daniel.santos@pobox.com, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] jffs2:freely allocate memory when parameters are invalid
Date: Fri, 20 Sep 2019 13:54:42 +0100 [thread overview]
Message-ID: <20190920125442.GA20754@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190920124532.GN1131@ZenIV.linux.org.uk>
On Fri, Sep 20, 2019 at 01:45:33PM +0100, Al Viro wrote:
> On Fri, Sep 20, 2019 at 08:21:53PM +0800, Xiaoming Ni wrote:
> >
> >
> > On 2019/9/20 19:43, Al Viro wrote:
> > > On Fri, Sep 20, 2019 at 02:54:38PM +0800, Xiaoming Ni wrote:
> > >> Use kzalloc() to allocate memory in jffs2_fill_super().
> > >> Freeing memory when jffs2_parse_options() fails will cause
> > >> use-after-free and double-free in jffs2_kill_sb()
> > >
> > > ... so we are not freeing it there. What's the problem?
> >
> > No code logic issues, no memory leaks
> >
> > But there is too much code logic between memory allocation and free,
> > which is difficult to understand.
>
> Er? An instance of jffs2 superblock might have a related object
> attached to it; it is created in jffs2 superblock constructor and
> freed in destructor.
>
> > The modified code is easier to understand.
>
> You are making the cleanup logics harder to follow.
PS: the whole point of ->kill_sb() is that it's always called on
superblock destruction, whether that instance had been fully set
up of failed halfway through.
In particular, anything like foofs_fill_super() *will* be followed
by ->kill_sb(). Always. Which allows for simpler logics in
failure exits. And the main thing about those is that they are
always the bitrot hot spots - they are systematically undertested,
so that's the last place where you want something non-trivial.
As for "too much code between"... Huh? We fail jffs2_fill_super()
immediately, which has get_tree_mtd() (or mount_mtd() in slightly
earlier kernels) destroy the superblock there and then...
next prev parent reply other threads:[~2019-09-20 12:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 6:54 [PATCH] jffs2:freely allocate memory when parameters are invalid Xiaoming Ni
2019-09-20 6:54 ` Xiaoming Ni
2019-09-20 11:43 ` Al Viro
2019-09-20 11:43 ` Al Viro
2019-09-20 12:21 ` Xiaoming Ni
2019-09-20 12:21 ` Xiaoming Ni
2019-09-20 12:45 ` Al Viro
2019-09-20 12:45 ` Al Viro
2019-09-20 12:54 ` Al Viro [this message]
2019-09-20 12:54 ` Al Viro
2019-09-20 14:13 ` Xiaoming Ni
2019-09-20 14:13 ` Xiaoming Ni
2019-09-20 14:38 ` Richard Weinberger
2019-09-20 14:38 ` Richard Weinberger
2019-09-21 1:24 ` Hou Tao
2019-09-21 1:24 ` Hou Tao
2019-09-21 15:37 ` Richard Weinberger
2019-09-21 15:37 ` Richard Weinberger
2019-09-20 15:28 ` Al Viro
2019-09-20 15:28 ` Al Viro
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=20190920125442.GA20754@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bbrezillon@kernel.org \
--cc=daniel.santos@pobox.com \
--cc=dilinger@queued.net \
--cc=dwmw2@infradead.org \
--cc=houtao1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nixiaoming@huawei.com \
--cc=richard@nod.at \
/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.