From: Omar Sandoval <redacted>
This series adds an API for reading compressed data on a filesystem
without decompressing it as well as support for writing compressed data
directly to the filesystem. I have test cases (including fsstress
support) and example programs which I'll send up once the dust settles
[1].
The main use-case is Btrfs send/receive: currently, when sending data
from one compressed filesystem to another, the sending side decompresses
the data and the receiving side recompresses it before writing it out.
This is wasteful and can be avoided if we can just send and write
compressed extents. The patches implementing the send/receive support
were sent with the last submission of this series [2].
Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7
are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and
patch 9 adds Btrfs encoded write support.
These patches are based on Dave Sterba's Btrfs misc-next branch [3],
which is in turn currently based on v5.13-rc6.
This is a _resend of a resend of a resend_ of v9 [4], rebased on the
latest kdave/misc-next branch.
In the last resend, there was some good discussion around how to support
encryption with this interface in the future. The conclusion was that
this interface should suffice for file data, and we would need separate
interface(s) for working with encrypted file names. So, this really just
needs review on the VFS side.
1: https://github.com/osandov/xfstests/tree/rwf-encoded
2: https://lore.kernel.org/linux-btrfs/cover.1615922753.git.osandov@fb.com/
3: https://github.com/kdave/btrfs-devel/tree/misc-next
4: https://lore.kernel.org/linux-fsdevel/cover.1621276134.git.osandov@fb.com/
Omar Sandoval (9):
iov_iter: add copy_struct_from_iter()
fs: add O_ALLOW_ENCODED open flag
fs: add RWF_ENCODED for reading/writing compressed data
btrfs: don't advance offset for compressed bios in
btrfs_csum_one_bio()
btrfs: add ram_bytes and offset to btrfs_ordered_extent
btrfs: support different disk extent size for delalloc
btrfs: optionally extend i_size in cow_file_range_inline()
btrfs: implement RWF_ENCODED reads
btrfs: implement RWF_ENCODED writes
Documentation/filesystems/encoded_io.rst | 240 ++++++
Documentation/filesystems/index.rst | 1 +
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 1 +
arch/sparc/include/uapi/asm/fcntl.h | 1 +
fs/btrfs/compression.c | 12 +-
fs/btrfs/compression.h | 6 +-
fs/btrfs/ctree.h | 9 +-
fs/btrfs/delalloc-space.c | 18 +-
fs/btrfs/file-item.c | 35 +-
fs/btrfs/file.c | 46 +-
fs/btrfs/inode.c | 925 +++++++++++++++++++++--
fs/btrfs/ordered-data.c | 124 +--
fs/btrfs/ordered-data.h | 25 +-
fs/btrfs/relocation.c | 4 +-
fs/fcntl.c | 10 +-
fs/namei.c | 4 +
fs/read_write.c | 168 +++-
include/linux/encoded_io.h | 17 +
include/linux/fcntl.h | 2 +-
include/linux/fs.h | 13 +
include/linux/uio.h | 1 +
include/uapi/asm-generic/fcntl.h | 4 +
include/uapi/linux/encoded_io.h | 30 +
include/uapi/linux/fs.h | 5 +-
lib/iov_iter.c | 91 +++
26 files changed, 1559 insertions(+), 234 deletions(-)
create mode 100644 Documentation/filesystems/encoded_io.rst
create mode 100644 include/linux/encoded_io.h
create mode 100644 include/uapi/linux/encoded_io.h
--
2.32.0
From: Omar Sandoval <redacted>
The upcoming RWF_ENCODED operation introduces some security concerns:
1. Compressed writes will pass arbitrary data to decompression
algorithms in the kernel.
2. Compressed reads can leak truncated/hole punched data.
Therefore, we need to require privilege for RWF_ENCODED. It's not
possible to do the permissions checks at the time of the read or write
because, e.g., io_uring submits IO from a worker thread. So, add an open
flag which requires CAP_SYS_ADMIN. It can also be set and cleared with
fcntl(). The flag is not cleared in any way on fork or exec.
Note that the usual issue that unknown open flags are ignored doesn't
really matter for O_ALLOW_ENCODED; if the kernel doesn't support
O_ALLOW_ENCODED, then it doesn't support RWF_ENCODED, either.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 1 +
arch/sparc/include/uapi/asm/fcntl.h | 1 +
fs/fcntl.c | 10 ++++++++--
fs/namei.c | 4 ++++
include/linux/fcntl.h | 2 +-
include/uapi/asm-generic/fcntl.h | 4 ++++
7 files changed, 20 insertions(+), 3 deletions(-)
@@ -50,6 +51,11 @@ static int setfl(int fd, struct file * filp, unsigned long arg)if(!inode_owner_or_capable(file_mnt_user_ns(filp),inode))return-EPERM;+/* O_ALLOW_ENCODED can only be set by superuser */+if((arg&O_ALLOW_ENCODED)&&!(filp->f_flags&O_ALLOW_ENCODED)&&+!capable(CAP_SYS_ADMIN))+return-EPERM;+/* required for strict SunOS emulation */if(O_NONBLOCK!=O_NDELAY)if(arg&O_NDELAY)
@@ -1043,7 +1049,7 @@ static int __init fcntl_init(void)*Exceptions:O_NONBLOCKisatwobitdefineonparisc;O_NDELAY*isdefinedasO_NONBLOCKonsomeplatformsandnotonothers.*/-BUILD_BUG_ON(21-1/* for O_RDONLY being 0 */!=+BUILD_BUG_ON(22-1/* for O_RDONLY being 0 */!=HWEIGHT32((VALID_OPEN_FLAGS&~(O_NONBLOCK|O_NDELAY))|__FMODE_EXEC|__FMODE_NONOTIFY));
@@ -2997,6 +2997,10 @@ static int may_open(struct user_namespace *mnt_userns, const struct path *path,if(flag&O_NOATIME&&!inode_owner_or_capable(mnt_userns,inode))return-EPERM;+/* O_ALLOW_ENCODED can only be set by superuser */+if((flag&O_ALLOW_ENCODED)&&!capable(CAP_SYS_ADMIN))+return-EPERM;+return0;}
@@ -10,7 +10,7 @@(O_RDONLY|O_WRONLY|O_RDWR|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|\O_APPEND|O_NDELAY|O_NONBLOCK|__O_SYNC|O_DSYNC|\FASYNC|O_DIRECT|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|\-O_NOATIME|O_CLOEXEC|O_PATH|__O_TMPFILE)+O_NOATIME|O_CLOEXEC|O_PATH|__O_TMPFILE|O_ALLOW_ENCODED)/* List of all valid flags for the how->upgrade_mask argument: */#define VALID_UPGRADE_FLAGS \
@@ -89,6 +89,10 @@#define __O_TMPFILE 020000000#endif+#ifndef O_ALLOW_ENCODED+#define O_ALLOW_ENCODED 040000000+#endif+/* a horrid kludge trying to make sure that this will fail on old kernels */#define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)#define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT)
From: Omar Sandoval <redacted>
Btrfs supports transparent compression: data written by the user can be
compressed when written to disk and decompressed when read back.
However, we'd like to add an interface to write pre-compressed data
directly to the filesystem, and the matching interface to read
compressed data without decompressing it. This adds support for
so-called "encoded I/O" via preadv2() and pwritev2().
A new RWF_ENCODED flags indicates that a read or write is "encoded". If
this flag is set, iov[0].iov_base points to a struct encoded_iov which
is used for metadata: namely, the compression algorithm, unencoded
(i.e., decompressed) length, and what subrange of the unencoded data
should be used (needed for truncated or hole-punched extents and when
reading in the middle of an extent). For reads, the filesystem returns
this information; for writes, the caller provides it to the filesystem.
iov[0].iov_len must be set to sizeof(struct encoded_iov), which can be
used to extend the interface in the future a la copy_struct_from_user().
The remaining iovecs contain the encoded extent.
This adds the VFS helpers for supporting encoded I/O and documentation.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
Documentation/filesystems/encoded_io.rst | 240 +++++++++++++++++++++++
Documentation/filesystems/index.rst | 1 +
fs/read_write.c | 168 ++++++++++++++--
include/linux/encoded_io.h | 17 ++
include/linux/fs.h | 13 ++
include/uapi/linux/encoded_io.h | 30 +++
include/uapi/linux/fs.h | 5 +-
7 files changed, 460 insertions(+), 14 deletions(-)
create mode 100644 Documentation/filesystems/encoded_io.rst
create mode 100644 include/linux/encoded_io.h
create mode 100644 include/uapi/linux/encoded_io.h
@@ -0,0 +1,240 @@+===========+Encoded I/O+===========++Several filesystems (e.g., Btrfs) support transparent encoding (e.g.,+compression, encryption) of data on disk: written data is encoded by the kernel+before it is written to disk, and read data is decoded before being returned to+the user. In some cases, it is useful to skip this encoding step. For example,+the user may want to read the compressed contents of a file or write+pre-compressed data directly to a file. This is referred to as "encoded I/O".++User API+========++Encoded I/O is specified with the ``RWF_ENCODED`` flag to ``preadv2()`` and+``pwritev2()``. If ``RWF_ENCODED`` is specified, then ``iov[0].iov_base``+points to an ``encoded_iov`` structure, defined in ``<linux/encoded_io.h>``+as::++ struct encoded_iov {+ __aligned_u64 len;+ __aligned_u64 unencoded_len;+ __aligned_u64 unencoded_offset;+ __u32 compression;+ __u32 encryption;+ };++This may be extended in the future, so ``iov[0].iov_len`` must be set to+``sizeof(struct encoded_iov)`` for forward/backward compatibility. The+remaining buffers contain the encoded data.++``compression`` and ``encryption`` are the encoding fields. ``compression`` is+``ENCODED_IOV_COMPRESSION_NONE`` (zero) or a filesystem-specific+``ENCODED_IOV_COMPRESSION_*`` constant; see `Filesystem support`_ below.+``encryption`` is currently always ``ENCODED_IOV_ENCRYPTION_NONE`` (zero).++``unencoded_len`` is the length of the unencoded (i.e., decrypted and+decompressed) data. ``unencoded_offset`` is the offset from the first byte of+the unencoded data to the first byte of logical data in the file (less than or+equal to ``unencoded_len``). ``len`` is the length of the data in the file+(less than or equal to ``unencoded_len - unencoded_offset``). See `Extent+layout`_ below for some examples.++If the unencoded data is actually longer than ``unencoded_len``, then it is+truncated; if it is shorter, then it is extended with zeroes.++``pwritev2()`` uses the metadata specified in ``iov[0]``, writes the encoded+data from the remaining buffers, and returns the number of encoded bytes+written (that is, the sum of ``iov[n].iov_len for 1 <= n < iovcnt``; partial+writes will not occur). At least one encoding field must be non-zero. Note that+the encoded data is not validated when it is written; if it is not valid (e.g.,+it cannot be decompressed), then a subsequent read may return an error. If the+offset argument to ``pwritev2()`` is -1, then the file offset is incremented by+``len``. If ``iov[0].iov_len`` is less than ``sizeof(struct encoded_iov)`` in+the kernel, then any fields unknown to user space are treated as if they were+zero; if it is greater and any fields unknown to the kernel are non-zero, then+``pwritev2()`` returns -1 and sets errno to ``E2BIG``.++``preadv2()`` populates the metadata in ``iov[0]``, the encoded data in the+remaining buffers, and returns the number of encoded bytes read. This will only+return one extent per call. This can also read data which is not encoded; all+encoding fields will be zero in that case. If the offset argument to+``preadv2()`` is -1, then the file offset is incremented by ``len``. If+``iov[0].iov_len`` is less than ``sizeof(struct encoded_iov)`` in the kernel+and any fields unknown to user space are non-zero, then ``preadv2()`` returns+-1 and sets errno to ``E2BIG``; if it is greater, then any fields unknown to+the kernel are returned as zero. If the provided buffers are not large enough+to return an entire encoded extent, then ``preadv2()`` returns -1 and sets+errno to ``ENOBUFS``.++As the filesystem page cache typically contains decoded data, encoded I/O+bypasses the page cache.++Extent layout+-------------++By using ``len``, ``unencoded_len``, and ``unencoded_offset``, it is possible+to refer to a subset of an unencoded extent.++In the simplest case, ``len`` is equal to ``unencoded_len`` and+``unencoded_offset`` is zero. This means that the entire unencoded extent is+used.++However, suppose we read 50 bytes into a file which contains a single+compressed extent. The filesystem must still return the entire compressed+extent for us to be able to decompress it, so ``unencoded_len`` would be the+length of the entire decompressed extent. However, because the read was at+offset 50, the first 50 bytes should be ignored. Therefore,+``unencoded_offset`` would be 50, and ``len`` would accordingly be+``unencoded_len - 50``.++Additionally, suppose we want to create an encrypted file with length 500, but+the file is encrypted with a block cipher using a block size of 4096. The+unencoded data would therefore include the appropriate padding, and+``unencoded_len`` would be 4096. However, to represent the logical size of the+file, ``len`` would be 500 (and ``unencoded_offset`` would be 0).++Similar situations can arise in other cases:++* If the filesystem pads data to the filesystem block size before compressing,+ then compressed files with a size unaligned to the filesystem block size will+ end with an extent with ``len < unencoded_len``.++* Extents cloned from the middle of a larger encoded extent with+``FICLONERANGE`` may have a non-zero ``unencoded_offset`` and/or+``len < unencoded_len``.++* If the middle of an encoded extent is overwritten, the filesystem may create+ extents with a non-zero ``unencoded_offset`` and/or ``len < unencoded_len``+ for the parts that were not overwritten.++Security+--------++Encoded I/O creates the potential for some security issues:++* Encoded writes allow writing arbitrary data which the kernel will decode on a+ subsequent read. Decompression algorithms are complex and may have bugs that+ can be exploited by maliciously crafted data.+* Encoded reads may return data that is not logically present in the file (see+ the discussion of ``len`` vs ``unencoded_len`` above). It may not be intended+ for this data to be readable.++Therefore, encoded I/O requires privilege. Namely, the ``RWF_ENCODED`` flag may+only be used if the file description has the ``O_ALLOW_ENCODED`` file status+flag set, and the ``O_ALLOW_ENCODED`` flag may only be set by a thread with the+``CAP_SYS_ADMIN`` capability. The ``O_ALLOW_ENCODED`` flag can be set by+``open()`` or ``fcntl()``. It can also be cleared by ``fcntl()``; clearing it+does not require ``CAP_SYS_ADMIN``. Note that it is not cleared on ``fork()``+or ``execve()``. One may wish to use ``O_CLOEXEC`` with ``O_ALLOW_ENCODED``.++Filesystem support+------------------++Encoded I/O is supported on the following filesystems:++Btrfs (since Linux 5.14)+~~~~~~~~~~~~~~~~~~~~~~~~++Btrfs supports encoded reads and writes of compressed data. The data is encoded+as follows:++* If ``compression`` is ``ENCODED_IOV_COMPRESSION_BTRFS_ZLIB``, then the encoded+ data is a single zlib stream.+* If ``compression`` is ``ENCODED_IOV_COMPRESSION_BTRFS_ZSTD``, then the+ encoded data is a single zstd frame compressed with the windowLog compression+ parameter set to no more than 17.+* If ``compression`` is one of ``ENCODED_IOV_COMPRESSION_BTRFS_LZO_4K``,+``ENCODED_IOV_COMPRESSION_BTRFS_LZO_8K``,+``ENCODED_IOV_COMPRESSION_BTRFS_LZO_16K``,+``ENCODED_IOV_COMPRESSION_BTRFS_LZO_32K``, or+``ENCODED_IOV_COMPRESSION_BTRFS_LZO_64K``, then the encoded data is+ compressed page by page (using the page size indicated by the name of the+ constant) with LZO1X and wrapped in the format documented in the Linux kernel+ source file ``fs/btrfs/lzo.c``.++Additionally, there are some restrictions on ``pwritev2()``:++*``offset`` (or the current file offset if ``offset`` is -1) must be aligned+ to the sector size of the filesystem.+*``len`` must be aligned to the sector size of the filesystem unless the data+ ends at or beyond the current end of the file.+*``unencoded_len`` and the length of the encoded data must each be no more+ than 128 KiB. This limit may increase in the future.+* The length of the encoded data must be less than or equal to+``unencoded_len.``+* If using LZO, the filesystem's page size must match the compression page+ size.++Implementation+==============++This section describes the requirements for filesystems implementing encoded+I/O.++First of all, a filesystem supporting encoded I/O must indicate this by setting+the ``FMODE_ENCODED_IO`` flag in its ``file_open`` file operation::++ static int foo_file_open(struct inode *inode, struct file *filp)+ {+ ...+ filep->f_mode |= FMODE_ENCODED_IO;+ ...+ }++Encoded I/O goes through ``read_iter`` and ``write_iter``, designated by the+``IOCB_ENCODED`` flag in ``kiocb->ki_flags``.++Reads+-----++Encoded ``read_iter`` should:++1. Call ``generic_encoded_read_checks()`` to validate the file and buffers+ provided by userspace.+2. Initialize the ``encoded_iov`` appropriately.+3. Copy it to the user with ``copy_encoded_iov_to_iter()``.+4. Copy the encoded data to the user.+5. Advance ``kiocb->ki_pos`` by ``encoded_iov->len``.+6. Return the size of the encoded data read, not including the ``encoded_iov``.++There are a few details to be aware of:++* Encoded ``read_iter`` should support reading unencoded data if the extent is+ not encoded.+* If the buffers provided by the user are not large enough to contain an entire+ encoded extent, then ``read_iter`` should return ``-ENOBUFS``. This is to+ avoid confusing userspace with truncated data that cannot be properly+ decoded.+* Reads in the middle of an encoded extent can be returned by setting+``encoded_iov->unencoded_offset`` to non-zero.+* Truncated unencoded data (e.g., because the file does not end on a block+ boundary) may be returned by setting ``encoded_iov->len`` to a value smaller+ value than ``encoded_iov->unencoded_len - encoded_iov->unencoded_offset``.++Writes+------++Encoded ``write_iter`` should (in addition to the usual accounting/checks done+by ``write_iter``):++1. Call ``copy_encoded_iov_from_iter()`` to get and validate the+``encoded_iov``.+2. Call ``generic_encoded_write_checks()`` instead of+``generic_write_checks()``.+3. Check that the provided encoding in ``encoded_iov`` is supported.+4. Advance ``kiocb->ki_pos`` by ``encoded_iov->len``.+5. Return the size of the encoded data written.++Again, there are a few details:++* Encoded ``write_iter`` doesn't need to support writing unencoded data.+*``write_iter`` should either write all of the encoded data or none of it; it+ must not do partial writes.+*``write_iter`` doesn't need to validate the encoded data; a subsequent read+ may return, e.g., ``-EIO`` if the data is not valid.+* The user may lie about the unencoded size of the data; a subsequent read+ should truncate or zero-extend the unencoded data rather than returning an+ error.+* Be careful of page cache coherency.
@@ -1632,24 +1633,15 @@ int generic_write_check_limits(struct file *file, loff_t pos, loff_t *count)return0;}-/*-*Performsnecessarychecksbeforedoingawrite-*-*Canadjustwritingpositionoramountofbytestowrite.-*Returnsappropriateerrorcodethatcallershouldreturnor-*zeroincasethatwriteshouldbeallowed.-*/-ssize_tgeneric_write_checks(structkiocb*iocb,structiov_iter*from)+staticintgeneric_write_checks_common(structkiocb*iocb,loff_t*count){structfile*file=iocb->ki_filp;structinode*inode=file->f_mapping->host;-loff_tcount;-intret;if(IS_SWAPFILE(inode))return-ETXTBSY;-if(!iov_iter_count(from))+if(!*count)return0;/* FIXME: this is for backwards compatibility with 2.4 */
From: Omar Sandoval <redacted>
btrfs_csum_one_bio() loops over each filesystem block in the bio while
keeping a cursor of its current logical position in the file in order to
look up the ordered extent to add the checksums to. However, this
doesn't make much sense for compressed extents, as a sector on disk does
not correspond to a sector of decompressed file data. It happens to work
because 1) the compressed bio always covers one ordered extent and 2)
the size of the bio is always less than the size of the ordered extent.
However, the second point will not always be true for encoded writes.
Let's add a boolean parameter to btrfs_csum_one_bio() to indicate that
it can assume that the bio only covers one ordered extent. Since we're
already changing the signature, let's get rid of the contig parameter
and make it implied by the offset parameter, similar to the change we
recently made to btrfs_lookup_bio_sums(). Additionally, let's rename
nr_sectors to blockcount to make it clear that it's the number of
filesystem blocks, not the number of 512-byte sectors.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
fs/btrfs/compression.c | 5 +++--
fs/btrfs/ctree.h | 2 +-
fs/btrfs/file-item.c | 35 ++++++++++++++++-------------------
fs/btrfs/inode.c | 8 ++++----
4 files changed, 24 insertions(+), 26 deletions(-)
From: Omar Sandoval <redacted>
Currently, we only create ordered extents when ram_bytes == num_bytes
and offset == 0. However, RWF_ENCODED writes may create extents which
only refer to a subset of the full unencoded extent, so we need to plumb
these fields through the ordered extent infrastructure and pass them
down to insert_reserved_file_extent().
Since we're changing the btrfs_add_ordered_extent* signature, let's get
rid of the trivial wrappers and add a kernel-doc.
Reviewed-by: Nikolay Borisov <redacted>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
fs/btrfs/inode.c | 56 +++++++++++---------
fs/btrfs/ordered-data.c | 112 +++++++++++-----------------------------
fs/btrfs/ordered-data.h | 22 ++++----
3 files changed, 76 insertions(+), 114 deletions(-)
@@ -1163,9 +1163,9 @@ static noinline int cow_file_range(struct btrfs_inode *inode,}free_extent_map(em);-ret=btrfs_add_ordered_extent(inode,start,ins.objectid,-ram_size,cur_alloc_size,-BTRFS_ORDERED_REGULAR);+ret=btrfs_add_ordered_extent(inode,start,ram_size,ram_size,+ins.objectid,cur_alloc_size,0,+0,BTRFS_COMPRESS_NONE);if(ret)gotoout_drop_extent_cache;
@@ -1826,10 +1826,11 @@ static noinline int run_delalloc_nocow(struct btrfs_inode *inode,gotoerror;}free_extent_map(em);-ret=btrfs_add_ordered_extent(inode,cur_offset,-disk_bytenr,num_bytes,-num_bytes,-BTRFS_ORDERED_PREALLOC);+ret=btrfs_add_ordered_extent(inode,+cur_offset,num_bytes,num_bytes,+disk_bytenr,num_bytes,0,+1<<BTRFS_ORDERED_PREALLOC,+BTRFS_COMPRESS_NONE);if(ret){btrfs_drop_extent_cache(inode,cur_offset,cur_offset+num_bytes-1,
@@ -1838,9 +1839,11 @@ static noinline int run_delalloc_nocow(struct btrfs_inode *inode,}}else{ret=btrfs_add_ordered_extent(inode,cur_offset,+num_bytes,num_bytes,disk_bytenr,num_bytes,-num_bytes,-BTRFS_ORDERED_NOCOW);+0,+1<<BTRFS_ORDERED_NOCOW,+BTRFS_COMPRESS_NONE);if(ret)gotoerror;}
@@ -2735,6 +2738,7 @@ static int insert_reserved_file_extent(struct btrfs_trans_handle *trans,structbtrfs_keyins;u64disk_num_bytes=btrfs_stack_file_extent_disk_num_bytes(stack_fi);u64disk_bytenr=btrfs_stack_file_extent_disk_bytenr(stack_fi);+u64offset=btrfs_stack_file_extent_offset(stack_fi);u64num_bytes=btrfs_stack_file_extent_num_bytes(stack_fi);u64ram_bytes=btrfs_stack_file_extent_ram_bytes(stack_fi);structbtrfs_drop_extents_argsdrop_args={0};
@@ -2809,7 +2813,8 @@ static int insert_reserved_file_extent(struct btrfs_trans_handle *trans,gotoout;ret=btrfs_alloc_reserved_file_extent(trans,root,btrfs_ino(inode),-file_pos,qgroup_reserved,&ins);+file_pos-offset,+qgroup_reserved,&ins);out:btrfs_free_path(path);
@@ -2835,20 +2840,20 @@ static int insert_ordered_extent_file_extent(struct btrfs_trans_handle *trans,structbtrfs_ordered_extent*oe){structbtrfs_file_extent_itemstack_fi;-u64logical_len;boolupdate_inode_bytes;+u64num_bytes=oe->num_bytes;+u64ram_bytes=oe->ram_bytes;memset(&stack_fi,0,sizeof(stack_fi));btrfs_set_stack_file_extent_type(&stack_fi,BTRFS_FILE_EXTENT_REG);btrfs_set_stack_file_extent_disk_bytenr(&stack_fi,oe->disk_bytenr);btrfs_set_stack_file_extent_disk_num_bytes(&stack_fi,oe->disk_num_bytes);+btrfs_set_stack_file_extent_offset(&stack_fi,oe->offset);if(test_bit(BTRFS_ORDERED_TRUNCATED,&oe->flags))-logical_len=oe->truncated_len;-else-logical_len=oe->num_bytes;-btrfs_set_stack_file_extent_num_bytes(&stack_fi,logical_len);-btrfs_set_stack_file_extent_ram_bytes(&stack_fi,logical_len);+num_bytes=ram_bytes=oe->truncated_len;+btrfs_set_stack_file_extent_num_bytes(&stack_fi,num_bytes);+btrfs_set_stack_file_extent_ram_bytes(&stack_fi,ram_bytes);btrfs_set_stack_file_extent_compression(&stack_fi,oe->compress_type);/* Encryption and other encoding is reserved and all 0 */
@@ -161,7 +172,8 @@ static int __btrfs_add_ordered_extent(struct btrfs_inode *inode, u64 file_offsetstructbtrfs_ordered_extent*entry;intret;-if(type==BTRFS_ORDERED_NOCOW||type==BTRFS_ORDERED_PREALLOC){+if(flags&+((1<<BTRFS_ORDERED_NOCOW)|(1<<BTRFS_ORDERED_PREALLOC))){/* For nocow write, we can release the qgroup rsv right now */ret=btrfs_qgroup_free_data(inode,NULL,file_offset,num_bytes);if(ret<0)
@@ -193,18 +207,12 @@ static int __btrfs_add_ordered_extent(struct btrfs_inode *inode, u64 file_offsetentry->disk=NULL;entry->partno=(u8)-1;-ASSERT(type==BTRFS_ORDERED_REGULAR||-type==BTRFS_ORDERED_NOCOW||-type==BTRFS_ORDERED_PREALLOC||-type==BTRFS_ORDERED_COMPRESSED);-set_bit(type,&entry->flags);+ASSERT((flags&~BTRFS_ORDERED_TYPE_FLAGS)==0);+entry->flags=flags;percpu_counter_add_batch(&fs_info->ordered_bytes,num_bytes,fs_info->delalloc_batch);-if(dio)-set_bit(BTRFS_ORDERED_DIRECT,&entry->flags);-/* one ref for the tree */refcount_set(&entry->refs,1);init_waitqueue_head(&entry->wait);
@@ -76,6 +76,13 @@ enum {BTRFS_ORDERED_PENDING,};+/* BTRFS_ORDERED_* flags that specify the type of the extent. */+#define BTRFS_ORDERED_TYPE_FLAGS ((1UL << BTRFS_ORDERED_REGULAR) | \+(1UL<<BTRFS_ORDERED_NOCOW)|\+(1UL<<BTRFS_ORDERED_PREALLOC)|\+(1UL<<BTRFS_ORDERED_COMPRESSED)|\+(1UL<<BTRFS_ORDERED_DIRECT))+structbtrfs_ordered_extent{/* logical offset in the file */u64file_offset;
@@ -84,9 +91,11 @@ struct btrfs_ordered_extent {*Thesefieldsdirectlycorrespondtothesamefieldsin*btrfs_file_extent_item.*/-u64disk_bytenr;u64num_bytes;+u64ram_bytes;+u64disk_bytenr;u64disk_num_bytes;+u64offset;/* number of bytes that still need writing */u64bytes_left;
From: Omar Sandoval <redacted>
Currently, an inline extent is always created after i_size is extended
from btrfs_dirty_pages(). However, for encoded writes, we only want to
update i_size after we successfully created the inline extent. Add an
update_i_size parameter to cow_file_range_inline() and
insert_inline_extent() and pass in the size of the extent rather than
determining it from i_size. Since the start parameter is always passed
as 0, get rid of it and simplify the logic in these two functions. While
we're here, let's document the requirements for creating an inline
extent.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
fs/btrfs/inode.c | 100 +++++++++++++++++++++++------------------------
1 file changed, 48 insertions(+), 52 deletions(-)
@@ -688,14 +680,15 @@ static noinline int compress_file_range(struct async_chunk *async_chunk)/* we didn't compress the entire range, try*tomakeanuncompressedinlineextent.*/-ret=cow_file_range_inline(BTRFS_I(inode),start,end,+ret=cow_file_range_inline(BTRFS_I(inode),actual_end,0,BTRFS_COMPRESS_NONE,-NULL);+NULL,false);}else{/* try making a compressed inline extent */-ret=cow_file_range_inline(BTRFS_I(inode),start,end,+ret=cow_file_range_inline(BTRFS_I(inode),actual_end,total_compressed,-compress_type,pages);+compress_type,pages,+false);}if(ret<=0){unsignedlongclear_flags=EXTENT_DELALLOC|
@@ -1081,9 +1074,12 @@ static noinline int cow_file_range(struct btrfs_inode *inode,inode_should_defrag(inode,start,end,num_bytes,SZ_64K);if(start==0){+u64actual_end=min_t(u64,i_size_read(&inode->vfs_inode),+end+1);+/* lets try to make an inline extent */-ret=cow_file_range_inline(inode,start,end,0,-BTRFS_COMPRESS_NONE,NULL);+ret=cow_file_range_inline(inode,actual_end,0,+BTRFS_COMPRESS_NONE,NULL,false);if(ret==0){/**WeuseDO_ACCOUNTINGherebecauseweneedthe
From: Omar Sandoval <redacted>
Currently, we always reserve the same extent size in the file and extent
size on disk for delalloc because the former is the worst case for the
latter. For RWF_ENCODED writes, we know the exact size of the extent on
disk, which may be less than or greater than (for bookends) the size in
the file. Add a disk_num_bytes parameter to
btrfs_delalloc_reserve_metadata() so that we can reserve the correct
amount of csum bytes. No functional change.
Reviewed-by: Nikolay Borisov <redacted>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
fs/btrfs/ctree.h | 3 ++-
fs/btrfs/delalloc-space.c | 18 ++++++++++--------
fs/btrfs/file.c | 3 ++-
fs/btrfs/inode.c | 2 +-
fs/btrfs/relocation.c | 4 ++--
5 files changed, 17 insertions(+), 13 deletions(-)
From: Omar Sandoval <redacted>
There are 4 main cases:
1. Inline extents: we copy the data straight out of the extent buffer.
2. Hole/preallocated extents: we fill in zeroes.
3. Regular, uncompressed extents: we read the sectors we need directly
from disk.
4. Regular, compressed extents: we read the entire compressed extent
from disk and indicate what subset of the decompressed extent is in
the file.
This initial implementation simplifies a few things that can be improved
in the future:
- We hold the inode lock during the operation.
- Cases 1, 3, and 4 allocate temporary memory to read into before
copying out to userspace.
- We don't do read repair, because it turns out that read repair is
currently broken for compressed data.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
fs/btrfs/ctree.h | 2 +
fs/btrfs/file.c | 5 +
fs/btrfs/inode.c | 503 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 510 insertions(+)
From: Omar Sandoval <redacted>
The implementation resembles direct I/O: we have to flush any ordered
extents, invalidate the page cache, and do the io tree/delalloc/extent
map/ordered extent dance. From there, we can reuse the compression code
with a minor modification to distinguish the write from writeback. This
also creates inline extents when possible.
Now that read and write are implemented, this also sets the
FMODE_ENCODED_IO flag in btrfs_file_open().
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Omar Sandoval <redacted>
---
fs/btrfs/compression.c | 7 +-
fs/btrfs/compression.h | 6 +-
fs/btrfs/ctree.h | 2 +
fs/btrfs/file.c | 38 +++++-
fs/btrfs/inode.c | 256 +++++++++++++++++++++++++++++++++++++++-
fs/btrfs/ordered-data.c | 12 +-
fs/btrfs/ordered-data.h | 5 +-
7 files changed, 313 insertions(+), 13 deletions(-)
@@ -354,7 +354,8 @@ static void end_compressed_bio_write(struct bio *bio)cb->start,cb->start+cb->len-1,bio->bi_status==BLK_STS_OK);-end_compressed_writeback(inode,cb);+if(cb->writeback)+end_compressed_writeback(inode,cb);/* note, our inode could be gone now *//*
@@ -52,6 +52,9 @@ struct compressed_bio {/* The compression algorithm for this bio */u8compress_type;+/* Whether this is a write for writeback. */+boolwriteback;+/* IO errors */u8errors;intmirror_num;
@@ -2861,6 +2861,7 @@ static int insert_ordered_extent_file_extent(struct btrfs_trans_handle *trans,*exceptiftheorderedextentwastruncated.*/update_inode_bytes=test_bit(BTRFS_ORDERED_DIRECT,&oe->flags)||+test_bit(BTRFS_ORDERED_ENCODED,&oe->flags)||test_bit(BTRFS_ORDERED_TRUNCATED,&oe->flags);returninsert_reserved_file_extent(trans,BTRFS_I(oe->inode),
@@ -2895,7 +2896,8 @@ static int btrfs_finish_ordered_io(struct btrfs_ordered_extent *ordered_extent)if(!test_bit(BTRFS_ORDERED_NOCOW,&ordered_extent->flags)&&!test_bit(BTRFS_ORDERED_PREALLOC,&ordered_extent->flags)&&-!test_bit(BTRFS_ORDERED_DIRECT,&ordered_extent->flags))+!test_bit(BTRFS_ORDERED_DIRECT,&ordered_extent->flags)&&+!test_bit(BTRFS_ORDERED_ENCODED,&ordered_extent->flags))clear_bits|=EXTENT_DELALLOC_NEW;freespace_inode=btrfs_is_free_space_inode(inode);
@@ -10773,6 +10775,256 @@ ssize_t btrfs_encoded_read(struct kiocb *iocb, struct iov_iter *iter)returnret;}+ssize_tbtrfs_do_encoded_write(structkiocb*iocb,structiov_iter*from,+structencoded_iov*encoded)+{+structinode*inode=file_inode(iocb->ki_filp);+structbtrfs_fs_info*fs_info=btrfs_sb(inode->i_sb);+structbtrfs_root*root=BTRFS_I(inode)->root;+structextent_io_tree*io_tree=&BTRFS_I(inode)->io_tree;+structextent_changeset*data_reserved=NULL;+structextent_state*cached_state=NULL;+intcompression;+size_torig_count;+u64start,end;+u64num_bytes,ram_bytes,disk_num_bytes;+unsignedlongnr_pages,i;+structpage**pages;+structbtrfs_keyins;+boolextent_reserved=false;+structextent_map*em;+ssize_tret;++switch(encoded->compression){+caseENCODED_IOV_COMPRESSION_BTRFS_ZLIB:+compression=BTRFS_COMPRESS_ZLIB;+break;+caseENCODED_IOV_COMPRESSION_BTRFS_ZSTD:+compression=BTRFS_COMPRESS_ZSTD;+break;+caseENCODED_IOV_COMPRESSION_BTRFS_LZO_4K:+caseENCODED_IOV_COMPRESSION_BTRFS_LZO_8K:+caseENCODED_IOV_COMPRESSION_BTRFS_LZO_16K:+caseENCODED_IOV_COMPRESSION_BTRFS_LZO_32K:+caseENCODED_IOV_COMPRESSION_BTRFS_LZO_64K:+/* The page size must match for LZO. */+if(encoded->compression-+ENCODED_IOV_COMPRESSION_BTRFS_LZO_4K+12!=PAGE_SHIFT)+return-EINVAL;+compression=BTRFS_COMPRESS_LZO;+break;+default:+return-EINVAL;+}+if(encoded->encryption!=ENCODED_IOV_ENCRYPTION_NONE)+return-EINVAL;++orig_count=iov_iter_count(from);++/* The extent size must be sane. */+if(encoded->unencoded_len>BTRFS_MAX_UNCOMPRESSED||+orig_count>BTRFS_MAX_COMPRESSED||orig_count==0)+return-EINVAL;++/*+*Thecompresseddatamustbesmallerthanthedecompresseddata.+*+*It'sofcoursepossiblefordatatocompresstolargerorthesame+*size,butthebufferedI/Opathfallsbacktonocompressionforsuch+*data,andwedon'twanttobreakanyassumptionsbycreatingthese+*extents.+*+*Notethatthisislessstrictthanthecurrentcheckwehavethatthe+*compresseddatamustbeatleastonesectorsmallerthanthe+*decompresseddata.Weonlywanttoenforcetheweakerrequirement+*fromoldkernelsthatitisatleastonebytesmaller.+*/+if(orig_count>=encoded->unencoded_len)+return-EINVAL;++/* The extent must start on a sector boundary. */+start=iocb->ki_pos;+if(!IS_ALIGNED(start,fs_info->sectorsize))+return-EINVAL;++/*+*Theextentmustendonasectorboundary.However,weallowawrite+*whichendsatorextendsi_sizetohaveanunalignedlength;weround+*uptheextentsizeandseti_sizetotheunalignedend.+*/+if(start+encoded->len<inode->i_size&&+!IS_ALIGNED(start+encoded->len,fs_info->sectorsize))+return-EINVAL;++/* Finally, the offset in the unencoded data must be sector-aligned. */+if(!IS_ALIGNED(encoded->unencoded_offset,fs_info->sectorsize))+return-EINVAL;++num_bytes=ALIGN(encoded->len,fs_info->sectorsize);+ram_bytes=ALIGN(encoded->unencoded_len,fs_info->sectorsize);+end=start+num_bytes-1;++/*+*Iftheextentcannotbeinline,thecompresseddataondiskmustbe+*sector-aligned.Forconvenience,weextenditwithzeroesifit+*isn't.+*/+disk_num_bytes=ALIGN(orig_count,fs_info->sectorsize);+nr_pages=DIV_ROUND_UP(disk_num_bytes,PAGE_SIZE);+pages=kvcalloc(nr_pages,sizeof(structpage*),GFP_KERNEL_ACCOUNT);+if(!pages)+return-ENOMEM;+for(i=0;i<nr_pages;i++){+size_tbytes=min_t(size_t,PAGE_SIZE,iov_iter_count(from));+char*kaddr;++pages[i]=alloc_page(GFP_KERNEL_ACCOUNT|__GFP_HIGHMEM);+if(!pages[i]){+ret=-ENOMEM;+gotoout_pages;+}+kaddr=kmap(pages[i]);+if(copy_from_iter(kaddr,bytes,from)!=bytes){+kunmap(pages[i]);+ret=-EFAULT;+gotoout_pages;+}+if(bytes<PAGE_SIZE)+memset(kaddr+bytes,0,PAGE_SIZE-bytes);+kunmap(pages[i]);+}++for(;;){+structbtrfs_ordered_extent*ordered;++ret=btrfs_wait_ordered_range(inode,start,num_bytes);+if(ret)+gotoout_pages;+ret=invalidate_inode_pages2_range(inode->i_mapping,+start>>PAGE_SHIFT,+end>>PAGE_SHIFT);+if(ret)+gotoout_pages;+lock_extent_bits(io_tree,start,end,&cached_state);+ordered=btrfs_lookup_ordered_range(BTRFS_I(inode),start,+num_bytes);+if(!ordered&&+!filemap_range_has_page(inode->i_mapping,start,end))+break;+if(ordered)+btrfs_put_ordered_extent(ordered);+unlock_extent_cached(io_tree,start,end,&cached_state);+cond_resched();+}++/*+*Wedon'tusethehigher-leveldelallocspacefunctionsbecauseour+*num_bytesanddisk_num_bytesaredifferent.+*/+ret=btrfs_alloc_data_chunk_ondemand(BTRFS_I(inode),disk_num_bytes);+if(ret)+gotoout_unlock;+ret=btrfs_qgroup_reserve_data(BTRFS_I(inode),&data_reserved,start,+num_bytes);+if(ret)+gotoout_free_data_space;+ret=btrfs_delalloc_reserve_metadata(BTRFS_I(inode),num_bytes,+disk_num_bytes);+if(ret)+gotoout_qgroup_free_data;++/* Try an inline extent first. */+if(start==0&&encoded->unencoded_len==encoded->len&&+encoded->unencoded_offset==0){+ret=cow_file_range_inline(BTRFS_I(inode),encoded->len,+orig_count,compression,pages,+true);+if(ret<=0){+if(ret==0)+ret=orig_count;+gotoout_delalloc_release;+}+}++ret=btrfs_reserve_extent(root,disk_num_bytes,disk_num_bytes,+disk_num_bytes,0,0,&ins,1,1);+if(ret)+gotoout_delalloc_release;+extent_reserved=true;++em=create_io_em(BTRFS_I(inode),start,num_bytes,+start-encoded->unencoded_offset,ins.objectid,+ins.offset,ins.offset,ram_bytes,compression,+BTRFS_ORDERED_COMPRESSED);+if(IS_ERR(em)){+ret=PTR_ERR(em);+gotoout_free_reserved;+}+free_extent_map(em);++ret=btrfs_add_ordered_extent(BTRFS_I(inode),start,num_bytes,+ram_bytes,ins.objectid,ins.offset,+encoded->unencoded_offset,+(1<<BTRFS_ORDERED_ENCODED)|+(1<<BTRFS_ORDERED_COMPRESSED),+compression);+if(ret){+btrfs_drop_extent_cache(BTRFS_I(inode),start,end,0);+gotoout_free_reserved;+}+btrfs_dec_block_group_reservations(fs_info,ins.objectid);++if(start+encoded->len>inode->i_size)+i_size_write(inode,start+encoded->len);++unlock_extent_cached(io_tree,start,end,&cached_state);++btrfs_delalloc_release_extents(BTRFS_I(inode),num_bytes);++if(btrfs_submit_compressed_write(BTRFS_I(inode),start,num_bytes,+ins.objectid,ins.offset,pages,+nr_pages,0,NULL,false)){+btrfs_writepage_endio_finish_ordered(BTRFS_I(inode),pages[0],+start,end,0);+ret=-EIO;+gotoout_pages;+}+ret=orig_count;+gotoout;++out_free_reserved:+btrfs_dec_block_group_reservations(fs_info,ins.objectid);+btrfs_free_reserved_extent(fs_info,ins.objectid,ins.offset,1);+out_delalloc_release:+btrfs_delalloc_release_extents(BTRFS_I(inode),num_bytes);+btrfs_delalloc_release_metadata(BTRFS_I(inode),disk_num_bytes,+ret<0);+out_qgroup_free_data:+if(ret<0){+btrfs_qgroup_free_data(BTRFS_I(inode),data_reserved,start,+num_bytes);+}+out_free_data_space:+/*+*Ifbtrfs_reserve_extent()succeeded,thenwealreadydecremented+*bytes_may_use.+*/+if(!extent_reserved)+btrfs_free_reserved_data_space_noquota(fs_info,disk_num_bytes);+out_unlock:+unlock_extent_cached(io_tree,start,end,&cached_state);+out_pages:+for(i=0;i<nr_pages;i++){+if(pages[i])+__free_page(pages[i]);+}+kvfree(pages);+out:+if(ret>=0)+iocb->ki_pos+=encoded->len;+returnret;+}+#ifdef CONFIG_SWAP/**Addanentryindicatingablockgroupordevicewhichispinnedbya
@@ -74,6 +74,8 @@ enum {BTRFS_ORDERED_LOGGED_CSUM,/* We wait for this extent to complete in the current transaction */BTRFS_ORDERED_PENDING,+/* RWF_ENCODED I/O */+BTRFS_ORDERED_ENCODED,};/* BTRFS_ORDERED_* flags that specify the type of the extent. */
@@ -81,7 +83,8 @@ enum {(1UL<<BTRFS_ORDERED_NOCOW)|\(1UL<<BTRFS_ORDERED_PREALLOC)|\(1UL<<BTRFS_ORDERED_COMPRESSED)|\-(1UL<<BTRFS_ORDERED_DIRECT))+(1UL<<BTRFS_ORDERED_DIRECT)|\+(1UL<<BTRFS_ORDERED_ENCODED))structbtrfs_ordered_extent{/* logical offset in the file */
On Thu, Jun 17, 2021 at 4:51 PM Omar Sandoval [off-list ref] wrote:
This is essentially copy_struct_from_user() but for an iov_iter.
So I continue to think that this series looks fine - if we want this
interface at all.
I do note a few issues with this iov patch, though - partly probably
because I have been reading Al's cleanup patches that had some
optimizations in place.
And in particular, I now react to this:
+ iov_iter_advance(i, usize);
at the end of copy_struct_from_iter().
It's very wasteful to use the generic iov_iter_advance() function,
when you just had special functions for each of the iterator cases.
Because that generic function will now just end up re-testing that
whole "what kind was it" and then do each kind separately.
So it would actually be a lot simpler and m,ore efficient to just do
that "advance" part as you go through the cases, iow just do
iov_iter_iovec_advance(i, usize);
at the end of the iter_is_iovec/iter_is_kvec cases, and
iov_iter_bvec_advance(i, usize)
for the bvec case.
I think that you may need it to be based on Al's series for that to
work, which might be inconvenient, though.
One other non-code issue: particularly since you only handle a subset
of the iov_iter cases, it would be nice to have an explanation for
_why_ those particular cases.
IOW, have some trivial explanation for each of the cases. "iovec" is
for regular read/write, what triggers the kvec and bvec cases?
But also, the other way around. Why doesn't the pipe case trigger? No
splice support?
Linus
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-18 19:42:46
On Fri, Jun 18, 2021 at 11:50:25AM -0700, Linus Torvalds wrote:
I think that you may need it to be based on Al's series for that to
work, which might be inconvenient, though.
One other non-code issue: particularly since you only handle a subset
of the iov_iter cases, it would be nice to have an explanation for
_why_ those particular cases.
IOW, have some trivial explanation for each of the cases. "iovec" is
for regular read/write, what triggers the kvec and bvec cases?
But also, the other way around. Why doesn't the pipe case trigger? No
splice support?
Pipe ones are strictly destinations - they can't be sources. So if you
see it called for one of those, you've a bug.
Xarray ones are *not* - they can be sources, and that's missing here.
Much more unpleasant, though, is that this thing has hard dependency on
nr_seg == 1 *AND* openly suggests the use of iov_iter_single_seg_count(),
which is completely wrong. That sucker has some weird users left (as
of #work.iov_iter), but all of them are actually due to API deficiencies
and I very much hope to kill that thing off.
Why not simply add iov_iter_check_zeroes(), that would be called after
copy_from_iter() and verified that all that's left in the iterator
consists of zeroes? Then this copy_struct_from_...() would be
trivial to express through those two. And check_zeroes would also
be trivial, especially on top of #work.iov_iter. With no calls of
iov_iter_advance() at all, while we are at it...
IDGI... Omar, what semantics do you really want from that primitive?
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-18 19:50:06
On Fri, Jun 18, 2021 at 07:42:41PM +0000, Al Viro wrote:
Pipe ones are strictly destinations - they can't be sources. So if you
see it called for one of those, you've a bug.
Xarray ones are *not* - they can be sources, and that's missing here.
Much more unpleasant, though, is that this thing has hard dependency on
nr_seg == 1 *AND* openly suggests the use of iov_iter_single_seg_count(),
which is completely wrong. That sucker has some weird users left (as
of #work.iov_iter), but all of them are actually due to API deficiencies
and I very much hope to kill that thing off.
Why not simply add iov_iter_check_zeroes(), that would be called after
copy_from_iter() and verified that all that's left in the iterator
consists of zeroes? Then this copy_struct_from_...() would be
trivial to express through those two. And check_zeroes would also
be trivial, especially on top of #work.iov_iter. With no calls of
iov_iter_advance() at all, while we are at it...
IDGI... Omar, what semantics do you really want from that primitive?
And for pity sake, let's not do that EXPORT_SYMBOL_GPL() posturing there.
If it's a sane general-purpose API, it doesn't matter who uses it;
if it's not, it shouldn't be exported in the first place.
It can be implemented via the already exported primitives, so it's
not as if we prevented anyone from doing an equivalent...
On Fri, Jun 18, 2021 at 07:42:41PM +0000, Al Viro wrote:
On Fri, Jun 18, 2021 at 11:50:25AM -0700, Linus Torvalds wrote:
quoted
I think that you may need it to be based on Al's series for that to
work, which might be inconvenient, though.
One other non-code issue: particularly since you only handle a subset
of the iov_iter cases, it would be nice to have an explanation for
_why_ those particular cases.
IOW, have some trivial explanation for each of the cases. "iovec" is
for regular read/write, what triggers the kvec and bvec cases?
But also, the other way around. Why doesn't the pipe case trigger? No
splice support?
Pipe ones are strictly destinations - they can't be sources. So if you
see it called for one of those, you've a bug.
Xarray ones are *not* - they can be sources, and that's missing here.
Ah, ITER_XARRAY was added recently so I missed it.
Much more unpleasant, though, is that this thing has hard dependency on
nr_seg == 1 *AND* openly suggests the use of iov_iter_single_seg_count(),
which is completely wrong. That sucker has some weird users left (as
of #work.iov_iter), but all of them are actually due to API deficiencies
and I very much hope to kill that thing off.
Why not simply add iov_iter_check_zeroes(), that would be called after
copy_from_iter() and verified that all that's left in the iterator
consists of zeroes? Then this copy_struct_from_...() would be
trivial to express through those two. And check_zeroes would also
be trivial, especially on top of #work.iov_iter. With no calls of
iov_iter_advance() at all, while we are at it...
IDGI... Omar, what semantics do you really want from that primitive?
RWF_ENCODED is intended to be used like this:
struct encoded_iov encoded_iov = {
/* compression metadata */ ...
};
char compressed_data[] = ...;
struct iovec iov[] = {
{ &encoded_iov, sizeof(encoded_iov) },
{ compressed_data, sizeof(compressed_data) },
};
pwritev2(fd, iov, 2, -1, RWF_ENCODED);
Basically, we squirrel away the compression metadata in the first
element of the iovec array, and we use iov[0].iov_len so that we can
support future extensions of struct encoded_iov in the style of
copy_struct_from_user().
So this doesn't require nr_seg == 1. On the contrary, it's expected that
the rest of the iovec has the compressed payload. And to support the
copy_struct_from_user()-style versioning, we need to know the size of
the struct encoded_iov that userspace gave us, which is the reason for
the iov_iter_single_seg_count().
I know this interface isn't the prettiest. It started as a
Btrfs-specific ioctl, but this approach was suggested as a way to avoid
having a whole new I/O path:
https://lore.kernel.org/linux-fsdevel/20190905021012.GL7777@dread.disaster.area/
The copy_struct_from_iter() thing was proposed as a way to allow future
extensions here:
https://lore.kernel.org/linux-btrfs/20191022020215.csdwgi3ky27rfidf@yavin.dot.cyphar.com/
Please let me know if you have any suggestions for how to improve this.
Thanks,
Omar
On Fri, Jun 18, 2021 at 07:49:53PM +0000, Al Viro wrote:
On Fri, Jun 18, 2021 at 07:42:41PM +0000, Al Viro wrote:
quoted
Pipe ones are strictly destinations - they can't be sources. So if you
see it called for one of those, you've a bug.
Xarray ones are *not* - they can be sources, and that's missing here.
Much more unpleasant, though, is that this thing has hard dependency on
nr_seg == 1 *AND* openly suggests the use of iov_iter_single_seg_count(),
which is completely wrong. That sucker has some weird users left (as
of #work.iov_iter), but all of them are actually due to API deficiencies
and I very much hope to kill that thing off.
Why not simply add iov_iter_check_zeroes(), that would be called after
copy_from_iter() and verified that all that's left in the iterator
consists of zeroes? Then this copy_struct_from_...() would be
trivial to express through those two. And check_zeroes would also
be trivial, especially on top of #work.iov_iter. With no calls of
iov_iter_advance() at all, while we are at it...
IDGI... Omar, what semantics do you really want from that primitive?
And for pity sake, let's not do that EXPORT_SYMBOL_GPL() posturing there.
If it's a sane general-purpose API, it doesn't matter who uses it;
if it's not, it shouldn't be exported in the first place.
It can be implemented via the already exported primitives, so it's
not as if we prevented anyone from doing an equivalent...
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-18 20:58:10
On Fri, Jun 18, 2021 at 01:32:26PM -0700, Omar Sandoval wrote:
RWF_ENCODED is intended to be used like this:
struct encoded_iov encoded_iov = {
/* compression metadata */ ...
};
char compressed_data[] = ...;
struct iovec iov[] = {
{ &encoded_iov, sizeof(encoded_iov) },
{ compressed_data, sizeof(compressed_data) },
};
pwritev2(fd, iov, 2, -1, RWF_ENCODED);
Basically, we squirrel away the compression metadata in the first
element of the iovec array, and we use iov[0].iov_len so that we can
support future extensions of struct encoded_iov in the style of
copy_struct_from_user().
Yecchhh...
So this doesn't require nr_seg == 1. On the contrary, it's expected that
the rest of the iovec has the compressed payload. And to support the
copy_struct_from_user()-style versioning, we need to know the size of
the struct encoded_iov that userspace gave us, which is the reason for
the iov_iter_single_seg_count().
I know this interface isn't the prettiest. It started as a
Btrfs-specific ioctl, but this approach was suggested as a way to avoid
having a whole new I/O path:
https://lore.kernel.org/linux-fsdevel/20190905021012.GL7777@dread.disaster.area/
The copy_struct_from_iter() thing was proposed as a way to allow future
extensions here:
https://lore.kernel.org/linux-btrfs/20191022020215.csdwgi3ky27rfidf@yavin.dot.cyphar.com/
Please let me know if you have any suggestions for how to improve this.
Just put the size of the encoded part first and be done with that.
Magical effect of the iovec sizes is a bloody bad idea.
And on top of #work.iov_iter something like
bool iov_iter_check_zeroes(struct iov_iter *i, size_t bytes)
{
bool failed = false;
iterate_and_advance(i, bytes, base, len, off,
failed = (check_zeroed_user(base, len) != 1),
failed = (memchr_inv(base, 0, len) != NULL),
)
if (unlikely(failed))
iov_iter_revert(i, bytes);
return !failed;
}
would do "is that chunk all-zeroes?" just fine. It's that simple...
On Fri, Jun 18, 2021 at 1:58 PM Al Viro [off-list ref] wrote:
On Fri, Jun 18, 2021 at 01:32:26PM -0700, Omar Sandoval wrote:
quoted
RWF_ENCODED is intended to be used like this:
struct encoded_iov encoded_iov = {
/* compression metadata */ ...
};
char compressed_data[] = ...;
struct iovec iov[] = {
{ &encoded_iov, sizeof(encoded_iov) },
{ compressed_data, sizeof(compressed_data) },
};
pwritev2(fd, iov, 2, -1, RWF_ENCODED);
Basically, we squirrel away the compression metadata in the first
element of the iovec array, and we use iov[0].iov_len so that we can
support future extensions of struct encoded_iov in the style of
copy_struct_from_user().
Yecchhh...
Al, this has been true since the beginning, and was the whole point of the set.
Just put the size of the encoded part first and be done with that.
Magical effect of the iovec sizes is a bloody bad idea.
That makes everything uglier and more complicated, honestly. Then
you'd have to do it in _two_ operations ("get the size, then get the
rest"), *AND* you'd have to worry about all the corner-cases (ie
people putting the structure in pieces across multiple iov entries.
So it would be slower, more complex, and much more likely to have bugs.
So no. Not acceptable. The "in the first iov" is simple, efficient,
and avoids all the problems.
The size *is* encoded already - in the iov itself. Encoding it
anywhere else is much worse.
The only issue I have is that the issue itself is kind of ugly -
regardless of any iov issues. And the "encryption" side of it doesn't
actually seem to be relevant or solvable using this model anyway, so
that side is questionable.
The alternative would be to have an ioctl rather than make this be
about the IO operations (and then that encoded data would be
explicitly separate).
Which I suggested originally, but apparently people who want to use
this had some real reasons not to.
But encoding the structure without having the rule of "first iov only"
is entirely unacceptable to me. See above. It's objectively much much
worse.
Linus
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-18 21:32:33
On Fri, Jun 18, 2021 at 02:10:36PM -0700, Linus Torvalds wrote:
quoted
Just put the size of the encoded part first and be done with that.
Magical effect of the iovec sizes is a bloody bad idea.
That makes everything uglier and more complicated, honestly. Then
you'd have to do it in _two_ operations ("get the size, then get the
rest"), *AND* you'd have to worry about all the corner-cases (ie
people putting the structure in pieces across multiple iov entries.
Huh? All corner cases are already taken care of by copy_from_iter{,_full}().
What I'm proposing is to have the size as a field in 'encoded' and
do this
if (!copy_from_iter_full(&encoded, sizeof(encoded), &i))
return -EFAULT;
if (encoded.size > sizeof(encoded)) {
// newer than what we expect
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// older than what we expect
iov_iter_revert(&i, sizeof(encoded) - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizoef(encoded) - encoded.size);
}
I don't think it would be more complex, but that's a matter of taste;
I *really* doubt it would be any slower or have higher odds of bugs,
regardless of the corner cases.
And it certainly would be much smaller on the lib/iov_iter.c side -
implementation of iov_iter_check_zeroes() would be simply this:
bool iov_iter_check_zeroes(struct iov_iter *i, size_t size)
{
bool failed = false;
iterate_and_advance(i, bytes, base, len, off,
failed = (check_zeroed_user(base, len) != 1),
failed = (memchr_inv(base, 0, len) != NULL))
if (unlikely(failed))
iov_iter_revert(i, bytes);
return !failed;
}
And that's it, no need to do anything special for xarray, etc.
This + EXPORT_SYMBOL + extern in uio.h + snippet above in the
user...
I could buy an argument that for userland the need to add
encoded.size = sizeof(encoded);
or equivalent when initializing that thing would make life too complex,
but on the kernel side I'd say that Omar's variant is considerably more
complex than the above...
On Fri, Jun 18, 2021 at 2:32 PM Al Viro [off-list ref] wrote:
Huh? All corner cases are already taken care of by copy_from_iter{,_full}().
What I'm proposing is to have the size as a field in 'encoded' and
do this
Hmm. Making it part of the structure does make it easier (also for the
sending userspace side, that doesn't now have to create yet another
iov or copy the structure or whatever).
Except your code doesn't actually handle the "smaller than expected"
case correctly, since by the time it even checks for that, it will
possibly already have failed. So you actually had a bug there - you
can't use the "xyz_full()" version and get it right.
That's fixable.
So I guess I'd be ok with that version.
Linus
On Fri, Jun 18, 2021 at 02:40:51PM -0700, Linus Torvalds wrote:
On Fri, Jun 18, 2021 at 2:32 PM Al Viro [off-list ref] wrote:
quoted
Huh? All corner cases are already taken care of by copy_from_iter{,_full}().
What I'm proposing is to have the size as a field in 'encoded' and
do this
Hmm. Making it part of the structure does make it easier (also for the
sending userspace side, that doesn't now have to create yet another
iov or copy the structure or whatever).
Except your code doesn't actually handle the "smaller than expected"
case correctly, since by the time it even checks for that, it will
possibly already have failed. So you actually had a bug there - you
can't use the "xyz_full()" version and get it right.
That's fixable.
Right, we either need to read the size first and then the rest:
size_t copy_size;
if (!copy_from_iter_full(&encoded.size, sizeof(encoded.size),
&i))
return -EFAULT;
if (encoded.size > PAGE_SIZE)
return -E2BIG;
if (encoded.size < ENCODED_IOV_SIZE_VER0)
return -EINVAL;
if (!copy_from_iter_full(&encoded.size + 1,
min(sizeof(encoded), encoded.size) - sizeof(encoded.size),
&i))
return -EFAULT;
if (encoded.size > sizeof(encoded)) {
// newer than what we expect
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// older than what we expect
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
Or do the same reverting thing that Al did, but with copy_from_iter()
instead of copy_from_iter_full() and being careful with the copied count
(which I'm not 100% sure I got correct here):
size_t copied = copy_from_iter(&encoded, sizeof(encoded), &i);
if (copied < offsetofend(struct encoded_iov, size))
return -EFAULT;
if (encoded.size > PAGE_SIZE)
return -E2BIG;
if (encoded.size < ENCODED_IOV_SIZE_VER0)
return -EINVAL;
if (encoded.size > sizeof(encoded)) {
if (copied < sizeof(encoded)
return -EFAULT;
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// older than what we expect
if (copied < encoded.size)
return -EFAULT;
iov_iter_revert(&i, copied - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-18 22:14:43
On Fri, Jun 18, 2021 at 02:40:51PM -0700, Linus Torvalds wrote:
On Fri, Jun 18, 2021 at 2:32 PM Al Viro [off-list ref] wrote:
quoted
Huh? All corner cases are already taken care of by copy_from_iter{,_full}().
What I'm proposing is to have the size as a field in 'encoded' and
do this
Hmm. Making it part of the structure does make it easier (also for the
sending userspace side, that doesn't now have to create yet another
iov or copy the structure or whatever).
Except your code doesn't actually handle the "smaller than expected"
case correctly, since by the time it even checks for that, it will
possibly already have failed. So you actually had a bug there - you
can't use the "xyz_full()" version and get it right.
Right you are - should be something along the lines of
#define MIN_ENCODED_SIZE minimal size, e.g. offsetof of the next field after .size
size = copy_from_iter(&encoded, sizeof(encoded), &i);
if (unlikely(size < sizeof(encoded))) {
// the total length is less than expected
// must be at least encoded.size, though, and it would better
// cover the .size field itself.
if (size < MIN_ENCODED_SIZE || size < encoded.size)
sod off
}
if (sizeof(encoded) < encoded.size) {
// newer than expected
same as in previous variant
} else if (size > encoded.size) {
// older than expected
iov_iter_revert(size - encoded.size);
memset(....) as in previous variant
}
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-18 22:32:59
On Fri, Jun 18, 2021 at 03:10:03PM -0700, Omar Sandoval wrote:
Or do the same reverting thing that Al did, but with copy_from_iter()
instead of copy_from_iter_full() and being careful with the copied count
(which I'm not 100% sure I got correct here):
size_t copied = copy_from_iter(&encoded, sizeof(encoded), &i);
if (copied < offsetofend(struct encoded_iov, size))
return -EFAULT;
if (encoded.size > PAGE_SIZE)
return -E2BIG;
if (encoded.size < ENCODED_IOV_SIZE_VER0)
return -EINVAL;
if (encoded.size > sizeof(encoded)) {
if (copied < sizeof(encoded)
return -EFAULT;
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// older than what we expect
if (copied < encoded.size)
return -EFAULT;
iov_iter_revert(&i, copied - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
simpler than that, actually -
copied = copy_from_iter(&encoded, sizeof(encoded), &i);
if (unlikely(copied < sizeof(encoded))) {
if (copied < offsetofend(struct encoded_iov, size) ||
copied < encoded.size)
return iov_iter_count(i) ? -EFAULT : -EINVAL;
}
if (encoded.size > sizeof(encoded)) {
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// copied can't be less than encoded.size here - otherwise
// we'd have copied < sizeof(encoded) and the check above
// would've buggered off
iov_iter_revert(&i, copied - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
should do it.
On Fri, Jun 18, 2021 at 10:32:54PM +0000, Al Viro wrote:
On Fri, Jun 18, 2021 at 03:10:03PM -0700, Omar Sandoval wrote:
quoted
Or do the same reverting thing that Al did, but with copy_from_iter()
instead of copy_from_iter_full() and being careful with the copied count
(which I'm not 100% sure I got correct here):
size_t copied = copy_from_iter(&encoded, sizeof(encoded), &i);
if (copied < offsetofend(struct encoded_iov, size))
return -EFAULT;
if (encoded.size > PAGE_SIZE)
return -E2BIG;
if (encoded.size < ENCODED_IOV_SIZE_VER0)
return -EINVAL;
if (encoded.size > sizeof(encoded)) {
if (copied < sizeof(encoded)
return -EFAULT;
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// older than what we expect
if (copied < encoded.size)
return -EFAULT;
iov_iter_revert(&i, copied - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
simpler than that, actually -
copied = copy_from_iter(&encoded, sizeof(encoded), &i);
if (unlikely(copied < sizeof(encoded))) {
if (copied < offsetofend(struct encoded_iov, size) ||
copied < encoded.size)
return iov_iter_count(i) ? -EFAULT : -EINVAL;
}
if (encoded.size > sizeof(encoded)) {
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// copied can't be less than encoded.size here - otherwise
// we'd have copied < sizeof(encoded) and the check above
// would've buggered off
iov_iter_revert(&i, copied - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
should do it.
Thanks, Al, I'll send an updated version with this approach next week.
On Fri, Jun 18, 2021 at 05:43:21PM -0700, Omar Sandoval wrote:
On Fri, Jun 18, 2021 at 10:32:54PM +0000, Al Viro wrote:
quoted
On Fri, Jun 18, 2021 at 03:10:03PM -0700, Omar Sandoval wrote:
quoted
Or do the same reverting thing that Al did, but with copy_from_iter()
instead of copy_from_iter_full() and being careful with the copied count
(which I'm not 100% sure I got correct here):
size_t copied = copy_from_iter(&encoded, sizeof(encoded), &i);
if (copied < offsetofend(struct encoded_iov, size))
return -EFAULT;
if (encoded.size > PAGE_SIZE)
return -E2BIG;
if (encoded.size < ENCODED_IOV_SIZE_VER0)
return -EINVAL;
if (encoded.size > sizeof(encoded)) {
if (copied < sizeof(encoded)
return -EFAULT;
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// older than what we expect
if (copied < encoded.size)
return -EFAULT;
iov_iter_revert(&i, copied - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
simpler than that, actually -
copied = copy_from_iter(&encoded, sizeof(encoded), &i);
if (unlikely(copied < sizeof(encoded))) {
if (copied < offsetofend(struct encoded_iov, size) ||
copied < encoded.size)
return iov_iter_count(i) ? -EFAULT : -EINVAL;
}
if (encoded.size > sizeof(encoded)) {
if (!iov_iter_check_zeroes(&i, encoded.size - sizeof(encoded))
return -EINVAL;
} else if (encoded.size < sizeof(encoded)) {
// copied can't be less than encoded.size here - otherwise
// we'd have copied < sizeof(encoded) and the check above
// would've buggered off
iov_iter_revert(&i, copied - encoded.size);
memset((void *)&encoded + encoded.size, 0, sizeof(encoded) - encoded.size);
}
should do it.
Thanks, Al, I'll send an updated version with this approach next week.
Okay, so this works for the write side of RWF_ENCODED, but it causes
problems for the read side. That currently works like so:
struct encoded_iov encoded_iov;
char compressed_data[...];
struct iovec iov[] = {
{ &encoded_iov, sizeof(encoded_iov) },
{ compressed_data, sizeof(compressed_data) },
};
preadv2(fd, iov, 2, -1, RWF_ENCODED);
The kernel fills in the encoded_iov with the compression metadata and
the remaining buffers with the compressed data. The kernel needs to know
how much of the iovec is for the encoded_iov. The backwards
compatibility is similar to the write side: if the kernel size is less
than the userspace size, then we can fill in extra zeroes. If the kernel
size is greater than the userspace size and all of the extra metadata is
zero, then we can omit it. If the extra metadata is non-zero, then we
return an error.
How do we get the userspace size with the encoded_iov.size approach?
We'd have to read the size from the iov_iter before writing to the rest
of the iov_iter. Is it okay to mix the iov_iter as a source and
destination like this? From what I can tell, it's not intended to be
used like this.
On Mon, Jun 21, 2021 at 11:46 AM Omar Sandoval [off-list ref] wrote:
How do we get the userspace size with the encoded_iov.size approach?
We'd have to read the size from the iov_iter before writing to the rest
of the iov_iter. Is it okay to mix the iov_iter as a source and
destination like this? From what I can tell, it's not intended to be
used like this.
I guess it could work that way, but yes, it's ugly as hell. And I
really don't want a readv() system call - that should write to the
result buffer - to first have to read from it.
So I think the original "just make it be the first iov entry" is the
better approach, even if Al hates it.
Although I still get the feeling that using an ioctl is the *really*
correct way to go. That was my first reaction to the series
originally, and I still don't see why we'd have encoded data in a
regular read/write path.
What was the argument against ioctl's, again?
To me, this isn't all that different from the fsverity things we
added, where filesystem people were happy to try to work out some
common model and add FS_IOC_*_VERITY* ioctls.
Linus
On Mon, Jun 21, 2021 at 12:33:17PM -0700, Linus Torvalds wrote:
On Mon, Jun 21, 2021 at 11:46 AM Omar Sandoval [off-list ref] wrote:
quoted
How do we get the userspace size with the encoded_iov.size approach?
We'd have to read the size from the iov_iter before writing to the rest
of the iov_iter. Is it okay to mix the iov_iter as a source and
destination like this? From what I can tell, it's not intended to be
used like this.
I guess it could work that way, but yes, it's ugly as hell. And I
really don't want a readv() system call - that should write to the
result buffer - to first have to read from it.
So I think the original "just make it be the first iov entry" is the
better approach, even if Al hates it.
Although I still get the feeling that using an ioctl is the *really*
correct way to go. That was my first reaction to the series
originally, and I still don't see why we'd have encoded data in a
regular read/write path.
What was the argument against ioctl's, again?
The suggestion came from Dave Chinner here:
https://lore.kernel.org/linux-fsdevel/20190905021012.GL7777@dread.disaster.area/
His objection to an ioctl was two-fold:
1. This interfaces looks really similar to normal read/write, so we
should try to use the normal read/write interface for it. Perhaps
this trouble with iov_iter has refuted that.
2. The last time we had Btrfs-specific ioctls that eventually became
generic (FIDEDUPERANGE and FICLONE{,RANGE}), the generalization was
painful. Part of the problem with clone/dedupe was that the Btrfs
ioctls were underspecified. I think I've done a better job of
documenting all of the semantics and corner cases for the encoded I/O
interface (and if not, I can address this). The other part of the
problem is that there were various sanity checks in the normal
read/write paths that were missed or drifted out of sync in the
ioctls. That requires some vigilance going forward. Maybe starting
this off as a generic (not Btrfs-specific) ioctl right off the bat
will help.
If we do go the ioctl route, then we also have to decide how much of
preadv2/pwritev2 it should emulate. Should it use the fd offset, or
should that be an ioctl argument? Some of the RWF_ flags would be useful
for encoded I/O, too (RWF_DSYNC, RWF_SYNC, RWF_APPEND), should it
support those? These bring us back to Dave's first point.
On Mon, Jun 21, 2021 at 01:46:04PM -0700, Omar Sandoval wrote:
On Mon, Jun 21, 2021 at 12:33:17PM -0700, Linus Torvalds wrote:
quoted
On Mon, Jun 21, 2021 at 11:46 AM Omar Sandoval [off-list ref] wrote:
quoted
How do we get the userspace size with the encoded_iov.size approach?
We'd have to read the size from the iov_iter before writing to the rest
of the iov_iter. Is it okay to mix the iov_iter as a source and
destination like this? From what I can tell, it's not intended to be
used like this.
I guess it could work that way, but yes, it's ugly as hell. And I
really don't want a readv() system call - that should write to the
result buffer - to first have to read from it.
So I think the original "just make it be the first iov entry" is the
better approach, even if Al hates it.
Although I still get the feeling that using an ioctl is the *really*
correct way to go. That was my first reaction to the series
originally, and I still don't see why we'd have encoded data in a
regular read/write path.
What was the argument against ioctl's, again?
The suggestion came from Dave Chinner here:
https://lore.kernel.org/linux-fsdevel/20190905021012.GL7777@dread.disaster.area/
His objection to an ioctl was two-fold:
1. This interfaces looks really similar to normal read/write, so we
should try to use the normal read/write interface for it. Perhaps
this trouble with iov_iter has refuted that.
2. The last time we had Btrfs-specific ioctls that eventually became
generic (FIDEDUPERANGE and FICLONE{,RANGE}), the generalization was
painful. Part of the problem with clone/dedupe was that the Btrfs
ioctls were underspecified. I think I've done a better job of
documenting all of the semantics and corner cases for the encoded I/O
interface (and if not, I can address this). The other part of the
problem is that there were various sanity checks in the normal
read/write paths that were missed or drifted out of sync in the
ioctls. That requires some vigilance going forward. Maybe starting
this off as a generic (not Btrfs-specific) ioctl right off the bat
will help.
If we do go the ioctl route, then we also have to decide how much of
preadv2/pwritev2 it should emulate. Should it use the fd offset, or
should that be an ioctl argument? Some of the RWF_ flags would be useful
for encoded I/O, too (RWF_DSYNC, RWF_SYNC, RWF_APPEND), should it
support those? These bring us back to Dave's first point.
Oops, I dropped Dave from the Cc list at some point. Adding him back
now.
From: Dave Chinner <david@fromorbit.com> Date: 2021-06-22 22:06:46
On Mon, Jun 21, 2021 at 01:55:03PM -0700, Omar Sandoval wrote:
On Mon, Jun 21, 2021 at 01:46:04PM -0700, Omar Sandoval wrote:
quoted
On Mon, Jun 21, 2021 at 12:33:17PM -0700, Linus Torvalds wrote:
quoted
On Mon, Jun 21, 2021 at 11:46 AM Omar Sandoval [off-list ref] wrote:
quoted
How do we get the userspace size with the encoded_iov.size approach?
We'd have to read the size from the iov_iter before writing to the rest
of the iov_iter. Is it okay to mix the iov_iter as a source and
destination like this? From what I can tell, it's not intended to be
used like this.
I guess it could work that way, but yes, it's ugly as hell. And I
really don't want a readv() system call - that should write to the
result buffer - to first have to read from it.
So I think the original "just make it be the first iov entry" is the
better approach, even if Al hates it.
Although I still get the feeling that using an ioctl is the *really*
correct way to go. That was my first reaction to the series
originally, and I still don't see why we'd have encoded data in a
regular read/write path.
What was the argument against ioctl's, again?
The suggestion came from Dave Chinner here:
https://lore.kernel.org/linux-fsdevel/20190905021012.GL7777@dread.disaster.area/
His objection to an ioctl was two-fold:
1. This interfaces looks really similar to normal read/write, so we
should try to use the normal read/write interface for it. Perhaps
this trouble with iov_iter has refuted that.
2. The last time we had Btrfs-specific ioctls that eventually became
generic (FIDEDUPERANGE and FICLONE{,RANGE}), the generalization was
painful. Part of the problem with clone/dedupe was that the Btrfs
ioctls were underspecified. I think I've done a better job of
documenting all of the semantics and corner cases for the encoded I/O
interface (and if not, I can address this). The other part of the
problem is that there were various sanity checks in the normal
read/write paths that were missed or drifted out of sync in the
ioctls. That requires some vigilance going forward. Maybe starting
this off as a generic (not Btrfs-specific) ioctl right off the bat
will help.
If we do go the ioctl route, then we also have to decide how much of
preadv2/pwritev2 it should emulate. Should it use the fd offset, or
should that be an ioctl argument? Some of the RWF_ flags would be useful
for encoded I/O, too (RWF_DSYNC, RWF_SYNC, RWF_APPEND), should it
support those? These bring us back to Dave's first point.
Oops, I dropped Dave from the Cc list at some point. Adding him back
now.
Fair summary. The only other thing that I'd add is this is an IO
interface that requires issuing physical IO. So if someone wants
high throughput for encoded IO, we really need AIO and/or io_uring
support, and we get that for free if we use readv2/writev2
interfaces.
Yes, it could be an ioctl() interface, but I think that this sort of
functionality is exactly what extensible syscalls like
preadv2/pwritev2 should be used for. It's a slight variant on normal
IO, and that's exactly what the RWF_* flags are intended to be used
for - allowing interesting per-IO variant behaviour without having
to completely re-implemnt the IO path via custom ioctls every time
we want slightly different functionality...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
On Wed, Jun 23, 2021 at 08:06:39AM +1000, Dave Chinner wrote:
On Mon, Jun 21, 2021 at 01:55:03PM -0700, Omar Sandoval wrote:
quoted
On Mon, Jun 21, 2021 at 01:46:04PM -0700, Omar Sandoval wrote:
quoted
On Mon, Jun 21, 2021 at 12:33:17PM -0700, Linus Torvalds wrote:
quoted
On Mon, Jun 21, 2021 at 11:46 AM Omar Sandoval [off-list ref] wrote:
quoted
How do we get the userspace size with the encoded_iov.size approach?
We'd have to read the size from the iov_iter before writing to the rest
of the iov_iter. Is it okay to mix the iov_iter as a source and
destination like this? From what I can tell, it's not intended to be
used like this.
I guess it could work that way, but yes, it's ugly as hell. And I
really don't want a readv() system call - that should write to the
result buffer - to first have to read from it.
So I think the original "just make it be the first iov entry" is the
better approach, even if Al hates it.
Although I still get the feeling that using an ioctl is the *really*
correct way to go. That was my first reaction to the series
originally, and I still don't see why we'd have encoded data in a
regular read/write path.
What was the argument against ioctl's, again?
The suggestion came from Dave Chinner here:
https://lore.kernel.org/linux-fsdevel/20190905021012.GL7777@dread.disaster.area/
His objection to an ioctl was two-fold:
1. This interfaces looks really similar to normal read/write, so we
should try to use the normal read/write interface for it. Perhaps
this trouble with iov_iter has refuted that.
2. The last time we had Btrfs-specific ioctls that eventually became
generic (FIDEDUPERANGE and FICLONE{,RANGE}), the generalization was
painful. Part of the problem with clone/dedupe was that the Btrfs
ioctls were underspecified. I think I've done a better job of
documenting all of the semantics and corner cases for the encoded I/O
interface (and if not, I can address this). The other part of the
problem is that there were various sanity checks in the normal
read/write paths that were missed or drifted out of sync in the
ioctls. That requires some vigilance going forward. Maybe starting
this off as a generic (not Btrfs-specific) ioctl right off the bat
will help.
If we do go the ioctl route, then we also have to decide how much of
preadv2/pwritev2 it should emulate. Should it use the fd offset, or
should that be an ioctl argument? Some of the RWF_ flags would be useful
for encoded I/O, too (RWF_DSYNC, RWF_SYNC, RWF_APPEND), should it
support those? These bring us back to Dave's first point.
Oops, I dropped Dave from the Cc list at some point. Adding him back
now.
Fair summary. The only other thing that I'd add is this is an IO
interface that requires issuing physical IO. So if someone wants
high throughput for encoded IO, we really need AIO and/or io_uring
support, and we get that for free if we use readv2/writev2
interfaces.
Yes, it could be an ioctl() interface, but I think that this sort of
functionality is exactly what extensible syscalls like
preadv2/pwritev2 should be used for. It's a slight variant on normal
IO, and that's exactly what the RWF_* flags are intended to be used
for - allowing interesting per-IO variant behaviour without having
to completely re-implemnt the IO path via custom ioctls every time
we want slightly different functionality...
Al, Linus, what do you think? Is there a path forward for this series as
is? I'd be happy to have this functionality merged in any form, but I do
think that this approach with preadv2/pwritev2 using iov_len is decent
relative to the alternatives.
On Wed, Jun 23, 2021 at 10:49 AM Omar Sandoval [off-list ref] wrote:
Al, Linus, what do you think? Is there a path forward for this series as
is?
So the "read from user space in order to write" is a no-go for me. It
completely violates what a "read()" system call should do. It also
entirely violates what an iovec can and should do.
And honestly, if Al hates the "first iov entry" model, I'm not sure I
want to merge that version - I personally find it fine, but Al is
effectively the iov-iter maintainer.
I do worry a bit about the "first iov entry" simply because it might
work for "writev2()" when given virtual user space addresses - but I
think it's conceptually broken for things like direct-IO which might
do things by physical address, and what is a contiguous user space
virtual address is not necessarily a contiguous physical address.
Yes, the filesystem can - and does - hide that path by basically not
doing direct-IO on the first entry at all, and just treat is very
specially in the front end of the IO access, but that only reinforces
the whole "this is not at all like read/write".
Similar issues might crop up in other situations, ie splice etc, where
it's not at all obvious that the iov_iter boundaries would be
maintained as it moves through the system.
So while I personally find the "first iov entry" model fairly
reasonable, I think Dave is being disingenuous when he says that it
looks like a normal read/write. It very much does not. The above is
quite fundamental.
I'd be happy to have this functionality merged in any form, but I do
think that this approach with preadv2/pwritev2 using iov_len is decent
relative to the alternatives.
As mentioned, I find it acceptable. I'm completely unimpressed with
Dave's argument, but ioctl's aren't perfect either, so weak or not,
that argument being bogus doesn't necessarily mean that the iovec
entry model is wrong.
That said, thinking about exactly the fact that I don't think a
translation from iovec to anything else can be truly valid, I find the
iter_is_iovec() case to be the only obviously valid one.
Which gets me back to: how can any of the non-iovec alternatives ever
be valid? You did mention having missed ITER_XARRAY, but my question
is more fundamental than that. How could a non-iter_is_iovec ever be
valid? There are no possible interfaces that can generate such a thing
sanely.
Linus
On Wed, Jun 23, 2021 at 11:28:15AM -0700, Linus Torvalds wrote:
On Wed, Jun 23, 2021 at 10:49 AM Omar Sandoval [off-list ref] wrote:
quoted
Al, Linus, what do you think? Is there a path forward for this series as
is?
So the "read from user space in order to write" is a no-go for me. It
completely violates what a "read()" system call should do. It also
entirely violates what an iovec can and should do.
And honestly, if Al hates the "first iov entry" model, I'm not sure I
want to merge that version - I personally find it fine, but Al is
effectively the iov-iter maintainer.
I do worry a bit about the "first iov entry" simply because it might
work for "writev2()" when given virtual user space addresses - but I
think it's conceptually broken for things like direct-IO which might
do things by physical address, and what is a contiguous user space
virtual address is not necessarily a contiguous physical address.
Yes, the filesystem can - and does - hide that path by basically not
doing direct-IO on the first entry at all, and just treat is very
specially in the front end of the IO access, but that only reinforces
the whole "this is not at all like read/write".
Similar issues might crop up in other situations, ie splice etc, where
it's not at all obvious that the iov_iter boundaries would be
maintained as it moves through the system.
So while I personally find the "first iov entry" model fairly
reasonable, I think Dave is being disingenuous when he says that it
looks like a normal read/write. It very much does not. The above is
quite fundamental.
quoted
I'd be happy to have this functionality merged in any form, but I do
think that this approach with preadv2/pwritev2 using iov_len is decent
relative to the alternatives.
As mentioned, I find it acceptable. I'm completely unimpressed with
Dave's argument, but ioctl's aren't perfect either, so weak or not,
that argument being bogus doesn't necessarily mean that the iovec
entry model is wrong.
That said, thinking about exactly the fact that I don't think a
translation from iovec to anything else can be truly valid, I find the
iter_is_iovec() case to be the only obviously valid one.
Which gets me back to: how can any of the non-iovec alternatives ever
be valid? You did mention having missed ITER_XARRAY, but my question
is more fundamental than that. How could a non-iter_is_iovec ever be
valid? There are no possible interfaces that can generate such a thing
sanely.
I only implemented the bvec and kvec cases for completeness, since
copy_struct_from_iter() would appear to be a generic helper. At least
for RWF_ENCODED, a bvec seems pretty bogus, but it doesn't seem too
far-flung to imagine an in-kernel user of RWF_ENCODED that uses a kvec.
One other option that we haven't considered is ditching the
copy_struct_from_user() semantics and going the simpler route of adding
some reserved space to the end of struct encoded_iov:
struct encoded_iov {
__aligned_u64 len;
__aligned_u64 unencoded_len;
__aligned_u64 unencoded_offset;
__u32 compression;
__u32 encryption;
__u8 reserved[32];
};
Then we can do an unconditional copy_from_user_full(sizeof(struct
encoded_iov)) and check the reserved space in the typical fashion.
(And in the unlikely case that we use up all of that space with
extensions, I suppose we could have an RWF_ENCODED2 with a matching
struct encoded_iov2.)
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-23 19:46:14
On Wed, Jun 23, 2021 at 10:49:51AM -0700, Omar Sandoval wrote:
quoted
Fair summary. The only other thing that I'd add is this is an IO
interface that requires issuing physical IO. So if someone wants
high throughput for encoded IO, we really need AIO and/or io_uring
support, and we get that for free if we use readv2/writev2
interfaces.
Yes, it could be an ioctl() interface, but I think that this sort of
functionality is exactly what extensible syscalls like
preadv2/pwritev2 should be used for. It's a slight variant on normal
IO, and that's exactly what the RWF_* flags are intended to be used
for - allowing interesting per-IO variant behaviour without having
to completely re-implemnt the IO path via custom ioctls every time
we want slightly different functionality...
Al, Linus, what do you think? Is there a path forward for this series as
is? I'd be happy to have this functionality merged in any form, but I do
think that this approach with preadv2/pwritev2 using iov_len is decent
relative to the alternatives.
IMO we might be better off with explicit ioctl - this magical mystery shite
with special meaning of the first iovec length is, IMO, more than enough
to make it a bad fit for read/write family.
It's *not* just a "slightly different functionality" - it's very different
calling conventions. And the deeper one needs to dig into the interface
details to parse what's going on, the less it differs from ioctl() mess.
Said that, why do you need a variable-length header on the read side,
in the first place?
On Wed, Jun 23, 2021 at 07:45:59PM +0000, Al Viro wrote:
On Wed, Jun 23, 2021 at 10:49:51AM -0700, Omar Sandoval wrote:
quoted
quoted
Fair summary. The only other thing that I'd add is this is an IO
interface that requires issuing physical IO. So if someone wants
high throughput for encoded IO, we really need AIO and/or io_uring
support, and we get that for free if we use readv2/writev2
interfaces.
Yes, it could be an ioctl() interface, but I think that this sort of
functionality is exactly what extensible syscalls like
preadv2/pwritev2 should be used for. It's a slight variant on normal
IO, and that's exactly what the RWF_* flags are intended to be used
for - allowing interesting per-IO variant behaviour without having
to completely re-implemnt the IO path via custom ioctls every time
we want slightly different functionality...
Al, Linus, what do you think? Is there a path forward for this series as
is? I'd be happy to have this functionality merged in any form, but I do
think that this approach with preadv2/pwritev2 using iov_len is decent
relative to the alternatives.
IMO we might be better off with explicit ioctl - this magical mystery shite
with special meaning of the first iovec length is, IMO, more than enough
to make it a bad fit for read/write family.
It's *not* just a "slightly different functionality" - it's very different
calling conventions. And the deeper one needs to dig into the interface
details to parse what's going on, the less it differs from ioctl() mess.
Said that, why do you need a variable-length header on the read side,
in the first place?
Suppose we add a new field representing a new type of encoding to the
end of encoded_iov. On the write side, the caller might want to specify
that the data is encoded in that new way, of course. But on the read
side, if the data is encoded in that new way, then the kernel will want
to return that. The kernel needs to know if the user's structure
includes the new field (otherwise when it copies the full struct out, it
will write into what the user thinks is the data instead).
As I mentioned in my reply to Linus, maybe we can stick with
preadv2/pwritev2, but make the struct encoded_iov structure a fixed size
with some reserved space for future expansion. That makes this a lot
less special: just copy a fixed size structure, then read/write the
rest. And then we don't need to reinvent the rest of the
preadv2/pwritev2 path for an ioctl.
Between a fixed size structure and an ioctl, what would you prefer?
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-23 21:40:17
On Wed, Jun 23, 2021 at 01:46:50PM -0700, Omar Sandoval wrote:
Suppose we add a new field representing a new type of encoding to the
end of encoded_iov. On the write side, the caller might want to specify
that the data is encoded in that new way, of course. But on the read
side, if the data is encoded in that new way, then the kernel will want
to return that. The kernel needs to know if the user's structure
includes the new field (otherwise when it copies the full struct out, it
will write into what the user thinks is the data instead).
Er... What's the problem with simply copying that extended structure out,
followed by the data?
IOW, why can't the caller pick the header out of the whole thing and
deal with it in whatever way it likes? Why should kernel need to do
anything special here?
IDGI... Userland had always been able to deal with that kind of stuff;
you read e.g. gzipped data into buffer, you decode the header, you figure
out how long it is and how far out does the payload begin, etc.
How is that different?
On Wed, Jun 23, 2021 at 09:39:48PM +0000, Al Viro wrote:
On Wed, Jun 23, 2021 at 01:46:50PM -0700, Omar Sandoval wrote:
quoted
Suppose we add a new field representing a new type of encoding to the
end of encoded_iov. On the write side, the caller might want to specify
that the data is encoded in that new way, of course. But on the read
side, if the data is encoded in that new way, then the kernel will want
to return that. The kernel needs to know if the user's structure
includes the new field (otherwise when it copies the full struct out, it
will write into what the user thinks is the data instead).
Er... What's the problem with simply copying that extended structure out,
followed by the data?
IOW, why can't the caller pick the header out of the whole thing and
deal with it in whatever way it likes? Why should kernel need to do
anything special here?
IDGI... Userland had always been able to deal with that kind of stuff;
you read e.g. gzipped data into buffer, you decode the header, you figure
out how long it is and how far out does the payload begin, etc.
How is that different?
Ah, I was stuck on thinking about this calling convention:
struct encoded_iov encoded_iov;
char compressed_data[...];
struct iovec iov[] = {
{ &encoded_iov, sizeof(encoded_iov) },
{ compressed_data, sizeof(compressed_data) },
};
preadv2(fd, iov, 2, -1, RWF_ENCODED);
But what you described would look more like:
// Needs to be large enough for maximum returned header + data.
char buffer[...];
struct iovec iov[] = {
{ buffer, sizeof(buffer) },
};
preadv2(fd, iov, 2, -1, RWF_ENCODED);
// We should probably align the buffer.
struct encoded_iov *encoded_iov = (void *)buffer;
char *data = buffer + encoded_iov->size;
That's a little uglier, but it should work, and allows for arbitrary
extensions. So, among these three alternatives (fixed size structure
with reserved space, variable size structure like above, or ioctl),
which would you prefer?
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2021-06-23 22:26:36
On Wed, Jun 23, 2021 at 02:58:32PM -0700, Omar Sandoval wrote:
Ah, I was stuck on thinking about this calling convention:
struct encoded_iov encoded_iov;
char compressed_data[...];
struct iovec iov[] = {
{ &encoded_iov, sizeof(encoded_iov) },
{ compressed_data, sizeof(compressed_data) },
};
preadv2(fd, iov, 2, -1, RWF_ENCODED);
But what you described would look more like:
// Needs to be large enough for maximum returned header + data.
char buffer[...];
struct iovec iov[] = {
{ buffer, sizeof(buffer) },
};
preadv2(fd, iov, 2, -1, RWF_ENCODED);
// We should probably align the buffer.
struct encoded_iov *encoded_iov = (void *)buffer;
char *data = buffer + encoded_iov->size;
That's a little uglier, but it should work, and allows for arbitrary
extensions. So, among these three alternatives (fixed size structure
with reserved space, variable size structure like above, or ioctl),
which would you prefer?
Variable-sized structure would seem to be the easiest from the kernel
POV and the interface is the easiest to describe - "you read the
encoded data preceded by the header"...
From: Matthew Wilcox <willy@infradead.org> Date: 2021-06-24 02:01:10
On Wed, Jun 23, 2021 at 02:58:32PM -0700, Omar Sandoval wrote:
But what you described would look more like:
// Needs to be large enough for maximum returned header + data.
char buffer[...];
struct iovec iov[] = {
{ buffer, sizeof(buffer) },
};
preadv2(fd, iov, 2, -1, RWF_ENCODED);
// We should probably align the buffer.
struct encoded_iov *encoded_iov = (void *)buffer;
char *data = buffer + encoded_iov->size;
That's a little uglier, but it should work, and allows for arbitrary
extensions. So, among these three alternatives (fixed size structure
with reserved space, variable size structure like above, or ioctl),
which would you prefer?
Does that work for O_DIRECT and the required 512-byte alignment?
On Thu, Jun 24, 2021 at 03:00:39AM +0100, Matthew Wilcox wrote:
On Wed, Jun 23, 2021 at 02:58:32PM -0700, Omar Sandoval wrote:
quoted
But what you described would look more like:
// Needs to be large enough for maximum returned header + data.
char buffer[...];
struct iovec iov[] = {
{ buffer, sizeof(buffer) },
};
preadv2(fd, iov, 2, -1, RWF_ENCODED);
// We should probably align the buffer.
struct encoded_iov *encoded_iov = (void *)buffer;
char *data = buffer + encoded_iov->size;
That's a little uglier, but it should work, and allows for arbitrary
extensions. So, among these three alternatives (fixed size structure
with reserved space, variable size structure like above, or ioctl),
which would you prefer?
Does that work for O_DIRECT and the required 512-byte alignment?
I suppose the kernel could pad the encoded_iov structure with zeroes to
the next sector boundary, since zeroes are effectively noops for
encoded_iov. (As an aside, RWF_ENCODED is always "direct I/O" in the
sense that it bypasses the page cache, but not necessarily in the sense
that it does DMA to/from the user buffers. The Btrfs implementation
doesn't do the latter yet.)
From: Christoph Hellwig <hch@infradead.org> Date: 2021-06-24 06:42:23
I'm also really worried with overloading the regular r/w path and
iov_iter with ever more special cases. We already have various
performance problems in the path, and adding more special cases ain't
gonna help.
On Thu, Jun 24, 2021 at 07:41:12AM +0100, Christoph Hellwig wrote:
I'm also really worried with overloading the regular r/w path and
iov_iter with ever more special cases. We already have various
performance problems in the path, and adding more special cases ain't
gonna help.
The changes to the normal path are:
* An extra check for RWF_ENCODED and FMODE_ENCODED_IO in kiocb_set_rw_flags().
* Splitting some of the checks in generic_write_checks() into a new
function.
* Checks for the IOCB_ENCODED flag in the filesystem's
read_iter/write_iter.
At least for Btrfs, the rest happens in a completely separate code path.
So, there are a couple of extra checks, but it's not as drastic as it
might first appear.
On Wed, Jun 23, 2021 at 11:15 PM Omar Sandoval [off-list ref] wrote:
On Thu, Jun 24, 2021 at 03:00:39AM +0100, Matthew Wilcox wrote:
quoted
Does that work for O_DIRECT and the required 512-byte alignment?
I suppose the kernel could pad the encoded_iov structure with zeroes to
the next sector boundary, since zeroes are effectively noops for
encoded_iov.
Ugh.
I really think the whole "embed the control structure in the stream"
is wrong. The alignment issue is just another sign of that.
Separating it out is the right thing to do. At least the "first iov
entry" thing did separate the control structure from the actual data.
I detest the whole "embed the two together".
Linus
On Thu, Jun 24, 2021 at 10:52:17AM -0700, Linus Torvalds wrote:
On Wed, Jun 23, 2021 at 11:15 PM Omar Sandoval [off-list ref] wrote:
quoted
On Thu, Jun 24, 2021 at 03:00:39AM +0100, Matthew Wilcox wrote:
quoted
Does that work for O_DIRECT and the required 512-byte alignment?
I suppose the kernel could pad the encoded_iov structure with zeroes to
the next sector boundary, since zeroes are effectively noops for
encoded_iov.
Ugh.
I really think the whole "embed the control structure in the stream"
is wrong. The alignment issue is just another sign of that.
Separating it out is the right thing to do. At least the "first iov
entry" thing did separate the control structure from the actual data.
I detest the whole "embed the two together".
I'll suggest the fixed-size struct encoded_iov again, then. If we're
willing to give up some of the flexibility of a variable size, then
userspace can always put the fixed-size structure in its own iovec or
include it inline with the data, depending on what's more convenient and
whether it's using O_DIRECT. A fixed size is much easier for both the
kernel and userspace to deal with. Do we really need to support
unlimited extensions to encoded_iov, or can we stick 32-64 bytes of
reserved space at the end of the structure and call it a day?
On Thu, Jun 24, 2021 at 11:28 AM Omar Sandoval [off-list ref] wrote:
I'll suggest the fixed-size struct encoded_iov again, then. If we're
willing to give up some of the flexibility of a variable size, then
userspace can always put the fixed-size structure in its own iovec or
include it inline with the data, depending on what's more convenient and
whether it's using O_DIRECT.
I really would prefer to have the separate pointer to it.
Fixed size doesn't help. It's still "mixed in" unless you have a
clearly separate pointer. Sure, user space *could* use a separate iov
entry if it wants to, but then it becomes a user choice rather than
part of the design.
That separate data structure would be the only way to do it for a
ioctl() interface, but in the readv/writev world the whole separate
"first iov entry" does that too.
I also worry that this "raw compressed data" thing isn't the only
thing people will want to do. I could easily see some kind of
"end-to-end CRC read/write" where the user passes in not just the
data, but also checksums for it to validate it (maybe because you're
doing a file copy and had the original checksums, but also maybe
because user space simply has a known good copy and doesn't want
errors re-introduced due to memory corruption).
And I continue to think that this whole issue isn't all that different
from the FSVERITY thing.
Of course, the real take-away is that "preadv2/pwritev2()" is a
horrible interface. It should have been more extensible, rather than
the lazy "just add another flag argument".
I think we finally may have gotten a real extensible interface right
with openat2(), and that "open_how" thing, but maybe I'm being naive
and it will turn out that that wasn't so great either.
Maybe we'll some day end up with a "preadv3()" that has an extensible
"struct io_how" argument.
Interfaces are hard.
Linus