netdev - Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1328001142.26983.289.camel@zakaz.uk.xensource.com>
Date:	Tue, 31 Jan 2012 09:12:22 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	"Wei Liu (Intern)" <wei.liu2@...rix.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.

On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:

[...snip... please do consider trimming unnecessary quotes]

> > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >               goto fail;
> >       }
> >
> > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > +                        "max-tx-ring-page-order", "%u",
> > +                        &max_tx_ring_page_order);
> > +     if (err < 0) {
> > +             info->tx_ring_page_order = 0;
> > +             dev_info(&dev->dev, "single tx ring\n");
> > +     } else {
> > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > +                      max_tx_ring_page_order);
> > +     }
> > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > +
> > +     txs = (struct xen_netif_tx_sring *)
> > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > +                                &info->tx_ring_dma_handle,
> > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> 
> Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> clue whether you are OK getting pages under 4GB or above it (so 64-bit support).

Does this allocation even need to be physically contiguous? I'd have
thought that virtually contiguous would be sufficient, and even then
only as a convenience at either end to avoid the need for more
complicated ring macros.

Ian.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html