Message ID | 20230523140342.2672713-1-linus.walleij@linaro.org (mailing list archive) |
---|---|
State | Accepted |
Commit | e36bfc0bc3ceb3ace1ff0ed5f9ed781395b6cbc5 |
Headers | show |
Series | xen/netback: Pass (void *) to virt_to_page() | expand |
On Tue, May 23, 2023 at 04:03:42PM +0200, Linus Walleij wrote: > virt_to_page() takes a virtual address as argument but > the driver passes an unsigned long, which works because > the target platform(s) uses polymorphic macros to calculate > the page. > > Since many architectures implement virt_to_pfn() as > a macro, this function becomes polymorphic and accepts both a > (unsigned long) and a (void *). > > Fix this up by an explicit (void *) cast. > > Cc: Wei Liu <wei.liu@kernel.org> > Cc: Paul Durrant <paul@xen.org> > Cc: xen-devel@lists.xenproject.org > Cc: netdev@vger.kernel.org > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Wei Liu <wei.liu@kernel.org>
On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote: > virt_to_page() takes a virtual address as argument but > the driver passes an unsigned long, which works because > the target platform(s) uses polymorphic macros to calculate > the page. > > Since many architectures implement virt_to_pfn() as > a macro, this function becomes polymorphic and accepts both a > (unsigned long) and a (void *). > > Fix this up by an explicit (void *) cast. Paul, Wei, looks like netdev may be the usual path for this patch to flow thru, although I'm never 100% sure with Xen. Please ack or LUK if you prefer to direct the patch elsewhere?
On Wed, 24 May 2023 22:11:47 -0700 Jakub Kicinski wrote: > On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote: > > virt_to_page() takes a virtual address as argument but > > the driver passes an unsigned long, which works because > > the target platform(s) uses polymorphic macros to calculate > > the page. > > > > Since many architectures implement virt_to_pfn() as > > a macro, this function becomes polymorphic and accepts both a > > (unsigned long) and a (void *). > > > > Fix this up by an explicit (void *) cast. > > Paul, Wei, looks like netdev may be the usual path for this patch > to flow thru, although I'm never 100% sure with Xen. > Please ack or LUK if you prefer to direct the patch elsewhere? Ugh, Wei already acked this, sorry for the noise.
On Thu, May 25, 2023 at 7:12 AM Jakub Kicinski <kuba@kernel.org> wrote: > On Wed, 24 May 2023 22:11:47 -0700 Jakub Kicinski wrote: > > On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote: > > > virt_to_page() takes a virtual address as argument but > > > the driver passes an unsigned long, which works because > > > the target platform(s) uses polymorphic macros to calculate > > > the page. > > > > > > Since many architectures implement virt_to_pfn() as > > > a macro, this function becomes polymorphic and accepts both a > > > (unsigned long) and a (void *). > > > > > > Fix this up by an explicit (void *) cast. > > > > Paul, Wei, looks like netdev may be the usual path for this patch > > to flow thru, although I'm never 100% sure with Xen. > > Please ack or LUK if you prefer to direct the patch elsewhere? > > Ugh, Wei already acked this, sorry for the noise. Don't worry about it Jakub, it's queued in the asm-generic tree along with patches making things give nasty compile messages if they are not typed right, we try to keep down the level of noise this way: silence it while fixing the root cause. If you prefer to take it into the net tree that works too but no need. Yours, Linus Walleij
On Wed, May 24, 2023 at 10:11:47PM -0700, Jakub Kicinski wrote: > On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote: > > virt_to_page() takes a virtual address as argument but > > the driver passes an unsigned long, which works because > > the target platform(s) uses polymorphic macros to calculate > > the page. > > > > Since many architectures implement virt_to_pfn() as > > a macro, this function becomes polymorphic and accepts both a > > (unsigned long) and a (void *). > > > > Fix this up by an explicit (void *) cast. > > Paul, Wei, looks like netdev may be the usual path for this patch > to flow thru, although I'm never 100% sure with Xen. Yes. Netdev is the right path. Thanks, Wei.
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index c1501f41e2d8..caf0c815436c 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -689,7 +689,7 @@ static void xenvif_fill_frags(struct xenvif_queue *queue, struct sk_buff *skb) prev_pending_idx = pending_idx; txp = &queue->pending_tx_info[pending_idx].req; - page = virt_to_page(idx_to_kaddr(queue, pending_idx)); + page = virt_to_page((void *)idx_to_kaddr(queue, pending_idx)); __skb_fill_page_desc(skb, i, page, txp->offset, txp->size); skb->len += txp->size; skb->data_len += txp->size;
virt_to_page() takes a virtual address as argument but the driver passes an unsigned long, which works because the target platform(s) uses polymorphic macros to calculate the page. Since many architectures implement virt_to_pfn() as a macro, this function becomes polymorphic and accepts both a (unsigned long) and a (void *). Fix this up by an explicit (void *) cast. Cc: Wei Liu <wei.liu@kernel.org> Cc: Paul Durrant <paul@xen.org> Cc: xen-devel@lists.xenproject.org Cc: netdev@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- drivers/net/xen-netback/netback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)