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@xxxxxxxxxxxxxxxxxxx/
> The copy_struct_from_iter() thing was proposed as a way to allow future
> extensions here:
> https://lore.kernel.org/linux-btrfs/20191022020215.csdwgi3ky27rfidf@xxxxxxxxxxxxxxxxxxxx/
>
> 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...
