| Message ID | 20240129143502.189370-8-hch@lst.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [01/20] mm: move mapping_set_update out of <linux/swap.h> | expand |
On Mon, Jan 29, 2024 at 03:34:49PM +0100, Christoph Hellwig wrote: > Add a blurb that simply dirtying the folio will persist data for in-kernel > shmem files. This is what most of the callers already do. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> I noticed today that drivers/gpu/drm/i915/gem/i915_gem_shmem.c is going to a lot of effort to call write_begin and write_end. I'll take that out as part of the shmem conversion to buffered_write_ops.
On Tue, Jan 30, 2024 at 06:06:12AM +0000, Matthew Wilcox wrote: > On Mon, Jan 29, 2024 at 03:34:49PM +0100, Christoph Hellwig wrote: > > Add a blurb that simply dirtying the folio will persist data for in-kernel > > shmem files. This is what most of the callers already do. > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > Reviewed-by: Darrick J. Wong <djwong@kernel.org> > > Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> > > I noticed today that drivers/gpu/drm/i915/gem/i915_gem_shmem.c is > going to a lot of effort to call write_begin and write_end. I'll > take that out as part of the shmem conversion to buffered_write_ops. I was planning to look into that, but I'll happily leave it to. It also calls into ->writepage in a somewhat gross way.
On Tue, Jan 30, 2024 at 06:06:12AM +0000, Matthew Wilcox wrote:
> take that out as part of the shmem conversion to buffered_write_ops.
Oh, and I think shmem is actually a good candidate for
iomap_file_buffered_write. I think it just needs to
plug shmem_get_folio into iomap_folio_ops ->get_folio and provide
an identify mapped iomap like the block device.
diff --git a/mm/shmem.c b/mm/shmem.c index e89fb5eccb0c0a..f73dead491b11d 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2148,6 +2148,10 @@ static int shmem_get_folio_gfp(struct inode *inode, pgoff_t index, * * If this function returns a folio, it is returned with an increased refcount. * + * If the caller modifies data in the folio, it must call folio_mark_dirty() + * before unlocking the folio to ensure that the folio is not reclaimed. + * These is no need to reserve space before calling folio_mark_dirty(). + * * Return: The found folio, %NULL if SGP_READ or SGP_NOALLOC was passed in @sgp * and no folio was found at @index, or an ERR_PTR() otherwise. */