On Thu, 2023-02-02 at 05:20 +0000, Michael Kelley (LINUX) wrote:
> From: Jakub Kicinski <kuba@xxxxxxxxxx> Sent: Wednesday, February 1, 2023 9:01 PM
> >
> > On Mon, 30 Jan 2023 19:33:06 -0800 Michael Kelley wrote:
> > > @@ -990,9 +987,7 @@ static int netvsc_dma_map(struct hv_device *hv_dev,
> > > struct hv_netvsc_packet *packet,
> > > struct hv_page_buffer *pb)
> > > {
> > > - u32 page_count = packet->cp_partial ?
> > > - packet->page_buf_cnt - packet->rmsg_pgcnt :
> > > - packet->page_buf_cnt;
> > > + u32 page_count = packet->page_buf_cnt;
> > > dma_addr_t dma;
> > > int i;
> >
> > Suspiciously, the caller still does:
> >
> > if (packet->cp_partial)
> > pb += packet->rmsg_pgcnt;
> >
> > ret = netvsc_dma_map(ndev_ctx->device_ctx, packet, pb);
> >
> > Shouldn't that if () pb +=... also go away?
>
> No -- it's correct.
>
> In netvsc_send(), cp_partial is tested and packet->page_buf_cnt is
> adjusted. But the pointer into the pagebuf array is not adjusted in
> netvsc_send(). Instead it is adjusted here in netvsc_send_pkt(), which
> brings it back in sync with packet->page_buf_cnt.
Ok
> I don't know if there's a good reason for the adjustment being split
> across two different functions. It doesn't seem like the most
> straightforward approach. From a quick glance at the code it looks
> like this adjustment to 'pb' could move to netvsc_send() to be
> together with the adjustment to packet->page_buf_cnt, but maybe
> there's a reason for the split that I'm not familiar with.
>
> Haiyang -- any insight?
While at that, please also have a look at the following allocation in
netvsc_dma_map():
packet->dma_range = kcalloc(page_count,
sizeof(*packet->dma_range),
GFP_KERNEL);
which looks wrong - netvsc_dma_map() should be in atomic context.
Anyway it's a topic unrelated from this patch. I just stumbled upon it
while reviewing.
Cheers,
Paolo
