From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fat: Avoid oops when bdi->io_pages==0
Date: Sun, 30 Aug 2020 10:54:35 +0900 [thread overview]
Message-ID: <874kokq4o4.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <20200830012151.GW14765@casper.infradead.org> (Matthew Wilcox's message of "Sun, 30 Aug 2020 02:21:51 +0100")
Matthew Wilcox <willy@infradead.org> writes:
> On Sun, Aug 30, 2020 at 09:59:41AM +0900, OGAWA Hirofumi 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);
>
> Wait, rounddown? ->io_pages is supposed to be the maximum number of
> pages to readahead. Shouldn't this be max() instead of rounddown()?
Hm, io_pages is limited by driver setting too, and io_pages can be lower
than ra_pages, e.g. usb storage.
Assuming ra_pages is user intent of readahead window. So if io_pages is
lower than ra_pages, this try ra_pages to align of io_pages chunk, but
not bigger than ra_pages. Because if block layer splits I/O requests to
hard limit, then I/O is not optimal.
So it is intent, I can be misunderstanding though.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2020-08-30 1:54 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 [this message]
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
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=874kokq4o4.fsf@mail.parknet.co.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.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.