All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.