* [PATCHv2 net-net] net: dsa: mv88e6xxx: Work around mv886e6161 SERDES missing MII_PHYSID2
From: Andrew Lunn @ 2018-11-12 17:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sergei.shtylyov, Andrew Lunn
We already have a workaround for a couple of switches whose internal
PHYs only have the Marvel OUI, but no model number. We detect such
PHYs and give them the 6390 ID as the model number. However the
mv88e6161 has two SERDES interfaces in the same address range as its
internal PHYs. These suffer from the same problem, the Marvell OUI,
but no model number. As a result, these SERDES interfaces were getting
the same PHY ID as the mv88e6390, even though they are not PHYs, and
the Marvell PHY driver was trying to drive them.
Add a special case to stop this from happen.
Reported-by: Chris Healy <Chris.Healy@zii.aero>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
v2:
grammar fix in commit message.
PHYS->PHYs
---
drivers/net/dsa/mv88e6xxx/chip.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fc0f508879d4..b603f8d6ee3e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2524,11 +2524,22 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
mutex_unlock(&chip->reg_lock);
if (reg == MII_PHYSID2) {
- /* Some internal PHYS don't have a model number. Use
- * the mv88e6390 family model number instead.
- */
- if (!(val & 0x3f0))
- val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
+ /* Some internal PHYs don't have a model number. */
+ if (chip->info->family != MV88E6XXX_FAMILY_6165)
+ /* Then there is the 6165 family. It gets is
+ * PHYs correct. But it can also have two
+ * SERDES interfaces in the PHY address
+ * space. And these don't have a model
+ * number. But they are not PHYs, so we don't
+ * want to give them something a PHY driver
+ * will recognise.
+ *
+ * Use the mv88e6390 family model number
+ * instead, for anything which really could be
+ * a PHY,
+ */
+ if (!(val & 0x3f0))
+ val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
}
return err ? err : val;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH bpf-next] filter: add BPF_ADJ_ROOM_DATA mode to bpf_skb_adjust_room()
From: Martin Lau @ 2018-11-12 18:39 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: ast@kernel.org, daniel@iogearbox.net, davem@davemloft.net,
netdev@vger.kernel.org
In-Reply-To: <a2e44e4c-03f3-5c8a-d209-c576da218395@6wind.com>
On Sun, Nov 11, 2018 at 12:43:27AM +0100, Nicolas Dichtel wrote:
> Le 09/11/2018 à 19:51, Martin Lau a écrit :
> > On Thu, Nov 08, 2018 at 04:11:37PM +0100, Nicolas Dichtel wrote:
> [snip]
> >> +static int bpf_skb_data_shrink(struct sk_buff *skb, u32 len)
> >> +{
> >> + unsigned short hhlen = skb->dev->header_ops ?
> >> + skb->dev->hard_header_len : 0;
> >> + int ret;
> >> +
> >> + ret = skb_unclone(skb, GFP_ATOMIC);
> >> + if (unlikely(ret < 0))
> >> + return ret;
> >> +
> >> + __skb_pull(skb, len);
> >> + skb_reset_mac_header(skb);
> >> + skb_reset_network_header(skb);
> >> + skb->network_header += hhlen;
Nit. skb_set_network_header(skb, hhlen);
Othen than that
Acked-by: Martin KaFai Lau <kafai@fb.com>
> >> + skb_reset_transport_header(skb);
> > hmm...why transport_header does not need += hhlen here
> > while network_header does?
>
> network_header is mandatory because bpf_redirect(BPF_F_INGRESS) can be called
> and network_header is expected to be correctly set in this case.
> For transport_header, I choose to not set it, because the stack will set it
> later (for example ip_rcv_core()).
ic. make sense.
^ permalink raw reply
* [PATCH bpf-next] bpftool: make libbfd optional
From: Stanislav Fomichev @ 2018-11-12 18:53 UTC (permalink / raw)
To: netdev, ast, daniel, jakub.kicinski, quentin.monnet; +Cc: Stanislav Fomichev
Make it possible to build bpftool without libbfd. This excludes support for
disassembling jit-ted code and prints an error if the user tries to use
these features.
Tested by:
cat > FEATURES_DUMP.bpftool <<EOF
feature-libbfd=0
feature-disassembler-four-args=1
feature-reallocarray=0
feature-libelf=1
feature-libelf-mmap=1
feature-bpf=1
EOF
FEATURES_DUMP=$PWD/FEATURES_DUMP.bpftool make
ldd bpftool | grep libbfd
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/bpf/bpftool/Makefile | 13 +++++++++++--
tools/bpf/bpftool/jit_disasm.c | 7 ++++++-
tools/bpf/bpftool/main.c | 3 +--
tools/bpf/bpftool/main.h | 11 +++++++++++
4 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index dac7eff4c7e5..1bea6b979082 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -53,7 +53,7 @@ ifneq ($(EXTRA_LDFLAGS),)
LDFLAGS += $(EXTRA_LDFLAGS)
endif
-LIBS = -lelf -lbfd -lopcodes $(LIBBPF)
+LIBS = -lelf $(LIBBPF)
INSTALL ?= install
RM ?= rm -f
@@ -90,7 +90,16 @@ include $(wildcard $(OUTPUT)*.d)
all: $(OUTPUT)bpftool
-SRCS = $(wildcard *.c)
+BFD_SRCS = jit_disasm.c
+
+SRCS = $(filter-out $(BFD_SRCS),$(wildcard *.c))
+
+ifeq ($(feature-libbfd),1)
+CFLAGS += -DHAVE_LIBBFD_SUPPORT
+SRCS += $(BFD_SRCS)
+LIBS += -lbfd -lopcodes
+endif
+
OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o
$(OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c
index c75ffd9ce2bb..6176bfe66f22 100644
--- a/tools/bpf/bpftool/jit_disasm.c
+++ b/tools/bpf/bpftool/jit_disasm.c
@@ -109,7 +109,7 @@ void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
if (inf) {
bfdf->arch_info = inf;
} else {
- p_err("No libfd support for %s", arch);
+ p_err("No libbfd support for %s", arch);
return;
}
}
@@ -183,3 +183,8 @@ void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
bfd_close(bfdf);
}
+
+void disasm_init(void)
+{
+ bfd_init();
+}
diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c
index 75a3296dc0bc..51aa71069b14 100644
--- a/tools/bpf/bpftool/main.c
+++ b/tools/bpf/bpftool/main.c
@@ -31,7 +31,6 @@
* SOFTWARE.
*/
-#include <bfd.h>
#include <ctype.h>
#include <errno.h>
#include <getopt.h>
@@ -399,7 +398,7 @@ int main(int argc, char **argv)
if (argc < 0)
usage();
- bfd_init();
+ disasm_init();
ret = cmd_select(cmds, argc, argv, do_help);
diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index 61d82020af58..ec1bc2ae3c71 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -147,8 +147,19 @@ int prog_parse_fd(int *argc, char ***argv);
int map_parse_fd(int *argc, char ***argv);
int map_parse_fd_and_info(int *argc, char ***argv, void *info, __u32 *info_len);
+#ifdef HAVE_LIBBFD_SUPPORT
void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
const char *arch, const char *disassembler_options);
+void disasm_init(void);
+#else
+static inline
+void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
+ const char *arch, const char *disassembler_options)
+{
+ p_err("No libbfd support");
+}
+static inline void disasm_init(void) {}
+#endif
void print_data_json(uint8_t *data, size_t len);
void print_hex_data_json(uint8_t *data, size_t len);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: [PATCH net-next] net: phy: icplus: add config_intr callback
From: Florian Fainelli @ 2018-11-12 18:54 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <31282778-9e55-0f2e-da60-aea11a8c1182@gmail.com>
On 11/11/18 12:49 PM, Heiner Kallweit wrote:
> Move IRQ configuration for IP101A/G from config_init to config_intr
> callback. Reasons:
>
> 1. This allows phylib to disable interrupts if needed.
> 2. Icplus was the only driver supporting interrupts w/o defining a
> config_intr callback. Now we can add a phylib plausibility check
> disabling interrupt mode if one of the two irq-related callbacks
> isn't defined.
>
> I don't own hardware with this PHY, and the change is based on the
> datasheet for IP101A LF (which is supposed to be register-compatible
> with IP101A/G). Change is compile-tested only.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
A bit surprising that this is not a read/modify/write sequence.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] net: phy: switch to lockdep_assert_held in phylib
From: Florian Fainelli @ 2018-11-12 18:58 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <20181112174416.GF5075@lunn.ch>
On 11/12/18 9:44 AM, Andrew Lunn wrote:
> On Sun, Nov 11, 2018 at 10:33:08PM +0100, Heiner Kallweit wrote:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 2e59a8419..5cb06f021 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -541,7 +541,7 @@ int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
>> {
>> int retval;
>>
>> - WARN_ON_ONCE(!mutex_is_locked(&bus->mdio_lock));
>> + lockdep_assert_held_once(&bus->mdio_lock);
>
> Hi Heiner
>
> I don't think there is a clear right/wrong here. This is not hot path
> code. The cost for checking the lock is held is very small compared to
> the actual MDIO transaction. So i don't think we really need to
> optimise this. I do sometimes build with lockdep on, but not
> always. So it is good to know when locking is broken on normal builds.
>
> Florian, what do you think?
lockdep_assert_held_once() also looks at debug_locks (global variable)
so it sounds like in that regard, it would be superior in that it allows
an user-configurable, general debugging facility to behave consistently
as opposed to always having opt-in debugging within the mdio_bus.c file,
but that also has a lot of value. I have to admit debugging MDIO bus
locking issues is not particularly fun, so I would probably stick with
the current code in that regard.
--
Florian
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Paweł Staszewski @ 2018-11-12 19:19 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20181111095627.6e2bf5cf@redhat.com>
W dniu 11.11.2018 o 09:56, Jesper Dangaard Brouer pisze:
> On Sat, 10 Nov 2018 22:53:53 +0100 Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>
>> Now im messing with ring configuration for connectx5 nics.
>> And after reading that paper:
>> https://netdevconf.org/2.1/slides/apr6/network-performance/04-amir-RX_and_TX_bulking_v2.pdf
>>
> Do notice that some of the ideas in that slide deck, was never
> implemented. But they are still on my todo list ;-).
>
> Notice how that it show that TX bulking is very important, but based on
> your ethtool_stats.pl, I can see that not much TX bulking is happening
> in your case. This is indicated via the xmit_more counters.
>
> Ethtool(enp175s0) stat: 2630 ( 2,630) <= tx_xmit_more /sec
> Ethtool(enp175s0) stat: 4956995 ( 4,956,995) <= tx_packets /sec
>
> And the per queue levels are also avail:
>
> Ethtool(enp175s0) stat: 184845 ( 184,845) <= tx7_packets /sec
> Ethtool(enp175s0) stat: 78 ( 78) <= tx7_xmit_more /sec
>
> This means that you are doing too many doorbell's to the NIC hardware
> at TX time, which I worry could be what cause the NIC and PCIe hardware
> not to operate at optimal speeds.
After tunning coal/ring a little with ethtool
Reached today:
bwm-ng v0.6.1 (probing every 1.000s), press 'h' for help
input: /proc/net/dev type: rate
| iface Rx Tx Total
==============================================================================
enp175s0: 50.68 Gb/s 21.53 Gb/s
72.20 Gb/s
enp216s0: 21.62 Gb/s 50.81 Gb/s
72.42 Gb/s
------------------------------------------------------------------------------
total: 72.30 Gb/s 72.33 Gb/s
144.63 Gb/s
And still no packet loss (icmp side to side test every 100ms)
Below perf top
PerfTop: 104692 irqs/sec kernel:99.5% exact: 0.0% [4000Hz
cycles], (all, 56 CPUs)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.06% [kernel] [k] mlx5e_skb_from_cqe_mpwrq_linear
6.43% [kernel] [k] tasklet_action_common.isra.21
5.68% [kernel] [k] fib_table_lookup
4.89% [kernel] [k] irq_entries_start
4.53% [kernel] [k] mlx5_eq_int
4.10% [kernel] [k] build_skb
3.39% [kernel] [k] mlx5e_poll_tx_cq
3.38% [kernel] [k] mlx5e_sq_xmit
2.73% [kernel] [k] mlx5e_poll_rx_cq
2.18% [kernel] [k] __dev_queue_xmit
2.13% [kernel] [k] vlan_do_receive
2.12% [kernel] [k] mlx5e_handle_rx_cqe_mpwrq
2.00% [kernel] [k] ip_finish_output2
1.87% [kernel] [k] mlx5e_post_rx_mpwqes
1.86% [kernel] [k] memcpy_erms
1.85% [kernel] [k] ipt_do_table
1.70% [kernel] [k] dev_gro_receive
1.39% [kernel] [k] __netif_receive_skb_core
1.31% [kernel] [k] inet_gro_receive
1.21% [kernel] [k] ip_route_input_rcu
1.21% [kernel] [k] tcp_gro_receive
1.13% [kernel] [k] _raw_spin_lock
1.08% [kernel] [k] __build_skb
1.06% [kernel] [k] kmem_cache_free_bulk
1.05% [kernel] [k] __softirqentry_text_start
1.03% [kernel] [k] vlan_dev_hard_start_xmit
0.98% [kernel] [k] pfifo_fast_dequeue
0.95% [kernel] [k] mlx5e_xmit
0.95% [kernel] [k] page_frag_free
0.88% [kernel] [k] ip_forward
0.81% [kernel] [k] dev_hard_start_xmit
0.78% [kernel] [k] rcu_irq_exit
0.77% [kernel] [k] netif_skb_features
0.72% [kernel] [k] napi_complete_done
0.72% [kernel] [k] kmem_cache_alloc
0.68% [kernel] [k] validate_xmit_skb.isra.142
0.66% [kernel] [k] ip_rcv_core.isra.20.constprop.25
0.58% [kernel] [k] swiotlb_map_page
0.57% [kernel] [k] __qdisc_run
0.56% [kernel] [k] tasklet_action
0.54% [kernel] [k] __get_xps_queue_idx
0.54% [kernel] [k] inet_lookup_ifaddr_rcu
0.50% [kernel] [k] tcp4_gro_receive
0.49% [kernel] [k] skb_release_data
0.47% [kernel] [k] eth_type_trans
0.40% [kernel] [k] sch_direct_xmit
0.40% [kernel] [k] net_rx_action
0.39% [kernel] [k] __local_bh_enable_ip
And perf record/report
https://ufile.io/zguq0
So now i know what was causing cpu load for some processes like:
2913 root 20 0 0 0 0 I 10.3 0.0 6:58.29
kworker/u112:1-
7 root 20 0 0 0 0 I 8.6 0.0 6:17.18
kworker/u112:0-
10289 root 20 0 0 0 0 I 6.6 0.0 6:33.90
kworker/u112:4-
2939 root 20 0 0 0 0 R 3.6 0.0 7:37.68
kworker/u112:2-
After disabling adaptative tx for coalescense - all this processes gone.
lavg drops from 40 to 1
Current settings for coalescence:
ethtool -c enp175s0
Coalesce parameters for enp175s0:
Adaptive RX: off TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
dmac: 32548
rx-usecs: 24
rx-frames: 256
rx-usecs-irq: 0
rx-frames-irq: 0
tx-usecs: 0
tx-frames: 64
tx-usecs-irq: 0
tx-frames-irq: 0
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
And currently with that traffiv lvls - have no packet loss (cpu is avg.
60% for all 28 cores)
^ permalink raw reply
* Re: [PATCH bpf-next] bpftool: make libbfd optional
From: Jakub Kicinski @ 2018-11-12 19:42 UTC (permalink / raw)
To: Stanislav Fomichev; +Cc: netdev, ast, daniel, quentin.monnet
In-Reply-To: <20181112185328.125589-1-sdf@google.com>
On Mon, 12 Nov 2018 10:53:28 -0800, Stanislav Fomichev wrote:
> Make it possible to build bpftool without libbfd. This excludes support for
> disassembling jit-ted code and prints an error if the user tries to use
> these features.
>
> Tested by:
> cat > FEATURES_DUMP.bpftool <<EOF
> feature-libbfd=0
> feature-disassembler-four-args=1
> feature-reallocarray=0
> feature-libelf=1
> feature-libelf-mmap=1
> feature-bpf=1
> EOF
> FEATURES_DUMP=$PWD/FEATURES_DUMP.bpftool make
> ldd bpftool | grep libbfd
>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Would you mind spelling out the motivation?
> diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
> index 61d82020af58..ec1bc2ae3c71 100644
> --- a/tools/bpf/bpftool/main.h
> +++ b/tools/bpf/bpftool/main.h
> @@ -147,8 +147,19 @@ int prog_parse_fd(int *argc, char ***argv);
> int map_parse_fd(int *argc, char ***argv);
> int map_parse_fd_and_info(int *argc, char ***argv, void *info, __u32 *info_len);
>
> +#ifdef HAVE_LIBBFD_SUPPORT
> void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
> const char *arch, const char *disassembler_options);
> +void disasm_init(void);
> +#else
> +static inline
> +void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
> + const char *arch, const char *disassembler_options)
> +{
> + p_err("No libbfd support");
> +}
I think an error per instruction is a bit much, could we make sure we
error out earlier?
> +static inline void disasm_init(void) {}
> +#endif
> void print_data_json(uint8_t *data, size_t len);
> void print_hex_data_json(uint8_t *data, size_t len);
Otherwise LGTM.
^ permalink raw reply
* [PATCH v2] net: Add trace events for all receive exit points
From: Geneviève Bastien @ 2018-11-12 19:44 UTC (permalink / raw)
To: davem
Cc: netdev, Geneviève Bastien, Mathieu Desnoyers, Steven Rostedt,
Ingo Molnar
Trace events are already present for the receive entry points, to indicate
how the reception entered the stack.
This patch adds the corresponding exit trace events that will bound the
reception such that all events occurring between the entry and the exit
can be considered as part of the reception context. This greatly helps
for dependency and root cause analyses.
Without this, it is impossible to determine whether a sched_wakeup
event following a netif_receive_skb event is the result of the packet
reception or a simple coincidence after further processing by the
thread.
Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: Ingo Molnar <mingo@redhat.com>
CC: David S. Miller <davem@davemloft.net>
---
Changes in v2:
- Add the return value to tracepoints where applicable
- Verify if tracepoint is enabled before walking list in
netif_receive_skb_list
---
include/trace/events/net.h | 78 ++++++++++++++++++++++++++++++++++++++
net/core/dev.c | 38 ++++++++++++++++---
2 files changed, 110 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/net.h b/include/trace/events/net.h
index 00aa72ce0e7c..cff1a7b9d0bb 100644
--- a/include/trace/events/net.h
+++ b/include/trace/events/net.h
@@ -117,6 +117,42 @@ DECLARE_EVENT_CLASS(net_dev_template,
__get_str(name), __entry->skbaddr, __entry->len)
)
+DECLARE_EVENT_CLASS(net_dev_template_return,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret),
+
+ TP_STRUCT__entry(
+ __field(void *, skbaddr)
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ __entry->skbaddr = skb;
+ __entry->ret = ret;
+ ),
+
+ TP_printk("skbaddr=%p ret=%d", __entry->skbaddr, __entry->ret)
+)
+
+DECLARE_EVENT_CLASS(net_dev_template_simple,
+
+ TP_PROTO(struct sk_buff *skb),
+
+ TP_ARGS(skb),
+
+ TP_STRUCT__entry(
+ __field(void *, skbaddr)
+ ),
+
+ TP_fast_assign(
+ __entry->skbaddr = skb;
+ ),
+
+ TP_printk("skbaddr=%p", __entry->skbaddr)
+)
+
DEFINE_EVENT(net_dev_template, net_dev_queue,
TP_PROTO(struct sk_buff *skb),
@@ -244,6 +280,48 @@ DEFINE_EVENT(net_dev_rx_verbose_template, netif_rx_ni_entry,
TP_ARGS(skb)
);
+DEFINE_EVENT(net_dev_template_return, napi_gro_frags_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_return, napi_gro_receive_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_return, netif_receive_skb_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_list_exit,
+
+ TP_PROTO(struct sk_buff *skb),
+
+ TP_ARGS(skb)
+);
+
+DEFINE_EVENT(net_dev_template_return, netif_rx_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_return, netif_rx_ni_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
#endif /* _TRACE_NET_H */
/* This part must be outside protection */
diff --git a/net/core/dev.c b/net/core/dev.c
index 0ffcbdd55fa9..c4dc5df34abe 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4520,9 +4520,14 @@ static int netif_rx_internal(struct sk_buff *skb)
int netif_rx(struct sk_buff *skb)
{
+ int ret;
+
trace_netif_rx_entry(skb);
- return netif_rx_internal(skb);
+ ret = netif_rx_internal(skb);
+ trace_netif_rx_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(netif_rx);
@@ -4537,6 +4542,7 @@ int netif_rx_ni(struct sk_buff *skb)
if (local_softirq_pending())
do_softirq();
preempt_enable();
+ trace_netif_rx_ni_exit(skb, err);
return err;
}
@@ -5222,9 +5228,14 @@ static void netif_receive_skb_list_internal(struct list_head *head)
*/
int netif_receive_skb(struct sk_buff *skb)
{
+ int ret;
+
trace_netif_receive_skb_entry(skb);
- return netif_receive_skb_internal(skb);
+ ret = netif_receive_skb_internal(skb);
+ trace_netif_receive_skb_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(netif_receive_skb);
@@ -5244,9 +5255,15 @@ void netif_receive_skb_list(struct list_head *head)
if (list_empty(head))
return;
- list_for_each_entry(skb, head, list)
- trace_netif_receive_skb_list_entry(skb);
+ if (trace_netif_receive_skb_list_entry_enabled()) {
+ list_for_each_entry(skb, head, list)
+ trace_netif_receive_skb_list_entry(skb);
+ }
netif_receive_skb_list_internal(head);
+ if (trace_netif_receive_skb_list_exit_enabled()) {
+ list_for_each_entry(skb, head, list)
+ trace_netif_receive_skb_list_exit(skb);
+ }
}
EXPORT_SYMBOL(netif_receive_skb_list);
@@ -5634,12 +5651,17 @@ static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
+ gro_result_t ret;
+
skb_mark_napi_id(skb, napi);
trace_napi_gro_receive_entry(skb);
skb_gro_reset_offset(skb);
- return napi_skb_finish(dev_gro_receive(napi, skb), skb);
+ ret = napi_skb_finish(dev_gro_receive(napi, skb), skb);
+ trace_napi_gro_receive_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(napi_gro_receive);
@@ -5753,6 +5775,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct *napi)
gro_result_t napi_gro_frags(struct napi_struct *napi)
{
+ gro_result_t ret;
struct sk_buff *skb = napi_frags_skb(napi);
if (!skb)
@@ -5760,7 +5783,10 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
trace_napi_gro_frags_entry(skb);
- return napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
+ ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
+ trace_napi_gro_frags_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(napi_gro_frags);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 07/44] bpf: fix partial copy of map_ptr when dst is scalar
From: Sasha Levin @ 2018-11-13 5:49 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Daniel Borkmann, Edward Cree, Alexei Starovoitov, Sasha Levin,
netdev
In-Reply-To: <20181113054950.77898-1-sashal@kernel.org>
From: Daniel Borkmann <daniel@iogearbox.net>
[ Upstream commit 0962590e553331db2cc0aef2dc35c57f6300dbbe ]
ALU operations on pointers such as scalar_reg += map_value_ptr are
handled in adjust_ptr_min_max_vals(). Problem is however that map_ptr
and range in the register state share a union, so transferring state
through dst_reg->range = ptr_reg->range is just buggy as any new
map_ptr in the dst_reg is then truncated (or null) for subsequent
checks. Fix this by adding a raw member and use it for copying state
over to dst_reg.
Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Edward Cree <ecree@solarflare.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/bpf_verifier.h | 3 +++
kernel/bpf/verifier.c | 10 ++++++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index 38b04f559ad3..1fd6fa822d2c 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -50,6 +50,9 @@ struct bpf_reg_state {
* PTR_TO_MAP_VALUE_OR_NULL
*/
struct bpf_map *map_ptr;
+
+ /* Max size from any of the above. */
+ unsigned long raw;
};
/* Fixed part of pointer offset, pointer types only */
s32 off;
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 465952a8e465..b046564cc18d 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2762,7 +2762,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
dst_reg->umax_value = umax_ptr;
dst_reg->var_off = ptr_reg->var_off;
dst_reg->off = ptr_reg->off + smin_val;
- dst_reg->range = ptr_reg->range;
+ dst_reg->raw = ptr_reg->raw;
break;
}
/* A new variable offset is created. Note that off_reg->off
@@ -2792,10 +2792,11 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
}
dst_reg->var_off = tnum_add(ptr_reg->var_off, off_reg->var_off);
dst_reg->off = ptr_reg->off;
+ dst_reg->raw = ptr_reg->raw;
if (reg_is_pkt_pointer(ptr_reg)) {
dst_reg->id = ++env->id_gen;
/* something was added to pkt_ptr, set range to zero */
- dst_reg->range = 0;
+ dst_reg->raw = 0;
}
break;
case BPF_SUB:
@@ -2824,7 +2825,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
dst_reg->var_off = ptr_reg->var_off;
dst_reg->id = ptr_reg->id;
dst_reg->off = ptr_reg->off - smin_val;
- dst_reg->range = ptr_reg->range;
+ dst_reg->raw = ptr_reg->raw;
break;
}
/* A new variable offset is created. If the subtrahend is known
@@ -2850,11 +2851,12 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
}
dst_reg->var_off = tnum_sub(ptr_reg->var_off, off_reg->var_off);
dst_reg->off = ptr_reg->off;
+ dst_reg->raw = ptr_reg->raw;
if (reg_is_pkt_pointer(ptr_reg)) {
dst_reg->id = ++env->id_gen;
/* something was added to pkt_ptr, set range to zero */
if (smin_val < 0)
- dst_reg->range = 0;
+ dst_reg->raw = 0;
}
break;
case BPF_AND:
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 08/44] net: hns3: bugfix for rtnl_lock's range in the hclgevf_reset()
From: Sasha Levin @ 2018-11-13 5:49 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Huazhong Tan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181113054950.77898-1-sashal@kernel.org>
From: Huazhong Tan <tanhuazhong@huawei.com>
[ Upstream commit 29118ab962d5476fdc65fae312ac38db68092d78 ]
Since hclgevf_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclgevf_reset_wait(). So this patch releases the lock for the duration
of hclgevf_reset_wait().
Fixes: 6988eb2a9b77 ("net: hns3: Add support to reset the enet/ring mgmt layer")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 9c0091f2addf..57958273945c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1062,6 +1062,8 @@ static int hclgevf_reset(struct hclgevf_dev *hdev)
/* bring down the nic to stop any ongoing TX/RX */
hclgevf_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ rtnl_unlock();
+
/* check if VF could successfully fetch the hardware reset completion
* status from the hardware
*/
@@ -1073,12 +1075,15 @@ static int hclgevf_reset(struct hclgevf_dev *hdev)
ret);
dev_warn(&hdev->pdev->dev, "VF reset failed, disabling VF!\n");
+ rtnl_lock();
hclgevf_notify_client(hdev, HNAE3_UNINIT_CLIENT);
rtnl_unlock();
return ret;
}
+ rtnl_lock();
+
/* now, re-initialize the nic client and ae device*/
ret = hclgevf_reset_stack(hdev);
if (ret)
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 09/44] net: hns3: bugfix for rtnl_lock's range in the hclge_reset()
From: Sasha Levin @ 2018-11-13 5:49 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Huazhong Tan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181113054950.77898-1-sashal@kernel.org>
From: Huazhong Tan <tanhuazhong@huawei.com>
[ Upstream commit a963052e539887df481d4d3a6ad4c92ca6461852 ]
Since hclge_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclge_reset_wait(). So this patch releases the lock for the duration
of hclge_reset_wait().
Fixes: 6d4fab39533f ("net: hns3: Reset net device with rtnl_lock")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 8577dfc799ad..18056c08f62a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2799,14 +2799,17 @@ static void hclge_reset(struct hclge_dev *hdev)
handle = &hdev->vport[0].nic;
rtnl_lock();
hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ rtnl_unlock();
if (!hclge_reset_wait(hdev)) {
+ rtnl_lock();
hclge_notify_client(hdev, HNAE3_UNINIT_CLIENT);
hclge_reset_ae_dev(hdev->ae_dev);
hclge_notify_client(hdev, HNAE3_INIT_CLIENT);
hclge_clear_reset_cause(hdev);
} else {
+ rtnl_lock();
/* schedule again to check pending resets later */
set_bit(hdev->reset_type, &hdev->reset_pending);
hclge_reset_task_schedule(hdev);
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 10/44] net: hns3: bugfix for handling mailbox while the command queue reinitialized
From: Sasha Levin @ 2018-11-13 5:49 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Huazhong Tan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181113054950.77898-1-sashal@kernel.org>
From: Huazhong Tan <tanhuazhong@huawei.com>
[ Upstream commit 3c88ed1d798da355859ca083d3884a16ce0841f2 ]
In a multi-core machine, the mailbox service and reset service
will be executed at the same time. The reset service will re-initialize
the command queue, before that, the mailbox handler can only get some
invalid messages.
The HCLGE_STATE_CMD_DISABLE flag means that the command queue is not
available and needs to be reinitialized. Therefore, when the mailbox
handler recognizes this flag, it should not process the command.
Fixes: dde1a86e93ca ("net: hns3: Add mailbox support to PF driver")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index f34851c91eb3..e08e82020402 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -458,6 +458,12 @@ void hclge_mbx_handler(struct hclge_dev *hdev)
/* handle all the mailbox requests in the queue */
while (!hclge_cmd_crq_empty(&hdev->hw)) {
+ if (test_bit(HCLGE_STATE_CMD_DISABLE, &hdev->state)) {
+ dev_warn(&hdev->pdev->dev,
+ "command queue needs re-initializing\n");
+ return;
+ }
+
desc = &crq->desc[crq->next_to_use];
req = (struct hclge_mbx_vf_to_pf_cmd *)desc->data;
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 11/44] net: hns3: bugfix for the initialization of command queue's spin lock
From: Sasha Levin @ 2018-11-13 5:49 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Huazhong Tan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181113054950.77898-1-sashal@kernel.org>
From: Huazhong Tan <tanhuazhong@huawei.com>
[ Upstream commit b2f74dbaf12bf59ff35d451005b3cdee78232ff0 ]
The spin lock of the command queue only need to be initialized once
when the driver initializes the command queue. It is not necessary to
initialize the spin lock when resetting. At the same time, the
modification of the queue member should be performed after acquiring
the lock.
Fixes: 3efb960f056d ("net: hns3: Refactor the initialization of command queue")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index ac13cb2b168e..68026a5ad7e7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -304,6 +304,10 @@ int hclge_cmd_queue_init(struct hclge_dev *hdev)
{
int ret;
+ /* Setup the lock for command queue */
+ spin_lock_init(&hdev->hw.cmq.csq.lock);
+ spin_lock_init(&hdev->hw.cmq.crq.lock);
+
/* Setup the queue entries for use cmd queue */
hdev->hw.cmq.csq.desc_num = HCLGE_NIC_CMQ_DESC_NUM;
hdev->hw.cmq.crq.desc_num = HCLGE_NIC_CMQ_DESC_NUM;
@@ -337,18 +341,20 @@ int hclge_cmd_init(struct hclge_dev *hdev)
u32 version;
int ret;
+ spin_lock_bh(&hdev->hw.cmq.csq.lock);
+ spin_lock_bh(&hdev->hw.cmq.crq.lock);
+
hdev->hw.cmq.csq.next_to_clean = 0;
hdev->hw.cmq.csq.next_to_use = 0;
hdev->hw.cmq.crq.next_to_clean = 0;
hdev->hw.cmq.crq.next_to_use = 0;
- /* Setup the lock for command queue */
- spin_lock_init(&hdev->hw.cmq.csq.lock);
- spin_lock_init(&hdev->hw.cmq.crq.lock);
-
hclge_cmd_init_regs(&hdev->hw);
clear_bit(HCLGE_STATE_CMD_DISABLE, &hdev->state);
+ spin_unlock_bh(&hdev->hw.cmq.crq.lock);
+ spin_unlock_bh(&hdev->hw.cmq.csq.lock);
+
ret = hclge_cmd_query_firmware_version(&hdev->hw, &version);
if (ret) {
dev_err(&hdev->pdev->dev,
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 12/44] ixgbe: fix MAC anti-spoofing filter after VFLR
From: Sasha Levin @ 2018-11-13 5:49 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Radoslaw Tyl, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20181113054950.77898-1-sashal@kernel.org>
From: Radoslaw Tyl <radoslawx.tyl@intel.com>
[ Upstream commit 6702185c1ffec3421181b5e24491e3fac920cb61 ]
This change resolves a driver bug where the driver is logging a
message that says "Spoofed packets detected". This can occur on the PF
(host) when a VF has VLAN+MACVLAN enabled and is re-started with a
different MAC address.
MAC and VLAN anti-spoofing filters are to be enabled together.
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Acked-by: Piotr Skajewski <piotrx.skajewski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 3c6f01c41b78..eea63a99f29c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -721,8 +721,10 @@ static inline void ixgbe_vf_reset_event(struct ixgbe_adapter *adapter, u32 vf)
ixgbe_set_vmvir(adapter, vfinfo->pf_vlan,
adapter->default_up, vf);
- if (vfinfo->spoofchk_enabled)
+ if (vfinfo->spoofchk_enabled) {
hw->mac.ops.set_vlan_anti_spoofing(hw, true, vf);
+ hw->mac.ops.set_mac_anti_spoofing(hw, true, vf);
+ }
}
/* reset multicast table array for vf */
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 07/39] net: hns3: bugfix for rtnl_lock's range in the hclgevf_reset()
From: Sasha Levin @ 2018-11-13 5:50 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Huazhong Tan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181113055053.78352-1-sashal@kernel.org>
From: Huazhong Tan <tanhuazhong@huawei.com>
[ Upstream commit 29118ab962d5476fdc65fae312ac38db68092d78 ]
Since hclgevf_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclgevf_reset_wait(). So this patch releases the lock for the duration
of hclgevf_reset_wait().
Fixes: 6988eb2a9b77 ("net: hns3: Add support to reset the enet/ring mgmt layer")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 12aa1f1b99ef..7e22853e5d2a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1052,6 +1052,8 @@ static int hclgevf_reset(struct hclgevf_dev *hdev)
/* bring down the nic to stop any ongoing TX/RX */
hclgevf_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ rtnl_unlock();
+
/* check if VF could successfully fetch the hardware reset completion
* status from the hardware
*/
@@ -1063,12 +1065,15 @@ static int hclgevf_reset(struct hclgevf_dev *hdev)
ret);
dev_warn(&hdev->pdev->dev, "VF reset failed, disabling VF!\n");
+ rtnl_lock();
hclgevf_notify_client(hdev, HNAE3_UNINIT_CLIENT);
rtnl_unlock();
return ret;
}
+ rtnl_lock();
+
/* now, re-initialize the nic client and ae device*/
ret = hclgevf_reset_stack(hdev);
if (ret)
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 08/39] net: hns3: bugfix for rtnl_lock's range in the hclge_reset()
From: Sasha Levin @ 2018-11-13 5:50 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Huazhong Tan, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20181113055053.78352-1-sashal@kernel.org>
From: Huazhong Tan <tanhuazhong@huawei.com>
[ Upstream commit a963052e539887df481d4d3a6ad4c92ca6461852 ]
Since hclge_reset_wait() is used to wait for the hardware to complete
the reset, it is not necessary to hold the rtnl_lock during
hclge_reset_wait(). So this patch releases the lock for the duration
of hclge_reset_wait().
Fixes: 6d4fab39533f ("net: hns3: Reset net device with rtnl_lock")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 13f43b74fd6d..de85a31106e7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2827,14 +2827,17 @@ static void hclge_reset(struct hclge_dev *hdev)
/* perform reset of the stack & ae device for a client */
rtnl_lock();
hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ rtnl_unlock();
if (!hclge_reset_wait(hdev)) {
+ rtnl_lock();
hclge_notify_client(hdev, HNAE3_UNINIT_CLIENT);
hclge_reset_ae_dev(hdev->ae_dev);
hclge_notify_client(hdev, HNAE3_INIT_CLIENT);
hclge_clear_reset_cause(hdev);
} else {
+ rtnl_lock();
/* schedule again to check pending resets later */
set_bit(hdev->reset_type, &hdev->reset_pending);
hclge_reset_task_schedule(hdev);
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 10/39] ixgbe: fix MAC anti-spoofing filter after VFLR
From: Sasha Levin @ 2018-11-13 5:50 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Radoslaw Tyl, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20181113055053.78352-1-sashal@kernel.org>
From: Radoslaw Tyl <radoslawx.tyl@intel.com>
[ Upstream commit 6702185c1ffec3421181b5e24491e3fac920cb61 ]
This change resolves a driver bug where the driver is logging a
message that says "Spoofed packets detected". This can occur on the PF
(host) when a VF has VLAN+MACVLAN enabled and is re-started with a
different MAC address.
MAC and VLAN anti-spoofing filters are to be enabled together.
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Acked-by: Piotr Skajewski <piotrx.skajewski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 2bc4fe475f28..23363bc92718 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -716,8 +716,10 @@ static inline void ixgbe_vf_reset_event(struct ixgbe_adapter *adapter, u32 vf)
ixgbe_set_vmvir(adapter, vfinfo->pf_vlan,
adapter->default_up, vf);
- if (vfinfo->spoofchk_enabled)
+ if (vfinfo->spoofchk_enabled) {
hw->mac.ops.set_vlan_anti_spoofing(hw, true, vf);
+ hw->mac.ops.set_mac_anti_spoofing(hw, true, vf);
+ }
}
/* reset multicast table array for vf */
--
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 06/26] ixgbe: fix MAC anti-spoofing filter after VFLR
From: Sasha Levin @ 2018-11-13 5:51 UTC (permalink / raw)
To: stable, linux-kernel; +Cc: Radoslaw Tyl, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20181113055150.78773-1-sashal@kernel.org>
From: Radoslaw Tyl <radoslawx.tyl@intel.com>
[ Upstream commit 6702185c1ffec3421181b5e24491e3fac920cb61 ]
This change resolves a driver bug where the driver is logging a
message that says "Spoofed packets detected". This can occur on the PF
(host) when a VF has VLAN+MACVLAN enabled and is re-started with a
different MAC address.
MAC and VLAN anti-spoofing filters are to be enabled together.
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Acked-by: Piotr Skajewski <piotrx.skajewski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 112d24c6c9ce..4904a63b83ef 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -760,8 +760,10 @@ static inline void ixgbe_vf_reset_event(struct ixgbe_adapter *adapter, u32 vf)
ixgbe_set_vmvir(adapter, vfinfo->pf_vlan,
adapter->default_up, vf);
- if (vfinfo->spoofchk_enabled)
+ if (vfinfo->spoofchk_enabled) {
hw->mac.ops.set_vlan_anti_spoofing(hw, true, vf);
+ hw->mac.ops.set_mac_anti_spoofing(hw, true, vf);
+ }
}
/* reset multicast table array for vf */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next] bpftool: make libbfd optional
From: Stanislav Fomichev @ 2018-11-12 19:58 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Stanislav Fomichev, netdev, ast, daniel, quentin.monnet
In-Reply-To: <20181112114234.48ef2e6b@cakuba.netronome.com>
On 11/12, Jakub Kicinski wrote:
> On Mon, 12 Nov 2018 10:53:28 -0800, Stanislav Fomichev wrote:
> > Make it possible to build bpftool without libbfd. This excludes support for
> > disassembling jit-ted code and prints an error if the user tries to use
> > these features.
> >
> > Tested by:
> > cat > FEATURES_DUMP.bpftool <<EOF
> > feature-libbfd=0
> > feature-disassembler-four-args=1
> > feature-reallocarray=0
> > feature-libelf=1
> > feature-libelf-mmap=1
> > feature-bpf=1
> > EOF
> > FEATURES_DUMP=$PWD/FEATURES_DUMP.bpftool make
> > ldd bpftool | grep libbfd
> >
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
>
> Would you mind spelling out the motivation?
Ack, will do in v2 commit message. tldr - some fleet machines don't
have dev/dbg stuff installed; would like an option to have bpftool that
works everywhere for introspection.
> > diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
> > index 61d82020af58..ec1bc2ae3c71 100644
> > --- a/tools/bpf/bpftool/main.h
> > +++ b/tools/bpf/bpftool/main.h
> > @@ -147,8 +147,19 @@ int prog_parse_fd(int *argc, char ***argv);
> > int map_parse_fd(int *argc, char ***argv);
> > int map_parse_fd_and_info(int *argc, char ***argv, void *info, __u32 *info_len);
> >
> > +#ifdef HAVE_LIBBFD_SUPPORT
> > void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
> > const char *arch, const char *disassembler_options);
> > +void disasm_init(void);
> > +#else
> > +static inline
> > +void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
> > + const char *arch, const char *disassembler_options)
> > +{
> > + p_err("No libbfd support");
> > +}
>
> I think an error per instruction is a bit much, could we make sure we
> error out earlier?
I can return int from disasm_print_insn as an indication to
stop/continue. Let me know if you have better ideas, will post v2 later
today.
> > +static inline void disasm_init(void) {}
> > +#endif
> > void print_data_json(uint8_t *data, size_t len);
> > void print_hex_data_json(uint8_t *data, size_t len);
>
> Otherwise LGTM.
Thanks!
^ permalink raw reply
* Re: [PATCH v2] net: Add trace events for all receive exit points
From: Mathieu Desnoyers @ 2018-11-12 20:09 UTC (permalink / raw)
To: Geneviève Bastien; +Cc: David S. Miller, netdev, rostedt, Ingo Molnar
In-Reply-To: <20181112194405.4133-1-gbastien@versatic.net>
----- On Nov 12, 2018, at 2:44 PM, Geneviève Bastien gbastien@versatic.net wrote:
> Trace events are already present for the receive entry points, to indicate
> how the reception entered the stack.
>
> This patch adds the corresponding exit trace events that will bound the
> reception such that all events occurring between the entry and the exit
> can be considered as part of the reception context. This greatly helps
> for dependency and root cause analyses.
>
> Without this, it is impossible to determine whether a sched_wakeup
> event following a netif_receive_skb event is the result of the packet
> reception or a simple coincidence after further processing by the
> thread.
As discussed over IRC, it is _possible_ to use kretprobes to instrument
the exit, but it is not practical. A v3 will be sent soon to clarify
this part of the commit message.
Also, I wonder if we should use "net_dev_template_exit" for the event
class rather than "net_dev_template_return" ?
Thanks,
Mathieu
>
> Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
> CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Ingo Molnar <mingo@redhat.com>
> CC: David S. Miller <davem@davemloft.net>
> ---
> Changes in v2:
> - Add the return value to tracepoints where applicable
> - Verify if tracepoint is enabled before walking list in
> netif_receive_skb_list
> ---
> include/trace/events/net.h | 78 ++++++++++++++++++++++++++++++++++++++
> net/core/dev.c | 38 ++++++++++++++++---
> 2 files changed, 110 insertions(+), 6 deletions(-)
>
> diff --git a/include/trace/events/net.h b/include/trace/events/net.h
> index 00aa72ce0e7c..cff1a7b9d0bb 100644
> --- a/include/trace/events/net.h
> +++ b/include/trace/events/net.h
> @@ -117,6 +117,42 @@ DECLARE_EVENT_CLASS(net_dev_template,
> __get_str(name), __entry->skbaddr, __entry->len)
> )
>
> +DECLARE_EVENT_CLASS(net_dev_template_return,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret),
> +
> + TP_STRUCT__entry(
> + __field(void *, skbaddr)
> + __field(int, ret)
> + ),
> +
> + TP_fast_assign(
> + __entry->skbaddr = skb;
> + __entry->ret = ret;
> + ),
> +
> + TP_printk("skbaddr=%p ret=%d", __entry->skbaddr, __entry->ret)
> +)
> +
> +DECLARE_EVENT_CLASS(net_dev_template_simple,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb),
> +
> + TP_STRUCT__entry(
> + __field(void *, skbaddr)
> + ),
> +
> + TP_fast_assign(
> + __entry->skbaddr = skb;
> + ),
> +
> + TP_printk("skbaddr=%p", __entry->skbaddr)
> +)
> +
> DEFINE_EVENT(net_dev_template, net_dev_queue,
>
> TP_PROTO(struct sk_buff *skb),
> @@ -244,6 +280,48 @@ DEFINE_EVENT(net_dev_rx_verbose_template,
> netif_rx_ni_entry,
> TP_ARGS(skb)
> );
>
> +DEFINE_EVENT(net_dev_template_return, napi_gro_frags_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, napi_gro_receive_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, netif_receive_skb_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_list_exit,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, netif_rx_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, netif_rx_ni_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> #endif /* _TRACE_NET_H */
>
> /* This part must be outside protection */
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0ffcbdd55fa9..c4dc5df34abe 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4520,9 +4520,14 @@ static int netif_rx_internal(struct sk_buff *skb)
>
> int netif_rx(struct sk_buff *skb)
> {
> + int ret;
> +
> trace_netif_rx_entry(skb);
>
> - return netif_rx_internal(skb);
> + ret = netif_rx_internal(skb);
> + trace_netif_rx_exit(skb, ret);
> +
> + return ret;
> }
> EXPORT_SYMBOL(netif_rx);
>
> @@ -4537,6 +4542,7 @@ int netif_rx_ni(struct sk_buff *skb)
> if (local_softirq_pending())
> do_softirq();
> preempt_enable();
> + trace_netif_rx_ni_exit(skb, err);
>
> return err;
> }
> @@ -5222,9 +5228,14 @@ static void netif_receive_skb_list_internal(struct
> list_head *head)
> */
> int netif_receive_skb(struct sk_buff *skb)
> {
> + int ret;
> +
> trace_netif_receive_skb_entry(skb);
>
> - return netif_receive_skb_internal(skb);
> + ret = netif_receive_skb_internal(skb);
> + trace_netif_receive_skb_exit(skb, ret);
> +
> + return ret;
> }
> EXPORT_SYMBOL(netif_receive_skb);
>
> @@ -5244,9 +5255,15 @@ void netif_receive_skb_list(struct list_head *head)
>
> if (list_empty(head))
> return;
> - list_for_each_entry(skb, head, list)
> - trace_netif_receive_skb_list_entry(skb);
> + if (trace_netif_receive_skb_list_entry_enabled()) {
> + list_for_each_entry(skb, head, list)
> + trace_netif_receive_skb_list_entry(skb);
> + }
> netif_receive_skb_list_internal(head);
> + if (trace_netif_receive_skb_list_exit_enabled()) {
> + list_for_each_entry(skb, head, list)
> + trace_netif_receive_skb_list_exit(skb);
> + }
> }
> EXPORT_SYMBOL(netif_receive_skb_list);
>
> @@ -5634,12 +5651,17 @@ static gro_result_t napi_skb_finish(gro_result_t ret,
> struct sk_buff *skb)
>
> gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
> {
> + gro_result_t ret;
> +
> skb_mark_napi_id(skb, napi);
> trace_napi_gro_receive_entry(skb);
>
> skb_gro_reset_offset(skb);
>
> - return napi_skb_finish(dev_gro_receive(napi, skb), skb);
> + ret = napi_skb_finish(dev_gro_receive(napi, skb), skb);
> + trace_napi_gro_receive_exit(skb, ret);
> +
> + return ret;
> }
> EXPORT_SYMBOL(napi_gro_receive);
>
> @@ -5753,6 +5775,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct
> *napi)
>
> gro_result_t napi_gro_frags(struct napi_struct *napi)
> {
> + gro_result_t ret;
> struct sk_buff *skb = napi_frags_skb(napi);
>
> if (!skb)
> @@ -5760,7 +5783,10 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
>
> trace_napi_gro_frags_entry(skb);
>
> - return napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
> + ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
> + trace_napi_gro_frags_exit(skb, ret);
> +
> + return ret;
> }
> EXPORT_SYMBOL(napi_gro_frags);
>
> --
> 2.19.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* [PATCH net-next] net: phy: check for implementation of both callbacks in phy_drv_supports_irq
From: Heiner Kallweit @ 2018-11-12 20:16 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Now that the icplus driver has been fixed all PHY drivers supporting
interrupts have both callbacks (config_intr and ack_interrupt)
implemented - as it should be. Therefore phy_drv_supports_irq()
can be changed now to check for both callbacks being implemented.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 55202a0ac..e06613f2d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2122,7 +2122,7 @@ static void of_set_phy_eee_broken(struct phy_device *phydev)
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
- return phydrv->config_intr || phydrv->ack_interrupt;
+ return phydrv->config_intr && phydrv->ack_interrupt;
}
/**
--
2.19.1
^ permalink raw reply related
* [PATCH net-next v2] geneve: Use empty braces for addr6 initializer
From: Nathan Chancellor @ 2018-11-13 6:11 UTC (permalink / raw)
To: David S. Miller
Cc: Stefano Brivio, Sabrina Dubroca, netdev, linux-kernel,
Joe Perches, Nathan Chancellor
In-Reply-To: <20181112221248.11477-1-natechancellor@gmail.com>
Clang warns:
drivers/net/geneve.c:428:29: error: suggest braces around initialization
of subobject [-Werror,-Wmissing-braces]
struct in6_addr addr6 = { 0 };
^
{}
Most initializations of structs in the kernel seem to use this format.
Fixes: a07966447f39 ("geneve: ICMP error lookup handler")
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Just remove the zero instead of adding more braces as it seems to
match the rest of the kernel (as suggested by Joe Perches).
drivers/net/geneve.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 7c53e06b31c3..f09e58b7b01e 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -425,7 +425,7 @@ static int geneve_udp_encap_err_lookup(struct sock *sk, struct sk_buff *skb)
#if IS_ENABLED(CONFIG_IPV6)
if (geneve_get_sk_family(gs) == AF_INET6) {
struct ipv6hdr *ip6h = ipv6_hdr(skb);
- struct in6_addr addr6 = { 0 };
+ struct in6_addr addr6 = { };
if (!gs->collect_md) {
vni = geneve_hdr(skb)->vni;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2] net: Add trace events for all receive exit points
From: Mathieu Desnoyers @ 2018-11-12 20:20 UTC (permalink / raw)
To: Geneviève Bastien; +Cc: David S. Miller, netdev, rostedt, Ingo Molnar
In-Reply-To: <879033794.3997.1542053367213.JavaMail.zimbra@efficios.com>
----- On Nov 12, 2018, at 3:09 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
> ----- On Nov 12, 2018, at 2:44 PM, Geneviève Bastien gbastien@versatic.net
> wrote:
>
>> Trace events are already present for the receive entry points, to indicate
>> how the reception entered the stack.
>>
>> This patch adds the corresponding exit trace events that will bound the
>> reception such that all events occurring between the entry and the exit
>> can be considered as part of the reception context. This greatly helps
>> for dependency and root cause analyses.
>>
>> Without this, it is impossible to determine whether a sched_wakeup
>> event following a netif_receive_skb event is the result of the packet
>> reception or a simple coincidence after further processing by the
>> thread.
>
> As discussed over IRC, it is _possible_ to use kretprobes to instrument
> the exit, but it is not practical. A v3 will be sent soon to clarify
> this part of the commit message.
>
> Also, I wonder if we should use "net_dev_template_exit" for the event
> class rather than "net_dev_template_return" ?
Hrm, looking at this again, I notice that there is a single DEFINE_EVENT
using net_dev_template_simple.
We could simply turn netif_receive_skb_list_exit into a TRACE_EVENT(),
remove the net_dev_template_simple, and rename the net_dev_template_return
to net_dev_template ?
It's pretty clear from the prototype that it expects a "ret" argument,
so I don't see the need to also state it in the template name.
Thanks,
Mathieu
>
> Thanks,
>
> Mathieu
>
>>
>> Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
>> CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> CC: Steven Rostedt <rostedt@goodmis.org>
>> CC: Ingo Molnar <mingo@redhat.com>
>> CC: David S. Miller <davem@davemloft.net>
>> ---
>> Changes in v2:
>> - Add the return value to tracepoints where applicable
>> - Verify if tracepoint is enabled before walking list in
>> netif_receive_skb_list
>> ---
>> include/trace/events/net.h | 78 ++++++++++++++++++++++++++++++++++++++
>> net/core/dev.c | 38 ++++++++++++++++---
>> 2 files changed, 110 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/trace/events/net.h b/include/trace/events/net.h
>> index 00aa72ce0e7c..cff1a7b9d0bb 100644
>> --- a/include/trace/events/net.h
>> +++ b/include/trace/events/net.h
>> @@ -117,6 +117,42 @@ DECLARE_EVENT_CLASS(net_dev_template,
>> __get_str(name), __entry->skbaddr, __entry->len)
>> )
>>
>> +DECLARE_EVENT_CLASS(net_dev_template_return,
>> +
>> + TP_PROTO(struct sk_buff *skb, int ret),
>> +
>> + TP_ARGS(skb, ret),
>> +
>> + TP_STRUCT__entry(
>> + __field(void *, skbaddr)
>> + __field(int, ret)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->skbaddr = skb;
>> + __entry->ret = ret;
>> + ),
>> +
>> + TP_printk("skbaddr=%p ret=%d", __entry->skbaddr, __entry->ret)
>> +)
>> +
>> +DECLARE_EVENT_CLASS(net_dev_template_simple,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb),
>> +
>> + TP_STRUCT__entry(
>> + __field(void *, skbaddr)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->skbaddr = skb;
>> + ),
>> +
>> + TP_printk("skbaddr=%p", __entry->skbaddr)
>> +)
>> +
>> DEFINE_EVENT(net_dev_template, net_dev_queue,
>>
>> TP_PROTO(struct sk_buff *skb),
>> @@ -244,6 +280,48 @@ DEFINE_EVENT(net_dev_rx_verbose_template,
>> netif_rx_ni_entry,
>> TP_ARGS(skb)
>> );
>>
>> +DEFINE_EVENT(net_dev_template_return, napi_gro_frags_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb, int ret),
>> +
>> + TP_ARGS(skb, ret)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_return, napi_gro_receive_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb, int ret),
>> +
>> + TP_ARGS(skb, ret)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_return, netif_receive_skb_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb, int ret),
>> +
>> + TP_ARGS(skb, ret)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_list_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_return, netif_rx_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb, int ret),
>> +
>> + TP_ARGS(skb, ret)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_return, netif_rx_ni_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb, int ret),
>> +
>> + TP_ARGS(skb, ret)
>> +);
>> +
>> #endif /* _TRACE_NET_H */
>>
>> /* This part must be outside protection */
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 0ffcbdd55fa9..c4dc5df34abe 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4520,9 +4520,14 @@ static int netif_rx_internal(struct sk_buff *skb)
>>
>> int netif_rx(struct sk_buff *skb)
>> {
>> + int ret;
>> +
>> trace_netif_rx_entry(skb);
>>
>> - return netif_rx_internal(skb);
>> + ret = netif_rx_internal(skb);
>> + trace_netif_rx_exit(skb, ret);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(netif_rx);
>>
>> @@ -4537,6 +4542,7 @@ int netif_rx_ni(struct sk_buff *skb)
>> if (local_softirq_pending())
>> do_softirq();
>> preempt_enable();
>> + trace_netif_rx_ni_exit(skb, err);
>>
>> return err;
>> }
>> @@ -5222,9 +5228,14 @@ static void netif_receive_skb_list_internal(struct
>> list_head *head)
>> */
>> int netif_receive_skb(struct sk_buff *skb)
>> {
>> + int ret;
>> +
>> trace_netif_receive_skb_entry(skb);
>>
>> - return netif_receive_skb_internal(skb);
>> + ret = netif_receive_skb_internal(skb);
>> + trace_netif_receive_skb_exit(skb, ret);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(netif_receive_skb);
>>
>> @@ -5244,9 +5255,15 @@ void netif_receive_skb_list(struct list_head *head)
>>
>> if (list_empty(head))
>> return;
>> - list_for_each_entry(skb, head, list)
>> - trace_netif_receive_skb_list_entry(skb);
>> + if (trace_netif_receive_skb_list_entry_enabled()) {
>> + list_for_each_entry(skb, head, list)
>> + trace_netif_receive_skb_list_entry(skb);
>> + }
>> netif_receive_skb_list_internal(head);
>> + if (trace_netif_receive_skb_list_exit_enabled()) {
>> + list_for_each_entry(skb, head, list)
>> + trace_netif_receive_skb_list_exit(skb);
>> + }
>> }
>> EXPORT_SYMBOL(netif_receive_skb_list);
>>
>> @@ -5634,12 +5651,17 @@ static gro_result_t napi_skb_finish(gro_result_t ret,
>> struct sk_buff *skb)
>>
>> gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
>> {
>> + gro_result_t ret;
>> +
>> skb_mark_napi_id(skb, napi);
>> trace_napi_gro_receive_entry(skb);
>>
>> skb_gro_reset_offset(skb);
>>
>> - return napi_skb_finish(dev_gro_receive(napi, skb), skb);
>> + ret = napi_skb_finish(dev_gro_receive(napi, skb), skb);
>> + trace_napi_gro_receive_exit(skb, ret);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(napi_gro_receive);
>>
>> @@ -5753,6 +5775,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct
>> *napi)
>>
>> gro_result_t napi_gro_frags(struct napi_struct *napi)
>> {
>> + gro_result_t ret;
>> struct sk_buff *skb = napi_frags_skb(napi);
>>
>> if (!skb)
>> @@ -5760,7 +5783,10 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
>>
>> trace_napi_gro_frags_entry(skb);
>>
>> - return napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
>> + ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
>> + trace_napi_gro_frags_exit(skb, ret);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(napi_gro_frags);
>>
>> --
>> 2.19.1
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH net-next] net: phy: check for implementation of both callbacks in phy_drv_supports_irq
From: Florian Fainelli @ 2018-11-12 20:22 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <d6f37c41-76f1-56ce-0047-c44224b7ff96@gmail.com>
On 11/12/18 12:16 PM, Heiner Kallweit wrote:
> Now that the icplus driver has been fixed all PHY drivers supporting
> interrupts have both callbacks (config_intr and ack_interrupt)
> implemented - as it should be. Therefore phy_drv_supports_irq()
> can be changed now to check for both callbacks being implemented.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v2] net: Add trace events for all receive exit points
From: Steven Rostedt @ 2018-11-12 20:32 UTC (permalink / raw)
To: Geneviève Bastien; +Cc: davem, netdev, Mathieu Desnoyers, Ingo Molnar
In-Reply-To: <20181112194405.4133-1-gbastien@versatic.net>
On Mon, 12 Nov 2018 14:44:05 -0500
Geneviève Bastien <gbastien@versatic.net> wrote:
> Trace events are already present for the receive entry points, to indicate
> how the reception entered the stack.
>
> This patch adds the corresponding exit trace events that will bound the
> reception such that all events occurring between the entry and the exit
> can be considered as part of the reception context. This greatly helps
> for dependency and root cause analyses.
>
> Without this, it is impossible to determine whether a sched_wakeup
> event following a netif_receive_skb event is the result of the packet
> reception or a simple coincidence after further processing by the
> thread.
>
> Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
> CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Ingo Molnar <mingo@redhat.com>
> CC: David S. Miller <davem@davemloft.net>
> ---
> Changes in v2:
> - Add the return value to tracepoints where applicable
> - Verify if tracepoint is enabled before walking list in
> netif_receive_skb_list
> ---
> include/trace/events/net.h | 78 ++++++++++++++++++++++++++++++++++++++
> net/core/dev.c | 38 ++++++++++++++++---
> 2 files changed, 110 insertions(+), 6 deletions(-)
>
> diff --git a/include/trace/events/net.h b/include/trace/events/net.h
> index 00aa72ce0e7c..cff1a7b9d0bb 100644
> --- a/include/trace/events/net.h
> +++ b/include/trace/events/net.h
> @@ -117,6 +117,42 @@ DECLARE_EVENT_CLASS(net_dev_template,
> __get_str(name), __entry->skbaddr, __entry->len)
> )
>
> +DECLARE_EVENT_CLASS(net_dev_template_return,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret),
> +
> + TP_STRUCT__entry(
> + __field(void *, skbaddr)
> + __field(int, ret)
> + ),
> +
> + TP_fast_assign(
> + __entry->skbaddr = skb;
> + __entry->ret = ret;
> + ),
> +
> + TP_printk("skbaddr=%p ret=%d", __entry->skbaddr, __entry->ret)
> +)
> +
> +DECLARE_EVENT_CLASS(net_dev_template_simple,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb),
> +
> + TP_STRUCT__entry(
> + __field(void *, skbaddr)
> + ),
> +
> + TP_fast_assign(
> + __entry->skbaddr = skb;
> + ),
> +
> + TP_printk("skbaddr=%p", __entry->skbaddr)
> +)
> +
> DEFINE_EVENT(net_dev_template, net_dev_queue,
>
> TP_PROTO(struct sk_buff *skb),
> @@ -244,6 +280,48 @@ DEFINE_EVENT(net_dev_rx_verbose_template, netif_rx_ni_entry,
> TP_ARGS(skb)
> );
>
> +DEFINE_EVENT(net_dev_template_return, napi_gro_frags_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, napi_gro_receive_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, netif_receive_skb_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_list_exit,
One small nit, and I don't care enough to ask you to fix it, but others
might care. We probably should not intermix net_dev_template_simple
events within net_dev_template_return events.
But like I said, I don't really care, it's more cosmetic than anything
else.
For the tracing side:
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, netif_rx_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> +DEFINE_EVENT(net_dev_template_return, netif_rx_ni_exit,
> +
> + TP_PROTO(struct sk_buff *skb, int ret),
> +
> + TP_ARGS(skb, ret)
> +);
> +
> #endif /* _TRACE_NET_H */
>
>
^ 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