From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-xfs@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 05/15] xfs: remove the xfile_pread/pwrite APIs
Date: Wed, 3 Jan 2024 15:48:49 -0800 [thread overview]
Message-ID: <20240103234849.GY361584@frogsfrogsfrogs> (raw)
In-Reply-To: <20240103084126.513354-6-hch@lst.de>
On Wed, Jan 03, 2024 at 08:41:16AM +0000, Christoph Hellwig wrote:
> All current and pending xfile users use the xfile_obj_load
> and xfile_obj_store API, so make those the actual implementation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> .../xfs/xfs-online-fsck-design.rst | 10 +---
> fs/xfs/scrub/trace.h | 4 +-
> fs/xfs/scrub/xfile.c | 54 +++++++++----------
> fs/xfs/scrub/xfile.h | 32 +----------
> 4 files changed, 30 insertions(+), 70 deletions(-)
>
> diff --git a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
> index 352516feef6ffe..324d5ec921e8e5 100644
> --- a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
> +++ b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
> @@ -1915,19 +1915,13 @@ four of those five higher level data structures.
> The fifth use case is discussed in the :ref:`realtime summary <rtsummary>` case
> study.
>
> -The most general storage interface supported by the xfile enables the reading
> -and writing of arbitrary quantities of data at arbitrary offsets in the xfile.
> -This capability is provided by ``xfile_pread`` and ``xfile_pwrite`` functions,
> -which behave similarly to their userspace counterparts.
> XFS is very record-based, which suggests that the ability to load and store
> complete records is important.
> To support these cases, a pair of ``xfile_obj_load`` and ``xfile_obj_store``
> -functions are provided to read and persist objects into an xfile.
> -They are internally the same as pread and pwrite, except that they treat any
> -error as an out of memory error.
> +functions are provided to read and persist objects into an xfile that unlike
> +the pread and pwrite system calls treat any error as an out of memory error.
I don't think we need to mention pread and pwrite anymore.
"To support these cases, a pair of ``xfile_obj_load`` and ``xfile_obj_store``
functions are provided to read and persist objects into an xfile. An errors
encountered here are treated as an out of memory error."
> For online repair, squashing error conditions in this manner is an acceptable
> behavior because the only reaction is to abort the operation back to userspace.
> -All five xfile usecases can be serviced by these four functions.
>
> However, no discussion of file access idioms is complete without answering the
> question, "But what about mmap?"
> diff --git a/fs/xfs/scrub/trace.h b/fs/xfs/scrub/trace.h
> index ed9e044f6d603c..e6156d000fc615 100644
> --- a/fs/xfs/scrub/trace.h
> +++ b/fs/xfs/scrub/trace.h
> @@ -903,8 +903,8 @@ DECLARE_EVENT_CLASS(xfile_class,
> DEFINE_EVENT(xfile_class, name, \
> TP_PROTO(struct xfile *xf, loff_t pos, unsigned long long bytecount), \
> TP_ARGS(xf, pos, bytecount))
> -DEFINE_XFILE_EVENT(xfile_pread);
> -DEFINE_XFILE_EVENT(xfile_pwrite);
> +DEFINE_XFILE_EVENT(xfile_obj_load);
> +DEFINE_XFILE_EVENT(xfile_obj_store);
Want to shorten the names to xfile_load and xfile_store? That's really
what they're doing anyway.
With those changes,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> DEFINE_XFILE_EVENT(xfile_seek_data);
> DEFINE_XFILE_EVENT(xfile_get_page);
> DEFINE_XFILE_EVENT(xfile_put_page);
> diff --git a/fs/xfs/scrub/xfile.c b/fs/xfs/scrub/xfile.c
> index 87654cdd5ac6f9..9e25ecf3dc2fec 100644
> --- a/fs/xfs/scrub/xfile.c
> +++ b/fs/xfs/scrub/xfile.c
> @@ -118,13 +118,11 @@ xfile_destroy(
> }
>
> /*
> - * Read a memory object directly from the xfile's page cache. Unlike regular
> - * pread, we return -E2BIG and -EFBIG for reads that are too large or at too
> - * high an offset, instead of truncating the read. Otherwise, we return
> - * bytes read or an error code, like regular pread.
> + * Load an object. Since we're treating this file as "memory", any error or
> + * short IO is treated as a failure to allocate memory.
> */
> -ssize_t
> -xfile_pread(
> +int
> +xfile_obj_load(
> struct xfile *xf,
> void *buf,
> size_t count,
> @@ -133,16 +131,15 @@ xfile_pread(
> struct inode *inode = file_inode(xf->file);
> struct address_space *mapping = inode->i_mapping;
> struct page *page = NULL;
> - ssize_t read = 0;
> unsigned int pflags;
> int error = 0;
>
> if (count > MAX_RW_COUNT)
> - return -E2BIG;
> + return -ENOMEM;
> if (inode->i_sb->s_maxbytes - pos < count)
> - return -EFBIG;
> + return -ENOMEM;
>
> - trace_xfile_pread(xf, pos, count);
> + trace_xfile_obj_load(xf, pos, count);
>
> pflags = memalloc_nofs_save();
> while (count > 0) {
> @@ -160,8 +157,10 @@ xfile_pread(
> __GFP_NOWARN);
> if (IS_ERR(page)) {
> error = PTR_ERR(page);
> - if (error != -ENOMEM)
> + if (error != -ENOMEM) {
> + error = -ENOMEM;
> break;
> + }
>
> memset(buf, 0, len);
> goto advance;
> @@ -185,23 +184,18 @@ xfile_pread(
> count -= len;
> pos += len;
> buf += len;
> - read += len;
> }
> memalloc_nofs_restore(pflags);
>
> - if (read > 0)
> - return read;
> return error;
> }
>
> /*
> - * Write a memory object directly to the xfile's page cache. Unlike regular
> - * pwrite, we return -E2BIG and -EFBIG for writes that are too large or at too
> - * high an offset, instead of truncating the write. Otherwise, we return
> - * bytes written or an error code, like regular pwrite.
> + * Store an object. Since we're treating this file as "memory", any error or
> + * short IO is treated as a failure to allocate memory.
> */
> -ssize_t
> -xfile_pwrite(
> +int
> +xfile_obj_store(
> struct xfile *xf,
> const void *buf,
> size_t count,
> @@ -211,16 +205,15 @@ xfile_pwrite(
> struct address_space *mapping = inode->i_mapping;
> const struct address_space_operations *aops = mapping->a_ops;
> struct page *page = NULL;
> - ssize_t written = 0;
> unsigned int pflags;
> int error = 0;
>
> if (count > MAX_RW_COUNT)
> - return -E2BIG;
> + return -ENOMEM;
> if (inode->i_sb->s_maxbytes - pos < count)
> - return -EFBIG;
> + return -ENOMEM;
>
> - trace_xfile_pwrite(xf, pos, count);
> + trace_xfile_obj_store(xf, pos, count);
>
> pflags = memalloc_nofs_save();
> while (count > 0) {
> @@ -239,8 +232,10 @@ xfile_pwrite(
> */
> error = aops->write_begin(NULL, mapping, pos, len, &page,
> &fsdata);
> - if (error)
> + if (error) {
> + error = -ENOMEM;
> break;
> + }
>
> /*
> * xfile pages must never be mapped into userspace, so we skip
> @@ -259,13 +254,14 @@ xfile_pwrite(
> ret = aops->write_end(NULL, mapping, pos, len, len, page,
> fsdata);
> if (ret < 0) {
> - error = ret;
> + error = -ENOMEM;
> break;
> }
>
> - written += ret;
> - if (ret != len)
> + if (ret != len) {
> + error = -ENOMEM;
> break;
> + }
>
> count -= ret;
> pos += ret;
> @@ -273,8 +269,6 @@ xfile_pwrite(
> }
> memalloc_nofs_restore(pflags);
>
> - if (written > 0)
> - return written;
> return error;
> }
>
> diff --git a/fs/xfs/scrub/xfile.h b/fs/xfs/scrub/xfile.h
> index c602d11560d8ee..f0e11febf216a7 100644
> --- a/fs/xfs/scrub/xfile.h
> +++ b/fs/xfs/scrub/xfile.h
> @@ -29,38 +29,10 @@ struct xfile {
> int xfile_create(const char *description, loff_t isize, struct xfile **xfilep);
> void xfile_destroy(struct xfile *xf);
>
> -ssize_t xfile_pread(struct xfile *xf, void *buf, size_t count, loff_t pos);
> -ssize_t xfile_pwrite(struct xfile *xf, const void *buf, size_t count,
> +int xfile_obj_load(struct xfile *xf, void *buf, size_t count, loff_t pos);
> +int xfile_obj_store(struct xfile *xf, const void *buf, size_t count,
> loff_t pos);
>
> -/*
> - * Load an object. Since we're treating this file as "memory", any error or
> - * short IO is treated as a failure to allocate memory.
> - */
> -static inline int
> -xfile_obj_load(struct xfile *xf, void *buf, size_t count, loff_t pos)
> -{
> - ssize_t ret = xfile_pread(xf, buf, count, pos);
> -
> - if (ret < 0 || ret != count)
> - return -ENOMEM;
> - return 0;
> -}
> -
> -/*
> - * Store an object. Since we're treating this file as "memory", any error or
> - * short IO is treated as a failure to allocate memory.
> - */
> -static inline int
> -xfile_obj_store(struct xfile *xf, const void *buf, size_t count, loff_t pos)
> -{
> - ssize_t ret = xfile_pwrite(xf, buf, count, pos);
> -
> - if (ret < 0 || ret != count)
> - return -ENOMEM;
> - return 0;
> -}
> -
> loff_t xfile_seek_data(struct xfile *xf, loff_t pos);
>
> int xfile_get_page(struct xfile *xf, loff_t offset, unsigned int len,
> --
> 2.39.2
>
>
next prev parent reply other threads:[~2024-01-03 23:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 8:41 put the xfs xfile abstraction on a diet Christoph Hellwig
2024-01-03 8:41 ` [PATCH 01/15] shmem: move the shmem_mapping assert into shmem_get_folio_gfp Christoph Hellwig
2024-01-03 23:32 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 02/15] shmem: export shmem_get_folio Christoph Hellwig
2024-01-03 8:41 ` [PATCH 03/15] shmem: document how to "persist" data when using shmem_*file_setup Christoph Hellwig
2024-01-04 0:21 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 04/15] xfs: remove xfile_stat Christoph Hellwig
2024-01-03 23:45 ` Darrick J. Wong
2024-01-04 6:14 ` Christoph Hellwig
2024-01-04 6:55 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 05/15] xfs: remove the xfile_pread/pwrite APIs Christoph Hellwig
2024-01-03 23:48 ` Darrick J. Wong [this message]
2024-01-04 6:15 ` Christoph Hellwig
2024-01-04 6:58 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 06/15] xfs: don't try to handle non-update pages in xfile_obj_load Christoph Hellwig
2024-01-03 23:55 ` Darrick J. Wong
2024-01-04 6:21 ` Christoph Hellwig
2024-01-03 8:41 ` [PATCH 07/15] xfs: shmem_file_setup can't return NULL Christoph Hellwig
2024-01-03 23:56 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 08/15] xfs: don't modify file and inode flags for shmem files Christoph Hellwig
2024-01-04 0:01 ` Darrick J. Wong
2024-01-04 6:23 ` Christoph Hellwig
2024-01-03 8:41 ` [PATCH 09/15] xfs: don't allow highmem pages in xfile mappings Christoph Hellwig
[not found] ` <20240104000324.GC361584@frogsfrogsfrogs>
2024-01-04 6:24 ` Christoph Hellwig
2024-01-04 7:01 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 10/15] xfs: remove xfarray_sortinfo.page_kaddr Christoph Hellwig
2024-01-04 0:04 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 11/15] xfs: use shmem_get_folio in xfile_get_page Christoph Hellwig
2024-01-04 0:12 ` Darrick J. Wong
2024-01-04 6:25 ` Christoph Hellwig
2024-01-03 8:41 ` [PATCH 12/15] xfs: remove struct xfile_page Christoph Hellwig
2024-01-10 22:42 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 13/15] xfs: don't unconditionally allocate a new page in xfile_get_page Christoph Hellwig
2024-01-04 0:18 ` Darrick J. Wong
2024-01-03 8:41 ` [PATCH 14/15] xfs: use xfile_get_page and xfile_put_page in xfile_obj_store Christoph Hellwig
2024-01-04 0:20 ` Darrick J. Wong
2024-01-04 6:26 ` Christoph Hellwig
2024-01-03 8:41 ` [PATCH 15/15] xfs: use xfile_get_page and xfile_put_page in xfile_obj_load Christoph Hellwig
2024-01-04 0:21 ` Darrick J. Wong
2024-01-04 1:35 ` put the xfs xfile abstraction on a diet Darrick J. Wong
2024-01-04 6:26 ` Christoph Hellwig
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=20240103234849.GY361584@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=chandan.babu@oracle.com \
--cc=hch@lst.de \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox