linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bernard Metzler" <BMT@zurich.ibm.com>
To: "Jason Gunthorpe" <jgg@ziepe.ca>
Cc: "Tom Seewald" <tseewald@gmail.com>,
	linux-rdma@vger.kernel.org, "Doug Ledford" <dledford@redhat.com>
Subject: RE: Re: [PATCH next] siw: Fix pointer-to-int-cast warning in siw_rx_pbl()
Date: Thu, 11 Jun 2020 15:06:12 +0000	[thread overview]
Message-ID: <OFD3ED6A67.BCC6E1B8-ON00258584.00526201-00258584.0052F73E@notes.na.collabserv.com> (raw)
In-Reply-To: <20200611142355.GX6578@ziepe.ca>

-----"Jason Gunthorpe" <jgg@ziepe.ca> wrote: -----

>To: "Bernard Metzler" <BMT@zurich.ibm.com>
>From: "Jason Gunthorpe" <jgg@ziepe.ca>
>Date: 06/11/2020 04:24PM
>Cc: "Tom Seewald" <tseewald@gmail.com>, linux-rdma@vger.kernel.org,
>"Doug Ledford" <dledford@redhat.com>
>Subject: [EXTERNAL] Re: Re: [PATCH next] siw: Fix pointer-to-int-cast
>warning in siw_rx_pbl()
>
>On Thu, Jun 11, 2020 at 02:11:51PM +0000, Bernard Metzler wrote:
>> 
>> >To: "Bernard Metzler" <BMT@zurich.ibm.com>
>> >From: "Jason Gunthorpe" <jgg@ziepe.ca>
>> >Date: 06/11/2020 01:35PM
>> >Cc: "Tom Seewald" <tseewald@gmail.com>,
>linux-rdma@vger.kernel.org,
>> >"Doug Ledford" <dledford@redhat.com>
>> >Subject: [EXTERNAL] Re: Re: [PATCH next] siw: Fix
>pointer-to-int-cast
>> >warning in siw_rx_pbl()
>> >
>> >On Thu, Jun 11, 2020 at 10:21:49AM +0000, Bernard Metzler wrote:
>> >> 
>> >> >To: "Tom Seewald" <tseewald@gmail.com>
>> >> >From: "Jason Gunthorpe" <jgg@ziepe.ca>
>> >> >Date: 06/10/2020 07:50PM
>> >> >Cc: linux-rdma@vger.kernel.org, "Bernard Metzler"
>> >> ><bmt@zurich.ibm.com>, "Doug Ledford" <dledford@redhat.com>
>> >> >Subject: [EXTERNAL] Re: [PATCH next] siw: Fix
>pointer-to-int-cast
>> >> >warning in siw_rx_pbl()
>> >> >
>> >> >On Wed, Jun 10, 2020 at 12:47:17PM -0500, Tom Seewald wrote:
>> >> >> The variable buf_addr is type dma_addr_t, which may not be
>the
>> >same
>> >> >size
>> >> >> as a pointer.  To ensure it is the correct size, cast to a
>> >> >uintptr_t.
>> >> >> 
>> >> >> Signed-off-by: Tom Seewald <tseewald@gmail.com>
>> >> >>  drivers/infiniband/sw/siw/siw_qp_rx.c | 3 ++-
>> >> >>  1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >> 
>> >> >> diff --git a/drivers/infiniband/sw/siw/siw_qp_rx.c
>> >> >b/drivers/infiniband/sw/siw/siw_qp_rx.c
>> >> >> index 650520244ed0..7271d705f4b0 100644
>> >> >> +++ b/drivers/infiniband/sw/siw/siw_qp_rx.c
>> >> >> @@ -139,7 +139,8 @@ static int siw_rx_pbl(struct
>siw_rx_stream
>> >> >*srx, int *pbl_idx,
>> >> >>  			break;
>> >> >>  
>> >> >>  		bytes = min(bytes, len);
>> >> >> -		if (siw_rx_kva(srx, (void *)buf_addr, bytes) == bytes) {
>> >> >> +		if (siw_rx_kva(srx, (void *)(uintptr_t)buf_addr, bytes) ==
>> >> >> +		    bytes) {
>> >> >
>> >> >How is a dma_addr_t being cast to a void *? That can't be
>right?
>> >> >Bernard??
>> >> >
>> >> >Jason
>> >> >
>> >> Hi Tom, Hi Jason,
>> >> 
>> >> Thanks for looking into that.
>> >> 
>> >> siw_rx_kva() calls skb_copy_bits() to move data to its
>> >> kernel clients destination.  It expects a void * target
>> >> address. This is why I chose it for siw_rx_kva() as well.
>> >> One could say siw_rx_kva() should better get an uintptr_t
>> >> as target argument, which would probably make it look
>> >> more clean. And we rename it to siw_rx_kbuf(), and we
>> >> cast from uintptr_t to (void *) just for
>> >>  skb_copy_bits(skb *, off, (void *)dest, len)
>> >> 
>> >> This would avoid all those nasty (void *) casting at all (!)
>> >> the places we are calling siw_rx_kva().
>> >
>> >But where did the dma_addr_t come from?
>> >
>> It initially comes from the scatterlist provided by the
>> kernel user via drivers .map_mr_sg() method. There we get a
>> dma_addr_t describing the users buffer.
>
>For the SW dma maps you have to convert the dma_addr_t to a kva using
>kmap, it cannot just be casted.
>

True for a real dma addr. But here the user initially came
with an address it got from dma_virt_ops.dma_virt_map_page(),
which provides the virtual address of the page referenced,
casted to dma_addr_t. So we mimic some great dma_addr_t stuff
we do not need for a SW driver and in the end we even have
to call heavy kmap_atomic() to just get the very same addr again.
This I don't want. It's why I just casted it back to void *.
hmmm.

Thanks,
Bernard.


  parent reply	other threads:[~2020-06-11 15:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 17:47 [PATCH next] siw: Fix pointer-to-int-cast warning in siw_rx_pbl() Tom Seewald
2020-06-10 17:50 ` Jason Gunthorpe
2020-06-10 18:21   ` Tom Seewald
2020-06-11 10:21 ` Bernard Metzler
2020-06-11 11:35   ` Jason Gunthorpe
2020-06-11 14:11   ` Bernard Metzler
2020-06-11 14:23     ` Jason Gunthorpe
2020-06-11 15:06     ` Bernard Metzler [this message]
2020-06-11 17:05       ` Jason Gunthorpe
2020-06-12 15:56       ` Bernard Metzler
2020-06-16 14:03 ` Jason Gunthorpe

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=OFD3ED6A67.BCC6E1B8-ON00258584.00526201-00258584.0052F73E@notes.na.collabserv.com \
    --to=bmt@zurich.ibm.com \
    --cc=dledford@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-rdma@vger.kernel.org \
    --cc=tseewald@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).