netdev - Re: [PATCH] net: Fix race condition on receive path.

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] [day] [month] [year] [list]

Message-ID: <20100305154812.55a59038@nehalam>
Date:	Fri, 5 Mar 2010 15:48:12 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Daniel Walker <dwalker@...eaurora.org>
Cc:	"Harford, Jim" <c_jharfo@...cinc.com>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Smith, Alan" <agsmith@...cinc.com>
Subject: Re: [PATCH] net: Fix race condition on receive path.

On Fri, 05 Mar 2010 15:44:27 -0800
Daniel Walker <dwalker@...eaurora.org> wrote:

> On Fri, 2010-03-05 at 15:41 -0800, Harford, Jim wrote:
> > It appears that this patch is no longer necessary.  It was made against 2.6.29, but I see that more recent kernel versions don't have the problem code.  For a more detailed explanation, see below.  All code references are in routine process_backlog(), file net/core/dev.c.
> > 
> > In kernel version 2.6.27.45, __napi_complete() is invoked BEFORE interrupts are re-enabled.  Thus, the receive queue status is cleaned up before another interrupt (due to a receive packet) can occur.  This is good design.
> > 
> > In kernel version 2.6.29, git commit ID 303c6a025 inverts this ordering.  Routine napi_complete() is invoked AFTER interrupts are re-enabled.  We observed interrupts taken after interrupts were re-enabled, but before napi_complete cleaned up the receive queue.  This would then shut down the processing of subsequent received packets.
> > 
> > In kernel versions 2.6.30.10 and later, the sequence of operations is identical to 2.6.27.45, so there is no problem.
> > 
> > Jim Harford
> > Qualcomm Innovation Center
> 
> Ok, I guess we can ignore this one then.
> 
> Daniel
> 

It was fixed by:

commit 8f1ead2d1a626ed0c85b3d2c2046a49081d5933f
Author: Herbert Xu <herbert@...dor.apana.org.au>
Date:   Thu Mar 26 00:59:10 2009 -0700

    GRO: Disable GRO on legacy netif_rx path
    
    When I fixed the GRO crash in the legacy receive path I used
    napi_complete to replace __napi_complete.  Unfortunately they're
    not the same when NETPOLL is enabled, which may result in us
    not calling __napi_complete at all.
    
    What's more, we really do need to keep the __napi_complete call
    within the IRQ-off section since in theory an IRQ can occur in
    between and fill up the backlog to the maximum, causing us to
    lock up.
    
    Since we can't seem to find a fix that works properly right now,
    this patch reverts all the GRO support from the netif_rx path.
    
    Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
    Signed-off-by: David S. Miller <davem@...emloft.net>
--
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