netdev - Re: [patch sungem] improved locking

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]

Date:	Mon, 11 Dec 2006 17:43:51 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	eric.lemoine@...il.com
Cc:	netdev@...r.kernel.org, benh@...nel.crashing.org
Subject: Re: [patch sungem] improved locking

From: "Eric Lemoine" <eric.lemoine@...il.com>
Date: Wed, 29 Nov 2006 11:56:30 +0100

> I don't understand why we'd need all this.
> 
> I think the following code for gem_interrupt should do the trick:
...
> The important thing is: we __netif_rx_schedule even if gem_status is 0
> (shared irq case) because we don't want to miss events should the
> following scenario occur:

I see, I miseed the bit where we're reading the status register
also in the ->poll() loop.

Reading the status register at least twice every interrupt is
really expensive.

I hope there is a lesson being learned, and nobody out there is
making modern networking NICs that put the interrupt status
in a register.

It should always be in a DMA'd status block, without any exception.
This way it can be polled in the cheapest manner possible.  When the
status block is in main memory, the CPU only takes the "cost" of a
read when the value actually changes.

Anyways, Eric your changes look fine as far as I can tell, can you
give them a really good testing on some SMP boxes?  Then we can
think about putting it into 2.6.21 or similar, I don't want to
put any more major networking changes into 2.6.20 at this time.
-
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