* Re: [Intel-wired-lan] [PATCH V3 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers
From: Jeff Kirsher @ 2016-10-17 22:48 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Alexander Duyck, Duyck, Alexander H, Netdev, intel-wired-lan
In-Reply-To: <20161017224702.GA17588@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Mon, 2016-10-17 at 18:47 -0400, Sowmini Varadhan wrote:
> On (10/17/16 15:37), Jeff Kirsher wrote:
> > > Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
> >
> > Sowmini, can you re-submit this to intel-wired-lan but without the RFC
> in
> > the title?
>
> V4 resubmitted.. I think I just inadvertently forgot to add Alex as the
> reviewed-by.. could you please fix that (or I can resubmit v5 if needed).
No need to resubmit, I can make sure Alex's reviewed-by gets added.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH V3 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers
From: Sowmini Varadhan @ 2016-10-17 22:47 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Alexander Duyck, Duyck, Alexander H, Netdev, intel-wired-lan
In-Reply-To: <1476743871.2326.52.camel@intel.com>
On (10/17/16 15:37), Jeff Kirsher wrote:
> > Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
>
> Sowmini, can you re-submit this to intel-wired-lan but without the RFC in
> the title?
V4 resubmitted.. I think I just inadvertently forgot to add Alex as the
reviewed-by.. could you please fix that (or I can resubmit v5 if needed).
--Sowmini
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH V3 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers
From: Jeff Kirsher @ 2016-10-17 22:37 UTC (permalink / raw)
To: Alexander Duyck, Sowmini Varadhan
Cc: Duyck, Alexander H, Netdev, intel-wired-lan
In-Reply-To: <CAKgT0Ue7HL4CWdF2jBzLYOqXuO2=J9GeF79qfcdOWB7+cA0_3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Mon, 2016-10-17 at 15:29 -0700, Alexander Duyck wrote:
> On Mon, Oct 17, 2016 at 2:12 PM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> >
> > For some Tx paths (e.g., tpacket_snd()), ixgbe_atr may be
> > passed down an sk_buff that has the network and transport
> > header in the paged data, so it needs to make sure these
> > headers are available in the headlen bytes to calculate the
> > l4_proto.
> >
> > This patch expect that network and transport headers are
> > already available in the non-paged header dat. The assumption
> > is that the caller has set this up if l4_proto based Tx
> > steering is desired.
> >
> > Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
>
> This all looks correct to me. I would recommend having Jeff pull it
> in to be submitted to the net queue.
>
> Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
Sowmini, can you re-submit this to intel-wired-lan but without the RFC in
the title?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH V3 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers
From: Alexander Duyck @ 2016-10-17 22:29 UTC (permalink / raw)
To: Sowmini Varadhan, Jeff Kirsher
Cc: Duyck, Alexander H, Netdev, intel-wired-lan
In-Reply-To: <07bf787b2a346e12ca6e57edaf1a3025de9ae5dc.1476737917.git.sowmini.varadhan@oracle.com>
On Mon, Oct 17, 2016 at 2:12 PM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> For some Tx paths (e.g., tpacket_snd()), ixgbe_atr may be
> passed down an sk_buff that has the network and transport
> header in the paged data, so it needs to make sure these
> headers are available in the headlen bytes to calculate the
> l4_proto.
>
> This patch expect that network and transport headers are
> already available in the non-paged header dat. The assumption
> is that the caller has set this up if l4_proto based Tx
> steering is desired.
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
This all looks correct to me. I would recommend having Jeff pull it
in to be submitted to the net queue.
Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
^ permalink raw reply
* [PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning
From: Arnd Bergmann @ 2016-10-17 22:19 UTC (permalink / raw)
To: Linus Torvalds, Michal Marek
Cc: Nicolas Pitre, Greg Kroah-Hartman, Heiko Carstens, dri-devel,
linux-mtd, Ingo Molnar, linux-s390, Herbert Xu, x86,
Christian Borntraeger, Ilya Dryomov, linux-ext4, linux-media,
Kees Cook, Arnd Bergmann, linux-kbuild, Josh Poimboeuf,
ceph-devel, Mauro Carvalho Chehab, linux-snps-arc, netdev,
linux-kernel, linux-f2fs-devel, netfilter-devel, linux-crypto,
Vineet Gupta
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].
Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.
With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.
However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that
I had not addressed until then. This caused a lot of actual bugs to
get merged into mainline, and I sent several dozen patches for these
during the v4.9 development cycle. Most of these are actual bugs,
some are for correct code that is safe because it is only called
under external constraints that make it impossible to run into
the case that gcc sees, and in a few cases gcc is just stupid and
finds something that can obviously never happen.
I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got
(I can provide the combined patch for the other warnings if anyone
is interested), so I hope we can get the warning back and let people
catch the actual bugs earlier.
Note that the majority of the patches I created are for the third kind
of problem (stupid false-positives), for one of two reasons:
- some of them only get triggered in certain combinations of config
options, so we don't always run into them, and
- the actual bugs tend to get addressed much quicker as they also
lead to incorrect runtime behavior.
These 27 patches address the warnings that either occur in one of the more
common configurations (defconfig, allmodconfig, or something built by the
kbuild robot or kernelci.org), or they are about a real bug. It would be
good to get these all into v4.9 if we want to turn on the warning again.
I have tested these extensively with gcc-4.9 and gcc-6 and done a bit
of testing with gcc-5, and all of these should now be fine. gcc-4.8
is much worse about the false-positive warnings and is also fairly old
now, so I'm leaving the warning disabled with that version. gcc-4.7 and
older don't understand the -Wno-maybe-uninitialized option and are not
affected by this patch either way.
I have another (smaller) series of patches for warnings that are both
harmless and not as easy to trigger, and I will send them for inclusion
in v4.10.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Makefile | 10 ++++++----
arch/arc/Makefile | 4 +++-
scripts/Makefile.ubsan | 4 ++++
3 files changed, 13 insertions(+), 5 deletions(-)
Cc: x86@kernel.org
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-mtd@lists.infradead.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: ceph-devel@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: linux-ext4@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
diff --git a/Makefile b/Makefile
index 512e47a..43cd3d9 100644
--- a/Makefile
+++ b/Makefile
@@ -370,7 +370,7 @@ LDFLAGS_MODULE =
CFLAGS_KERNEL =
AFLAGS_KERNEL =
LDFLAGS_vmlinux =
-CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im
+CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
@@ -620,7 +620,6 @@ ARCH_CFLAGS :=
include arch/$(SRCARCH)/Makefile
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
-KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
@@ -629,15 +628,18 @@ KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
endif
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS += -Os
+KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
else
ifdef CONFIG_PROFILE_ALL_BRANCHES
-KBUILD_CFLAGS += -O2
+KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,)
else
KBUILD_CFLAGS += -O2
endif
endif
+KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
+ $(call cc-disable-warning,maybe-uninitialized,))
+
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index aa82d13..19cce22 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -71,7 +71,9 @@ cflags-$(CONFIG_ARC_DW2_UNWIND) += -fasynchronous-unwind-tables $(cfi)
ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
# Generic build system uses -O2, we want -O3
# Note: No need to add to cflags-y as that happens anyways
-ARCH_CFLAGS += -O3
+#
+# Disable the false maybe-uninitialized warings gcc spits out at -O3
+ARCH_CFLAGS += -O3 $(call cc-disable-warning,maybe-uninitialized,)
endif
# small data is default for elf32 tool-chain. If not usable, disable it
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index dd779c4..3b1b138 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -17,4 +17,8 @@ endif
ifdef CONFIG_UBSAN_NULL
CFLAGS_UBSAN += $(call cc-option, -fsanitize=null)
endif
+
+ # -fsanitize=* options makes GCC less smart than usual and
+ # increase number of 'maybe-uninitialized false-positives
+ CFLAGS_UBSAN += $(call cc-option, -Wno-maybe-uninitialized)
endif
--
2.9.0
^ permalink raw reply related
* [PATCH 20/28] net: bcm63xx: avoid referencing uninitialized variable
From: Arnd Bergmann @ 2016-10-17 22:16 UTC (permalink / raw)
To: David S. Miller
Cc: Linus Torvalds, linux-kernel, Arnd Bergmann, Philippe Reynes,
Florian Fainelli, bcm-kernel-feedback-list, Andrew Lunn, netdev,
linux-arm-kernel
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
gcc found a reference to an uninitialized variable in the error handling
of bcm_enet_open, introduced by a recent cleanup:
drivers/net/ethernet/broadcom/bcm63xx_enet.c: In function 'bcm_enet_open'
drivers/net/ethernet/broadcom/bcm63xx_enet.c:1129:2: warning: 'phydev' may be used uninitialized in this function [-Wmaybe-uninitialized]
This makes the use of that variable conditional, so we only reference it
here after it has been used before. Unlike my normal patches, I have not
build-tested this one, as I don't currently have mips test in my
randconfig setup.
Fixes: 625eb8667d6f ("net: ethernet: broadcom: bcm63xx: use phydev from struct net_device")
Cc: Philippe Reynes <tremyfr@gmail.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index ae364c7..5370909 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1126,7 +1126,8 @@ static int bcm_enet_open(struct net_device *dev)
free_irq(dev->irq, dev);
out_phy_disconnect:
- phy_disconnect(phydev);
+ if (priv->has_phy)
+ phy_disconnect(phydev);
return ret;
}
--
2.9.0
^ permalink raw reply related
* [PATCH 27/28] rocker: fix maybe-uninitialized warning
From: Arnd Bergmann @ 2016-10-17 22:16 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linus Torvalds, linux-kernel, Arnd Bergmann, David S. Miller,
Ido Schimmel, Dan Carpenter, netdev
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
In some rare configurations, we get a warning about the 'index' variable
being used without an initialization:
drivers/net/ethernet/rocker/rocker_ofdpa.c: In function ‘ofdpa_port_fib_ipv4.isra.16.constprop’:
drivers/net/ethernet/rocker/rocker_ofdpa.c:2425:92: warning: ‘index’ may be used uninitialized in this function [-Wmaybe-uninitialized]
This is a false positive, the logic is just a bit too complex for gcc
to follow here. Moving the intialization of 'index' a little further
down makes it clear to gcc that the function always returns an error
if it is not initialized.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
index 431a608..4ca4613 100644
--- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
+++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
@@ -1493,8 +1493,6 @@ static int ofdpa_port_ipv4_nh(struct ofdpa_port *ofdpa_port,
spin_lock_irqsave(&ofdpa->neigh_tbl_lock, lock_flags);
found = ofdpa_neigh_tbl_find(ofdpa, ip_addr);
- if (found)
- *index = found->index;
updating = found && adding;
removing = found && !adding;
@@ -1508,9 +1506,11 @@ static int ofdpa_port_ipv4_nh(struct ofdpa_port *ofdpa_port,
resolved = false;
} else if (removing) {
ofdpa_neigh_del(trans, found);
+ *index = found->index;
} else if (updating) {
ofdpa_neigh_update(found, trans, NULL, false);
resolved = !is_zero_ether_addr(found->eth_dst);
+ *index = found->index;
} else {
err = -ENOENT;
}
--
2.9.0
^ permalink raw reply related
* [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Arnd Bergmann @ 2016-10-17 22:13 UTC (permalink / raw)
To: Arend van Spriel
Cc: Linus Torvalds, linux-kernel, Arnd Bergmann, Hante Meuleman,
Kalle Valo, Franky Lin, Pieter-Paul Giesberts,
Franky (Zhenhui) Lin, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
A bugfix added a sanity check around the assignment and use of the
'is_11d' variable, which looks correct to me, but as the function is
rather complex already, this confuses the compiler to the point where
it can no longer figure out if the variable is always initialized
correctly:
brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
This adds an initialization for the newly introduced case in which
the variable should not really be used, in order to make the warning
go away.
Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
Cc: Hante Meuleman <hante.meuleman@broadcom.com>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..78d9966 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4516,7 +4516,7 @@ brcmf_cfg80211_start_ap(struct wiphy *wiphy, struct net_device *ndev,
/* store current 11d setting */
if (brcmf_fil_cmd_int_get(ifp, BRCMF_C_GET_REGULATORY,
&ifp->vif->is_11d)) {
- supports_11d = false;
+ is_11d = supports_11d = false;
} else {
country_ie = brcmf_parse_tlvs((u8 *)settings->beacon.tail,
settings->beacon.tail_len,
--
2.9.0
^ permalink raw reply related
* [PATCH 21/28] net/hyperv: avoid uninitialized variable
From: Arnd Bergmann @ 2016-10-17 22:16 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang
Cc: Arnd Bergmann, netdev, linux-kernel, devel, Linus Torvalds,
David S. Miller
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
The hdr_offset variable is only if we deal with a TCP or UDP packet,
but as the check surrounding its usage tests for skb_is_gso()
instead, the compiler has no idea if the variable is initialized
or not at that point:
drivers/net/hyperv/netvsc_drv.c: In function ‘netvsc_start_xmit’:
drivers/net/hyperv/netvsc_drv.c:494:42: error: ‘hdr_offset’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
This adds an additional check for the transport type, which
tells the compiler that this path cannot happen. Since the
get_net_transport_info() function should always be inlined
here, I don't expect this to result in additional runtime
checks.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/hyperv/netvsc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index f0919bd..5d6e75a 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -447,7 +447,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
* Setup the sendside checksum offload only if this is not a
* GSO packet.
*/
- if (skb_is_gso(skb)) {
+ if ((net_trans_info & (INFO_TCP | INFO_UDP)) && skb_is_gso(skb)) {
struct ndis_tcp_lso_info *lso_info;
rndis_msg_size += NDIS_LSO_PPI_SIZE;
--
2.9.0
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply related
* [PATCH 01/28] [v2] netfilter: nf_tables: avoid uninitialized variable warning
From: Arnd Bergmann @ 2016-10-17 22:05 UTC (permalink / raw)
To: Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
Cc: Linus Torvalds, linux-kernel, Arnd Bergmann, netfilter-devel,
coreteam, netdev
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
The newly added nft_range_eval() function handles the two possible
nft range operations, but as the compiler warning points out,
any unexpected value would lead to the 'mismatch' variable being
used without being initialized:
net/netfilter/nft_range.c: In function 'nft_range_eval':
net/netfilter/nft_range.c:45:5: error: 'mismatch' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This removes the variable in question and instead moves the
condition into the switch itself, which is potentially more
efficient than adding a bogus 'default' clause as in my
first approach, and is nicer than using the 'uninitialized_var'
macro.
Fixes: 0f3cd9b36977 ("netfilter: nf_tables: add range expression")
Link: http://patchwork.ozlabs.org/patch/677114/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/netfilter/nft_range.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
diff --git a/net/netfilter/nft_range.c b/net/netfilter/nft_range.c
index c6d5358..2dd80f4 100644
--- a/net/netfilter/nft_range.c
+++ b/net/netfilter/nft_range.c
@@ -28,22 +28,20 @@ static void nft_range_eval(const struct nft_expr *expr,
const struct nft_pktinfo *pkt)
{
const struct nft_range_expr *priv = nft_expr_priv(expr);
- bool mismatch;
int d1, d2;
d1 = memcmp(®s->data[priv->sreg], &priv->data_from, priv->len);
d2 = memcmp(®s->data[priv->sreg], &priv->data_to, priv->len);
switch (priv->op) {
case NFT_RANGE_EQ:
- mismatch = (d1 < 0 || d2 > 0);
+ if (d1 < 0 || d2 > 0)
+ regs->verdict.code = NFT_BREAK;
break;
case NFT_RANGE_NEQ:
- mismatch = (d1 >= 0 && d2 <= 0);
+ if (d1 >= 0 && d2 <= 0)
+ regs->verdict.code = NFT_BREAK;
break;
}
-
- if (mismatch)
- regs->verdict.code = NFT_BREAK;
}
static const struct nla_policy nft_range_policy[NFTA_RANGE_MAX + 1] = {
--
2.9.0
^ permalink raw reply related
* [PATCH 00/28] Reenable maybe-uninitialized warnings
From: Arnd Bergmann @ 2016-10-17 22:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-s390, linux-ext4, Herbert Xu, Arnd Bergmann, netdev, x86,
ceph-devel, linux-kernel, dri-devel, linux-f2fs-devel, linux-mtd,
linux-crypto, Greg Kroah-Hartman, Martin Schwidefsky,
netfilter-devel, Ilya Dryomov, Mauro Carvalho Chehab,
David S. Miller, linux-media
This is a set of patches that I hope to get into v4.9 in some form
in order to turn on the -Wmaybe-uninitialized warnings again.
After talking to Linus in person at Linaro Connect about this, I
spent some time on finding all the remaining warnings, and this
is the resulting patch series. More details are in the description
of the last patch that actually enables the warning.
Let me know if there are other warnings that I missed, and whether
you think these are still appropriate for v4.9 or not.
A couple of patches are non-obvious, and could use some more
detailed review.
Arnd
Arnd Bergmann (28):
[v2] netfilter: nf_tables: avoid uninitialized variable warning
[v2] mtd: mtk: avoid warning in mtk_ecc_encode
[v2] infiniband: shut up a maybe-uninitialized warning
f2fs: replace a build-time warning with runtime WARN_ON
ext2: avoid bogus -Wmaybe-uninitialized warning
NFSv4.1: work around -Wmaybe-uninitialized warning
ceph: avoid false positive maybe-uninitialized warning
staging: lustre: restore initialization of return code
staging: lustre: remove broken dead code in
cfs_cpt_table_create_pattern
UBI: fix uninitialized access of vid_hdr pointer
block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized
[media] rc: print correct variable for z8f0811
[media] dib0700: fix uninitialized data on 'repeat' event
iio: accel: sca3000_core: avoid potentially uninitialized variable
crypto: aesni: avoid -Wmaybe-uninitialized warning
pcmcia: fix return value of soc_pcmcia_regulator_set
spi: fsl-espi: avoid processing uninitalized data on error
drm: avoid uninitialized timestamp use in wait_vblank
brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
net: bcm63xx: avoid referencing uninitialized variable
net/hyperv: avoid uninitialized variable
x86: apm: avoid uninitialized data
x86: mark target address as output in 'insb' asm
x86: math-emu: possible uninitialized variable use
s390: pci: don't print uninitialized data for debugging
nios2: fix timer initcall return value
rocker: fix maybe-uninitialized warning
Kbuild: bring back -Wmaybe-uninitialized warning
Makefile | 10 +-
arch/arc/Makefile | 4 +-
arch/nios2/kernel/time.c | 1 +
arch/s390/pci/pci_dma.c | 2 +-
arch/x86/crypto/aesni-intel_glue.c | 121 +++++++++++++--------
arch/x86/include/asm/io.h | 4 +-
arch/x86/kernel/apm_32.c | 5 +-
arch/x86/math-emu/Makefile | 4 +-
arch/x86/math-emu/reg_compare.c | 16 +--
drivers/block/rbd.c | 1 +
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/infiniband/core/cma.c | 56 +++++-----
drivers/media/i2c/ir-kbd-i2c.c | 2 +-
drivers/media/usb/dvb-usb/dib0700_core.c | 10 +-
drivers/mtd/nand/mtk_ecc.c | 19 ++--
drivers/mtd/ubi/eba.c | 2 +-
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 3 +-
drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 +-
drivers/net/hyperv/netvsc_drv.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
drivers/pcmcia/soc_common.c | 2 +-
drivers/spi/spi-fsl-espi.c | 2 +-
drivers/staging/iio/accel/sca3000_core.c | 2 +
.../staging/lustre/lnet/libcfs/linux/linux-cpu.c | 7 --
drivers/staging/lustre/lustre/lov/lov_pack.c | 2 +
fs/ceph/super.c | 3 +-
fs/ext2/inode.c | 7 +-
fs/f2fs/data.c | 7 ++
fs/nfs/nfs4session.c | 10 +-
net/netfilter/nft_range.c | 10 +-
scripts/Makefile.ubsan | 4 +
31 files changed, 187 insertions(+), 141 deletions(-)
--
Cc: x86@kernel.org
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-mtd@lists.infradead.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: ceph-devel@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: linux-ext4@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
2.9.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH net] soreuseport: do not export reuseport_add_sock()
From: Eric Dumazet @ 2016-10-17 21:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
reuseport_add_sock() is not used from a module,
no need to export it.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/sock_reuseport.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c
index e92b759d906c..9a1a352fd1eb 100644
--- a/net/core/sock_reuseport.c
+++ b/net/core/sock_reuseport.c
@@ -129,7 +129,6 @@ int reuseport_add_sock(struct sock *sk, struct sock *sk2)
return 0;
}
-EXPORT_SYMBOL(reuseport_add_sock);
static void reuseport_free_rcu(struct rcu_head *head)
{
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH V2 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers
From: Sowmini Varadhan @ 2016-10-17 21:16 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Duyck, Alexander H, Netdev, intel-wired-lan
In-Reply-To: <CAKgT0UcGy_fD6HYxfzO_xoWOcB+Cjf38Qon8ZdWxyTNtzP7-=Q@mail.gmail.com>
On (10/17/16 12:49), Alexander Duyck wrote:
> >> > /* Currently only IPv4/IPv6 with TCP is supported */
> >> > switch (hdr.ipv4->version) {
> >> > case IPVERSION:
> >> > /* access ihl as u8 to avoid unaligned access on ia64 */
> >> > hlen = (hdr.network[0] & 0x0F) << 2;
> >> > + if (skb_tail_pointer(skb) < hdr.network + hlen +
> >> > + sizeof(struct tcphdr))
> >> > + return;
> >> > l4_proto = hdr.ipv4->protocol;
> >> > break;
> >> > case 6:
> >> > hlen = hdr.network - skb->data;
> >> > + if (skb_tail_pointer(skb) < hdr.network + hlen +
> >> > + sizeof(struct tcphdr))
> >> > + return;
> >> > l4_proto = ipv6_find_hdr(skb, &hlen, IPPROTO_TCP, NULL, NULL);
> >> > hlen -= hdr.network - skb->data;
> >> > break;
:
> >> So you probably need to add a check for "skb_tail_pointer(skb) <
> >> (hdr.network + hlen + 20)".
> >
> > But isnt that the same thing as the checks before l4_proto computation above?
>
> Sort of. The problem is IPv6 can include extension headers and that
> can totally mess with us. So we need to do one more check to verify
> that we have enough space for IPv6 w/ TCP which would be hdr.raw + 20
> + hlenl.
Yes, you are right. So given that I already check that I have
at least 40 bytes past the network header, and ipv6_find_hdr
will pull up exthdrs as needed, my checks are not needed, and the
real ones should happen after we come out of that switch().
--Sowmini
^ permalink raw reply
* [PATCH V3 RFC 2/2] ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has network/transport headers
From: Sowmini Varadhan @ 2016-10-17 21:12 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, intel-wired-lan, Sowmini Varadhan
In-Reply-To: <cover.1476737917.git.sowmini.varadhan@oracle.com>
For some Tx paths (e.g., tpacket_snd()), ixgbe_atr may be
passed down an sk_buff that has the network and transport
header in the paged data, so it needs to make sure these
headers are available in the headlen bytes to calculate the
l4_proto.
This patch expect that network and transport headers are
already available in the non-paged header dat. The assumption
is that the caller has set this up if l4_proto based Tx
steering is desired.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
v3: add unlikely(); remove needless check for hdr.network against
skb_tail_pointer(); refactor check to make sure we have tcp header
in non-paged part.
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index eceb47b..a9d2b0c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -54,6 +54,7 @@
#include <net/pkt_cls.h>
#include <net/tc_act/tc_gact.h>
#include <net/tc_act/tc_mirred.h>
+#include <net/vxlan.h>
#include "ixgbe.h"
#include "ixgbe_common.h"
@@ -7651,11 +7652,17 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
/* snag network header to get L4 type and address */
skb = first->skb;
hdr.network = skb_network_header(skb);
+ if (unlikely(hdr.network <= skb->data))
+ return;
if (skb->encapsulation &&
first->protocol == htons(ETH_P_IP) &&
hdr.ipv4->protocol == IPPROTO_UDP) {
struct ixgbe_adapter *adapter = q_vector->adapter;
+ if (unlikely(skb_tail_pointer(skb) < hdr.network +
+ VXLAN_HEADROOM))
+ return;
+
/* verify the port is recognized as VXLAN */
if (adapter->vxlan_port &&
udp_hdr(skb)->dest == adapter->vxlan_port)
@@ -7666,6 +7673,12 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
hdr.network = skb_inner_network_header(skb);
}
+ /* Make sure we have at least [minimum IPv4 header + TCP]
+ * or [IPv6 header] bytes
+ */
+ if (unlikely(skb_tail_pointer(skb) < hdr.network + 40))
+ return;
+
/* Currently only IPv4/IPv6 with TCP is supported */
switch (hdr.ipv4->version) {
case IPVERSION:
@@ -7685,6 +7698,10 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
if (l4_proto != IPPROTO_TCP)
return;
+ if (unlikely(skb_tail_pointer(skb) < hdr.network +
+ hlen + sizeof(struct tcphdr)))
+ return;
+
th = (struct tcphdr *)(hdr.network + hlen);
/* skip this packet since the socket is closing */
--
1.7.1
^ permalink raw reply related
* [PATCH v3 RFC 0/2] ixgbe: ixgbe_atr() bug fixes
From: Sowmini Varadhan @ 2016-10-17 21:12 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, intel-wired-lan, Sowmini Varadhan
Two bug fixes:
- ixgbe_atr() should check for protocol == udp in the
skb->encapsulation case (instead of !=)
- ixgbe_atr() should make sure the non-paged data has the
needed network/transport header for computing l4_proto.
v3: Alex Duyck comments
Sowmini Varadhan (2):
ixgbe: ixgbe_atr() should access udp_hdr(skb) only for UDP packets
ixgbe: ixgbe_atr() compute l4_proto only if non-paged data has
network/transport headers
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH V3 RFC 1/2] ixgbe: ixgbe_atr() should access udp_hdr(skb) only for UDP packets
From: Sowmini Varadhan @ 2016-10-17 21:12 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, intel-wired-lan, Sowmini Varadhan
In-Reply-To: <cover.1476737917.git.sowmini.varadhan@oracle.com>
Commit 9f12df906cd8 ("ixgbe: Store VXLAN port number in network order")
incorrectly checks for hdr.ipv4->protocol != IPPROTO_UDP
in ixgbe_atr(). This check should be for "==" instead.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index a244d9a..eceb47b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7653,7 +7653,7 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
hdr.network = skb_network_header(skb);
if (skb->encapsulation &&
first->protocol == htons(ETH_P_IP) &&
- hdr.ipv4->protocol != IPPROTO_UDP) {
+ hdr.ipv4->protocol == IPPROTO_UDP) {
struct ixgbe_adapter *adapter = q_vector->adapter;
/* verify the port is recognized as VXLAN */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3 net v2] ibmvnic: Driver Version 1.0.1
From: Thomas Falcon @ 2016-10-17 20:56 UTC (permalink / raw)
To: netdev
Increment driver version to reflect features that have
been added since release.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
Sorry about the extra noise.
v2: revise version format to be consistent with other IBM virtual drivers
---
drivers/net/ethernet/ibm/ibmvnic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
index bfc84c7..d244e29 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -27,7 +27,7 @@
/**************************************************************************/
#define IBMVNIC_NAME "ibmvnic"
-#define IBMVNIC_DRIVER_VERSION "1.0"
+#define IBMVNIC_DRIVER_VERSION "1.0.1"
#define IBMVNIC_INVALID_MAP -1
#define IBMVNIC_STATS_TIMEOUT 1
/* basic structures plus 100 2k buffers */
--
2.7.4
^ permalink raw reply related
* Re: Need help with mdiobus_register and phy
From: Timur Tabi @ 2016-10-17 20:53 UTC (permalink / raw)
To: Zefir Kurtisi, Andrew Lunn; +Cc: Florian Fainelli, netdev
In-Reply-To: <7dced72e-c441-06d1-161d-3bccad34f2cd@neratec.com>
Zefir Kurtisi wrote:
> Anyway, since the SGMII reset is required, instead of reverting the patch in full
> I suggest to move the SGMII power down from at803x_suspend() and do a SerDes power
> cycle in at803x_resume(). Could you please test if the patch below fixes the problem?
I have never seen the original problem that you noticed. When I use the
generic phy driver instead of the at803x driver, everything works great
for me. Perhaps the problem that you noticed only occurs with the
Gianfar NIC?
Anyway, I tested the change you suggested, and it fixes the problem for
me. I moved the power-down code to before the power-up code. But like
I said, since I never experienced the original problem, I don't know if
that works for you.
I suggest you make the changes in the driver yourself and test it, and
then I will test whether that patch also works for me.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bpf: add initial suite for selftests
From: Alexei Starovoitov @ 2016-10-17 20:45 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <08cc05da80eda6abe3287c6d4876c31bb6107109.1476705709.git.daniel@iogearbox.net>
On Mon, Oct 17, 2016 at 02:28:36PM +0200, Daniel Borkmann wrote:
> Add a start of a test suite for kernel selftests. This moves test_verifier
> and test_maps over to tools/testing/selftests/bpf/ along with various
> code improvements and also adds a script for invoking test_bpf module.
> The test suite can simply be run via selftest framework, f.e.:
>
> # cd tools/testing/selftests/bpf/
> # make
> # make run_tests
>
> Both test_verifier and test_maps were kind of misplaced in samples/bpf/
> directory and we were looking into adding them to selftests for a while
> now, so it can be picked up by kbuild bot et al and hopefully also get
> more exposure and thus new test case additions.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 1/2] bpf: add various tests around spill/fill of regs
From: Alexei Starovoitov @ 2016-10-17 20:44 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <b116029a1133424fdec5ee54cc5bf91968a62463.1476705709.git.daniel@iogearbox.net>
On Mon, Oct 17, 2016 at 02:28:35PM +0200, Daniel Borkmann wrote:
> Add several spill/fill tests. Besides others, one that performs xadd
> on the spilled register, one ldx/stx test where different types are
> spilled from two branches and read out from common path. Verfier does
> handle all correctly.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH -next] net: wan: slic_ds26522: Remove .owner field for driver
From: Javier Martinez Canillas @ 2016-10-17 20:38 UTC (permalink / raw)
To: Wei Yongjun, Zhao Qiang; +Cc: Wei Yongjun, netdev
In-Reply-To: <1476715898-27808-1-git-send-email-weiyj.lk@gmail.com>
Hello Wei,
On 10/17/2016 11:51 AM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Remove .owner field if calls are used which set it automatically.
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/net/wan/slic_ds26522.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wan/slic_ds26522.c b/drivers/net/wan/slic_ds26522.c
> index b776a0a..5bca31c 100644
> --- a/drivers/net/wan/slic_ds26522.c
> +++ b/drivers/net/wan/slic_ds26522.c
> @@ -241,7 +241,6 @@ static struct spi_driver slic_ds26522_driver = {
> .driver = {
> .name = "ds26522",
> .bus = &spi_bus_type,
> - .owner = THIS_MODULE,
> .of_match_table = slic_ds26522_match,
> },
> .probe = slic_ds26522_probe,
>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH -next] net: wan: slic_ds26522: Use module_spi_driver to simplify the code
From: Javier Martinez Canillas @ 2016-10-17 20:38 UTC (permalink / raw)
To: Wei Yongjun, Zhao Qiang; +Cc: Wei Yongjun, netdev
In-Reply-To: <1476715845-27691-1-git-send-email-weiyj.lk@gmail.com>
Hello Wei,
On 10/17/2016 11:50 AM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> module_spi_driver() makes the code simpler by eliminating
> boilerplate code.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/net/wan/slic_ds26522.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/net/wan/slic_ds26522.c b/drivers/net/wan/slic_ds26522.c
> index b776a0a..8f782f1 100644
> --- a/drivers/net/wan/slic_ds26522.c
> +++ b/drivers/net/wan/slic_ds26522.c
> @@ -249,15 +249,4 @@ static struct spi_driver slic_ds26522_driver = {
> .id_table = slic_ds26522_id,
> };
>
> -static int __init slic_ds26522_init(void)
> -{
> - return spi_register_driver(&slic_ds26522_driver);
> -}
> -
> -static void __exit slic_ds26522_exit(void)
> -{
> - spi_unregister_driver(&slic_ds26522_driver);
> -}
> -
> -module_init(slic_ds26522_init);
> -module_exit(slic_ds26522_exit);
> +module_spi_driver(slic_ds26522_driver);
>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH net v2] flow_dissector: Check skb for VLAN only if skb specified.
From: Eric Garver @ 2016-10-17 20:30 UTC (permalink / raw)
To: netdev; +Cc: Hadar Hen Zion
Fixes a panic when calling eth_get_headlen(). Noticed on i40e driver.
Fixes: d5709f7ab776 ("flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci")
Signed-off-by: Eric Garver <e@erig.me>
---
net/core/flow_dissector.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1a7b80f73376..44e6ba9d3a6b 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -247,12 +247,10 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
case htons(ETH_P_8021Q): {
const struct vlan_hdr *vlan;
- if (skb_vlan_tag_present(skb))
+ if (skb && skb_vlan_tag_present(skb))
proto = skb->protocol;
- if (!skb_vlan_tag_present(skb) ||
- proto == cpu_to_be16(ETH_P_8021Q) ||
- proto == cpu_to_be16(ETH_P_8021AD)) {
+ if (eth_type_vlan(proto)) {
struct vlan_hdr _vlan;
vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net-next 00/15] ethernet: use core min/max MTU checking
From: Jarod Wilson @ 2016-10-17 20:29 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20161017.160341.529517225075047124.davem@davemloft.net>
On Mon, Oct 17, 2016 at 04:03:41PM -0400, David Miller wrote:
> From: Jarod Wilson <jarod@redhat.com>
> Date: Mon, 17 Oct 2016 15:54:02 -0400
>
> > For the most part, every patch does the same essential thing: removes the
> > MTU range checking from the drivers' ndo_change_mtu function, puts those
> > ranges into the core net_device min_mtu and max_mtu fields, and where
> > possible, removes ndo_change_mtu functions entirely.
>
> Jarod, please read my other posting.
Done, didn't see it until just after I'd hit send, have replied there as
well.
> You've positively broken the maximum MTU for all of these drivers.
>
> That's not cool.
>
> And this series fixing things doesn't make things better, because now
> we've significanyly broken bisection for anyone running into this
> regression.
Agreed, and my suggestion right now is to revert the 2nd patch from the
prior series. I believe it can be resubmitted after all other callers of
ether_setup() have been converted to have their own min/max_mtu.
> You should have arranged this in such a way that the drivers needing
> > 1500 byte MTU were not impacted at all by your changes, but that
> isn't what happened.
Yeah, I must admit to not looking closely enough at the state the first
two patches left things in. It was absolutely my intention to not alter
behaviour in any way, but I neglected to test sufficiently without this
additional set applied.
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* [PATCH 3/3 net] ibmvnic: Update MTU after device initialization
From: Thomas Falcon @ 2016-10-17 20:28 UTC (permalink / raw)
To: netdev
In-Reply-To: <1476736090-13588-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
It is possible for the MTU to be changed during the initialization
process with the VNIC Server. Ensure that the net device is updated
to reflect the new MTU.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 928bf8a..213162d 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3654,6 +3654,7 @@ static void handle_crq_init_rsp(struct work_struct *work)
goto task_failed;
netdev->real_num_tx_queues = adapter->req_tx_queues;
+ netdev->mtu = adapter->req_mtu;
if (adapter->failover) {
adapter->failover = false;
@@ -3792,6 +3793,7 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
}
netdev->real_num_tx_queues = adapter->req_tx_queues;
+ netdev->mtu = adapter->req_mtu;
rc = register_netdev(netdev);
if (rc) {
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox