[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200921142204.GE24515@infradead.org>
Date: Mon, 21 Sep 2020 15:22:04 +0100
From: Christoph Hellwig <hch@...radead.org>
To: David Laight <David.Laight@...lab.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>,
"David S. Miller" <davem@...emloft.net>,
Al Viro <viro@...iv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 5/9 next] scsi: Use iovec_import() instead of
import_iovec().
So looking at the various callers I'm not sure this API is the
best. If we want to do something fancy I'd hide the struct iovec
instances entirely with something like:
struct iov_storage {
struct iovec stack[UIO_FASTIOV], *vec;
}
int iov_iter_import_iovec(struct iov_iter *iter, struct iov_storage *s,
const struct iovec __user *vec, unsigned long nr_segs,
int type);
and then add a new helper to free the thing if needed:
void iov_iter_release_iovec(struct iov_storage *s)
{
if (s->vec != s->stack)
kfree(s->vec);
}
Powered by blists - more mailing lists