netdev - Re: Hang: 2.6.32.4 sky2/DMAR (was [PATCH] sky2: Fix WARNING: at lib/dma-debug.c:902 check

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]

Message-ID: <20100127085049.5b5048e9@nehalam>
Date:	Wed, 27 Jan 2010 08:50:49 -0800
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Michael Breuer <mbreuer@...jas.com>
Cc:	Jarek Poplawski <jarkao2@...il.com>,
	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	flyboy@...il.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Michael Chan <mchan@...adcom.com>,
	Don Fry <pcnet32@...izon.net>,
	Francois Romieu <romieu@...zoreil.com>,
	Matt Carlson <mcarlson@...adcom.com>
Subject: Re: Hang: 2.6.32.4 sky2/DMAR (was [PATCH] sky2: Fix WARNING: at
 lib/dma-debug.c:902 check_sync)

On Wed, 27 Jan 2010 10:34:51 -0500
Michael Breuer <mbreuer@...jas.com> wrote:

> On 01/23/2010 06:21 PM, Jarek Poplawski wrote:
> > On Fri, Jan 22, 2010 at 06:50:21PM -0500, Michael Breuer wrote:
> >      
> >> When the packets were dropped, there was a different sequence in the
> >> log - DISCOVER/OFFER repeated. The "normal" is that the sequence
> >> appeared correct and complete - DISCOVER/OFFER/REQUEST/ACK - or
> >> INFORM/ACK (vs. INFORM repeatedly sans ACK) as the case may be.
> >>        
> > Anyway, I'd be intersted if the switch matters here.
> >
> > Plus one more test: could you try to load sky2 with the parameter:
> > "copybreak=1" (the rest as in any recent test, which gave you dmar
> > errors; any switch).
> >
> > Thanks,
> > Jarek P.
> >      
> Ok - now up 80+ hours with copybreak=1. I'm going to redo w/o copybreak 
> to confirm that I haven't inadvertently fixed something. However, given 
> that it might be copybreak-related, I looked at sky2.c again and I'm 
> wondering about the copybreak max size in sky2_rx_start:
> 
>    size = roundup(sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN, 8);
> 
>          /* Stopping point for hardware truncation */
>          thresh = (size - 8) / sizeof(u32);
> 
>          sky2->rx_nfrags = size >> PAGE_SHIFT;
>          BUG_ON(sky2->rx_nfrags > ARRAY_SIZE(re->frag_addr));
> 
>          /* Compute residue after pages */
>          size -= sky2->rx_nfrags << PAGE_SHIFT;
> 
>          /* Optimize to handle small packets and headers */
>          if (size < copybreak)
>                  size = copybreak;
>          if (size < ETH_HLEN)
>                  size = ETH_HLEN;
> 
> 
> Why would increasing size to copybreak be valid here?
> 
> Guessing a bit as I'm not sure about rx_nfrags, but if I read this 
> correctly, if size is ever less than copybreak it's because there isn't 
> enough space left for anything larger. If so, wouldn't increasing size 
> potentially corrupt something? I'd further guess that the resulting 
> condition manifests sooner (or at least with a more visible effect) when 
> using DMAR.
> 
> In any event, why "copybreak" as the minimum buffer size? I'd suggest 
> that if it isn't possible to allocate at least MTU + overhead that 
> sky2_rx_start ought to be delayed until there is room.

This code is where driver decides how much data will be received in skb
data area and the remaining data spills over into skb frags.
Copybreak is the threshold so that packets less than size are copied
to a new skb.  The code doing the copying there assumes the data is
totally contained in the skb (not in frags). The size increase there
is to make sure that assumption is always true.  I suppose you
could do something perverse like setting copybreak really huge 
and confuse driver, but that is a user error.


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