From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Jens Axboe <axboe@kernel.dk>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] block: ensure bdi->io_pages is always initialized
Date: Tue, 01 Sep 2020 02:53:41 +0900 [thread overview]
Message-ID: <878sdu66sa.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <346e5bf5-b08e-84e8-7b0e-c6cb0c814f96@kernel.dk> (Jens Axboe's message of "Mon, 31 Aug 2020 11:23:32 -0600")
Jens Axboe <axboe@kernel.dk> writes:
> If a driver leaves the limit settings as the defaults, then we don't
> initialize bdi->io_pages. This means that file systems may need to
> work around bdi->io_pages == 0, which is somewhat messy.
>
> Initialize the default value just like we do for ->ra_pages.
>
> Cc: stable@vger.kernel.org
> Reported-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
When queued to submit, please let us know to drop fatfs workaround
"fat-avoid-oops-when-bdi-io_pages==0.patch" in akpm series.
Thanks.
> ---
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index d9d632639bd1..10c08ac50697 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -539,6 +539,7 @@ struct request_queue *blk_alloc_queue(int node_id)
> goto fail_stats;
>
> q->backing_dev_info->ra_pages = VM_READAHEAD_PAGES;
> + q->backing_dev_info->io_pages = VM_READAHEAD_PAGES;
> q->backing_dev_info->capabilities = BDI_CAP_CGROUP_WRITEBACK;
> q->node = node_id;
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2020-08-31 18:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 17:23 [PATCH] block: ensure bdi->io_pages is always initialized Jens Axboe
2020-08-31 17:53 ` OGAWA Hirofumi [this message]
2020-08-31 18:10 ` Jens Axboe
2020-08-31 18:20 ` OGAWA Hirofumi
2020-09-01 5:43 ` Christoph Hellwig
2020-09-01 14:00 ` 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=878sdu66sa.fsf@mail.parknet.co.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=linux-block@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 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.