netdev - Re: KS8695: possible NAPI issue

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:	Fri, 5 Mar 2010 08:22:18 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Yegor Yefremov <yegorslists@...glemail.com>
Cc:	"Figo.zhang" <figo1802@...il.com>,
	Dick Hollenbeck <dick@...tplc.com>, netdev@...r.kernel.org,
	zealcook@...il.com
Subject: Re: KS8695: possible NAPI issue

On Fri, 5 Mar 2010 16:00:11 +0100
Yegor Yefremov <yegorslists@...glemail.com> wrote:

> >> My tests look like following:
> >>
> >> 1. system start
> >> 2. ping one host: O.K.
> >> 3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
> >> 4. ping the same host: failed
> > 1. type "arp" command, see the arp is exit or expire?
> 
> debian:~# nc -l -p 5000 > /var/zImage
> 
> debian:~# ping -c 1 192.168.1.38
> 
> PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data.
> 
> From 192.168.1.66 icmp_seq=1 Destination Host Unreachable
> 
> 
> 
> --- 192.168.1.38 ping statistics ---
> 
> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
> 
> 
> 
> debian:~# arp
> 
> Address                  HWtype  HWaddress           Flags Mask            Iface
> 192.168.1.38          (incomplete)                              eth0
> 
> 192.168.1.36             ether   00:10:18:39:19:aa   C                     eth0
> 
> 
> > 2. at this point, see is it still have RX interrpt and receive packet in
> > ks8695_rx()? (in some watchpoint add printk).
> 
> I've inserted some printks and I can see that interrupts are coming
> and the received count will be increased. I can also see my system
> sending arp requests. Even this ping request is visible in wireshark
> and its reply, but the ping utility sees nothing of it.


One of the requirements for NAPI to work is that the IRQ is level triggered.
Otherwise there can be a race between packet arrival and the end of
NAPI processing:

static int ks8695_poll(struct napi_struct *napi, int budget)
{
	struct ks8695_priv *ksp = container_of(napi, struct ks8695_priv, napi);
	unsigned long  work_done;

	unsigned long isr = readl(KS8695_IRQ_VA + KS8695_INTEN);
	unsigned long mask_bit = 1 << ks8695_get_rx_enable_bit(ksp);

	work_done = ks8695_rx(ksp, budget);

	if (work_done < budget) {
		unsigned long flags;
		spin_lock_irqsave(&ksp->rx_lock, flags);
>>> packet arrives >>
		/*enable rx interrupt*/
		writel(isr | mask_bit, KS8695_IRQ_VA + KS8695_INTEN);
>>> or here >>
		__napi_complete(napi);
		spin_unlock_irqrestore(&ksp->rx_lock, flags);

If the hardware can't be reprogrammed to level mode;
the solution used in some drivers is to poll for lost packet after re-enabling
NAPI.



-- 
--
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