[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YLUY/7pcFMibDnRn@zeniv-ca.linux.org.uk>
Date: Mon, 31 May 2021 17:12:31 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Andreas Gruenbacher <agruenba@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
cluster-devel@...hat.com, linux-kernel@...r.kernel.org,
Jan Kara <jack@...e.cz>, Matthew Wilcox <willy@...radead.org>
Subject: Re: [RFC 5/9] iov_iter: Add iov_iter_fault_in_writeable()
On Mon, May 31, 2021 at 07:01:19PM +0200, Andreas Gruenbacher wrote:
> Add the equivalent of iov_iter_fault_in_readable(), but for pages that
> will be written to.
>
> While at it, fix an indentation error in iov_iter_fault_in_readable().
> +int iov_iter_fault_in_writeable(struct iov_iter *i, size_t bytes)
> +{
> + size_t skip = i->iov_offset;
> + const struct iovec *iov;
> + int err;
> + struct iovec v;
> +
> + if (!(i->type & (ITER_BVEC|ITER_KVEC))) {
> + iterate_iovec(i, bytes, v, iov, skip, ({
> + err = fault_in_pages_writeable(v.iov_base, v.iov_len);
> + if (unlikely(err))
> + return err;
> + 0;}))
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(iov_iter_fault_in_writeable);
I really don't like that. Conflicts with iov_iter patches are not hard to
deal with, but (like fault_in_pages_writeable() itself) it's dangerous as
hell - fault-in for read is non-destructive, but that is *not*. Existing
users have to be careful with it and there are very few of those. Adding
that as a new primitive is inviting trouble; at the very least it needs
a big fat "Don't use unless you really know what you are doing" kind of
warning.
Powered by blists - more mailing lists