From: Jens Axboe <axboe@kernel.dk>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] fat: Avoid oops when bdi->io_pages==0
Date: Mon, 31 Aug 2020 10:39:26 -0600 [thread overview]
Message-ID: <4010690f-20ad-f7ba-b595-2e07b0fa2d94@kernel.dk> (raw)
In-Reply-To: <87o8mq6aao.fsf@mail.parknet.co.jp>
On 8/31/20 10:37 AM, OGAWA Hirofumi wrote:
> Jens Axboe <axboe@kernel.dk> writes:
>
>> On Sat, Aug 29, 2020 at 7:08 PM OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
>>>
>>> On one system, there was bdi->io_pages==0. This seems to be the bug of
>>> a driver somewhere, and should fix it though. Anyway, it is better to
>>> avoid the divide-by-zero Oops.
>>>
>>> So this check it.
>>>
>>> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>> Cc: <stable@vger.kernel.org>
>>> ---
>>> fs/fat/fatent.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c
>>> index f7e3304..98a1c4f 100644
>>> --- a/fs/fat/fatent.c 2020-08-30 06:52:47.251564566 +0900
>>> +++ b/fs/fat/fatent.c 2020-08-30 06:54:05.838319213 +0900
>>> @@ -660,7 +660,7 @@ static void fat_ra_init(struct super_blo
>>> if (fatent->entry >= ent_limit)
>>> return;
>>>
>>> - if (ra_pages > sb->s_bdi->io_pages)
>>> + if (sb->s_bdi->io_pages && ra_pages > sb->s_bdi->io_pages)
>>> ra_pages = rounddown(ra_pages, sb->s_bdi->io_pages);
>>> reada_blocks = ra_pages << (PAGE_SHIFT - sb->s_blocksize_bits + 1);
>>
>> I don't think we should work-around this here. What device is this on?
>> Something like the below may help.
>
> The reported bug is from nvme stack, and the below patch (I submitted
> same patch to you) fixed the reported case though. But I didn't verify
> all possible path, so I'd liked to use safer side.
>
> If block layer can guarantee io_pages!=0 instead, and can apply to
> stable branch (5.8+). It would work too.
We really should ensure that ->io_pages is always set, imho, instead of
having to work-around it in other spots.
--
Jens Axboe
next prev parent reply other threads:[~2020-08-31 16:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-30 0:59 [PATCH] fat: Avoid oops when bdi->io_pages==0 OGAWA Hirofumi
2020-08-30 1:21 ` Matthew Wilcox
2020-08-30 1:54 ` OGAWA Hirofumi
2020-08-30 3:53 ` Matthew Wilcox
2020-08-30 9:04 ` OGAWA Hirofumi
2020-08-30 14:01 ` Sasha Levin
2020-08-30 14:16 ` OGAWA Hirofumi
2020-08-31 15:22 ` Jens Axboe
2020-08-31 16:37 ` OGAWA Hirofumi
2020-08-31 16:39 ` Jens Axboe [this message]
2020-08-31 16:56 ` Matthew Wilcox
2020-08-31 17:00 ` Jens Axboe
2020-08-31 17:39 ` OGAWA Hirofumi
2020-08-31 17:16 ` OGAWA Hirofumi
2020-08-31 17:19 ` Jens Axboe
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=4010690f-20ad-f7ba-b595-2e07b0fa2d94@kernel.dk \
--to=axboe@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.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 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).