linux-kernel - Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

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 for Android: free password hash cracker in your pocket

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

Message-ID: <yw1xlhajauup.fsf@unicorn.mansr.com>
Date:	Sat, 31 Oct 2015 16:03:26 +0000
From:	Måns Rullgård <mans@...sr.com>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Francois Romieu <romieu@...zoreil.com> writes:

>> +static int nb8800_poll(struct napi_struct *napi, int budget)
>> +{
>> +	struct net_device *dev = napi->dev;
>> +	struct nb8800_priv *priv = netdev_priv(dev);
>> +	struct nb8800_dma_desc *rx;
>> +	int work = 0;
>> +	int last = priv->rx_eoc;
>> +	int next;
>> +
>> +	while (work < budget) {
>> +		struct rx_buf *rx_buf;
>> +		u32 report;
>> +		int len;
>> +
>> +		next = (last + 1) & (RX_DESC_COUNT - 1);
>> +
>> +		rx_buf = &priv->rx_bufs[next];
>> +		rx = &priv->rx_descs[next];
>> +		report = rx->report;
>> +
>> +		if (!report)
>> +			break;
>> +
>> +		if (IS_RX_ERROR(report)) {
>> +			nb8800_rx_error(dev, report);
>> +		} else if (likely(rx_buf->page)) {
>> +			len = RX_BYTES_TRANSFERRED(report);
>> +			nb8800_receive(dev, next, len);
>> +		}
>> +
>> +		rx->report = 0;
>> +		if (!rx_buf->page)
>> +			nb8800_alloc_rx(dev, next, true);
>
> It looks like it receives, then tries to allocate new resources. If so
> it may deplete the ring and you should instead consider allocating new
> resources first, then receive data if alloc + map suceeded.

The hardware receives a frame and stores it in the provided DMA buffer,
then raises an interrupt and moves on to the next buffer.  When a buffer
is handed over to the network stack, a new one has to take its place in
the DMA queue.  I'm not sure how you're suggesting this be done
differently.

-- 
Måns Rullgård
mans@...sr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/