From: Jason Gunthorpe <jgg@ziepe.ca>
To: Bernard Metzler <BMT@zurich.ibm.com>
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 08:35:39 -0300 [thread overview]
Message-ID: <20200611113539.GV6578@ziepe.ca> (raw)
In-Reply-To: <OF2F6FD798.5AF6086F-ON00258584.00329A25-00258584.0038EE32@notes.na.collabserv.com>
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?
Jason
next prev parent reply other threads:[~2020-06-11 11:35 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 [this message]
2020-06-11 14:11 ` Bernard Metzler
2020-06-11 14:23 ` Jason Gunthorpe
2020-06-11 15:06 ` Bernard Metzler
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=20200611113539.GV6578@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=BMT@zurich.ibm.com \
--cc=dledford@redhat.com \
--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).