From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jia-Ju Bai <baijiaju1990@163.com>, Jan Kara <jack@suse.com>,
Sagi Grimberg <sagi@grimberg.me>,
james.smart@broadcom.com,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options
Date: Sat, 7 Oct 2017 03:28:39 +0100 [thread overview]
Message-ID: <20171007022839.GP21978@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20171007020217.GN21978@ZenIV.linux.org.uk>
On Sat, Oct 07, 2017 at 03:02:17AM +0100, Al Viro wrote:
> > I do wonder if we shouldn't just use something like
> >
> > "skip leading zeroes, copy to size-limited stack location instead"
> >
> > because the input length really *is* limited once you skip leading
> > zeroes (and whatever base marker we have). We might have at most a
> > 64-bit value in octal, so 22 bytes max.
> >
> > But I guess just changing the two GFP_KERNEL's to GFP_ATOMIC is much simpler.
>
> There's match_strdup() as well...
>
> FWIW, ext2 side also looks fishy; it might be cleaner if we
> collected new state into some object and applied it only after the last
> possible failure exit. The entire "restore the original state" logics
> would go away...
I'm not saying that the bug had been introduced by conversion to
spinlock, BTW - it was racy back when ext2_remount() relied upon BKL.
I hadn't considered the atomicity issues back then - mea culpa...
next prev parent reply other threads:[~2017-10-07 2:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-07 1:20 [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options Jia-Ju Bai
2017-10-07 1:37 ` Linus Torvalds
2017-10-07 1:55 ` Jia-Ju Bai
2017-10-07 2:02 ` Al Viro
2017-10-07 2:28 ` Al Viro [this message]
2017-10-09 13:32 ` Jan Kara
2017-10-08 22:20 ` Dave Chinner
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=20171007022839.GP21978@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=baijiaju1990@163.com \
--cc=jack@suse.com \
--cc=james.smart@broadcom.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sagi@grimberg.me \
--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 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.