Re: Uses of ->write_begin/write_end

[Christoph Hellwig <hch@lst.de>]

On Mon, Jul 15, 2024 at 04:59:36PM +0100, Matthew Wilcox wrote:
> I'm looking at ->write_begin() / ->write_end() again.  Here are our
> current callers:
> 
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c:
> [1]	shmem_pwrite()
> [2]	i915_gem_object_create_shmem_from_data()

These really need to use actual shmem exported APIs, probably
shmem_get_folio, instead of abusing the aops.  With that we can
then easily kill ->write_begin() / ->write_end() for shmem.

> fs/affs/file.c:

Most of these fs-specific ones should really hardcode the calls to the
usually once or sometimes few potential instances that could be called
so that we can devirtualize the alls.

> fs/buffer.c:
> [4]	generic_cont_expand_simple()
> [5]	cont_expand_zero()
> [6]	cont_expand_zero()

> fs/namei.c:
> [B]	page_symlink()

> The copy_from_user() / memcpy() users feel like they should all end
> up calling ->write_iter().

> One way they could do this is by calling
> kernel_write() / __kernel_write(), but I'm not sure whether they
> should have the various accounting things (add_wchar(), inc_syscw())
> that happen inside __kernel_write_iter().
> 

They often sit much lower in the stack and/or are used for files that
don't have a ->write_iter.  e.g. page_symlink is obviously used for
symlinks that don't have ->write_iter.

For generic_cont_expand_simple goins through write_iter might be an
option, but instead of going through file ops the better idea might be
to just pass a write_iter-prototyped callback directly to it.

cont_expand_zero is a helper for cont_write_begin, which is used to
implement ->write_begin, so this actually already is a recursion, adding
another indirect to it is probably not helpful.