From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, brauner@kernel.org,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH 3/9] iov_iter: overlay struct iovec and ubuf/len
Date: Tue, 28 Mar 2023 16:19:16 -0600 [thread overview]
Message-ID: <416ec013-72db-7ef0-2205-e8fa0165b712@kernel.dk> (raw)
In-Reply-To: <CAHk-=winXSHgikHZSyDrmoN=WNZWKoR1JrKGW6Vv4mqn6F4EmA@mail.gmail.com>
On 3/28/23 4:16 PM, Linus Torvalds wrote:
> On Tue, Mar 28, 2023 at 2:58 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> + struct iovec __ubuf_iovec;
>
> This really should be "const struct iovec".
>
> The only valid use for this is as an alternative to "iter->iov", and
> that one is a 'const' pointer too:
True, it should. But as per the cover letter, this only really
serves as a space filler, none of the code actually uses it. But
let's make it const, because that is the right thing to do.
>> + const struct iovec *iov;
>
> and any code that tries to use it as a non-const iovec entry really is
> very very wrong.
Nobody should use it, though. The one case where I thought we'd use
it was iov_iter_iovec(), but that doesn't work...
> And yes, the current infiniband/hw/hfi1/* code does indeed do all of
> this wrong and cast the pointer to a non-const one, but that's
> actually just because somebody didn't do the const conversion right.
>
> That cast should just go away, and hfi1_user_sdma_process_request()
> should just take a 'const struct iovec *iovec' argument. It doesn't
> actually want to write to it anyway, so it's literally just a "change
> the prototype of the function" change.
Let's leave that for the IB people!
--
Jens Axboe
next prev parent reply other threads:[~2023-03-28 22:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 21:58 [PATCHSET v5 0/9] Turn single segment imports into ITER_UBUF Jens Axboe
2023-03-28 21:58 ` [PATCH 1/9] block: ensure bio_alloc_map_data() deals with ITER_UBUF correctly Jens Axboe
2023-03-28 21:58 ` [PATCH 2/9] iov_iter: teach iov_iter_iovec() to deal with ITER_UBUF Jens Axboe
2023-03-28 21:58 ` [PATCH 3/9] iov_iter: overlay struct iovec and ubuf/len Jens Axboe
2023-03-28 22:16 ` Linus Torvalds
2023-03-28 22:19 ` Jens Axboe [this message]
2023-03-28 22:30 ` Linus Torvalds
2023-03-29 0:38 ` Jens Axboe
2023-03-28 21:58 ` [PATCH 4/9] iov_iter: set nr_segs = 1 for ITER_UBUF Jens Axboe
2023-03-28 21:58 ` [PATCH 5/9] IB/hfi1: check for user backed iterator, not specific iterator type Jens Axboe
2023-03-28 21:58 ` [PATCH 6/9] IB/qib: " Jens Axboe
2023-03-28 21:58 ` [PATCH 7/9] ALSA: pcm: " Jens Axboe
2023-03-28 21:58 ` [PATCH 8/9] iov_iter: convert import_single_range() to ITER_UBUF Jens Axboe
2023-03-28 21:58 ` [PATCH 9/9] iov_iter: import single vector iovecs as ITER_UBUF Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=416ec013-72db-7ef0-2205-e8fa0165b712@kernel.dk \
--to=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.