* [PATCH bpf-next v4 1/6] ipv6: sr: make seg6.h includable without IPv6
From: Mathieu Xhonneux @ 2018-05-09 21:16 UTC (permalink / raw)
To: netdev; +Cc: dlebrun, alexei.starovoitov
In-Reply-To: <cover.1525898587.git.m.xhonneux@gmail.com>
include/net/seg6.h cannot be included in a source file if CONFIG_IPV6 is
not enabled:
include/net/seg6.h: In function 'seg6_pernet':
>> include/net/seg6.h:52:14: error: 'struct net' has no member named
'ipv6'; did you mean 'ipv4'?
return net->ipv6.seg6_data;
^~~~
ipv4
This commit makes seg6_pernet return NULL if IPv6 is not compiled, hence
allowing seg6.h to be included regardless of the configuration.
Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
---
include/net/seg6.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/net/seg6.h b/include/net/seg6.h
index 099bad59dc90..70b4cfac52d7 100644
--- a/include/net/seg6.h
+++ b/include/net/seg6.h
@@ -49,7 +49,11 @@ struct seg6_pernet_data {
static inline struct seg6_pernet_data *seg6_pernet(struct net *net)
{
+#if IS_ENABLED(CONFIG_IPV6)
return net->ipv6.seg6_data;
+#else
+ return NULL;
+#endif
}
extern int seg6_init(void);
--
2.16.1
^ permalink raw reply related
* [PATCH bpf-next v4 0/6] ipv6: sr: introduce seg6local End.BPF action
From: Mathieu Xhonneux @ 2018-05-09 21:16 UTC (permalink / raw)
To: netdev; +Cc: dlebrun, alexei.starovoitov
As of Linux 4.14, it is possible to define advanced local processing for
IPv6 packets with a Segment Routing Header through the seg6local LWT
infrastructure. This LWT implements the network programming principles
defined in the IETF “SRv6 Network Programming” draft.
The implemented operations are generic, and it would be very interesting to
be able to implement user-specific seg6local actions, without having to
modify the kernel directly. To do so, this patchset adds an End.BPF action
to seg6local, powered by some specific Segment Routing-related helpers,
which provide SR functionalities that can be applied on the packet. This
BPF hook would then allow to implement specific actions at native kernel
speed such as OAM features, advanced SR SDN policies, SRv6 actions like
Segment Routing Header (SRH) encapsulation depending on the content of
the packet, etc.
This patchset is divided in 6 patches, whose main features are :
- A new seg6local action End.BPF with the corresponding new BPF program
type BPF_PROG_TYPE_LWT_SEG6LOCAL. Such attached BPF program can be
passed to the LWT seg6local through netlink, the same way as the LWT
BPF hook operates.
- 3 new BPF helpers for the seg6local BPF hook, allowing to edit/grow/
shrink a SRH and apply on a packet some of the generic SRv6 actions.
- 1 new BPF helper for the LWT BPF IN hook, allowing to add a SRH through
encapsulation (via IPv6 encapsulation or inlining if the packet contains
already an IPv6 header).
As this patchset adds a new LWT BPF hook, I took into account the result of
the discussions when the LWT BPF infrastructure got merged. Hence, the
seg6local BPF hook doesn’t allow write access to skb->data directly, only
the SRH can be modified through specific helpers, which ensures that the
integrity of the packet is maintained.
More details are available in the related patches messages.
The performances of this BPF hook have been assessed with the BPF JIT
enabled on a Intel Xeon X3440 processors with 4 cores and 8 threads
clocked at 2.53 GHz. No throughput losses are noted with the seg6local
BPF hook when the BPF program does nothing (440kpps). Adding a 8-bytes
TLV (1 call each to bpf_lwt_seg6_adjust_srh and bpf_lwt_seg6_store_bytes)
drops the throughput to 410kpps, and inlining a SRH via
bpf_lwt_seg6_action drops the throughput to 420kpps.
All throughputs are stable.
-------
v2: move the SRH integrity state from skb->cb to a per-cpu buffer
v3: - document helpers in man-page style
- fix kbuild bugs
- un-break BPF LWT out hook
- bpf_push_seg6_encap is now static
- preempt_enable is now called when the packet is dropped in
input_action_end_bpf
v4: fix kbuild bugs when CONFIG_IPV6=m
Thanks.
Mathieu Xhonneux (6):
ipv6: sr: make seg6.h includable without IPv6
ipv6: sr: export function lookup_nexthop
bpf: Add IPv6 Segment Routing helpers
bpf: Split lwt inout verifier structures
ipv6: sr: Add seg6local action End.BPF
selftests/bpf: test for seg6local End.BPF action
include/linux/bpf_types.h | 7 +-
include/net/seg6.h | 7 +-
include/net/seg6_local.h | 32 ++
include/uapi/linux/bpf.h | 96 ++++-
include/uapi/linux/seg6_local.h | 3 +
kernel/bpf/verifier.c | 1 +
net/core/filter.c | 390 ++++++++++++++++---
net/ipv6/Kconfig | 5 +
net/ipv6/seg6_local.c | 180 ++++++++-
tools/include/uapi/linux/bpf.h | 97 ++++-
tools/testing/selftests/bpf/Makefile | 5 +-
tools/testing/selftests/bpf/bpf_helpers.h | 12 +
tools/testing/selftests/bpf/test_lwt_seg6local.c | 438 ++++++++++++++++++++++
tools/testing/selftests/bpf/test_lwt_seg6local.sh | 140 +++++++
14 files changed, 1340 insertions(+), 73 deletions(-)
create mode 100644 include/net/seg6_local.h
create mode 100644 tools/testing/selftests/bpf/test_lwt_seg6local.c
create mode 100755 tools/testing/selftests/bpf/test_lwt_seg6local.sh
--
2.16.1
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: add RMU disable op
From: Andrew Lunn @ 2018-05-09 19:08 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev, linux-kernel, kernel, davem, f.fainelli
In-Reply-To: <20180509153851.10207-4-vivien.didelot@savoirfairelinux.com>
On Wed, May 09, 2018 at 11:38:51AM -0400, Vivien Didelot wrote:
> The RMU mode bits moved a lot within the Global Control 2 register of
> the Marvell switch families. Add an .rmu_disable op to support at least
> 3 known alternatives.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mv88e6xxx: set device number
From: Andrew Lunn @ 2018-05-09 19:06 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev, linux-kernel, kernel, davem, f.fainelli
In-Reply-To: <20180509153851.10207-3-vivien.didelot@savoirfairelinux.com>
On Wed, May 09, 2018 at 11:38:50AM -0400, Vivien Didelot wrote:
> All Marvell switches supported by mv88e6xxx have to set their device
> number in the Global Control 2 register. Extract this in a read then
> write function, called from the device mapping setup code.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mv88e6xxx: add a cascade port op
From: Andrew Lunn @ 2018-05-09 19:05 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev, linux-kernel, kernel, davem, f.fainelli
In-Reply-To: <20180509153851.10207-2-vivien.didelot@savoirfairelinux.com>
On Wed, May 09, 2018 at 11:38:49AM -0400, Vivien Didelot wrote:
> Only the 88E6185 family has bits 15:12 Cascade Port bits in the Global
> Control 2 register. Hence inconsistent values are actually written in
> this register for other families.
>
> Add a .set_cascade_port operation to isolate the 88E6185 case, and call
> it from the device mapping setup function.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: Performance regression between 4.13 and 4.14
From: Ben Greear @ 2018-05-09 19:02 UTC (permalink / raw)
To: Eric Dumazet, netdev
In-Reply-To: <988a00db-bab3-7318-5e31-2a7c0948262a@gmail.com>
On 05/09/2018 11:48 AM, Eric Dumazet wrote:
>
>
> On 05/09/2018 11:43 AM, Ben Greear wrote:
>> On 05/08/2018 10:10 AM, Eric Dumazet wrote:
>>>
>>>
>>> On 05/08/2018 09:44 AM, Ben Greear wrote:
>>>> Hello,
>>>>
>>>> I am trying to track down a performance regression that appears to be between 4.13
>>>> and 4.14.
>>>>
>>>> I first saw the problem with a hacked version of pktgen on some ixgbe NICs. 4.13 can do
>>>> right at 10G bi-directional on two ports, and 4.14 and later can do only about 6Gbps.
>>>>
>>>> I also tried with user-space UDP traffic on a stock kernel, and I can get about 3.2Gbps combined tx+rx
>>>> on 4.14 and about 4.4Gbps on 4.13.
>>>>
>>>> Attempting to bisect seems to be triggering a weirdness in git, and also lots of commits
>>>> crash or do not bring up networking, which makes the bisect difficult.
>>>>
>>>> Looking at perf top, it would appear that some lock is probably to blame.
>>>
>>>
>>> perf record -a -g -e cycles:pp sleep 5
>>> perf report
>>>
>>> Then you'll be able to tell us which lock (or call graph) is killing your perf.
>>>
>>
>> I seem to be chasing multiple issues. For 4.13, at least part of my problem was that LOCKDEP was enabled,
>> during my bisect, though it does NOT appear enabled in 4.16. I think maybe CONFIG_LOCKDEP moved to CONFIG_PROVE_LOCKING
>> in 4.16, or something like that? My 4.16 .config does have CONFIG_LOCKDEP_SUPPORT enabled, and I see no option to disable it:
>>
>> [greearb@ben-dt3 linux-4.16.x64]$ grep LOCKDEP .config
>> CONFIG_LOCKDEP_SUPPORT=y
>>
>>
>> For 4.16, I am disabling RETRAMPOLINE...are there any other such things I need
>> to disable to keep from getting a performance hit from the spectre-related bug
>> fixes? At this point, I do not care about the security implications.
>>
>> greearb@ben-dt3 linux-4.16.x64]$ grep RETPO .config
>> # CONFIG_RETPOLINE is not set
>>
>>
>> Thanks,
>> Ben
>>
>
> No idea really, you mention a 4.13 -> 4.14 regression and jump then to 4.16 :/
I initially saw the problem in 4.16, then bisected, and 4.14 still showed the
issue.
4.13 works, but only when I use a .config I originally built for 4.13, not the 4.16 .config
that I ended up using with the bisect (make oldconfig, accept all defaults). I originally
configured 4.16 with a .config that had lockdep enabled, then manually tried to disable it
through 'make xconfig'. I think that must leave "CONFIG_LOCKDEP=y" in the .config, which
screws up older builds during bisect, perhaps?
> Before doing a (painful) dissection, the perf output would immediately tell you if
> something is really wrong on your .config.
I didn't realize lockdep might be an issue at the time, but here is a 'bad' run from
a 4.13+ (plus pktgen hacks). I guess lockdep is why this runs slowly, but I see no obvious
proof of that in the output:
4.13+, patched pktgen, 6Gbps throughput, on commit 906dde0f355bd97c080c215811ae7db1137c4af8
Samples: 26K of event 'cycles:pp', Event count (approx.): 20119166736
Children Self Command Shared Object Symbol
+ 87.97% 0.00% kpktgend_1 [kernel.kallsyms] [k] ret_from_fork
+ 87.97% 0.00% kpktgend_1 [kernel.kallsyms] [k] kthread
+ 86.89% 5.42% kpktgend_1 [kernel.kallsyms] [k] pktgen_thread_worker
+ 33.75% 0.18% kpktgend_1 [kernel.kallsyms] [k] getnstimeofday64
+ 32.77% 4.47% kpktgend_1 [kernel.kallsyms] [k] __getnstimeofday64
+ 24.60% 10.91% kpktgend_1 [kernel.kallsyms] [k] lock_acquire
+ 23.59% 0.03% kpktgend_1 [kernel.kallsyms] [k] __do_softirq
+ 23.55% 0.07% kpktgend_1 [kernel.kallsyms] [k] net_rx_action
+ 22.29% 0.47% kpktgend_1 [kernel.kallsyms] [k] getRelativeCurNs
+ 21.33% 1.71% kpktgend_1 [kernel.kallsyms] [k] ixgbe_poll
+ 15.79% 0.02% kpktgend_1 [kernel.kallsyms] [k] ret_from_intr
+ 15.78% 0.01% kpktgend_1 [kernel.kallsyms] [k] do_IRQ
+ 15.34% 0.01% kpktgend_1 [kernel.kallsyms] [k] irq_exit
+ 13.95% 10.00% kpktgend_1 [kernel.kallsyms] [k] ip_send_check
+ 13.80% 13.80% kpktgend_1 [kernel.kallsyms] [k] __lock_acquire.isra.31
+ 12.98% 0.53% kpktgend_1 [kernel.kallsyms] [k] pktgen_finalize_skb
+ 12.31% 0.20% kpktgend_1 [kernel.kallsyms] [k] timestamp_skb.isra.24
+ 11.68% 0.13% kpktgend_1 [kernel.kallsyms] [k] napi_gro_receive
+ 11.36% 0.25% kpktgend_1 [kernel.kallsyms] [k] netif_receive_skb_internal
+ 10.93% 0.00% swapper [kernel.kallsyms] [k] verify_cpu
+ 10.93% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry
+ 10.92% 0.02% swapper [kernel.kallsyms] [k] do_idle
+ 10.71% 0.00% swapper [kernel.kallsyms] [k] cpuidle_enter
+ 10.71% 0.00% swapper [kernel.kallsyms] [k] call_cpuidle
+ 10.66% 0.06% swapper [kernel.kallsyms] [k] cpuidle_enter_state
+ 9.78% 0.00% swapper [kernel.kallsyms] [k] x86_64_start_kernel
+ 9.78% 0.00% swapper [kernel.kallsyms] [k] x86_64_start_reservations
+ 9.78% 0.00% swapper [kernel.kallsyms] [k] start_kernel
+ 9.78% 0.00% swapper [kernel.kallsyms] [k] rest_init
+ 9.25% 0.00% swapper [kernel.kallsyms] [k] ret_from_intr
+ 9.25% 0.00% swapper [kernel.kallsyms] [k] do_IRQ
+ 9.24% 0.30% kpktgend_1 [kernel.kallsyms] [k] pktgen_alloc_skb
+ 9.14% 0.00% swapper [kernel.kallsyms] [k] irq_exit
+ 8.89% 0.00% swapper [kernel.kallsyms] [k] __do_softirq
+ 8.82% 0.01% swapper [kernel.kallsyms] [k] net_rx_action
+ 8.80% 0.47% kpktgend_1 [kernel.kallsyms] [k] __local_bh_enable_ip
+ 8.67% 6.87% kpktgend_1 [kernel.kallsyms] [k] lock_release
+ 8.57% 1.10% kpktgend_1 [kernel.kallsyms] [k] __netdev_alloc_skb
+ 8.28% 0.00% kpktgend_1 [kernel.kallsyms] [k] do_softirq.part.17
+ 8.28% 0.00% kpktgend_1 [kernel.kallsyms] [k] do_softirq_own_stack
+ 8.01% 0.74% swapper [kernel.kallsyms] [k] ixgbe_poll
+ 6.85% 2.28% kpktgend_1 [kernel.kallsyms] [k] __build_skb
+ 4.89% 0.07% kpktgend_1 [kernel.kallsyms] [k] __netif_receive_skb
+ 4.87% 0.75% kpktgend_1 [kernel.kallsyms] [k] __netif_receive_skb_core
+ 4.66% 0.16% kpktgend_1 [kernel.kallsyms] [k] _raw_spin_lock
+ 4.37% 0.06% swapper [kernel.kallsyms] [k] napi_gro_receive
+ 4.23% 0.10% swapper [kernel.kallsyms] [k] netif_receive_skb_internal
Here is a 'bad' run of 4.16.0 + my full out-of-tree patches, including my normal pktgen changes
(pktgen code should be nearly identical between the run above and the run here)
Samples: 26K of event 'cycles:pp', Event count (approx.): 19888249841
Children Self Command Shared Object Symbol
+ 74.24% 5.38% kpktgend_1 [kernel.kallsyms] [k] pktgen_thread_worker
+ 73.89% 0.00% kpktgend_1 [kernel.kallsyms] [k] ret_from_fork
+ 73.89% 0.00% kpktgend_1 [kernel.kallsyms] [k] kthread
+ 27.31% 0.25% kpktgend_1 [kernel.kallsyms] [k] getnstimeofday64
+ 26.15% 4.24% kpktgend_1 [kernel.kallsyms] [k] __getnstimeofday64
+ 22.64% 0.02% kpktgend_1 [kernel.kallsyms] [k] __softirqentry_text_s
+ 22.62% 0.06% kpktgend_1 [kernel.kallsyms] [k] net_rx_action
+ 22.59% 2.04% kpktgend_1 [kernel.kallsyms] [k] ixgbe_poll
+ 21.49% 7.92% kpktgend_1 [kernel.kallsyms] [k] lock_acquire
+ 17.78% 17.78% kpktgend_1 [kernel.kallsyms] [k] __lock_acquire.isra.3
+ 15.95% 0.39% kpktgend_1 [kernel.kallsyms] [k] getRelativeCurNs
+ 14.49% 0.02% kpktgend_1 [kernel.kallsyms] [k] ret_from_intr
+ 14.48% 0.00% kpktgend_1 [kernel.kallsyms] [k] do_IRQ
+ 14.35% 0.01% kpktgend_1 [kernel.kallsyms] [k] irq_exit
+ 13.46% 9.90% kpktgend_1 [kernel.kallsyms] [k] ip_send_check
+ 11.36% 0.18% kpktgend_1 [kernel.kallsyms] [k] napi_gro_receive
+ 11.25% 0.17% kpktgend_1 [kernel.kallsyms] [k] netif_receive_skb_int
+ 10.37% 0.16% kpktgend_1 [kernel.kallsyms] [k] timestamp_skb.isra.25
+ 8.85% 0.45% kpktgend_1 [kernel.kallsyms] [k] __local_bh_enable_ip
+ 8.61% 0.02% swapper [kernel.kallsyms] [k] do_idle
+ 8.60% 0.00% swapper [kernel.kallsyms] [k] secondary_startup_64
+ 8.60% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry
+ 8.37% 0.05% swapper [kernel.kallsyms] [k] cpuidle_enter_state
+ 8.35% 7.57% kpktgend_1 [kernel.kallsyms] [k] lock_release
+ 8.32% 0.00% kpktgend_1 [kernel.kallsyms] [k] do_softirq.part.16
+ 8.31% 0.00% kpktgend_1 [kernel.kallsyms] [k] do_softirq_own_stack
+ 7.16% 0.36% kpktgend_1 [kernel.kallsyms] [k] pktgen_alloc_skb
+ 7.09% 1.14% kpktgend_1 [kernel.kallsyms] [k] __netdev_alloc_skb
+ 6.87% 0.00% swapper [kernel.kallsyms] [k] start_kernel
+ 6.55% 0.00% swapper [kernel.kallsyms] [k] ret_from_intr
+ 6.55% 0.01% swapper [kernel.kallsyms] [k] do_IRQ
+ 6.51% 0.01% swapper [kernel.kallsyms] [k] irq_exit
+ 6.34% 0.02% swapper [kernel.kallsyms] [k] __softirqentry_text_s
+ 6.25% 0.01% swapper [kernel.kallsyms] [k] net_rx_action
+ 6.06% 0.45% swapper [kernel.kallsyms] [k] ixgbe_poll
+ 5.35% 2.11% kpktgend_1 [kernel.kallsyms] [k] __build_skb
I tried testing with stock kernels and UDP user-space traffic, but results varied widely
from run to run, so it was useless for bisecting.
I have irqbalance disabled on this system in order to pin pktgen process and ixgbe IRQs
to be efficient, so maybe that is why user-space UDP traffic works so unreliably. My hacked pktgen
reliably shows good on my good 4.13 kernel and reliably bad on higher kernels I have compiled
so far, so I decided it was the only useful way to bisect this problem.
I will now try 4.14 and higher again with lockdep definitely disabled.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] socket statistics for ss
From: Eric Dumazet @ 2018-05-09 18:53 UTC (permalink / raw)
To: Stephen Hemminger, Eric Dumazet
Cc: davem, gerrit, kuznet, yoshfuji, netdev, dccp, Stephen Hemminger
In-Reply-To: <20180509114456.0303a026@xeon-e3>
On 05/09/2018 11:44 AM, Stephen Hemminger wrote:
> On Wed, 9 May 2018 10:53:58 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On 05/09/2018 10:31 AM, Stephen Hemminger wrote:
>>> On Wed, 9 May 2018 10:18:23 -0700
>>> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>
>>>> On 05/09/2018 08:22 AM, Stephen Hemminger wrote:
>>>>
>>>>> I am not sure if these patches are worth applying.
>>>>> The 'ss -s' command has had missing values since 2.4 kernel.
>>>>> And the first complaints came in only this year.
>>>>>
>>>>> Another alternative would be just to remove these fields from ss -s
>>>>> output and move on.
>>>>>
>>>>
>>>> Anyway your patches are not netns ready, so lets remove these fields from ss.
>>>>
>>>> Or you have to spend _much_ more time on writing and testing the kernel part.
>>>>
>>>> Thanks.
>>>
>>> The patches only expose the existing TCP socket accounting infrastructure.
>>> Several other pieces that sockstat has are not netns aware.
>>> That is a completely different problem.
>>
>>
>> Adding a new field counting 'bounds ports' without being netns ready is a total mistake,
>> as it is useless by current standards.
>>
>> The first thing that users will do is add proper netns support, with extra complexity in the kernel.
>>
>> So, instead of pushing some incomplete feature, trying to fool ourselves with a sentiment of 'small cost'
>> that will later need another 100 lines of code in the kernel, please give us the complete picture.
>>
>> I am just saying, you can of course ignore my feedback.
>
> The current TCP hashinfo should be moved into netns. The current method of scanning and matching
> by net namespace is a scalability issue now.
It is not the plan yet, and we have no scalability issue.
Before switching to netns hash table, this would need rhashtable conversions
but so far this has not been done.
- Time to create/delete netns is critical.
- Adding few Mbytes of overhead per netns is a nogo,
Please do not change subject, this is adding noise to this particular thread.
^ permalink raw reply
* [PATCH net-next] liquidio: bump up driver version to 1.7.2 to match newer NIC firmware
From: Felix Manlunas @ 2018-05-09 18:49 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/liquidio_common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
index 285b248..690424b 100644
--- a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
@@ -28,7 +28,7 @@
#define LIQUIDIO_PACKAGE ""
#define LIQUIDIO_BASE_MAJOR_VERSION 1
#define LIQUIDIO_BASE_MINOR_VERSION 7
-#define LIQUIDIO_BASE_MICRO_VERSION 0
+#define LIQUIDIO_BASE_MICRO_VERSION 2
#define LIQUIDIO_BASE_VERSION __stringify(LIQUIDIO_BASE_MAJOR_VERSION) "." \
__stringify(LIQUIDIO_BASE_MINOR_VERSION)
#define LIQUIDIO_MICRO_VERSION "." __stringify(LIQUIDIO_BASE_MICRO_VERSION)
^ permalink raw reply related
* Re: Performance regression between 4.13 and 4.14
From: Eric Dumazet @ 2018-05-09 18:48 UTC (permalink / raw)
To: Ben Greear, Eric Dumazet, netdev
In-Reply-To: <17a364e0-89c8-d4f6-3873-353c7dae4fba@candelatech.com>
On 05/09/2018 11:43 AM, Ben Greear wrote:
> On 05/08/2018 10:10 AM, Eric Dumazet wrote:
>>
>>
>> On 05/08/2018 09:44 AM, Ben Greear wrote:
>>> Hello,
>>>
>>> I am trying to track down a performance regression that appears to be between 4.13
>>> and 4.14.
>>>
>>> I first saw the problem with a hacked version of pktgen on some ixgbe NICs. 4.13 can do
>>> right at 10G bi-directional on two ports, and 4.14 and later can do only about 6Gbps.
>>>
>>> I also tried with user-space UDP traffic on a stock kernel, and I can get about 3.2Gbps combined tx+rx
>>> on 4.14 and about 4.4Gbps on 4.13.
>>>
>>> Attempting to bisect seems to be triggering a weirdness in git, and also lots of commits
>>> crash or do not bring up networking, which makes the bisect difficult.
>>>
>>> Looking at perf top, it would appear that some lock is probably to blame.
>>
>>
>> perf record -a -g -e cycles:pp sleep 5
>> perf report
>>
>> Then you'll be able to tell us which lock (or call graph) is killing your perf.
>>
>
> I seem to be chasing multiple issues. For 4.13, at least part of my problem was that LOCKDEP was enabled,
> during my bisect, though it does NOT appear enabled in 4.16. I think maybe CONFIG_LOCKDEP moved to CONFIG_PROVE_LOCKING
> in 4.16, or something like that? My 4.16 .config does have CONFIG_LOCKDEP_SUPPORT enabled, and I see no option to disable it:
>
> [greearb@ben-dt3 linux-4.16.x64]$ grep LOCKDEP .config
> CONFIG_LOCKDEP_SUPPORT=y
>
>
> For 4.16, I am disabling RETRAMPOLINE...are there any other such things I need
> to disable to keep from getting a performance hit from the spectre-related bug
> fixes? At this point, I do not care about the security implications.
>
> greearb@ben-dt3 linux-4.16.x64]$ grep RETPO .config
> # CONFIG_RETPOLINE is not set
>
>
> Thanks,
> Ben
>
No idea really, you mention a 4.13 -> 4.14 regression and jump then to 4.16 :/
Before doing a (painful) dissection, the perf output would immediately tell you if
something is really wrong on your .config.
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] socket statistics for ss
From: Stephen Hemminger @ 2018-05-09 18:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, gerrit, kuznet, yoshfuji, netdev, dccp, Stephen Hemminger
In-Reply-To: <57fc8849-d1a4-4748-8780-bca3b0c7ca47@gmail.com>
On Wed, 9 May 2018 10:53:58 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On 05/09/2018 10:31 AM, Stephen Hemminger wrote:
> > On Wed, 9 May 2018 10:18:23 -0700
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >> On 05/09/2018 08:22 AM, Stephen Hemminger wrote:
> >>
> >>> I am not sure if these patches are worth applying.
> >>> The 'ss -s' command has had missing values since 2.4 kernel.
> >>> And the first complaints came in only this year.
> >>>
> >>> Another alternative would be just to remove these fields from ss -s
> >>> output and move on.
> >>>
> >>
> >> Anyway your patches are not netns ready, so lets remove these fields from ss.
> >>
> >> Or you have to spend _much_ more time on writing and testing the kernel part.
> >>
> >> Thanks.
> >
> > The patches only expose the existing TCP socket accounting infrastructure.
> > Several other pieces that sockstat has are not netns aware.
> > That is a completely different problem.
>
>
> Adding a new field counting 'bounds ports' without being netns ready is a total mistake,
> as it is useless by current standards.
>
> The first thing that users will do is add proper netns support, with extra complexity in the kernel.
>
> So, instead of pushing some incomplete feature, trying to fool ourselves with a sentiment of 'small cost'
> that will later need another 100 lines of code in the kernel, please give us the complete picture.
>
> I am just saying, you can of course ignore my feedback.
The current TCP hashinfo should be moved into netns. The current method of scanning and matching
by net namespace is a scalability issue now.
^ permalink raw reply
* Re: Performance regression between 4.13 and 4.14
From: Ben Greear @ 2018-05-09 18:43 UTC (permalink / raw)
To: Eric Dumazet, netdev
In-Reply-To: <b411b57e-9d2f-3ca0-f9b7-19dd2238675c@gmail.com>
On 05/08/2018 10:10 AM, Eric Dumazet wrote:
>
>
> On 05/08/2018 09:44 AM, Ben Greear wrote:
>> Hello,
>>
>> I am trying to track down a performance regression that appears to be between 4.13
>> and 4.14.
>>
>> I first saw the problem with a hacked version of pktgen on some ixgbe NICs. 4.13 can do
>> right at 10G bi-directional on two ports, and 4.14 and later can do only about 6Gbps.
>>
>> I also tried with user-space UDP traffic on a stock kernel, and I can get about 3.2Gbps combined tx+rx
>> on 4.14 and about 4.4Gbps on 4.13.
>>
>> Attempting to bisect seems to be triggering a weirdness in git, and also lots of commits
>> crash or do not bring up networking, which makes the bisect difficult.
>>
>> Looking at perf top, it would appear that some lock is probably to blame.
>
>
> perf record -a -g -e cycles:pp sleep 5
> perf report
>
> Then you'll be able to tell us which lock (or call graph) is killing your perf.
>
I seem to be chasing multiple issues. For 4.13, at least part of my problem was that LOCKDEP was enabled,
during my bisect, though it does NOT appear enabled in 4.16. I think maybe CONFIG_LOCKDEP moved to CONFIG_PROVE_LOCKING
in 4.16, or something like that? My 4.16 .config does have CONFIG_LOCKDEP_SUPPORT enabled, and I see no option to disable it:
[greearb@ben-dt3 linux-4.16.x64]$ grep LOCKDEP .config
CONFIG_LOCKDEP_SUPPORT=y
For 4.16, I am disabling RETRAMPOLINE...are there any other such things I need
to disable to keep from getting a performance hit from the spectre-related bug
fixes? At this point, I do not care about the security implications.
greearb@ben-dt3 linux-4.16.x64]$ grep RETPO .config
# CONFIG_RETPOLINE is not set
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH net-next] liquidio: monitor all of Octeon's cores in watchdog thread
From: Felix Manlunas @ 2018-05-09 18:31 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
The liquidio_watchdog kernel thread is watching over only 12 cores of the
Octeon CN23XX; it's neglecting the other 4 cores that are present in the
CN2360. Fix it by defining LIO_MAX_CORES as 16.
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/octeon_network.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_network.h b/drivers/net/ethernet/cavium/liquidio/octeon_network.h
index dd3177a..d7a3916 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_network.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_network.h
@@ -192,7 +192,7 @@ struct lio {
#define LIO_SIZE (sizeof(struct lio))
#define GET_LIO(netdev) ((struct lio *)netdev_priv(netdev))
-#define LIO_MAX_CORES 12
+#define LIO_MAX_CORES 16
/**
* \brief Enable or disable feature
^ permalink raw reply related
* [net-next v2 1/6] fm10k: setup VLANs for l2 accelerated macvlan interfaces
From: Jeff Kirsher @ 2018-05-09 18:10 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180509181011.30907-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
We have support for accelerating macvlan devices via the
.ndo_dfwd_add_station() netdev op. These accelerated macvlan MAC
addresses are stored in the l2_accel structure, separate from the
unicast or multicast address lists.
If a VLAN is added on top of the macvlan device by the stack, traffic
will not properly flow to the macvlan. This occurs because we fail to
setup the VLANs for l2_accel MAC addresses.
In the non-offloaded case the MAC address is added to the unicast
address list, and thus the normal setup for enabling VLANs works as
expected.
We also need to add VLANs marked from .ndo_vlan_rx_add_vid() into the
l2_accel MAC addresses. Otherwise, VLAN traffic will not properly be
received by the VLAN devices attached to the offloaded macvlan devices.
Fix this by adding necessary logic to setup VLANs not only for the
unicast and multicast addresses, but also the l2_accel list. We need
similar logic in dfwd_add_station, dfwd_del_station, fm10k_update_vid,
and fm10k_restore_rx_state.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/fm10k/fm10k_netdev.c | 50 ++++++++++++++++++-
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index c879af72bbf5..0dc9f2dbc1ad 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -907,7 +907,9 @@ static int fm10k_mc_vlan_unsync(struct net_device *netdev,
static int fm10k_update_vid(struct net_device *netdev, u16 vid, bool set)
{
struct fm10k_intfc *interface = netdev_priv(netdev);
+ struct fm10k_l2_accel *l2_accel = interface->l2_accel;
struct fm10k_hw *hw = &interface->hw;
+ u16 glort;
s32 err;
int i;
@@ -975,6 +977,22 @@ static int fm10k_update_vid(struct net_device *netdev, u16 vid, bool set)
if (err)
goto err_out;
+ /* Update L2 accelerated macvlan addresses */
+ if (l2_accel) {
+ for (i = 0; i < l2_accel->size; i++) {
+ struct net_device *sdev = l2_accel->macvlan[i];
+
+ if (!sdev)
+ continue;
+
+ glort = l2_accel->dglort + 1 + i;
+
+ fm10k_queue_mac_request(interface, glort,
+ sdev->dev_addr,
+ vid, set);
+ }
+ }
+
/* set VLAN ID prior to syncing/unsyncing the VLAN */
interface->vid = vid + (set ? VLAN_N_VID : 0);
@@ -1214,6 +1232,22 @@ void fm10k_restore_rx_state(struct fm10k_intfc *interface)
fm10k_queue_mac_request(interface, glort,
hw->mac.addr, vid, true);
+
+ /* synchronize macvlan addresses */
+ if (l2_accel) {
+ for (i = 0; i < l2_accel->size; i++) {
+ struct net_device *sdev = l2_accel->macvlan[i];
+
+ if (!sdev)
+ continue;
+
+ glort = l2_accel->dglort + 1 + i;
+
+ fm10k_queue_mac_request(interface, glort,
+ sdev->dev_addr,
+ vid, true);
+ }
+ }
}
/* update xcast mode before synchronizing addresses if host's mailbox
@@ -1430,7 +1464,7 @@ static void *fm10k_dfwd_add_station(struct net_device *dev,
struct fm10k_dglort_cfg dglort = { 0 };
struct fm10k_hw *hw = &interface->hw;
int size = 0, i;
- u16 glort;
+ u16 vid, glort;
/* The hardware supported by fm10k only filters on the destination MAC
* address. In order to avoid issues we only support offloading modes
@@ -1510,6 +1544,12 @@ static void *fm10k_dfwd_add_station(struct net_device *dev,
hw->mac.default_vid, true);
}
+ for (vid = fm10k_find_next_vlan(interface, 0);
+ vid < VLAN_N_VID;
+ vid = fm10k_find_next_vlan(interface, vid))
+ fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
+ vid, true);
+
fm10k_mbx_unlock(interface);
return sdev;
@@ -1522,8 +1562,8 @@ static void fm10k_dfwd_del_station(struct net_device *dev, void *priv)
struct fm10k_dglort_cfg dglort = { 0 };
struct fm10k_hw *hw = &interface->hw;
struct net_device *sdev = priv;
+ u16 vid, glort;
int i;
- u16 glort;
if (!l2_accel)
return;
@@ -1550,6 +1590,12 @@ static void fm10k_dfwd_del_station(struct net_device *dev, void *priv)
hw->mac.default_vid, false);
}
+ for (vid = fm10k_find_next_vlan(interface, 0);
+ vid < VLAN_N_VID;
+ vid = fm10k_find_next_vlan(interface, vid))
+ fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
+ vid, false);
+
fm10k_mbx_unlock(interface);
/* record removal */
--
2.17.0
^ permalink raw reply related
* [net-next v2 4/6] fm10k: use macro to avoid passing the array and size separately
From: Jeff Kirsher @ 2018-05-09 18:10 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180509181011.30907-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Avoid potential bugs with fm10k_add_stat_strings and
fm10k_add_ethtool_stats by using a macro to calculate the ARRAY_SIZE
when passing. This helps ensure that the size is always correct.
Note that it assumes we only pass static const fm10k_stat arrays, and
that evaluation of the argument won't have side effects.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/fm10k/fm10k_ethtool.c | 48 ++++++++-----------
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
index 17d2388e71a2..09fa1a30ee3e 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
@@ -135,8 +135,8 @@ enum {
static const char fm10k_prv_flags[FM10K_PRV_FLAG_LEN][ETH_GSTRING_LEN] = {
};
-static void fm10k_add_stat_strings(u8 **p, const struct fm10k_stats stats[],
- const unsigned int size, ...)
+static void __fm10k_add_stat_strings(u8 **p, const struct fm10k_stats stats[],
+ const unsigned int size, ...)
{
unsigned int i;
@@ -150,31 +150,28 @@ static void fm10k_add_stat_strings(u8 **p, const struct fm10k_stats stats[],
}
}
+#define fm10k_add_stat_strings(p, stats, ...) \
+ __fm10k_add_stat_strings(p, stats, ARRAY_SIZE(stats), ## __VA_ARGS__)
+
static void fm10k_get_stat_strings(struct net_device *dev, u8 *data)
{
struct fm10k_intfc *interface = netdev_priv(dev);
unsigned int i;
- fm10k_add_stat_strings(&data, fm10k_gstrings_net_stats,
- FM10K_NETDEV_STATS_LEN);
+ fm10k_add_stat_strings(&data, fm10k_gstrings_net_stats);
- fm10k_add_stat_strings(&data, fm10k_gstrings_global_stats,
- FM10K_GLOBAL_STATS_LEN);
+ fm10k_add_stat_strings(&data, fm10k_gstrings_global_stats);
- fm10k_add_stat_strings(&data, fm10k_gstrings_mbx_stats,
- FM10K_MBX_STATS_LEN);
+ fm10k_add_stat_strings(&data, fm10k_gstrings_mbx_stats);
if (interface->hw.mac.type != fm10k_mac_vf)
- fm10k_add_stat_strings(&data, fm10k_gstrings_pf_stats,
- FM10K_PF_STATS_LEN);
+ fm10k_add_stat_strings(&data, fm10k_gstrings_pf_stats);
for (i = 0; i < interface->hw.mac.max_queues; i++) {
fm10k_add_stat_strings(&data, fm10k_gstrings_queue_stats,
- FM10K_QUEUE_STATS_LEN,
"tx", i);
fm10k_add_stat_strings(&data, fm10k_gstrings_queue_stats,
- FM10K_QUEUE_STATS_LEN,
"rx", i);
}
}
@@ -220,9 +217,9 @@ static int fm10k_get_sset_count(struct net_device *dev, int sset)
}
}
-static void fm10k_add_ethtool_stats(u64 **data, void *pointer,
- const struct fm10k_stats stats[],
- const unsigned int size)
+static void __fm10k_add_ethtool_stats(u64 **data, void *pointer,
+ const struct fm10k_stats stats[],
+ const unsigned int size)
{
unsigned int i;
char *p;
@@ -256,6 +253,9 @@ static void fm10k_add_ethtool_stats(u64 **data, void *pointer,
}
}
+#define fm10k_add_ethtool_stats(data, pointer, stats) \
+ __fm10k_add_ethtool_stats(data, pointer, stats, ARRAY_SIZE(stats))
+
static void fm10k_get_ethtool_stats(struct net_device *netdev,
struct ethtool_stats __always_unused *stats,
u64 *data)
@@ -266,20 +266,16 @@ static void fm10k_get_ethtool_stats(struct net_device *netdev,
fm10k_update_stats(interface);
- fm10k_add_ethtool_stats(&data, net_stats, fm10k_gstrings_net_stats,
- FM10K_NETDEV_STATS_LEN);
+ fm10k_add_ethtool_stats(&data, net_stats, fm10k_gstrings_net_stats);
- fm10k_add_ethtool_stats(&data, interface, fm10k_gstrings_global_stats,
- FM10K_GLOBAL_STATS_LEN);
+ fm10k_add_ethtool_stats(&data, interface, fm10k_gstrings_global_stats);
fm10k_add_ethtool_stats(&data, &interface->hw.mbx,
- fm10k_gstrings_mbx_stats,
- FM10K_MBX_STATS_LEN);
+ fm10k_gstrings_mbx_stats);
if (interface->hw.mac.type != fm10k_mac_vf) {
fm10k_add_ethtool_stats(&data, interface,
- fm10k_gstrings_pf_stats,
- FM10K_PF_STATS_LEN);
+ fm10k_gstrings_pf_stats);
}
for (i = 0; i < interface->hw.mac.max_queues; i++) {
@@ -287,13 +283,11 @@ static void fm10k_get_ethtool_stats(struct net_device *netdev,
ring = interface->tx_ring[i];
fm10k_add_ethtool_stats(&data, ring,
- fm10k_gstrings_queue_stats,
- FM10K_QUEUE_STATS_LEN);
+ fm10k_gstrings_queue_stats);
ring = interface->rx_ring[i];
fm10k_add_ethtool_stats(&data, ring,
- fm10k_gstrings_queue_stats,
- FM10K_QUEUE_STATS_LEN);
+ fm10k_gstrings_queue_stats);
}
}
--
2.17.0
^ permalink raw reply related
* [net-next v2 0/6][pull request] 100GbE Intel Wired LAN Driver Updates 2018-05-09
From: Jeff Kirsher @ 2018-05-09 18:10 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to fm10k only.
Jake provides all the changes in the series, starting with adding
support for accelerated MACVLAN devices. Reduced code duplication by
implementing a macro to be used when setting up the type specific
macros. Avoided potential bugs with stats by using a macro to calculate
the array size when passing to ensure that the size is correct.
v2: changed macro reference '#' with __stringify() as suggested by
Joe Perches to patch 2 of the series. Also made sure the updated
series of patches is actually pushed to my kernel.org tree
The following are changes since commit 53a7bdfb2a2756cce8003b90817f8a6fb4d830d9:
dt-bindings: dsa: Remove unnecessary #address/#size-cells
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 100GbE
Jacob Keller (6):
fm10k: setup VLANs for l2 accelerated macvlan interfaces
fm10k: reduce duplicate fm10k_stat macro code
fm10k: use variadic arguments to fm10k_add_stat_strings
fm10k: use macro to avoid passing the array and size separately
fm10k: warn if the stat size is unknown
fm10k: don't protect fm10k_queue_mac_request by fm10k_host_mbx_ready
.../net/ethernet/intel/fm10k/fm10k_ethtool.c | 116 +++++++++---------
.../net/ethernet/intel/fm10k/fm10k_netdev.c | 62 ++++++++--
2 files changed, 111 insertions(+), 67 deletions(-)
--
2.17.0
^ permalink raw reply
* [net-next v2 2/6] fm10k: reduce duplicate fm10k_stat macro code
From: Jeff Kirsher @ 2018-05-09 18:10 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180509181011.30907-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Share some of the code for setting up fm10k_stat macros by implementing
an FM10K_STAT_FIELDS macro which we can use when setting up the type
specific macros.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
v2: use __stringify() macro in definition of FM10K_NETDEV_STAT
.../net/ethernet/intel/fm10k/fm10k_ethtool.c | 29 ++++++++++---------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
index eeac2b75a195..471dfd92d41b 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
@@ -11,12 +11,17 @@ struct fm10k_stats {
int stat_offset;
};
-#define FM10K_NETDEV_STAT(_net_stat) { \
- .stat_string = #_net_stat, \
- .sizeof_stat = FIELD_SIZEOF(struct net_device_stats, _net_stat), \
- .stat_offset = offsetof(struct net_device_stats, _net_stat) \
+#define FM10K_STAT_FIELDS(_type, _name, _stat) { \
+ .stat_string = _name, \
+ .sizeof_stat = FIELD_SIZEOF(_type, _stat), \
+ .stat_offset = offsetof(_type, _stat) \
}
+/* netdevice statistics */
+#define FM10K_NETDEV_STAT(_net_stat) \
+ FM10K_STAT_FIELDS(struct net_device_stats, __stringify(_net_stat), \
+ _net_stat)
+
static const struct fm10k_stats fm10k_gstrings_net_stats[] = {
FM10K_NETDEV_STAT(tx_packets),
FM10K_NETDEV_STAT(tx_bytes),
@@ -34,11 +39,9 @@ static const struct fm10k_stats fm10k_gstrings_net_stats[] = {
#define FM10K_NETDEV_STATS_LEN ARRAY_SIZE(fm10k_gstrings_net_stats)
-#define FM10K_STAT(_name, _stat) { \
- .stat_string = _name, \
- .sizeof_stat = FIELD_SIZEOF(struct fm10k_intfc, _stat), \
- .stat_offset = offsetof(struct fm10k_intfc, _stat) \
-}
+/* General interface statistics */
+#define FM10K_STAT(_name, _stat) \
+ FM10K_STAT_FIELDS(struct fm10k_intfc, _name, _stat)
static const struct fm10k_stats fm10k_gstrings_global_stats[] = {
FM10K_STAT("tx_restart_queue", restart_queue),
@@ -75,11 +78,9 @@ static const struct fm10k_stats fm10k_gstrings_pf_stats[] = {
FM10K_STAT("nodesc_drop", stats.nodesc_drop.count),
};
-#define FM10K_MBX_STAT(_name, _stat) { \
- .stat_string = _name, \
- .sizeof_stat = FIELD_SIZEOF(struct fm10k_mbx_info, _stat), \
- .stat_offset = offsetof(struct fm10k_mbx_info, _stat) \
-}
+/* mailbox statistics */
+#define FM10K_MBX_STAT(_name, _stat) \
+ FM10K_STAT_FIELDS(struct fm10k_mbx_info, _name, _stat)
static const struct fm10k_stats fm10k_gstrings_mbx_stats[] = {
FM10K_MBX_STAT("mbx_tx_busy", tx_busy),
--
2.17.0
^ permalink raw reply related
* [net-next v2 3/6] fm10k: use variadic arguments to fm10k_add_stat_strings
From: Jeff Kirsher @ 2018-05-09 18:10 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180509181011.30907-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Instead of using a fixed prefix string we setup before each call to
fm10k_add_stat_strings, modify the helper to take variadic arguments and
pass them to vsnprintf. This requires changing the fm10k_stat strings to
take % format specifiers where necessary, but the resulting code is much
simpler.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/fm10k/fm10k_ethtool.c | 53 ++++++++++---------
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
index 471dfd92d41b..17d2388e71a2 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
@@ -6,6 +6,11 @@
#include "fm10k.h"
struct fm10k_stats {
+ /* The stat_string is expected to be a format string formatted using
+ * vsnprintf by fm10k_add_stat_strings. Every member of a stats array
+ * should use the same format specifiers as they will be formatted
+ * using the same variadic arguments.
+ */
char stat_string[ETH_GSTRING_LEN];
int sizeof_stat;
int stat_offset;
@@ -94,15 +99,13 @@ static const struct fm10k_stats fm10k_gstrings_mbx_stats[] = {
FM10K_MBX_STAT("mbx_rx_mbmem_pushed", rx_mbmem_pushed),
};
-#define FM10K_QUEUE_STAT(_name, _stat) { \
- .stat_string = _name, \
- .sizeof_stat = FIELD_SIZEOF(struct fm10k_ring, _stat), \
- .stat_offset = offsetof(struct fm10k_ring, _stat) \
-}
+/* per-queue ring statistics */
+#define FM10K_QUEUE_STAT(_name, _stat) \
+ FM10K_STAT_FIELDS(struct fm10k_ring, _name, _stat)
static const struct fm10k_stats fm10k_gstrings_queue_stats[] = {
- FM10K_QUEUE_STAT("packets", stats.packets),
- FM10K_QUEUE_STAT("bytes", stats.bytes),
+ FM10K_QUEUE_STAT("%s_queue_%u_packets", stats.packets),
+ FM10K_QUEUE_STAT("%s_queue_%u_bytes", stats.bytes),
};
#define FM10K_GLOBAL_STATS_LEN ARRAY_SIZE(fm10k_gstrings_global_stats)
@@ -132,16 +135,18 @@ enum {
static const char fm10k_prv_flags[FM10K_PRV_FLAG_LEN][ETH_GSTRING_LEN] = {
};
-static void fm10k_add_stat_strings(u8 **p, const char *prefix,
- const struct fm10k_stats stats[],
- const unsigned int size)
+static void fm10k_add_stat_strings(u8 **p, const struct fm10k_stats stats[],
+ const unsigned int size, ...)
{
unsigned int i;
for (i = 0; i < size; i++) {
- snprintf(*p, ETH_GSTRING_LEN, "%s%s",
- prefix, stats[i].stat_string);
+ va_list args;
+
+ va_start(args, size);
+ vsnprintf(*p, ETH_GSTRING_LEN, stats[i].stat_string, args);
*p += ETH_GSTRING_LEN;
+ va_end(args);
}
}
@@ -150,31 +155,27 @@ static void fm10k_get_stat_strings(struct net_device *dev, u8 *data)
struct fm10k_intfc *interface = netdev_priv(dev);
unsigned int i;
- fm10k_add_stat_strings(&data, "", fm10k_gstrings_net_stats,
+ fm10k_add_stat_strings(&data, fm10k_gstrings_net_stats,
FM10K_NETDEV_STATS_LEN);
- fm10k_add_stat_strings(&data, "", fm10k_gstrings_global_stats,
+ fm10k_add_stat_strings(&data, fm10k_gstrings_global_stats,
FM10K_GLOBAL_STATS_LEN);
- fm10k_add_stat_strings(&data, "", fm10k_gstrings_mbx_stats,
+ fm10k_add_stat_strings(&data, fm10k_gstrings_mbx_stats,
FM10K_MBX_STATS_LEN);
if (interface->hw.mac.type != fm10k_mac_vf)
- fm10k_add_stat_strings(&data, "", fm10k_gstrings_pf_stats,
+ fm10k_add_stat_strings(&data, fm10k_gstrings_pf_stats,
FM10K_PF_STATS_LEN);
for (i = 0; i < interface->hw.mac.max_queues; i++) {
- char prefix[ETH_GSTRING_LEN];
-
- snprintf(prefix, ETH_GSTRING_LEN, "tx_queue_%u_", i);
- fm10k_add_stat_strings(&data, prefix,
- fm10k_gstrings_queue_stats,
- FM10K_QUEUE_STATS_LEN);
+ fm10k_add_stat_strings(&data, fm10k_gstrings_queue_stats,
+ FM10K_QUEUE_STATS_LEN,
+ "tx", i);
- snprintf(prefix, ETH_GSTRING_LEN, "rx_queue_%u_", i);
- fm10k_add_stat_strings(&data, prefix,
- fm10k_gstrings_queue_stats,
- FM10K_QUEUE_STATS_LEN);
+ fm10k_add_stat_strings(&data, fm10k_gstrings_queue_stats,
+ FM10K_QUEUE_STATS_LEN,
+ "rx", i);
}
}
--
2.17.0
^ permalink raw reply related
* [net-next v2 5/6] fm10k: warn if the stat size is unknown
From: Jeff Kirsher @ 2018-05-09 18:10 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180509181011.30907-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
index 09fa1a30ee3e..7657daa27298 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
@@ -248,6 +248,8 @@ static void __fm10k_add_ethtool_stats(u64 **data, void *pointer,
*((*data)++) = *(u8 *)p;
break;
default:
+ WARN_ONCE(1, "unexpected stat size for %s",
+ stats[i].stat_string);
*((*data)++) = 0;
}
}
--
2.17.0
^ permalink raw reply related
* [net-next v2 6/6] fm10k: don't protect fm10k_queue_mac_request by fm10k_host_mbx_ready
From: Jeff Kirsher @ 2018-05-09 18:10 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180509181011.30907-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
We don't actually need to check if the host mbx is ready when queuing
MAC requests, because these are not handled by a special queue which
queues up requests until the mailbox is capable of handling them.
Pull these requests outside the fm10k_host_mbx_ready() check, as it is
not necessary.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index 0dc9f2dbc1ad..929f538d28bc 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -1537,12 +1537,12 @@ static void *fm10k_dfwd_add_station(struct net_device *dev,
glort = l2_accel->dglort + 1 + i;
- if (fm10k_host_mbx_ready(interface)) {
+ if (fm10k_host_mbx_ready(interface))
hw->mac.ops.update_xcast_mode(hw, glort,
FM10K_XCAST_MODE_NONE);
- fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
- hw->mac.default_vid, true);
- }
+
+ fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
+ hw->mac.default_vid, true);
for (vid = fm10k_find_next_vlan(interface, 0);
vid < VLAN_N_VID;
@@ -1583,12 +1583,12 @@ static void fm10k_dfwd_del_station(struct net_device *dev, void *priv)
glort = l2_accel->dglort + 1 + i;
- if (fm10k_host_mbx_ready(interface)) {
+ if (fm10k_host_mbx_ready(interface))
hw->mac.ops.update_xcast_mode(hw, glort,
FM10K_XCAST_MODE_NONE);
- fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
- hw->mac.default_vid, false);
- }
+
+ fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
+ hw->mac.default_vid, false);
for (vid = fm10k_find_next_vlan(interface, 0);
vid < VLAN_N_VID;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] can: hi311x: Acquire SPI lock on ->do_get_berr_counter
From: Akshay Bhat @ 2018-05-09 17:58 UTC (permalink / raw)
To: Lukas Wunner, Marc Kleine-Budde, Wolfgang Grandegger, linux-can,
netdev
Cc: Mathias Duckeck, Casey Fitzpatrick, Stef Walter, Karel Zak
In-Reply-To: <b1518690dd293a008959b56cc52f3f29f52be25e.1525869191.git.lukas@wunner.de>
On 05/09/2018 08:38 AM, Lukas Wunner wrote:
> hi3110_get_berr_counter() may run concurrently to the rest of the driver
> but neglects to acquire the lock protecting access to the SPI device.
> As a result, it and the rest of the driver may clobber each other's tx
> and rx buffers.
>
> We became aware of this issue because transmission of packets with
> "cangen -g 0 -i -x" frequently hung. It turns out that agetty executes
> ->do_get_berr_counter every few seconds via the following call stack:
>
> CPU: 2 PID: 1605 Comm: agetty
> [<7f3f7500>] (hi3110_get_berr_counter [hi311x])
> [<7f130204>] (can_fill_info [can_dev])
> [<80693bc0>] (rtnl_fill_ifinfo)
> [<806949ec>] (rtnl_dump_ifinfo)
> [<806b4834>] (netlink_dump)
> [<806b4bc8>] (netlink_recvmsg)
> [<8065f180>] (sock_recvmsg)
> [<80660f90>] (___sys_recvmsg)
> [<80661e7c>] (__sys_recvmsg)
> [<80661ec0>] (SyS_recvmsg)
> [<80108b20>] (ret_fast_syscall+0x0/0x1c)
>
> agetty listens to netlink messages in order to update the login prompt
> when IP addresses change (if /etc/issue contains \4 or \6 escape codes):
> https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=e36deb6424e8
>
> It's a useful feature, though it seems questionable that it causes CAN
> bit error statistics to be queried.
>
> Be that as it may, if hi3110_get_berr_counter() is invoked while a frame
> is sent by hi3110_hw_tx(), bogus SPI transfers like the following may
> occur:
>
> => 12 00 (hi3110_get_berr_counter() wanted to transmit
> EC 00 to query the transmit error counter,
> but the first byte was overwritten by
> hi3110_hw_tx_frame())
>
> => EA 00 3E 80 01 FB (hi3110_hw_tx_frame() wanted to transmit a
> frame, but the first byte was overwritten by
> hi3110_get_berr_counter() because it wanted
> to query the receive error counter)
>
> This sequence hangs the transmission because the driver believes it has
> sent a frame and waits for the interrupt signaling completion, but in
> reality the chip has never sent away the frame since the commands it
> received were malformed.
>
> Fix by acquiring the SPI lock in hi3110_get_berr_counter().
>
> I've scrutinized the entire driver for further unlocked SPI accesses but
> found no others.
>
> Cc: Mathias Duckeck <m.duckeck@kunbus.de>
> Cc: Akshay Bhat <akshay.bhat@timesys.com>
> Cc: Casey Fitzpatrick <casey.fitzpatrick@timesys.com>
> Cc: Stef Walter <stefw@redhat.com>
> Cc: Karel Zak <kzak@redhat.com>
> Cc: stable@vger.kernel.org # v4.12+
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
Reviewed-by: Akshay Bhat <akshay.bhat@timesys.com>
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] socket statistics for ss
From: Eric Dumazet @ 2018-05-09 17:53 UTC (permalink / raw)
To: Stephen Hemminger, Eric Dumazet
Cc: davem, gerrit, kuznet, yoshfuji, netdev, dccp, Stephen Hemminger
In-Reply-To: <20180509103144.195e7494@xeon-e3>
On 05/09/2018 10:31 AM, Stephen Hemminger wrote:
> On Wed, 9 May 2018 10:18:23 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On 05/09/2018 08:22 AM, Stephen Hemminger wrote:
>>
>>> I am not sure if these patches are worth applying.
>>> The 'ss -s' command has had missing values since 2.4 kernel.
>>> And the first complaints came in only this year.
>>>
>>> Another alternative would be just to remove these fields from ss -s
>>> output and move on.
>>>
>>
>> Anyway your patches are not netns ready, so lets remove these fields from ss.
>>
>> Or you have to spend _much_ more time on writing and testing the kernel part.
>>
>> Thanks.
>
> The patches only expose the existing TCP socket accounting infrastructure.
> Several other pieces that sockstat has are not netns aware.
> That is a completely different problem.
Adding a new field counting 'bounds ports' without being netns ready is a total mistake,
as it is useless by current standards.
The first thing that users will do is add proper netns support, with extra complexity in the kernel.
So, instead of pushing some incomplete feature, trying to fool ourselves with a sentiment of 'small cost'
that will later need another 100 lines of code in the kernel, please give us the complete picture.
I am just saying, you can of course ignore my feedback.
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Michel Machado @ 2018-05-09 17:37 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang
Cc: Nishanth Devarajan, Jiri Pirko, David Miller,
Linux Kernel Network Developers, Cody Doucette
In-Reply-To: <bee1e54d-e2eb-1393-1a4e-d54e731f7bfc@mojatatu.com>
On 05/09/2018 10:43 AM, Jamal Hadi Salim wrote:
> On 08/05/18 10:27 PM, Cong Wang wrote:
>> On Tue, May 8, 2018 at 6:29 AM, Jamal Hadi Salim <jhs@mojatatu.com>
>> wrote:
>>> Have you considered using skb->prio instead of peeking into the packet
>>> header.
>>> Also have you looked at the dsmark qdisc?
>>>
>>
>> dsmark modifies ds fields, while this one just maps ds fields into
>> different queues.
>>
>
> Yeah, I was thinking more of re-using it for the purpose of mapping to
> queues - but would require a lot more work.
>
> once skbprio is set by something[1] then this qdisc could be used by
> other subsystems (8021q, sockets etc); so i would argue for removal
> of the embedded classification and instead maybe writing a simple
> extension to skbmod to mark skbprio based on ds.
I like the suggestion of extending skbmod to mark skbprio based on ds.
Given that DSprio would no longer depend on the DS field, would you have
a name suggestion for this new queue discipline since the name "prio" is
currently in use?
What should be the range of priorities that this new queue discipline
would accept? skb->prioriry is of type __u32, but supporting 2^32
priorities would require too large of an array to index packets by
priority; the DS field is only 6 bits long. Do you have a use case in
mind to guide us here?
> I find the cleverness in changing the highest/low prios confusing.
> It looks error-prone (I guess that is why there is a BUG check)
> To the authors: Is there a document/paper on the theory of this thing
> as to why no explicit queues are "faster"?
The priority orientation in GKprio is due to two factors: failing safe
and elegance. If zero were the highest priority, any operational mistake
that leads not-classified packets through GKprio would potentially
disrupt the system. We are humans, we'll make mistakes. The elegance
aspect comes from the fact that the assigned priority is not massaged to
fit the DS field. We find it helpful while inspecting packets on the wire.
The reason for us to avoid explicit queues in GKprio, which could change
the behavior within a given priority, is to closely abide to the
expected behavior assumed to prove Theorem 4.1 in the paper "Portcullis:
Protecting Connection Setup from Denial-of-Capability Attacks":
https://dl.acm.org/citation.cfm?id=1282413
> 1) I agree that using multiple queues as in prio qdisc would make it
> more manageable; does not necessarily need to be classful if you
> use implicit skbprio classification. i.e on equeue use a priority
> map to select a queue; on dequeue always dequeu from highest prio
> until it has no more packets to send.
In my reply to Cong, I point out that there is a technical limitation
in the interface of queue disciplines that forbids GKprio to have
explicit sub-queues:
https://www.mail-archive.com/netdev@vger.kernel.org/msg234201.html
> 2) Dropping already enqueued packets will not work well for
> local feedback (__NET_XMIT_BYPASS return code is about the
> packet that has been dropped from earlier enqueueing because
> it is lower priority - it does not signify anything with
> current skb to which actually just got enqueud).
> Perhaps (off top of my head) is to always enqueue packets on
> high priority when their limit is exceeded as long as lower prio has
> some space. Means youd have to increment low prio accounting if their
> space is used.
I don't understand the point you are making here. Could you develop it
further?
[ ]'s
Michel Machado
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] socket statistics for ss
From: Stephen Hemminger @ 2018-05-09 17:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, gerrit, kuznet, yoshfuji, netdev, dccp, Stephen Hemminger
In-Reply-To: <be94fb64-1dd5-e512-50d6-16a1b7d4d092@gmail.com>
On Wed, 9 May 2018 10:18:23 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On 05/09/2018 08:22 AM, Stephen Hemminger wrote:
>
> > I am not sure if these patches are worth applying.
> > The 'ss -s' command has had missing values since 2.4 kernel.
> > And the first complaints came in only this year.
> >
> > Another alternative would be just to remove these fields from ss -s
> > output and move on.
> >
>
> Anyway your patches are not netns ready, so lets remove these fields from ss.
>
> Or you have to spend _much_ more time on writing and testing the kernel part.
>
> Thanks.
The patches only expose the existing TCP socket accounting infrastructure.
Several other pieces that sockstat has are not netns aware.
That is a completely different problem.
^ permalink raw reply
* RE: [PATCH net] tipc: fix one byte leak in tipc_sk_set_orig_addr()
From: Jon Maloy @ 2018-05-09 17:19 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet, Ying Xue
In-Reply-To: <20180509165022.199827-1-edumazet@google.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Thank you Eric.
> -----Original Message-----
> From: Eric Dumazet [mailto:edumazet@google.com]
> Sent: Wednesday, May 09, 2018 09:50
> To: David S . Miller <davem@davemloft.net>
> Cc: netdev <netdev@vger.kernel.org>; Eric Dumazet
> <edumazet@google.com>; Eric Dumazet <eric.dumazet@gmail.com>; Jon
> Maloy <jon.maloy@ericsson.com>; Ying Xue <ying.xue@windriver.com>
> Subject: [PATCH net] tipc: fix one byte leak in tipc_sk_set_orig_addr()
>
> sysbot/KMSAN reported an uninit-value in recvmsg() that I tracked down to
> tipc_sk_set_orig_addr(), missing
> srcaddr->member.scope initialization.
>
> This patches moves srcaddr->sock.scope init to follow fields order and ease
> future verifications.
>
> BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184
> [inline]
> BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530
> net/socket.c:226
> CPU: 0 PID: 4549 Comm: syz-executor287 Not tainted 4.17.0-rc3+ #88
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011 Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x185/0x1d0 lib/dump_stack.c:113
> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> kmsan_internal_check_memory+0x135/0x1e0 mm/kmsan/kmsan.c:1157
> kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199 copy_to_user
> include/linux/uaccess.h:184 [inline]
> move_addr_to_user+0x32e/0x530 net/socket.c:226
> ___sys_recvmsg+0x4e2/0x810 net/socket.c:2285 __sys_recvmsg
> net/socket.c:2328 [inline] __do_sys_recvmsg net/socket.c:2338 [inline]
> __se_sys_recvmsg net/socket.c:2335 [inline]
> __x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
> do_syscall_64+0x154/0x220 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x4455e9
> RSP: 002b:00007fe3bd36ddb8 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002f
> RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004455e9
> RDX: 0000000000002002 RSI: 0000000020000400 RDI: 0000000000000003
> RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fff98ce4b6f R14: 00007fe3bd36e9c0 R15: 0000000000000003
>
> Local variable description: ----addr@___sys_recvmsg Variable was created
> at:
> ___sys_recvmsg+0xd5/0x810 net/socket.c:2246 __sys_recvmsg
> net/socket.c:2328 [inline] __do_sys_recvmsg net/socket.c:2338 [inline]
> __se_sys_recvmsg net/socket.c:2335 [inline]
> __x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
>
> Byte 19 of 32 is uninitialized
>
> Fixes: 31c82a2d9d51 ("tipc: add second source address to
> recvmsg()/recvfrom()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Cc: Jon Maloy <jon.maloy@ericsson.com>
> Cc: Ying Xue <ying.xue@windriver.com>
> ---
> net/tipc/socket.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/socket.c b/net/tipc/socket.c index
> 252a52ae0893261fc6f146ad81111c59f375fdce..6be21575503aa532014e7aa141
> 5b2bf294757308 100644
> --- a/net/tipc/socket.c
> +++ b/net/tipc/socket.c
> @@ -1516,10 +1516,10 @@ static void tipc_sk_set_orig_addr(struct msghdr
> *m, struct sk_buff *skb)
>
> srcaddr->sock.family = AF_TIPC;
> srcaddr->sock.addrtype = TIPC_ADDR_ID;
> + srcaddr->sock.scope = 0;
> srcaddr->sock.addr.id.ref = msg_origport(hdr);
> srcaddr->sock.addr.id.node = msg_orignode(hdr);
> srcaddr->sock.addr.name.domain = 0;
> - srcaddr->sock.scope = 0;
> m->msg_namelen = sizeof(struct sockaddr_tipc);
>
> if (!msg_in_group(hdr))
> @@ -1528,6 +1528,7 @@ static void tipc_sk_set_orig_addr(struct msghdr
> *m, struct sk_buff *skb)
> /* Group message users may also want to know sending member's id
> */
> srcaddr->member.family = AF_TIPC;
> srcaddr->member.addrtype = TIPC_ADDR_NAME;
> + srcaddr->member.scope = 0;
> srcaddr->member.addr.name.name.type = msg_nametype(hdr);
> srcaddr->member.addr.name.name.instance = TIPC_SKB_CB(skb)-
> >orig_member;
> srcaddr->member.addr.name.domain = 0;
> --
> 2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] socket statistics for ss
From: Eric Dumazet @ 2018-05-09 17:18 UTC (permalink / raw)
To: Stephen Hemminger, davem, gerrit, kuznet, yoshfuji
Cc: netdev, dccp, Stephen Hemminger
In-Reply-To: <20180509082209.38fa4f43@xeon-e3>
On 05/09/2018 08:22 AM, Stephen Hemminger wrote:
> I am not sure if these patches are worth applying.
> The 'ss -s' command has had missing values since 2.4 kernel.
> And the first complaints came in only this year.
>
> Another alternative would be just to remove these fields from ss -s
> output and move on.
>
Anyway your patches are not netns ready, so lets remove these fields from ss.
Or you have to spend _much_ more time on writing and testing the kernel part.
Thanks.
^ 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