From: Pankaj Raghav <p.raghav@samsung.com>
To: Matthew Wilcox <willy@infradead.org>,
Luis Chamberlain <mcgrof@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
Daniel Gomez <da.gomez@samsung.com>, Jens Axboe <axboe@kernel.dk>,
Miklos Szeredi <miklos@szeredi.hu>,
"Darrick J. Wong" <djwong@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
<linux-block@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
<ceph-devel@vger.kernel.org>, <linux-ext4@vger.kernel.org>,
<linux-f2fs-devel@lists.sourceforge.net>,
<cluster-devel@redhat.com>, <linux-xfs@vger.kernel.org>,
<linux-nfs@vger.kernel.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 17/17] fs: add CONFIG_BUFFER_HEAD
Date: Mon, 1 May 2023 18:00:52 +0200 [thread overview]
Message-ID: <6dcf69ee-21cd-ae06-c250-e991652989ac@samsung.com> (raw)
In-Reply-To: <ZE/ew1VpU/a1gqQP@casper.infradead.org>
>> No but the only place to add that would be in the block cache. Adding
>> that alone to the block cache doesn't fix the issue. The below patch
>> however does get us by.
>
> That's "working around the error", not fixing it ... probably the same
> root cause as your other errors; at least I'm not diving into them until
> the obvious one is fixed.
>
>> >From my readings it does't seem like readahead_folio() should always
>> return non-NULL, and also I couldn't easily verify the math is right.
>
> readahead_folio() always returns non-NULL. That's guaranteed by how
> page_cache_ra_unbounded() and page_cache_ra_order() work. It allocates
> folios, until it can't (already-present folio, ENOMEM, EOF, max batch
> size) and then calls the filesystem to make those folios uptodate,
> telling it how many folios it put in the page cache, where they start.
>
> Hm. The fact that it's coming from page_cache_ra_unbounded() makes
> me wonder if you updated this line:
>
> folio = filemap_alloc_folio(gfp_mask, 0);
>
> without updating this line:
>
> ractl->_nr_pages++;
>
> This is actually number of pages, not number of folios, so needs to be
> ractl->_nr_pages += 1 << order;
>
I already had a patch which did the following:
ractl->_nr_pages += folio_nr_pages(folio);
but the variable `i` in the loop was not updated properly (assumption of zero order folio). This now
fixes the crash:
@@ -210,7 +210,7 @@ void page_cache_ra_unbounded(struct readahead_control *ractl,
unsigned long index = readahead_index(ractl);
gfp_t gfp_mask = readahead_gfp_mask(mapping);
unsigned long i;
-
+ int order = 0;
/*
* Partway through the readahead operation, we will have added
* locked pages to the page cache, but will not yet have submitted
@@ -223,6 +223,9 @@ void page_cache_ra_unbounded(struct readahead_control *ractl,
*/
unsigned int nofs = memalloc_nofs_save();
+ if (mapping->host->i_blkbits > PAGE_SHIFT)
+ order = mapping->host->i_blkbits - PAGE_SHIFT;
+
filemap_invalidate_lock_shared(mapping);
/*
* Preallocate as many pages as we will need.
@@ -245,7 +248,7 @@ void page_cache_ra_unbounded(struct readahead_control *ractl,
continue;
}
- folio = filemap_alloc_folio(gfp_mask, 0);
+ folio = filemap_alloc_folio(gfp_mask, order);
if (!folio)
break;
if (filemap_add_folio(mapping, folio, index + i,
@@ -259,7 +262,8 @@ void page_cache_ra_unbounded(struct readahead_control *ractl,
if (i == nr_to_read - lookahead_size)
folio_set_readahead(folio);
ractl->_workingset |= folio_test_workingset(folio);
- ractl->_nr_pages++;
+ ractl->_nr_pages += folio_nr_pages(folio);
+ i += folio_nr_pages(folio) - 1;
}
> various other parts of page_cache_ra_unbounded() need to be examined
> carefully for assumptions of order-0; it's never been used for that
> before. all the large folio work has concentrated on
> page_cache_ra_order()
As you have noted here, this needs to be examined more carefully. Even though the patches fix the
crash, fio with verify option fails (i.e write and read are not giving the same output).
I think it is better to send an RFC patch series on top of Christoph's work with optional
BUFFER_HEAD to iron out some core issues/bugs.
prev parent reply other threads:[~2023-05-01 16:01 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 5:49 RFC: allow building a kernel without buffer_heads Christoph Hellwig
2023-04-24 5:49 ` [PATCH 01/17] fs: unexport buffer_check_dirty_writeback Christoph Hellwig
2023-05-19 14:17 ` Hannes Reinecke
2023-07-06 0:18 ` [f2fs-dev] " patchwork-bot+f2fs
2023-09-04 18:11 ` patchwork-bot+f2fs
2023-04-24 5:49 ` [PATCH 02/17] fs: remove the special !CONFIG_BLOCK def_blk_fops Christoph Hellwig
2023-04-24 19:22 ` Randy Dunlap
2023-04-24 19:37 ` Keith Busch
2023-04-24 5:49 ` [PATCH 03/17] fs: rename and move block_page_mkwrite_return Christoph Hellwig
2023-04-24 12:30 ` Matthew Wilcox
2023-04-24 12:42 ` Christoph Hellwig
2023-04-24 5:49 ` [PATCH 04/17] fs: remove emergency_thaw_bdev Christoph Hellwig
2023-04-24 5:49 ` [PATCH 05/17] filemap: update ki_pos in generic_perform_write Christoph Hellwig
2023-04-24 18:54 ` [Cluster-devel] " Andreas Gruenbacher
2023-04-24 5:49 ` [PATCH 06/17] filemap: add a kiocb_write_and_wait helper Christoph Hellwig
2023-04-24 5:49 ` [PATCH 07/17] filemap: add a kiocb_invalidate_pages helper Christoph Hellwig
2023-04-24 5:49 ` [PATCH 08/17] filemap: add a kiocb_invalidate_post_write helper Christoph Hellwig
2023-04-24 5:49 ` [PATCH 09/17] fs: factor out a direct_write_fallback helper Christoph Hellwig
2023-04-24 5:49 ` [PATCH 10/17] iomap: use kiocb_write_and_wait and kiocb_invalidate_pages Christoph Hellwig
2023-04-24 5:49 ` [PATCH 11/17] iomap: assign current->backing_dev_info in iomap_file_buffered_write Christoph Hellwig
2023-04-24 6:18 ` Darrick J. Wong
2023-04-24 6:22 ` Christoph Hellwig
2023-04-24 5:49 ` [PATCH 12/17] fuse: use direct_write_fallback Christoph Hellwig
2023-04-24 5:49 ` [PATCH 13/17] block: don't plug in blkdev_write_iter Christoph Hellwig
2023-04-24 5:49 ` [PATCH 14/17] block: open code __generic_file_write_iter for blkdev writes Christoph Hellwig
2023-05-24 22:23 ` Luis Chamberlain
2023-04-24 5:49 ` [PATCH 15/17] block: stop setting ->direct_IO Christoph Hellwig
2023-04-24 5:49 ` [PATCH 16/17] block: use iomap for writes to block devices Christoph Hellwig
[not found] ` <CGME20230426130921eucas1p279078812be7e8d50c1305e47cea53661@eucas1p2.samsung.com>
2023-04-26 13:00 ` [f2fs-dev] " Pankaj Raghav
2023-05-19 14:22 ` Hannes Reinecke
2023-05-23 22:27 ` Dave Chinner
2023-05-24 13:33 ` Matthew Wilcox
2023-07-20 12:09 ` Christoph Hellwig
2023-07-20 12:06 ` Christoph Hellwig
2023-07-20 12:16 ` Hannes Reinecke
2023-04-24 5:49 ` [PATCH 17/17] fs: add CONFIG_BUFFER_HEAD Christoph Hellwig
2023-04-29 0:11 ` Luis Chamberlain
2023-04-29 1:20 ` Matthew Wilcox
2023-05-01 3:14 ` Luis Chamberlain
2023-05-01 15:46 ` Matthew Wilcox
2023-05-01 16:00 ` Pankaj Raghav [this message]
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=6dcf69ee-21cd-ae06-c250-e991652989ac@samsung.com \
--to=p.raghav@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=ceph-devel@vger.kernel.org \
--cc=cluster-devel@redhat.com \
--cc=da.gomez@samsung.com \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=miklos@szeredi.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome