From patchwork Thu May 2 04:55:38 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 240892 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 8800A2C00B1 for ; Thu, 2 May 2013 14:56:02 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751804Ab3EBEzk (ORCPT ); Thu, 2 May 2013 00:55:40 -0400 Received: from mail-vc0-f177.google.com ([209.85.220.177]:35866 "EHLO mail-vc0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750809Ab3EBEzj convert rfc822-to-8bit (ORCPT ); Thu, 2 May 2013 00:55:39 -0400 Received: by mail-vc0-f177.google.com with SMTP id ha12so159417vcb.8 for ; Wed, 01 May 2013 21:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ScVPsmyWCJmoaRLI7SFGq7w+dskzGlrusyh1MDWIouA=; b=zRs+ldyns+NqjZ7gzmBvkXMpSYV2rTtUk3iKDQkkEkJnMt/iOi2u/v70xvkk6sEM/M lCnLqTXsOZvrUZjq/CBasnbN2kHjbhM03iKJfHQ5bRAFXB3MoKhaiFQ3GrlDnrwE8bWk 8Pq6/SqxJ6ng1uxunVsPlQOLeAZ7n1Llf/iBD2kPx/7/XOiEK+K674YtshhKfh5Gj1Ge GIJ62+L34euecUTBswzgEJjJim67z+bh9ESq7JRxGVan+FaxC4cWwFALkn6ZSNlBLoEj i+tPjUoaQ0I6t/Atf+f/Byu2yXWnZlwRld3g3Cj76T1dPNL/XJnwVVY3Dqpiu9R6nG4d zscg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ScVPsmyWCJmoaRLI7SFGq7w+dskzGlrusyh1MDWIouA=; b=iCYxLQd6Q+Y4X10UldMlmnxPndc4qYhuCij1aM9Lh2DzYDASN4i2C+eFH/I/fVmYEC Gn7q4S2CLd7gfEdt0aXc3TxKHqDnyy0cfwwWCkVx0ubDzDbVr08dwmjlQVhJC1OgReWi s/bPBMTAlb1I4yYff0qWag4UFNn8jlT4RNjSk= MIME-Version: 1.0 X-Received: by 10.58.144.170 with SMTP id sn10mr1686458veb.7.1367470538147; Wed, 01 May 2013 21:55:38 -0700 (PDT) Received: by 10.220.186.197 with HTTP; Wed, 1 May 2013 21:55:38 -0700 (PDT) In-Reply-To: References: <20130501.164755.1859264969403837546.davem@davemloft.net> Date: Wed, 1 May 2013 21:55:38 -0700 X-Google-Sender-Auth: YEeIiJyCXgf7BgvJSig66oFkzw4 Message-ID: Subject: Re: [GIT] Networking From: Linus Torvalds To: David Miller , hayeswang , Patrick McHardy Cc: Andrew Morton , Network Development , Linux Kernel Mailing List Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, May 1, 2013 at 9:37 PM, Linus Torvalds wrote: > > I don't see what could be broken in that commit, and I'd *like* to > just revert it on top of current -git, but that causes problems > ("error: ‘NETIF_F_HW_VLAN_STAG_TX_BIT’ undeclared"), so I can't just > do a straight revert to double-check with the current tree state. But > the bisection was very straightforward, and as mentioned, I checked > that boundary several times just because it looked so odd. Ok, this is just f*cking odd. So I first tried to revert commit 8ad227ff89a7 but leave the new *_HW_VLAN_STAG_* bit definitions in place so that it would compile without that error. That still resulted in a non-working network. So then I start getting desperate, and say to myself "maybe the bit positions matter". So do a full revert (so that those bits are no longer enumerated), and then to make things compile for me I comment out the uses I hit in my build: [NETIF_F_LLTX_BIT] = "tx-lockless", and guess what? I have working networking again. So either this is some very odd heisenbug (but quite frankly, it bisected perfectly, and reverting it *does* fix it with the above addition), or the bit positions for those NETIF constants matter. I think the positions of those bits matter, and adding NETIF_F_HW_VLAN_STAG_*_BIT randomly in the middle broke things. That's backed up by the fact that we have things like __UNUSED_NETIF_F_1 and /**/NETIF_F_GSO_SHIFT, /* keep the order of SKB_GSO_* bits */ NETIF_F_TSO_BIT /* ... TCPv4 segmentation */ = NETIF_F_GSO_SHIFT, in that array. There is some ordering, and there is some meaning to the bit numbers, and adding the *_STAG_* bits in the middle broke some subtle dependency. That's as far as I'm going to be able to debug this. I've pinpointed the commit, and I think I've pinpointed the approximate cause. Pls get my networking going again without my disgusting local hack.. Linus --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/core/ethtool.c b/net/core/ethtool.c index 5a934ef90f8b..df019a7ab51e 100644 --- a/net/core/ethtool.c +++ b/net/core/ethtool.c @@ -64,9 +64,11 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GST [NETIF_F_HW_VLAN_CTAG_RX_BIT] = "rx-vlan-ctag-hw-parse", [NETIF_F_HW_VLAN_CTAG_FILTER_BIT] = "rx-vlan-ctag-filter", +#if 0 [NETIF_F_HW_VLAN_STAG_TX_BIT] = "tx-vlan-stag-hw-insert", [NETIF_F_HW_VLAN_STAG_RX_BIT] = "rx-vlan-stag-hw-parse", [NETIF_F_HW_VLAN_STAG_FILTER_BIT] = "rx-vlan-stag-filter", +#endif [NETIF_F_VLAN_CHALLENGED_BIT] = "vlan-challenged", [NETIF_F_GSO_BIT] = "tx-generic-segmentation",