[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7582460ba52e413eaab26d37fb56beed@AcuMS.aculab.com>
Date: Wed, 6 Dec 2023 11:38:45 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Jens Axboe' <axboe@...nel.dk>,
Arnaud POULIQUEN <arnaud.pouliquen@...s.st.com>,
Sumit Garg <sumit.garg@...aro.org>,
Al Viro <viro@...iv.linux.org.uk>
CC: Jens Wiklander <jens.wiklander@...aro.org>,
Christoph Hellwig <hch@...radead.org>,
"op-tee@...ts.trustedfirmware.org" <op-tee@...ts.trustedfirmware.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Christian Brauner <brauner@...nel.org>,
Christian Brauner <christian@...uner.io>
Subject: RE: [PATCH v4] tee: Use iov_iter to better support shared buffer
registration
> > As Jens Wiklander has proposed using iov_iter_ubuf() instead of
> > import_ubuf(), should I propose a patch updating import_ubuf() and
> > import_single_range()? Or would you prefer that we keep the functions
> > unchanged for the time being?
>
> Arguably it should be consistent with iovec imports, which return the
> length (or error). But it might be safer to just check access_ok()
> first and then truncate at least, vs what is there now.
Is the access_ok() check even needed when setting up an iov_iter?
It is always checked again when the actual copy is done.
I looked at this a while back and couldn't see any code paths that
relied on the early access_ok() check.
Maybe it is historic?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists