| Message ID | 20250612143443.2848197-1-willy@infradead.org |
|---|---|
| Headers | show |
| Series | Remove zero_user() | expand |
On Thu, 2025-06-12 at 15:34 +0100, Matthew Wilcox (Oracle) wrote: > Retrieve a folio from the pagecache instead of a page and operate on it. > Removes several hidden calls to compound_head() along with calls to > deprecated functions like wait_on_page_writeback() and find_lock_page(). > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > --- > fs/ceph/file.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/fs/ceph/file.c b/fs/ceph/file.c > index a7254cab44cc..d5c674d2ba8a 100644 > --- a/fs/ceph/file.c > +++ b/fs/ceph/file.c > @@ -2530,18 +2530,17 @@ static loff_t ceph_llseek(struct file *file, loff_t offset, int whence) > return generic_file_llseek(file, offset, whence); > } > > -static inline void ceph_zero_partial_page( > - struct inode *inode, loff_t offset, unsigned size) > +static inline void ceph_zero_partial_page(struct inode *inode, > + loff_t offset, size_t size) > { > - struct page *page; > - pgoff_t index = offset >> PAGE_SHIFT; > - > - page = find_lock_page(inode->i_mapping, index); > - if (page) { > - wait_on_page_writeback(page); > - zero_user(page, offset & (PAGE_SIZE - 1), size); > - unlock_page(page); > - put_page(page); > + struct folio *folio; > + > + folio = filemap_lock_folio(inode->i_mapping, offset >> PAGE_SHIFT); > + if (folio) { > + folio_wait_writeback(folio); > + folio_zero_range(folio, offset_in_folio(folio, offset), size); > + folio_unlock(folio); > + folio_put(folio); > } > } > Looks really good. And filemap_lock_folio() is more efficient than find_lock_page() now. Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Thanks, Slava.
On Thu, Jun 12, 2025 at 03:34:36PM +0100, Matthew Wilcox (Oracle) wrote: > The zero_user() API is almost unused these days. Finish the job of > removing it. Both the block layer users really should use bvec based helpers. I was planning to get to that this merge window. Can we queue up just the other two removals for and remove zero_user after -rc1 to reduce conflicts?
On Fri, Jun 13, 2025 at 07:24:32AM +0200, Christoph Hellwig wrote: > On Thu, Jun 12, 2025 at 03:34:36PM +0100, Matthew Wilcox (Oracle) wrote: > > The zero_user() API is almost unused these days. Finish the job of > > removing it. > > Both the block layer users really should use bvec based helpers. > I was planning to get to that this merge window. Can we queue up > just the other two removals for and remove zero_user after -rc1 > to reduce conflicts? If I'd known you were doing that, I wouldn't've bothered. However, Andrew's taken the patches now, so I'm inclined to leave them in. No matter which tree it gets merged through, this is a relatively easy conflict to resolve (ie just take your version). I have some more patches which build on the removal of zero_user() so it'd be nice to not hold them up.
On Fri, 13 Jun 2025 20:51:06 +0100 Matthew Wilcox <willy@infradead.org> wrote: > On Fri, Jun 13, 2025 at 07:24:32AM +0200, Christoph Hellwig wrote: > > On Thu, Jun 12, 2025 at 03:34:36PM +0100, Matthew Wilcox (Oracle) wrote: > > > The zero_user() API is almost unused these days. Finish the job of > > > removing it. > > > > Both the block layer users really should use bvec based helpers. > > I was planning to get to that this merge window. Can we queue up > > just the other two removals for and remove zero_user after -rc1 > > to reduce conflicts? > > If I'd known you were doing that, I wouldn't've bothered. However, > Andrew's taken the patches now, so I'm inclined to leave them in. > No matter which tree it gets merged through, this is a relatively easy > conflict to resolve (ie just take your version). I have some more > patches which build on the removal of zero_user() so it'd be nice to > not hold them up. Sure, Christoph, please just proceed with the block changes and we can see what the conflicts look like when Stephen hits them. If Matthew's series needs modification then so be it.