* Re: [pull request][net-next 0/5] Mellanox, mlx5 updates 2017-04-22
From: David Miller @ 2017-04-24 18:11 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, roid, stephen
In-Reply-To: <20170422184507.26569-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sat, 22 Apr 2017 21:45:02 +0300
> This series contains some updates to mlx5 driver.
>
> Sparse and compiler warnings fixes from Stephen Hemminger.
>
> From Roi Dayan and Or Gerlitz, Add devlink and mlx5 support for controlling
> E-Switch encapsulation mode, this knob will enable HW support for applying
> encapsulation/decapsulation to VF traffic as part of SRIOV e-switch offloading.
>
> Please pull and let me know if there's any problem.
Applied, thank you.
^ permalink raw reply
* Re: cpsw regression in mainline with "cpsw/netcp: cpts depends on posix_timers"
From: Arnd Bergmann @ 2017-04-24 18:12 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Grygorii Strashko, Networking, linux-omap
In-Reply-To: <20170424174413.GD3780@atomide.com>
On Mon, Apr 24, 2017 at 7:44 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Arnd Bergmann <arnd@arndb.de> [170424 10:38]:
>> On Mon, Apr 24, 2017 at 6:51 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > Hi,
>> >
>> > Looks like commit 07fef3623407 ("cpsw/netcp: cpts depends on posix_timers")
>> > in mainline started triggering the following oops at least on j5eco-evm.
>> >
>> > Adding CONFIG_PTP_1588_CLOCK to .config solves it, but the oops hints
>> > something is wrong with the dependencies.. CONFIG_TI_CPTS defaults to N
>> > and not selecting it causes the oops.
>> >
>> > Any ideas what's needed to properly fix this?
>>
>> Does your configuration have POSIX_TIMERS enabled? If not, then CPTS
>> is now also disabled. There are two issues here that we need to solve:
>>
>> a) find out why POSIX_TIMERS got disabled, and make sure it's always
>> turned on for normal users
>
> $ make omap2plus_defconfig
> ...
> CONFIG_POSIX_TIMERS=y
> # CONFIG_PTP_1588_CLOCK is not set
>
> So CONFIG_TI_CPTS is unselectable.
Ok, so at least this one is easy to understand, it's a direct consequence
of my change, as nothing else will select CONFIG_PTP_1588_CLOCK
now.
My first try would be this one:
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 9e631952b86f..8042a7626056 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -76,7 +76,7 @@ config TI_CPSW
config TI_CPTS
bool "TI Common Platform Time Sync (CPTS) Support"
depends on TI_CPSW || TI_KEYSTONE_NETCP
- depends on PTP_1588_CLOCK
+ depends on POSIX_TIMERS
---help---
This driver supports the Common Platform Time Sync unit of
the CPSW Ethernet Switch and Keystone 2 1g/10g Switch Subsystem.
@@ -87,6 +87,7 @@ config TI_CPTS_MOD
tristate
depends on TI_CPTS
default y if TI_CPSW=y || TI_KEYSTONE_NETCP=y
+ imply PTP_1588_CLOCK
default m
config TI_KEYSTONE_NETCP
>> b) find out what's wrong with the driver when CPTS is disabled. This would
>> be an existing problem that you just never saw because CPTS was
>> always enabled so far.
>
> See a) above, yes seems there are two problems here.
Ok.
Arnd
^ permalink raw reply related
* Re: PATCH drivers:net:cris/eth_v10: alternate string char arrary
From: David Miller @ 2017-04-24 18:18 UTC (permalink / raw)
To: karim.eshapa
Cc: felipe.balbi, paul.gortmaker, mugunthanvnm, jarod, fw, netdev,
linux-kernel
In-Reply-To: <1493056179-6460-1-git-send-email-karim.eshapa@gmail.com>
From: Karim Eshapa <karim.eshapa@gmail.com>
Date: Mon, 24 Apr 2017 19:49:39 +0200
> static char pointer creates two variables in final assembly.
> static string and pointer to it according to
> Jeff Garzik janitors TODO.
>
> Signed-off-by: Karim Eshapa <karim.eshapa@gmail.com>
Instead of trusting some document written more than 10 years ago on
the internet, why don't you build the source file in question and take
a look at what actually happens?
I'm not applying this, sorry.
^ permalink raw reply
* Re: cpsw regression in mainline with "cpsw/netcp: cpts depends on posix_timers"
From: Tony Lindgren @ 2017-04-24 18:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Grygorii Strashko, Networking, linux-omap
In-Reply-To: <CAK8P3a2ybR29txotehP5uKtstucxW_ZYZXArMroSEbmV=Y--7A@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [170424 11:14]:
> On Mon, Apr 24, 2017 at 7:44 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Arnd Bergmann <arnd@arndb.de> [170424 10:38]:
> >> On Mon, Apr 24, 2017 at 6:51 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Hi,
> >> >
> >> > Looks like commit 07fef3623407 ("cpsw/netcp: cpts depends on posix_timers")
> >> > in mainline started triggering the following oops at least on j5eco-evm.
> >> >
> >> > Adding CONFIG_PTP_1588_CLOCK to .config solves it, but the oops hints
> >> > something is wrong with the dependencies.. CONFIG_TI_CPTS defaults to N
> >> > and not selecting it causes the oops.
> >> >
> >> > Any ideas what's needed to properly fix this?
> >>
> >> Does your configuration have POSIX_TIMERS enabled? If not, then CPTS
> >> is now also disabled. There are two issues here that we need to solve:
> >>
> >> a) find out why POSIX_TIMERS got disabled, and make sure it's always
> >> turned on for normal users
> >
> > $ make omap2plus_defconfig
> > ...
> > CONFIG_POSIX_TIMERS=y
> > # CONFIG_PTP_1588_CLOCK is not set
> >
> > So CONFIG_TI_CPTS is unselectable.
>
> Ok, so at least this one is easy to understand, it's a direct consequence
> of my change, as nothing else will select CONFIG_PTP_1588_CLOCK
> now.
>
> My first try would be this one:
>
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index 9e631952b86f..8042a7626056 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -76,7 +76,7 @@ config TI_CPSW
> config TI_CPTS
> bool "TI Common Platform Time Sync (CPTS) Support"
> depends on TI_CPSW || TI_KEYSTONE_NETCP
> - depends on PTP_1588_CLOCK
> + depends on POSIX_TIMERS
> ---help---
> This driver supports the Common Platform Time Sync unit of
> the CPSW Ethernet Switch and Keystone 2 1g/10g Switch Subsystem.
> @@ -87,6 +87,7 @@ config TI_CPTS_MOD
> tristate
> depends on TI_CPTS
> default y if TI_CPSW=y || TI_KEYSTONE_NETCP=y
> + imply PTP_1588_CLOCK
> default m
>
> config TI_KEYSTONE_NETCP
Yup this produces a booting .config for me:
Tested-by: Tony Lindgren <tony@atomide.com>
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC
From: David Miller @ 2017-04-24 18:24 UTC (permalink / raw)
To: jslaby
Cc: alexei.starovoitov, mingo, mingo, tglx, hpa, x86, jpoimboe,
linux-kernel, netdev, daniel, edumazet
In-Reply-To: <26f5afd7-d70b-effa-e528-8d0a2b95717a@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Mon, 24 Apr 2017 19:51:54 +0200
> For example what's the point of making the sk_load_word_positive_offset
> label a global, callable function? Note that this is exactly the reason
> why this particular two hunks look weird to you even though the
> annotations only mechanically paraphrase what is in the current code.
So that it can be referenced by the eBPF JIT, because these are
helpers for eBPF JIT generated code. Every architecture implementing
an eBPF JIT has this "mess".
You can't even put a tracepoint or kprobe on these things and expect
to see "arguments" or "return PC" values in the usual spots. This
code has special calling conventions and register usage as Alexei
explained.
I would suggest that you read and understand how this assembler is
designed, how it is called from the generated JIT code, and what it's
semantics and register usage are, before trying to annotating it.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net/tcp_fastopen: Fix for various TFO firewall issues
From: David Miller @ 2017-04-24 18:27 UTC (permalink / raw)
To: weiwan; +Cc: netdev, ycheng, edumazet
In-Reply-To: <20170420214548.23666-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Thu, 20 Apr 2017 14:45:45 -0700
> Currently there are still some firewall issues in the middlebox
> which make the middlebox drop packets silently for TFO sockets.
> This kind of issue is hard to be detected by the end client.
>
> This patch series tries to detect such issues in the kernel and disable
> TFO temporarily.
> More details about the issues and the fixes are included in the following
> patches.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] flower: add MPLS matching support
From: David Miller @ 2017-04-24 18:32 UTC (permalink / raw)
To: benjamin.lahaise; +Cc: netdev, bcrl
In-Reply-To: <1492894367-11637-1-git-send-email-benjamin.lahaise@netronome.com>
From: Benjamin LaHaise <benjamin.lahaise@netronome.com>
Date: Sat, 22 Apr 2017 16:52:45 -0400
> From: Benjamin LaHaise <bcrl@kvack.org>
>
> This patch series adds support for parsing MPLS flows in the flow dissector
> and the flower classifier. Each of the MPLS TTL, BOS, TC and Label fields
> can be used for matching.
>
> v2: incorporate style feedback, move #defines to linux/include/mpls.h
> Note: this omits Jiri's request to remove tabs between the type and
> field names in struct declarations. This would be inconsistent with
> numerous other struct definitions.
Series applied, but in the future:
1) Put the "v2", "v3", whatever in the inital [PATCH xxx] bracketed
part of the subject line, otherwise it ends up in the GIT commit
message header line and that's not desired.
2) Please cut it with these double signoffs, and add an appropriate
entry to the email aliases file.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] nfp: DMA flags, adjust head and fixes
From: David Miller @ 2017-04-24 18:36 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, kubakici, oss-drivers
In-Reply-To: <20170423031756.94429-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Sat, 22 Apr 2017 20:17:51 -0700
> This series takes advantage of Alex's DMA_ATTR_SKIP_CPU_SYNC to make
> XDP packet modifications "correct" from DMA API point of view. It
> also allows us to parse the metadata before we run XDP at no additional
> DMA sync cost. That way we can get rid of the metadata memcpy, and
> remove the last upstream user of bpf_prog->xdp_adjust_head.
>
> David's patch adds a way to read capabilities from the management
> firmware.
>
> There are also two net-next fixes. Patch 4 which fixes what seems to
> be a result of a botched rebase on my part. Patch 5 corrects locking
> when state of ethernet ports is being refreshed.
>
> ---
> v3: move the sync from alloc func to the actual give to hw func
> v2: sync rx buffers before giving them to the card (Alex)
Series applied, thanks Jakub.
^ permalink raw reply
* Re: PROBLEM: IPVS incorrectly reverse-NATs traffic to LVS host
From: Julian Anastasov @ 2017-04-24 18:42 UTC (permalink / raw)
To: Nick Moriarty; +Cc: Wensong Zhang, Simon Horman, netdev, lvs-devel
In-Reply-To: <CAEo=OUmQb0FGQ2Lm+H4RNKTZD7hVKBJ+LTe2Sjy+BgW84yJ_ug@mail.gmail.com>
Hello,
On Mon, 24 Apr 2017, Nick Moriarty wrote:
> Many thanks for your prompt fix! I've now tested this patch against
> the 4.11.0-rc8 kernel on Ubuntu, and I can confirm that my check
> script is no longer seeing incorrect addresses in its responses.
>
> Could you please keep me posted as this is merged?
Sure. Thanks for the confirmation! I'll do some
tests and will post official patch in few days.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [iproute PATCH] man: ip-rule.8: Further clarify how to interpret priority value
From: Stephen Hemminger @ 2017-04-24 18:44 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20170424153537.15072-1-phil@nwl.cc>
On Mon, 24 Apr 2017 17:35:37 +0200
Phil Sutter <phil@nwl.cc> wrote:
> Despite the past changes, users seemed to get confused by the seemingly
> contradictory relation of priority value and actual rule priority.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Makes sense. Applied.
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: Make skb header writable before use
From: Arend Van Spriel @ 2017-04-24 18:59 UTC (permalink / raw)
To: Eric Dumazet, James Hughes
Cc: Franky Lin, Hante Meuleman, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493057382.6453.39.camel-XN9IlZ5yJG9HTL0Zs8A6p+yfmBU6pStAUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
On 24-4-2017 20:09, Eric Dumazet wrote:
> On Mon, 2017-04-24 at 14:03 +0100, James Hughes wrote:
>> The driver was making changes to the skb_header without
>> ensuring it was writable (i.e. uncloned).
>> This patch also removes some boiler plate header size
>> checking/adjustment code as that is also handled by the
>> skb_cow_header function used to make header writable.
>>
>> This patch depends on
>> brcmfmac: Ensure pointer correctly set if skb data location changes
>>
>> Signed-off-by: James Hughes <james.hughes-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
>> ---
>> Changes in v2
>> Makes the _cow_ call at the entry point of the skb in to the
>> stack, means only needs to be done once, and error handling
>> is easier.
>> Split a separate minor bug fix off to a separate patch (which
>> this patch depends on)
>
> Best way to handle dependencies is to send a patch series.
>
> 1/2 brcmfmac: Ensure pointer correctly set if skb data location changes
> 2/2 brcmfmac: Make skb header writable before use
There is actually no real dependency. Both are valid fixes of course but
either one applies to wireless-drivers-next/master on its own.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled
From: Stephen Hemminger @ 2017-04-24 19:00 UTC (permalink / raw)
To: Mike Manning; +Cc: netdev, Nikolay Aleksandrov
In-Reply-To: <1493042944-4005-1-git-send-email-mmanning@brocade.com>
On Mon, 24 Apr 2017 15:09:04 +0100
Mike Manning <mmanning@brocade.com> wrote:
> Flood suppression for packets that are not unicast needs to be handled
> consistently by also not flooding broadcast packets. As broadcast is a
> special case of multicast, the same kernel parameter should be used to
> suppress flooding for both of these packet types.
>
> Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag")
> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Signed-off-by: Mike Manning <mmanning@brocade.com>
> ---
Makes sense.
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats
From: Benjamin Poirier @ 2017-04-24 19:01 UTC (permalink / raw)
To: Paul Menzel; +Cc: Jeff Kirsher, netdev, intel-wired-lan, Stefan Priebe
In-Reply-To: <71d8032d-5ed1-8242-83e6-16ce65718966@molgen.mpg.de>
On 2017/04/24 10:23, Paul Menzel wrote:
> Dear Benjamin,
>
>
> Thank you for your fix.
>
> On 04/21/17 23:20, Benjamin Poirier wrote:
> > Some statistics passed to ethtool are garbage because e1000e_get_stats64()
> > doesn't write them, for example: tx_heartbeat_errors. This leaks kernel
> > memory to userspace and confuses users.
>
> Could you please give specific examples to reproduce the issue? That way
> your fix can also be tested.
>
Some fields in e1000_get_ethtool_stats()'s net_stats are not initialized
by e1000e_get_stats64(). The structure is allocated on the stack,
therefore, the value of those fields depends on previous stack content;
that in turns depends on kernel version, compiler and previous execution
path. I've tried on 8 machines with different kernel versions and it
reproduced on 3.
root@linux-zxe0:/usr/local/src/linux# git log -n1 --oneline
fc1f8f4f310a net: ipv6: send unsolicited NA if enabled for all interfaces
root@linux-zxe0:/usr/local/src/linux# ethtool -i eth0
driver: e1000e
[...]
root@linux-zxe0:/usr/local/src/linux# ethtool -S eth0
NIC statistics:
rx_packets: 217
tx_packets: 153
rx_bytes: 23091
tx_bytes: 20533
rx_broadcast: 0
tx_broadcast: 6
rx_multicast: 0
tx_multicast: 10
rx_errors: 0
tx_errors: 0
tx_dropped: 18446683600612146192
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 70364470214850
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 18446744072101618112
tx_heartbeat_errors: 18446612150964469760
[...]
(gdb) p /x 18446683600612146192
$1 = 0xffffc9000282bc10
(gdb) p /x 18446744072101618112
$2 = 0xffffffffa028e1c0
(gdb) p /x 18446612150964469760
$3 = 0xffff880457a44000
... a bunch of kernel addresses
Inserting a dummy memset is a reliable way to show the issue:
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -2061,6 +2061,8 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
int i;
char *p = NULL;
+ memset(&net_stats, 0xff, sizeof(net_stats));
+
pm_runtime_get_sync(netdev->dev.parent);
e1000e_get_stats64(netdev, &net_stats);
root@linux-zxe0:/usr/local/src/linux# ethtool -S eth0
NIC statistics:
rx_packets: 30
tx_packets: 29
rx_bytes: 2924
tx_bytes: 3012
rx_broadcast: 0
tx_broadcast: 6
rx_multicast: 0
tx_multicast: 7
rx_errors: 0
tx_errors: 0
tx_dropped: 18446744073709551615
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 18446744073709551615
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 18446744073709551615
tx_heartbeat_errors: 18446744073709551615
[...]
(gdb) p /x 18446744073709551615
$1 = 0xffffffffffffffff
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats
From: Benjamin Poirier @ 2017-04-24 19:10 UTC (permalink / raw)
To: Neftin, Sasha
Cc: netdev@vger.kernel.org, intel-wired-lan, Ruinskiy, Dima, Kirsher,
Jeffrey T, Stefan Priebe
In-Reply-To: <caef8d69-9e47-bbcc-0758-e5900e1cb291@intel.com>
Sasha, please use reply-all to keep everyone in cc (including me...).
On 2017/04/24 11:17, Neftin, Sasha wrote:
> On 4/23/2017 15:53, Neftin, Sasha wrote:
> > -----Original Message-----
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Benjamin Poirier
> > Sent: Saturday, April 22, 2017 00:20
> > To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> > Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org; Stefan Priebe <s.priebe@profihost.ag>
> > Subject: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats
> >
> > Some statistics passed to ethtool are garbage because e1000e_get_stats64() doesn't write them, for example: tx_heartbeat_errors. This leaks kernel memory to userspace and confuses users.
> >
> > Do like ixgbe and use dev_get_stats() which first zeroes out rtnl_link_stats64.
> >
> > Reported-by: Stefan Priebe <s.priebe@profihost.ag>
> > Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
> > ---
> > drivers/net/ethernet/intel/e1000e/ethtool.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
> > index 7aff68a4a4df..f117b90cdc2f 100644
> > --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> > +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
> > @@ -2063,7 +2063,7 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
> > pm_runtime_get_sync(netdev->dev.parent);
> > - e1000e_get_stats64(netdev, &net_stats);
> > + dev_get_stats(netdev, &net_stats);
> > pm_runtime_put_sync(netdev->dev.parent);
> > --
> > 2.12.2
> >
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan@lists.osuosl.org
> > http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>
> Hello,
>
> We would like to not accept this patch. Suggested generic method
> '*dev_get_stats' (net/core/dev.c) calls 'ops->ndo_get_stats64' method which
> eventually calls e1000e_get_stats64 (netdev.c) - so there is same
> functionality. Also, see that 'e1000e_get_stats64' method in netdev.c (line
No, it's not the same functionality because dev_get_stats() does a
memset on the rtnl_link_stats64 struct.
> 5928) calls 'memset' with 0's before update statistics. Local sanity check
I don't see any memset in e1000e_get_stats64(). What kernel version are
you looking at?
> in our lab shows 'tx_heartbeat_errors' counter reported as 0.
>
Please see the mail I just sent to Paul Menzel <pmenzel@molgen.mpg.de>
for more information about the issue and how to reproduce it.
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: Make skb header writable before use
From: Arend Van Spriel @ 2017-04-24 19:14 UTC (permalink / raw)
To: James Hughes, Franky Lin, Hante Meuleman, Kalle Valo,
linux-wireless, brcm80211-dev-list.pdl, netdev
In-Reply-To: <20170424130322.476-1-james.hughes@raspberrypi.org>
On 24-4-2017 15:03, James Hughes wrote:
> The driver was making changes to the skb_header without
> ensuring it was writable (i.e. uncloned).
> This patch also removes some boiler plate header size
> checking/adjustment code as that is also handled by the
> skb_cow_header function used to make header writable.
>
> This patch depends on
> brcmfmac: Ensure pointer correctly set if skb data location changes
Hi James,
I actually thought I was going to tackle this so I spend some time
working on it today, but I will submit that as a subsequent patch. Below
some comments but apart from that:
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: James Hughes <james.hughes@raspberrypi.org>
> ---
> Changes in v2
> Makes the _cow_ call at the entry point of the skb in to the
> stack, means only needs to be done once, and error handling
> is easier.
> Split a separate minor bug fix off to a separate patch (which
> this patch depends on)
>
>
>
> .../net/wireless/broadcom/brcm80211/brcmfmac/core.c | 19 ++++---------------
> 1 file changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 9b7c19a508ac..88f8675a94c2 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -211,22 +211,11 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
> goto done;
> }
>
> - /* Make sure there's enough room for any header */
> - if (skb_headroom(skb) < drvr->hdrlen) {
> - struct sk_buff *skb2;
> -
> - brcmf_dbg(INFO, "%s: insufficient headroom\n",
> - brcmf_ifname(ifp));
> - drvr->bus_if->tx_realloc++;
> - skb2 = skb_realloc_headroom(skb, drvr->hdrlen);
> + /* Make sure there's enough room for any header, and make it writable */
Please rephrase: /* Make sure there is enough writable headroom */
Just do:
ret = skb_cow_head(skb, drvr->hdrlen);
if (ret < 0) {
brcmf_err("%s: skb_cow_head failed\n",
brcmf_ifname(ifp));
> + if (skb_cow_head(skb, drvr->hdrlen)) {
> dev_kfree_skb(skb);
> - skb = skb2;
> - if (skb == NULL) {
> - brcmf_err("%s: skb_realloc_headroom failed\n",
> - brcmf_ifname(ifp));
> - ret = -ENOMEM;
> - goto done;
> - }
> + ret = -ENOMEM;
... and drop this assignment.
> + goto done;
> }
>
> /* validate length for ether packet */
>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats
From: David Miller @ 2017-04-24 19:15 UTC (permalink / raw)
To: bpoirier; +Cc: pmenzel, jeffrey.t.kirsher, netdev, intel-wired-lan, s.priebe
In-Reply-To: <20170424190151.cbmbbeyjspoolpho@f1.synalogic.ca>
From: Benjamin Poirier <bpoirier@suse.com>
Date: Mon, 24 Apr 2017 12:01:51 -0700
> On 2017/04/24 10:23, Paul Menzel wrote:
>> Dear Benjamin,
>>
>>
>> Thank you for your fix.
>>
>> On 04/21/17 23:20, Benjamin Poirier wrote:
>> > Some statistics passed to ethtool are garbage because e1000e_get_stats64()
>> > doesn't write them, for example: tx_heartbeat_errors. This leaks kernel
>> > memory to userspace and confuses users.
>>
>> Could you please give specific examples to reproduce the issue? That way
>> your fix can also be tested.
>>
>
> Some fields in e1000_get_ethtool_stats()'s net_stats are not initialized
> by e1000e_get_stats64(). The structure is allocated on the stack,
> therefore, the value of those fields depends on previous stack content;
> that in turns depends on kernel version, compiler and previous execution
> path.
I agree.
I read over these code paths earlier today and came to the same exact
conclusion.
^ permalink raw reply
* [PATCH] net: hso: fix module unloading
From: Andreas Kemnade @ 2017-04-24 19:18 UTC (permalink / raw)
To: davem, joe, peter, linux-usb, netdev, linux-kernel,
Discussions about the Letux Kernel
Cc: Andreas Kemnade
keep tty driver until usb driver is unregistered
rmmod hso
produces traces like this without that:
[40261.645904] usb 2-2: new high-speed USB device number 2 using ehci-omap
[40261.854644] usb 2-2: New USB device found, idVendor=0af0, idProduct=8800
[40261.862609] usb 2-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[40261.872772] usb 2-2: Product: Globetrotter HSUPA Modem
[40261.880279] usb 2-2: Manufacturer: Option N.V.
[40262.021270] hso 2-2:1.5: Not our interface
[40265.556945] hso: unloaded
[40265.559875] usbcore: deregistering interface driver hso
[40265.595947] Unable to handle kernel NULL pointer dereference at virtual address 00000033
[40265.604522] pgd = ecb14000
[40265.611877] [00000033] *pgd=00000000
[40265.617034] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[40265.622650] Modules linked in: hso(-) bnep bluetooth ipv6 arc4 twl4030_madc_hwmon wl18xx wlcore mac80211 cfg80211 snd_soc_simple_card snd_soc_simple_card_utils snd_soc_omap_twl4030 snd_soc_gtm601 generic_adc_battery extcon_gpio omap3_isp videobuf2_dma_contig videobuf2_memops wlcore_sdio videobuf2_v4l2 videobuf2_core ov9650 bmp280_i2c v4l2_common bmp280 bmg160_i2c bmg160_core at24 nvmem_core videodev bmc150_accel_i2c bmc150_magn_i2c media bmc150_accel_core tsc2007 bmc150_magn leds_tca6507 bno055 snd_soc_omap_mcbsp industrialio_triggered_buffer snd_soc_omap kfifo_buf snd_pcm_dmaengine gpio_twl4030 snd_soc_twl4030 twl4030_vibra twl4030_madc wwan_on_off ehci_omap pwm_bl pwm_omap_dmtimer panel_tpo_td028ttec1 encoder_opa362 connector_analog_tv omapdrm drm_kms_helper cfbfillrect syscopyarea cf
bimgblt sysfillrect
[40265.698211] sysimgblt fb_sys_fops cfbcopyarea drm omapdss usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap2430 phy_twl4030_usb musb_hdrc twl4030_charger industrialio w2sg0004 twl4030_pwrbutton bq27xxx_battery w1_bq27000 omap_hdq [last unloaded: hso]
[40265.723175] CPU: 0 PID: 2701 Comm: rmmod Not tainted 4.11.0-rc6-letux+ #6
[40265.730346] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[40265.736938] task: ecb81100 task.stack: ecb82000
[40265.741729] PC is at cdev_del+0xc/0x2c
[40265.745666] LR is at tty_unregister_device+0x40/0x50
[40265.750915] pc : [<c027472c>] lr : [<c04b3ecc>] psr: 600b0113
sp : ecb83ea8 ip : eca4f898 fp : 00000000
[40265.763000] r10: 00000000 r9 : 00000000 r8 : 00000001
[40265.768493] r7 : eca4f800 r6 : 00000003 r5 : 00000000 r4 : ffffffff
[40265.775360] r3 : c1458d54 r2 : 00000000 r1 : 00000004 r0 : ffffffff
[40265.782257] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[40265.789764] Control: 10c5387d Table: acb14019 DAC: 00000051
[40265.795806] Process rmmod (pid: 2701, stack limit = 0xecb82218)
[40265.802062] Stack: (0xecb83ea8 to 0xecb84000)
[40265.806640] 3ea0: ec9e8100 c04b3ecc bf737378 ed5b7c00 00000003 bf7327ec
[40265.815277] 3ec0: eca4f800 00000000 ec9fd800 eca4f800 bf737070 bf7328bc eca4f820 c05a9a04
[40265.823883] 3ee0: eca4f820 00000000 00000001 eca4f820 ec9fd870 bf737070 eca4f854 ec9fd8a4
[40265.832519] 3f00: ecb82000 00000000 00000000 c04e6960 eca4f820 bf737070 bf737048 00000081
[40265.841125] 3f20: c01071e4 c04e6a60 ecb81100 bf737070 bf737070 c04e5d94 bf737020 c05a8f88
[40265.849731] 3f40: bf737100 00000800 7f5fa254 00000081 c01071e4 c01c4afc 00000000 006f7368
[40265.858367] 3f60: ecb815f4 00000000 c0cac9c4 c01071e4 ecb82000 00000000 00000000 c01512f4
[40265.866973] 3f80: ed5b3200 c01071e4 7f5fa220 7f5fa220 bea78ec9 0010711c 7f5fa220 7f5fa220
[40265.875579] 3fa0: bea78ec9 c0107040 7f5fa220 7f5fa220 7f5fa254 00000800 dd35b800 dd35b800
[40265.884216] 3fc0: 7f5fa220 7f5fa220 bea78ec9 00000081 bea78dcc 00000000 bea78bd8 00000000
[40265.892822] 3fe0: b6f70521 bea78b6c 7f5dd613 b6f70526 80070030 7f5fa254 ffffffff ffffffff
[40265.901458] [<c027472c>] (cdev_del) from [<c04b3ecc>] (tty_unregister_device+0x40/0x50)
[40265.909942] [<c04b3ecc>] (tty_unregister_device) from [<bf7327ec>] (hso_free_interface+0x80/0x144 [hso])
[40265.919982] [<bf7327ec>] (hso_free_interface [hso]) from [<bf7328bc>] (hso_disconnect+0xc/0x18 [hso])
[40265.929718] [<bf7328bc>] (hso_disconnect [hso]) from [<c05a9a04>] (usb_unbind_interface+0x84/0x200)
[40265.939239] [<c05a9a04>] (usb_unbind_interface) from [<c04e6960>] (device_release_driver_internal+0x138/0x1cc)
[40265.949798] [<c04e6960>] (device_release_driver_internal) from [<c04e6a60>] (driver_detach+0x60/0x6c)
[40265.959503] [<c04e6a60>] (driver_detach) from [<c04e5d94>] (bus_remove_driver+0x64/0x8c)
[40265.968017] [<c04e5d94>] (bus_remove_driver) from [<c05a8f88>] (usb_deregister+0x5c/0xb8)
[40265.976654] [<c05a8f88>] (usb_deregister) from [<c01c4afc>] (SyS_delete_module+0x160/0x1dc)
[40265.985443] [<c01c4afc>] (SyS_delete_module) from [<c0107040>] (ret_fast_syscall+0x0/0x1c)
[40265.994171] Code: c1458d54 e59f3020 e92d4010 e1a04000 (e5941034)
[40266.016693] ---[ end trace 9d5ac43c7e41075c ]---
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
drivers/net/usb/hso.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 2e66340..b75e23f 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -3293,9 +3293,9 @@ static void __exit hso_exit(void)
pr_info("unloaded\n");
tty_unregister_driver(tty_drv);
- put_tty_driver(tty_drv);
/* deregister the usb driver */
usb_deregister(&hso_driver);
+ put_tty_driver(tty_drv);
}
/* Module definitions */
--
2.1.4
^ permalink raw reply related
* [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Jan Kiszka @ 2017-04-24 19:27 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue
Cc: netdev, Linux Kernel Mailing List, Sascha Weisenberger
The IOT2000 is industrial controller platform, derived from the Intel
Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the
IOT2040 has two of them. They can be told apart based on the board asset
tag in the DMI table.
Based on patch by Sascha Weisenberger.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Sascha Weisenberger <sascha.weisenberger@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 5c9e462276b9..de87c329fb5c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -32,6 +32,7 @@
*/
struct stmmac_pci_dmi_data {
const char *name;
+ const char *asset_tag;
unsigned int func;
int phy_addr;
};
@@ -46,6 +47,7 @@ struct stmmac_pci_info {
static int stmmac_pci_find_phy_addr(struct stmmac_pci_info *info)
{
const char *name = dmi_get_system_info(DMI_BOARD_NAME);
+ const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
unsigned int func = PCI_FUNC(info->pdev->devfn);
struct stmmac_pci_dmi_data *dmi;
@@ -57,7 +59,8 @@ static int stmmac_pci_find_phy_addr(struct stmmac_pci_info *info)
return 1;
for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
- if (!strcmp(dmi->name, name) && dmi->func == func)
+ if (dmi->func == func && !strcmp(dmi->name, name) &&
+ (!dmi->asset_tag || !strcmp(dmi->asset_tag, asset_tag)))
return dmi->phy_addr;
}
@@ -142,6 +145,24 @@ static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
.func = 6,
.phy_addr = 1,
},
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-0YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 7,
+ .phy_addr = 1,
+ },
{}
};
^ permalink raw reply related
* Re: [PATCH 2/2] ixgbe: add support for XDP_TX action
From: Jesper Dangaard Brouer @ 2017-04-24 19:29 UTC (permalink / raw)
To: John Fastabend; +Cc: brouer, jeffrey.t.kirsher, netdev
In-Reply-To: <20170424013135.8354.93583.stgit@john-Precision-Tower-5810>
On Sun, 23 Apr 2017 18:31:36 -0700
John Fastabend <john.fastabend@gmail.com> wrote:
> +static int ixgbe_xmit_xdp_ring(struct ixgbe_adapter *adapter,
> + struct xdp_buff *xdp)
> +{
> + struct ixgbe_ring *ring = adapter->xdp_ring[smp_processor_id()];
I was about to question whether is it always true that the array size
can match the number of CPUs in the system, but I can see later in
ixgbe_xdp_setup() that you reject XDP program if the system have more
CPUs that MAX_XDP_QUEUES.
> + struct ixgbe_tx_buffer *tx_buffer;
> + union ixgbe_adv_tx_desc *tx_desc;
> + u32 len, cmd_type;
> + dma_addr_t dma;
> + u16 i;
> +
> + len = xdp->data_end - xdp->data;
> +
> + if (unlikely(!ixgbe_desc_unused(ring)))
> + return IXGBE_XDP_CONSUMED;
> +
> + dma = dma_map_single(ring->dev, xdp->data, len, DMA_TO_DEVICE);
> + if (dma_mapping_error(ring->dev, dma))
> + return IXGBE_XDP_CONSUMED;
> +
> + /* record the location of the first descriptor for this packet */
> + tx_buffer = &ring->tx_buffer_info[ring->next_to_use];
> + tx_buffer->bytecount = len;
> + tx_buffer->gso_segs = 1;
> + tx_buffer->protocol = 0;
> +
> + i = ring->next_to_use;
> + tx_desc = IXGBE_TX_DESC(ring, i);
> +
> + dma_unmap_len_set(tx_buffer, len, len);
> + dma_unmap_addr_set(tx_buffer, dma, dma);
> + tx_buffer->data = xdp->data;
> + tx_desc->read.buffer_addr = cpu_to_le64(dma);
> +
> + /* put descriptor type bits */
> + cmd_type = IXGBE_ADVTXD_DTYP_DATA |
> + IXGBE_ADVTXD_DCMD_DEXT |
> + IXGBE_ADVTXD_DCMD_IFCS;
> + cmd_type |= len | IXGBE_TXD_CMD;
> + tx_desc->read.cmd_type_len = cpu_to_le32(cmd_type);
> + tx_desc->read.olinfo_status =
> + cpu_to_le32(len << IXGBE_ADVTXD_PAYLEN_SHIFT);
> +
> + /* Force memory writes to complete before letting h/w know there
> + * are new descriptors to fetch. (Only applicable for weak-ordered
> + * memory model archs, such as IA-64).
> + *
> + * We also need this memory barrier to make certain all of the
> + * status bits have been updated before next_to_watch is written.
> + */
> + wmb();
> +
> + /* set next_to_watch value indicating a packet is present */
> + i++;
> + if (i == ring->count)
> + i = 0;
> +
> + tx_buffer->next_to_watch = tx_desc;
> + ring->next_to_use = i;
> +
> + writel(i, ring->tail);
A tailptr write for every XDP_TX packet is not going be fast, but you
already mentioned that this is not optimal yet, so I guess you are aware.
> + return IXGBE_XDP_TX;
> +}
On Sun, 23 Apr 2017 18:31:36 -0700
John Fastabend <john.fastabend@gmail.com> wrote:
> @@ -9559,9 +9740,23 @@ static int ixgbe_xdp_setup(struct net_device *dev, struct bpf_prog *prog)
> return -EINVAL;
> }
>
> + if (nr_cpu_ids > MAX_XDP_QUEUES)
> + return -ENOMEM;
> +
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 2/2] ixgbe: add support for XDP_TX action
From: John Fastabend @ 2017-04-24 19:35 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <20170424212921.36fdfff7@redhat.com>
On 17-04-24 12:29 PM, Jesper Dangaard Brouer wrote:
> On Sun, 23 Apr 2017 18:31:36 -0700
> John Fastabend <john.fastabend@gmail.com> wrote:
>
>> +static int ixgbe_xmit_xdp_ring(struct ixgbe_adapter *adapter,
>> + struct xdp_buff *xdp)
>> +{
>> + struct ixgbe_ring *ring = adapter->xdp_ring[smp_processor_id()];
>
> I was about to question whether is it always true that the array size
> can match the number of CPUs in the system, but I can see later in
> ixgbe_xdp_setup() that you reject XDP program if the system have more
> CPUs that MAX_XDP_QUEUES.
Yep.
[...]
>> +
>> + tx_buffer->next_to_watch = tx_desc;
>> + ring->next_to_use = i;
>> +
>> + writel(i, ring->tail);
>
> A tailptr write for every XDP_TX packet is not going be fast, but you
> already mentioned that this is not optimal yet, so I guess you are aware.
>
There is another patch on Jeff's tree to only kick the tail ptr once per
receive path invocation.
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?h=dev-queue&id=24043a662d11e048de903e12bf86059844c207e2
That patch brings packet rates up to near line rate @ 64 bytes.
Thanks,
John
^ permalink raw reply
* Re: [PATCH v3 net] net: ipv6: regenerate host route if moved to gc list
From: David Ahern @ 2017-04-24 19:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, dvyukov, andreyknvl, mmanning, kafai
In-Reply-To: <1493051946.6453.37.camel@edumazet-glaptop3.roam.corp.google.com>
On 4/24/17 10:39 AM, Eric Dumazet wrote:
>
> Very nice changelog !
Thanks. Given my aggressive brain cell recycling program, I needed to
write down the analysis.
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 80ce478c4851..93f81d9cd85f 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -3271,14 +3271,25 @@ static void addrconf_gre_config(struct net_device *dev)
>> static int fixup_permanent_addr(struct inet6_dev *idev,
>> struct inet6_ifaddr *ifp)
>> {
>> - if (!ifp->rt) {
>> - struct rt6_info *rt;
>> + /* rt6i_ref == 0 means the host route was removed from the
>> + * FIB, for example, if 'lo' device is taken down. In that
>> + * case regenerate the host route.
>> + */
>> + if (!ifp->rt || !atomic_read(&ifp->rt->rt6i_ref)) {
>> + struct rt6_info *rt, *prev;
>>
>> rt = addrconf_dst_alloc(idev, &ifp->addr, false);
>> if (unlikely(IS_ERR(rt)))
>> return PTR_ERR(rt);
>>
>> + prev = ifp->rt;
>
> I would feel more comfortable if this was moved after the spin_lock() ?
That's what I had in v2; it reads better to me even if it is not
technically required (all changes to ifp->rt happen under rtnl).
Martin you agree?
I'll send a v3 tomorrow -- allow more time for other comments.
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Neal Cardwell @ 2017-04-24 19:42 UTC (permalink / raw)
To: Lars Erik Storbukås; +Cc: LKML, Netdev
In-Reply-To: <CAF0XkCCFwxuyJ5bc4SUHjdDJb_E-CqYC-3k3nzi+0i3H9D2zPA@mail.gmail.com>
On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
<storbukas.dev@gmail.com> wrote:
> I'm trying to get amount of congestion events in TCP caused by
> DUPACK's (fast retransmissions), and can't seem to find any variable
> in the TCP info struct which hold that value. There are three
> variables in the TCP info struct that seem to hold similar congestion
> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
> tcpi_total_retrans;
>
> Does anyone have any pointers on how to find this value in the TCP code?
>
> Please CC me personally if answering this question. Any help is
> greatly appreciated.
[I'm cc-ing the netdev list.]
Do you need this per-socket? On a per-socket basis, I do not think
there are separate totals for fast retransmits and timeout
retransmits.
If a global number is good enough, then you can get that number from
the global network statistics. In "nstat" output they look like:
TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
It sounds like TcpExtTCPFastRetrans is what you are after.
Hope that helps,
neal
^ permalink raw reply
* Networking security fixes
From: Ben Hutchings @ 2017-04-24 19:47 UTC (permalink / raw)
To: David S. Miller; +Cc: stable, netdev
Please queue up these fixes for 4.10.y:
8605330aac5a tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs
4ef1b2869447 tcp: mark skbs with SCM_TIMESTAMPING_OPT_STATS
If I understand correctly, you are no longer sending Greg fixes for
4.4.y or older stable branches, so I'll send stable requests for those
older versions directly.
Please can you also send the pending fixes to Greg soon, as the
AF_PACKET issue is quite serious?
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply
* Re: [PATCH 1/1] net: bcmgenet: fix incorrect return value checks
From: David Miller @ 2017-04-24 19:48 UTC (permalink / raw)
To: bianpan201602; +Cc: f.fainelli, netdev, linux-kernel, bianpan2016
In-Reply-To: <1492941665-17155-1-git-send-email-bianpan201602@163.com>
From: Pan Bian <bianpan201602@163.com>
Date: Sun, 23 Apr 2017 18:01:05 +0800
> From: Pan Bian <bianpan2016@163.com>
>
> Function platform_get_irq() will return a negative value on errors.
> However, in function bcmgenet_probe(), 0 is considered as a flag of
> error. This patch fixes the bug by checking whether the return value of
> platform_get_irq() is less than 0.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
I'm definitely not confident enough to apply this.
On some platform zero IRQs are invalid.
There are also lots of pieces of code that check the return value ">
0" as success.
^ permalink raw reply
* Re: [PATCH 1/1] lwtunnel: check return value of nla_nest_start
From: David Miller @ 2017-04-24 19:51 UTC (permalink / raw)
To: bianpan2016
Cc: dsa, roopa, ast, david.lebrun, tom, rshearma, netdev,
linux-kernel
In-Reply-To: <1492928917-25628-1-git-send-email-bianpan2016@163.com>
From: Pan Bian <bianpan2016@163.com>
Date: Sun, 23 Apr 2017 14:28:37 +0800
> Function nla_nest_start() may return a NULL pointer on error. However,
> in function lwtunnel_fill_encap(), the return value of nla_nest_start()
> is not validated before it is used. This patch checks the return value
> of nla_nest_start() against NULL.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Applied.
^ permalink raw reply
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