netdev - Re: data received but not detected

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:	Sun, 22 Jun 2008 10:16:14 +0100
From:	James Chapman <jchapman@...alix.com>
To:	Travis Stratman <tstratman@...cinc.com>
CC:	netdev@...r.kernel.org
Subject: Re: data received but not detected

Travis Stratman wrote:
> I was able to do some more extensive testing today with the macb (atmel
> Eternet MAC controller) driver and noticed that the
> netif_rx_schedule_prep function is returning false at times in the
> interrupt handler. In the code below, the printk shows up during heavy
> traffic, though it only happens a handful of times. (The else block is
> code that I have added to the driver while debugging).
> 
> if (status & MACB_RX_INT_FLAGS) {
>     if (netif_rx_schedule_prep(dev)) {
>     /*
>      * There's no point taking any more interrupts
>      * until we have processed the buffers
>      */
>         macb_writel(bp, IDR, MACB_RX_INT_FLAGS);
>         dev_dbg(&bp->pdev->dev, "scheduling RX softirq\n");
>         __netif_rx_schedule(dev);
>     } else {
>         printk(KERN_ERR "%s: Driver bug: interrupt while in polling mode\n", dev->name);
>         /* disable interrupts */
>         macb_writel(bp, IDR, MACB_RX_INT_FLAGS);
>     }
> }
> 
>>>From what I can tell of this function, it should only return false if
> polling is already enabled for the interface (though I haven't looked
> much deeper than the inline for netif_rx_schedule_prep()).
> 
> I went through the poll function, and actually rewrote the whole thing
> according to the guidelines in the NAPI documentation, and I can't see
> anyway for it to get out of poll with interrupts enabled without first
> removing itself from the polling list.
> 
> Can someone who knows more about this give me some more insight into
> what might be happening here? I can post the poll function or a patch to
> macb.c if it would be helpful.

I looked at macb.c and can see that it uses napi only for rx work, 
leaving tx interrupts enabled at all times. The interrupt handler reads 
the device interrupt status when a tx interrupt happens and may find rx 
bits also set. As a result, your netif_rx_schedule_prep() will sometimes 
return false because napi might be already scheduled. The code you have 
above (i.e. the "driver bug" case) is wrong.

The napi code in the in-tree version looks suspect because it seems to 
enable rx interrupts unconditionally regardless of whether napi rx 
processing is complete.

It might help to post a patch here showing all of your changes.


-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

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