* Re: [PATCH net-next] tcp: Check daddr_cache before use in tracepoint
From: Cong Wang @ 2017-10-16 21:46 UTC (permalink / raw)
To: David Ahern; +Cc: Linux Kernel Network Developers
In-Reply-To: <1508189387-27931-1-git-send-email-dsahern@gmail.com>
On Mon, Oct 16, 2017 at 2:29 PM, David Ahern <dsahern@gmail.com> wrote:
> Running perf in one window to capture tcp_retransmit_skb tracepoint:
> $ perf record -e tcp:tcp_retransmit_skb -a
>
> And causing a retransmission on an active TCP session (e.g., dropping
> packets in the receiver, changing MTU on the interface to 500 and back
> to 1500) triggers a panic:
>
> [ 58.543144] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> [ 58.545300] IP: perf_trace_tcp_retransmit_skb+0xd0/0x145
> [ 58.546770] PGD 0 P4D 0
> [ 58.547472] Oops: 0000 [#1] SMP
> [ 58.548328] Modules linked in: vrf
> [ 58.549262] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc4+ #26
> [ 58.551004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [ 58.554560] task: ffffffff81a0e540 task.stack: ffffffff81a00000
> [ 58.555817] RIP: 0010:perf_trace_tcp_retransmit_skb+0xd0/0x145
> [ 58.557137] RSP: 0018:ffff88003fc03d68 EFLAGS: 00010282
> [ 58.558292] RAX: 0000000000000000 RBX: ffffe8ffffc0ec80 RCX: ffff880038543098
> [ 58.559850] RDX: 0400000000000000 RSI: ffff88003fc03d70 RDI: ffff88003fc14b68
> [ 58.561099] RBP: ffff88003fc03da8 R08: 0000000000000000 R09: ffffea0000d3224a
> [ 58.562005] R10: ffff88003fc03db8 R11: 0000000000000010 R12: ffff8800385428c0
> [ 58.562930] R13: ffffe8ffffc0e478 R14: ffffffff81a93a40 R15: ffff88003d4f0c00
> [ 58.563845] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 58.564873] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 58.565613] CR2: 0000000000000008 CR3: 000000003d68f004 CR4: 00000000000606f0
> [ 58.566538] Call Trace:
> [ 58.566865] <IRQ>
> [ 58.567140] __tcp_retransmit_skb+0x4ab/0x4c6
> [ 58.567704] ? tcp_set_ca_state+0x22/0x3f
> [ 58.568231] tcp_retransmit_skb+0x14/0xa3
> [ 58.568754] tcp_retransmit_timer+0x472/0x5e3
> [ 58.569324] ? tcp_write_timer_handler+0x1e9/0x1e9
> [ 58.569946] tcp_write_timer_handler+0x95/0x1e9
> [ 58.570548] tcp_write_timer+0x2a/0x58
>
> Check that daddr_cache is non-NULL before de-referencing.
Well, for NULL case, the entry->saddr_v6 will not be filled with
your patch.
How about using sk->sk_v6_daddr?
^ permalink raw reply
* Re: [PATCH net-next] tcp: Use pI6c in tcp tracepoint
From: David Ahern @ 2017-10-16 21:45 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpV5=uSzF3zBDPjrg9uhpLGk0tk07p0RLJgEvgOnSkSjDw@mail.gmail.com>
On 10/16/17 3:41 PM, Cong Wang wrote:
> I was planning to send a same patch based on your
> suggestion, you are faster than me. ;)
>
I would have sent that patch hours ago, but got hung up on the testing.
See the second patch.
^ permalink raw reply
* [net-next:master 277/285] include/trace/events/xdp.h:91:17: warning: 'struct bpf_map' declared inside parameter list
From: kbuild test robot @ 2017-10-16 21:42 UTC (permalink / raw)
To: Steven Rostedt (VMware); +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 18116 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: e4467f2e2442e15cf047c2e7b91cb44a643cb149
commit: 9185a610f8f7f1b4e4d28c9de27d1969cf58e0f1 [277/285] tracing: bpf: Hide bpf trace events when they are not used
config: x86_64-randconfig-i0-201742 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 9185a610f8f7f1b4e4d28c9de27d1969cf58e0f1
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/trace/events/xdp.h:9:0,
from include/linux/bpf_trace.h:5,
from drivers/net//ethernet/qlogic/qede/qede_fp.c:35:
>> include/trace/events/xdp.h:91:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:256:34: note: in definition of macro '__DECLARE_TRACE'
static inline void trace_##name(proto) \
^
include/linux/tracepoint.h:352:24: note: in expansion of macro 'PARAMS'
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:87:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
^
include/trace/events/xdp.h:88:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
>> include/trace/events/xdp.h:91:17: warning: its scope is only this definition or declaration, which is probably not what you want
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:256:34: note: in definition of macro '__DECLARE_TRACE'
static inline void trace_##name(proto) \
^
include/linux/tracepoint.h:352:24: note: in expansion of macro 'PARAMS'
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:87:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
^
include/trace/events/xdp.h:88:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
>> include/trace/events/xdp.h:91:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:258:44: note: in definition of macro '__DECLARE_TRACE'
static inline void trace_##name##_rcuidle(proto) \
^
include/linux/tracepoint.h:352:24: note: in expansion of macro 'PARAMS'
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:87:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
^
include/trace/events/xdp.h:88:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
>> include/trace/events/xdp.h:91:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:261:38: note: in definition of macro '__DECLARE_TRACE'
register_trace_##name(void (*probe)(data_proto), \
^
include/linux/tracepoint.h:354:4: note: in expansion of macro 'PARAMS'
PARAMS(void *__data, proto), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:87:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
^
include/trace/events/xdp.h:88:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
>> include/trace/events/xdp.h:91:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:267:40: note: in definition of macro '__DECLARE_TRACE'
unregister_trace_##name(void (*probe)(data_proto), \
^
include/linux/tracepoint.h:354:4: note: in expansion of macro 'PARAMS'
PARAMS(void *__data, proto), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:87:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
^
include/trace/events/xdp.h:88:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
>> include/trace/events/xdp.h:91:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:272:65: note: in definition of macro '__DECLARE_TRACE'
static inline void check_trace_callback_type_##name(void (*cb)(data_proto)) \
^
include/linux/tracepoint.h:354:4: note: in expansion of macro 'PARAMS'
PARAMS(void *__data, proto), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:87:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
^
include/trace/events/xdp.h:88:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
include/trace/events/xdp.h:99:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:256:34: note: in definition of macro '__DECLARE_TRACE'
static inline void trace_##name(proto) \
^
include/linux/tracepoint.h:352:24: note: in expansion of macro 'PARAMS'
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:95:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect_err,
^
include/trace/events/xdp.h:96:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
include/trace/events/xdp.h:99:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:258:44: note: in definition of macro '__DECLARE_TRACE'
static inline void trace_##name##_rcuidle(proto) \
^
include/linux/tracepoint.h:352:24: note: in expansion of macro 'PARAMS'
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:95:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect_err,
^
include/trace/events/xdp.h:96:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
include/trace/events/xdp.h:99:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:261:38: note: in definition of macro '__DECLARE_TRACE'
register_trace_##name(void (*probe)(data_proto), \
^
include/linux/tracepoint.h:354:4: note: in expansion of macro 'PARAMS'
PARAMS(void *__data, proto), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:95:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect_err,
^
include/trace/events/xdp.h:96:2: note: in expansion of macro 'TP_PROTO'
TP_PROTO(const struct net_device *dev,
^
include/trace/events/xdp.h:99:17: warning: 'struct bpf_map' declared inside parameter list
const struct bpf_map *map, u32 map_index),
^
include/linux/tracepoint.h:267:40: note: in definition of macro '__DECLARE_TRACE'
unregister_trace_##name(void (*probe)(data_proto), \
^
include/linux/tracepoint.h:354:4: note: in expansion of macro 'PARAMS'
PARAMS(void *__data, proto), \
^
include/linux/tracepoint.h:477:2: note: in expansion of macro 'DECLARE_TRACE'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/linux/tracepoint.h:477:22: note: in expansion of macro 'PARAMS'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
include/trace/events/xdp.h:95:1: note: in expansion of macro 'DEFINE_EVENT'
DEFINE_EVENT(xdp_redirect_template, xdp_redirect_err,
vim +91 include/trace/events/xdp.h
a67edbf4f Daniel Borkmann 2017-01-25 6
a67edbf4f Daniel Borkmann 2017-01-25 7 #include <linux/netdevice.h>
a67edbf4f Daniel Borkmann 2017-01-25 8 #include <linux/filter.h>
a67edbf4f Daniel Borkmann 2017-01-25 @9 #include <linux/tracepoint.h>
a67edbf4f Daniel Borkmann 2017-01-25 10
a67edbf4f Daniel Borkmann 2017-01-25 11 #define __XDP_ACT_MAP(FN) \
a67edbf4f Daniel Borkmann 2017-01-25 12 FN(ABORTED) \
a67edbf4f Daniel Borkmann 2017-01-25 13 FN(DROP) \
a67edbf4f Daniel Borkmann 2017-01-25 14 FN(PASS) \
5acaee0a8 John Fastabend 2017-07-17 15 FN(TX) \
5acaee0a8 John Fastabend 2017-07-17 16 FN(REDIRECT)
a67edbf4f Daniel Borkmann 2017-01-25 17
a67edbf4f Daniel Borkmann 2017-01-25 18 #define __XDP_ACT_TP_FN(x) \
a67edbf4f Daniel Borkmann 2017-01-25 19 TRACE_DEFINE_ENUM(XDP_##x);
a67edbf4f Daniel Borkmann 2017-01-25 20 #define __XDP_ACT_SYM_FN(x) \
a67edbf4f Daniel Borkmann 2017-01-25 21 { XDP_##x, #x },
a67edbf4f Daniel Borkmann 2017-01-25 22 #define __XDP_ACT_SYM_TAB \
a67edbf4f Daniel Borkmann 2017-01-25 23 __XDP_ACT_MAP(__XDP_ACT_SYM_FN) { -1, 0 }
a67edbf4f Daniel Borkmann 2017-01-25 24 __XDP_ACT_MAP(__XDP_ACT_TP_FN)
a67edbf4f Daniel Borkmann 2017-01-25 25
a67edbf4f Daniel Borkmann 2017-01-25 26 TRACE_EVENT(xdp_exception,
a67edbf4f Daniel Borkmann 2017-01-25 27
a67edbf4f Daniel Borkmann 2017-01-25 28 TP_PROTO(const struct net_device *dev,
a67edbf4f Daniel Borkmann 2017-01-25 29 const struct bpf_prog *xdp, u32 act),
a67edbf4f Daniel Borkmann 2017-01-25 30
a67edbf4f Daniel Borkmann 2017-01-25 31 TP_ARGS(dev, xdp, act),
a67edbf4f Daniel Borkmann 2017-01-25 32
a67edbf4f Daniel Borkmann 2017-01-25 33 TP_STRUCT__entry(
b06337dfd Jesper Dangaard Brouer 2017-08-29 34 __field(int, prog_id)
a67edbf4f Daniel Borkmann 2017-01-25 35 __field(u32, act)
315ec3990 Jesper Dangaard Brouer 2017-08-24 36 __field(int, ifindex)
a67edbf4f Daniel Borkmann 2017-01-25 37 ),
a67edbf4f Daniel Borkmann 2017-01-25 38
a67edbf4f Daniel Borkmann 2017-01-25 39 TP_fast_assign(
b06337dfd Jesper Dangaard Brouer 2017-08-29 40 __entry->prog_id = xdp->aux->id;
a67edbf4f Daniel Borkmann 2017-01-25 41 __entry->act = act;
315ec3990 Jesper Dangaard Brouer 2017-08-24 42 __entry->ifindex = dev->ifindex;
a67edbf4f Daniel Borkmann 2017-01-25 43 ),
a67edbf4f Daniel Borkmann 2017-01-25 44
b06337dfd Jesper Dangaard Brouer 2017-08-29 45 TP_printk("prog_id=%d action=%s ifindex=%d",
b06337dfd Jesper Dangaard Brouer 2017-08-29 46 __entry->prog_id,
315ec3990 Jesper Dangaard Brouer 2017-08-24 47 __print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
315ec3990 Jesper Dangaard Brouer 2017-08-24 48 __entry->ifindex)
a67edbf4f Daniel Borkmann 2017-01-25 49 );
a67edbf4f Daniel Borkmann 2017-01-25 50
8d3b778ff Jesper Dangaard Brouer 2017-08-29 51 DECLARE_EVENT_CLASS(xdp_redirect_template,
5acaee0a8 John Fastabend 2017-07-17 52
a87358558 Jesper Dangaard Brouer 2017-08-24 53 TP_PROTO(const struct net_device *dev,
c31e5a487 Jesper Dangaard Brouer 2017-08-29 54 const struct bpf_prog *xdp,
8d3b778ff Jesper Dangaard Brouer 2017-08-29 55 int to_ifindex, int err,
8d3b778ff Jesper Dangaard Brouer 2017-08-29 56 const struct bpf_map *map, u32 map_index),
5acaee0a8 John Fastabend 2017-07-17 57
8d3b778ff Jesper Dangaard Brouer 2017-08-29 58 TP_ARGS(dev, xdp, to_ifindex, err, map, map_index),
5acaee0a8 John Fastabend 2017-07-17 59
5acaee0a8 John Fastabend 2017-07-17 60 TP_STRUCT__entry(
b06337dfd Jesper Dangaard Brouer 2017-08-29 61 __field(int, prog_id)
5acaee0a8 John Fastabend 2017-07-17 62 __field(u32, act)
a87358558 Jesper Dangaard Brouer 2017-08-24 63 __field(int, ifindex)
4c03bdd7b Jesper Dangaard Brouer 2017-08-17 64 __field(int, err)
8d3b778ff Jesper Dangaard Brouer 2017-08-29 65 __field(int, to_ifindex)
8d3b778ff Jesper Dangaard Brouer 2017-08-29 66 __field(u32, map_id)
8d3b778ff Jesper Dangaard Brouer 2017-08-29 67 __field(int, map_index)
5acaee0a8 John Fastabend 2017-07-17 68 ),
5acaee0a8 John Fastabend 2017-07-17 69
5acaee0a8 John Fastabend 2017-07-17 70 TP_fast_assign(
b06337dfd Jesper Dangaard Brouer 2017-08-29 71 __entry->prog_id = xdp->aux->id;
c31e5a487 Jesper Dangaard Brouer 2017-08-29 72 __entry->act = XDP_REDIRECT;
a87358558 Jesper Dangaard Brouer 2017-08-24 73 __entry->ifindex = dev->ifindex;
4c03bdd7b Jesper Dangaard Brouer 2017-08-17 74 __entry->err = err;
8d3b778ff Jesper Dangaard Brouer 2017-08-29 75 __entry->to_ifindex = to_ifindex;
8d3b778ff Jesper Dangaard Brouer 2017-08-29 76 __entry->map_id = map ? map->id : 0;
8d3b778ff Jesper Dangaard Brouer 2017-08-29 77 __entry->map_index = map_index;
5acaee0a8 John Fastabend 2017-07-17 78 ),
5acaee0a8 John Fastabend 2017-07-17 79
59a308967 Jesper Dangaard Brouer 2017-08-29 80 TP_printk("prog_id=%d action=%s ifindex=%d to_ifindex=%d err=%d",
b06337dfd Jesper Dangaard Brouer 2017-08-29 81 __entry->prog_id,
4c03bdd7b Jesper Dangaard Brouer 2017-08-17 82 __print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
8d3b778ff Jesper Dangaard Brouer 2017-08-29 83 __entry->ifindex, __entry->to_ifindex,
59a308967 Jesper Dangaard Brouer 2017-08-29 84 __entry->err)
5acaee0a8 John Fastabend 2017-07-17 85 );
8d3b778ff Jesper Dangaard Brouer 2017-08-29 86
8d3b778ff Jesper Dangaard Brouer 2017-08-29 @87 DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
8d3b778ff Jesper Dangaard Brouer 2017-08-29 88 TP_PROTO(const struct net_device *dev,
8d3b778ff Jesper Dangaard Brouer 2017-08-29 89 const struct bpf_prog *xdp,
8d3b778ff Jesper Dangaard Brouer 2017-08-29 90 int to_ifindex, int err,
8d3b778ff Jesper Dangaard Brouer 2017-08-29 @91 const struct bpf_map *map, u32 map_index),
8d3b778ff Jesper Dangaard Brouer 2017-08-29 92 TP_ARGS(dev, xdp, to_ifindex, err, map, map_index)
8d3b778ff Jesper Dangaard Brouer 2017-08-29 93 );
8d3b778ff Jesper Dangaard Brouer 2017-08-29 94
:::::: The code at line 91 was first introduced by commit
:::::: 8d3b778ff544b369f0847e6c15f3e73057298aa4 xdp: tracepoint xdp_redirect also need a map argument
:::::: TO: Jesper Dangaard Brouer <brouer@redhat.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32470 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] tcp: Use pI6c in tcp tracepoint
From: Cong Wang @ 2017-10-16 21:41 UTC (permalink / raw)
To: David Ahern; +Cc: Linux Kernel Network Developers
In-Reply-To: <1508189042-19591-1-git-send-email-dsahern@gmail.com>
On Mon, Oct 16, 2017 at 2:24 PM, David Ahern <dsahern@gmail.com> wrote:
> The compact form for IPv6 addresses is more user friendly than the full
> version. For example:
> compact: 2001:db8:1::1
> full: 2001:0db8:0001:0000:0000:0000:0000:0004i
>
> Update the tcp tracepoint to show the compact form.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
I was planning to send a same patch based on your
suggestion, you are faster than me. ;)
^ permalink raw reply
* [PATCH net-next] tcp: Check daddr_cache before use in tracepoint
From: David Ahern @ 2017-10-16 21:29 UTC (permalink / raw)
To: netdev; +Cc: xiyou.wangcong, David Ahern
Running perf in one window to capture tcp_retransmit_skb tracepoint:
$ perf record -e tcp:tcp_retransmit_skb -a
And causing a retransmission on an active TCP session (e.g., dropping
packets in the receiver, changing MTU on the interface to 500 and back
to 1500) triggers a panic:
[ 58.543144] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 58.545300] IP: perf_trace_tcp_retransmit_skb+0xd0/0x145
[ 58.546770] PGD 0 P4D 0
[ 58.547472] Oops: 0000 [#1] SMP
[ 58.548328] Modules linked in: vrf
[ 58.549262] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc4+ #26
[ 58.551004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 58.554560] task: ffffffff81a0e540 task.stack: ffffffff81a00000
[ 58.555817] RIP: 0010:perf_trace_tcp_retransmit_skb+0xd0/0x145
[ 58.557137] RSP: 0018:ffff88003fc03d68 EFLAGS: 00010282
[ 58.558292] RAX: 0000000000000000 RBX: ffffe8ffffc0ec80 RCX: ffff880038543098
[ 58.559850] RDX: 0400000000000000 RSI: ffff88003fc03d70 RDI: ffff88003fc14b68
[ 58.561099] RBP: ffff88003fc03da8 R08: 0000000000000000 R09: ffffea0000d3224a
[ 58.562005] R10: ffff88003fc03db8 R11: 0000000000000010 R12: ffff8800385428c0
[ 58.562930] R13: ffffe8ffffc0e478 R14: ffffffff81a93a40 R15: ffff88003d4f0c00
[ 58.563845] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 58.564873] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 58.565613] CR2: 0000000000000008 CR3: 000000003d68f004 CR4: 00000000000606f0
[ 58.566538] Call Trace:
[ 58.566865] <IRQ>
[ 58.567140] __tcp_retransmit_skb+0x4ab/0x4c6
[ 58.567704] ? tcp_set_ca_state+0x22/0x3f
[ 58.568231] tcp_retransmit_skb+0x14/0xa3
[ 58.568754] tcp_retransmit_timer+0x472/0x5e3
[ 58.569324] ? tcp_write_timer_handler+0x1e9/0x1e9
[ 58.569946] tcp_write_timer_handler+0x95/0x1e9
[ 58.570548] tcp_write_timer+0x2a/0x58
Check that daddr_cache is non-NULL before de-referencing.
Fixes: e086101b150a ("tcp: add a tracepoint for tcp retransmission")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/trace/events/tcp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index 3d1cbd072b7e..13e8ee8af2c8 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -48,7 +48,8 @@ TRACE_EVENT(tcp_retransmit_skb,
pin6 = (struct in6_addr *)__entry->saddr_v6;
*pin6 = np->saddr;
pin6 = (struct in6_addr *)__entry->daddr_v6;
- *pin6 = *(np->daddr_cache);
+ if (np->daddr_cache)
+ *pin6 = *(np->daddr_cache);
} else {
pin6 = (struct in6_addr *)__entry->saddr_v6;
ipv6_addr_set_v4mapped(inet->inet_saddr, pin6);
--
2.1.4
^ permalink raw reply related
* Re: [iproute2] regression in ss output
From: Stephen Hemminger @ 2017-10-16 21:28 UTC (permalink / raw)
To: Humberto Alves; +Cc: Phil Sutter, netdev@vger.kernel.org
In-Reply-To: <AM4PR0901MB12527C55F04814777A0E6849CC4F0@AM4PR0901MB1252.eurprd09.prod.outlook.com>
On Mon, 16 Oct 2017 20:44:07 +0000
Humberto Alves <hjalves@live.com> wrote:
> Yes, just get rid of this 'if statement'.
> in6addr_any should be represented as '::', not '*'. Otherwise it's
> impossible to distinguish IPv4 listening addresses from IPv6. Thank you :)
But IPv6 accepts IPv4 as well.
^ permalink raw reply
* [PATCH net-next] tcp: Use pI6c in tcp tracepoint
From: David Ahern @ 2017-10-16 21:24 UTC (permalink / raw)
To: netdev; +Cc: xiyou.wangcong, David Ahern
The compact form for IPv6 addresses is more user friendly than the full
version. For example:
compact: 2001:db8:1::1
full: 2001:0db8:0001:0000:0000:0000:0000:0004i
Update the tcp tracepoint to show the compact form.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
include/trace/events/tcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index 3d1cbd072b7e..1ffab6d96e94 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -57,7 +57,7 @@ TRACE_EVENT(tcp_retransmit_skb,
}
),
- TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6 daddrv6=%pI6",
+ TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c",
__entry->sport, __entry->dport, __entry->saddr, __entry->daddr,
__entry->saddr_v6, __entry->daddr_v6)
);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 3/3] bpf: Make sure that ->comm does not change under us.
From: Richard Weinberger @ 2017-10-16 21:10 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-kernel, ast
In-Reply-To: <59E51E4E.4060009@iogearbox.net>
Am Montag, 16. Oktober 2017, 23:02:06 CEST schrieb Daniel Borkmann:
> On 10/16/2017 10:55 PM, Richard Weinberger wrote:
> > Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel Borkmann:
> >>> struct task_struct *task = current;
> >>>
> >>> + task_lock(task);
> >>>
> >>> strncpy(buf, task->comm, size);
> >>>
> >>> + task_unlock(task);
> >>
> >> Wouldn't this potentially lead to a deadlock? E.g. you attach yourself
> >> to task_lock() / spin_lock() / etc, and then the BPF prog triggers the
> >> bpf_get_current_comm() taking the lock again ...
> >
> > Yes, but doesn't the same apply to the use case when I attach to strncpy()
> > and run bpf_get_current_comm()?
>
> You mean due to recursion? In that case trace_call_bpf() would bail out
> due to the bpf_prog_active counter.
Ah, that's true.
So, when someone wants to use bpf_get_current_comm() while tracing task_lock,
we have a problem. I agree.
On the other hand, without locking the function may return wrong results.
Thanks,
//richard
^ permalink raw reply
* Re: [next-queue PATCH v8 0/6] TSN: Add qdisc based config interface for CBS
From: Guedes, Andre @ 2017-10-16 21:07 UTC (permalink / raw)
To: davem@davemloft.net, Gomes, Vinicius, Kirsher, Jeffrey T
Cc: jiri@resnulli.us, jhs@mojatatu.com, Ong, Boon Leong,
rodney.cummings@ni.com, levipearson@gmail.com,
xiyou.wangcong@gmail.com, Sanchez-Palencia, Jesus,
richardcochran@gmail.com, netdev@vger.kernel.org,
henrik@austad.us, Briano, Ivan, intel-wired-lan@lists.osuosl.org
In-Reply-To: <20171016.205146.1053238236578937188.davem@davemloft.net>
+Jeff
Since this patchset also touches the IGB driver, Jeff suggested we merged it
into his tree and he'd make a pull-request to your net-next tree.
@Jeff, are we moving with this approach or should David apply the patchset to
his net-next tree directly?
Thanks,
Andre
On Mon, 2017-10-16 at 20:51 +0100, David Miller wrote:
> I'm fine with this patch set. I see it's against Jeff's next-queue, so
> where exactly do you want this to be merged? My net-next tree?
>
> Thank you.
^ permalink raw reply
* Re: [PATCH 3/3] bpf: Make sure that ->comm does not change under us.
From: Daniel Borkmann @ 2017-10-16 21:02 UTC (permalink / raw)
To: Richard Weinberger; +Cc: netdev, linux-kernel, ast
In-Reply-To: <3636052.F7cf4ubS1t@blindfold>
On 10/16/2017 10:55 PM, Richard Weinberger wrote:
> Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel Borkmann:
>>> struct task_struct *task = current;
>>>
>>> + task_lock(task);
>>>
>>> strncpy(buf, task->comm, size);
>>>
>>> + task_unlock(task);
>>
>> Wouldn't this potentially lead to a deadlock? E.g. you attach yourself
>> to task_lock() / spin_lock() / etc, and then the BPF prog triggers the
>> bpf_get_current_comm() taking the lock again ...
>
> Yes, but doesn't the same apply to the use case when I attach to strncpy()
> and run bpf_get_current_comm()?
You mean due to recursion? In that case trace_call_bpf() would bail out
due to the bpf_prog_active counter.
^ permalink raw reply
* Re: [PATCH 3/3] bpf: Make sure that ->comm does not change under us.
From: Richard Weinberger @ 2017-10-16 20:55 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-kernel, ast
In-Reply-To: <59E51BA3.8040106@iogearbox.net>
Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel Borkmann:
> > struct task_struct *task = current;
> >
> > + task_lock(task);
> >
> > strncpy(buf, task->comm, size);
> >
> > + task_unlock(task);
>
> Wouldn't this potentially lead to a deadlock? E.g. you attach yourself
> to task_lock() / spin_lock() / etc, and then the BPF prog triggers the
> bpf_get_current_comm() taking the lock again ...
Yes, but doesn't the same apply to the use case when I attach to strncpy()
and run bpf_get_current_comm()?
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH 3/3] bpf: Make sure that ->comm does not change under us.
From: Daniel Borkmann @ 2017-10-16 20:50 UTC (permalink / raw)
To: Richard Weinberger, netdev; +Cc: linux-kernel, ast
In-Reply-To: <20171016181856.12497-3-richard@nod.at>
On 10/16/2017 08:18 PM, Richard Weinberger wrote:
> Sadly we cannot use get_task_comm() since bpf_get_current_comm()
> allows truncation.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> kernel/bpf/helpers.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 511c9d522cfc..4b042b24524d 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -18,6 +18,7 @@
> #include <linux/sched.h>
> #include <linux/uidgid.h>
> #include <linux/filter.h>
> +#include <linux/sched/task.h>
>
> /* If kernel subsystem is allowing eBPF programs to call this function,
> * inside its own verifier_ops->get_func_proto() callback it should return
> @@ -149,7 +150,9 @@ BPF_CALL_2(bpf_get_current_comm, char *, buf, u32, size)
> {
> struct task_struct *task = current;
>
> + task_lock(task);
> strncpy(buf, task->comm, size);
> + task_unlock(task);
Wouldn't this potentially lead to a deadlock? E.g. you attach yourself
to task_lock() / spin_lock() / etc, and then the BPF prog triggers the
bpf_get_current_comm() taking the lock again ...
> /* Verifier guarantees that size > 0. For task->comm exceeding
> * size, guarantee that buf is %NUL-terminated. Unconditionally
>
^ permalink raw reply
* [PATCH] ipv4: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2017-10-16 20:48 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: netdev, linux-kernel, netfilter-devel, coreteam,
Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that in some cases I placed the "fall through" comment
on its own line, which is what GCC is expecting to find.
Addresses-Coverity-ID: 115108
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
This code was tested by compilation only (GCC 7.2.0 was used).
Please, verify if the actual intention of the code is to fall through.
net/ipv4/af_inet.c | 3 ++-
net/ipv4/arp.c | 1 +
net/ipv4/devinet.c | 1 +
net/ipv4/ipmr.c | 1 +
net/ipv4/netfilter/nf_nat_l3proto_ipv4.c | 3 ++-
net/ipv4/tcp_input.c | 2 ++
net/ipv4/tcp_ipv4.c | 3 ++-
7 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 43a1bbe..ce4aa82 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -827,6 +827,7 @@ int inet_shutdown(struct socket *sock, int how)
err = -ENOTCONN;
/* Hack to wake up other listeners, who can poll for
POLLHUP, even on eg. unconnected UDP sockets -- RR */
+ /* fall through */
default:
sk->sk_shutdown |= how;
if (sk->sk_prot->shutdown)
@@ -840,7 +841,7 @@ int inet_shutdown(struct socket *sock, int how)
case TCP_LISTEN:
if (!(how & RCV_SHUTDOWN))
break;
- /* Fall through */
+ /* fall through */
case TCP_SYN_SENT:
err = sk->sk_prot->disconnect(sk, O_NONBLOCK);
sock->state = err ? SS_DISCONNECTING : SS_UNCONNECTED;
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 7c45b88..a8d7c5a 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -1180,6 +1180,7 @@ int arp_ioctl(struct net *net, unsigned int cmd, void __user *arg)
case SIOCSARP:
if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
return -EPERM;
+ /* fall through */
case SIOCGARP:
err = copy_from_user(&r, arg, sizeof(struct arpreq));
if (err)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 7ce22a2..d1aee7a 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1522,6 +1522,7 @@ static int inetdev_event(struct notifier_block *this, unsigned long event,
if (inetdev_valid_mtu(dev->mtu))
break;
/* disable IP when MTU is not enough */
+ /* fall through */
case NETDEV_UNREGISTER:
inetdev_destroy(in_dev);
break;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index b3ee01b..40a43ad 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1528,6 +1528,7 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
case MRT_ADD_MFC:
case MRT_DEL_MFC:
parent = -1;
+ /* fall through */
case MRT_ADD_MFC_PROXY:
case MRT_DEL_MFC_PROXY:
if (optlen != sizeof(mfc)) {
diff --git a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
index a0f37b2..0443ca4 100644
--- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
@@ -276,7 +276,8 @@ nf_nat_ipv4_fn(void *priv, struct sk_buff *skb,
else
return NF_ACCEPT;
}
- /* Fall thru... (Only ICMPs can be IP_CT_IS_REPLY) */
+ /* Only ICMPs can be IP_CT_IS_REPLY: */
+ /* fall through */
case IP_CT_NEW:
/* Seen it before? This can happen for loopback, retrans,
* or local packets.
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d0682ce..b2390bf 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2885,6 +2885,7 @@ static void tcp_fastretrans_alert(struct sock *sk, const int acked,
(*ack_flag & FLAG_LOST_RETRANS)))
return;
/* Change state if cwnd is undone or retransmits are lost */
+ /* fall through */
default:
if (tcp_is_reno(tp)) {
if (flag & FLAG_SND_UNA_ADVANCED)
@@ -6044,6 +6045,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
case TCP_LAST_ACK:
if (!before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
break;
+ /* fall through */
case TCP_FIN_WAIT1:
case TCP_FIN_WAIT2:
/* RFC 793 says to queue data in these states,
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5418ecf..ecee4dd 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1779,8 +1779,9 @@ int tcp_v4_rcv(struct sk_buff *skb)
refcounted = false;
goto process;
}
- /* Fall through to ACK */
}
+ /* to ACK */
+ /* fall through */
case TCP_TW_ACK:
tcp_v4_timewait_ack(sk, skb);
break;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/3] bpf: Remove dead variable
From: Daniel Borkmann @ 2017-10-16 20:48 UTC (permalink / raw)
To: Richard Weinberger; +Cc: netdev, linux-kernel, ast
In-Reply-To: <2869131.K5Z6hvSGBl@blindfold>
On 10/16/2017 09:22 PM, Richard Weinberger wrote:
[...]
> So, I can happily squash 2/3 into 1/3 and resent.
Yeah, please just squash them.
Thanks,
Daniel
^ permalink raw reply
* Re: [iproute2] regression in ss output
From: Humberto Alves @ 2017-10-16 20:44 UTC (permalink / raw)
To: Phil Sutter, netdev@vger.kernel.org
In-Reply-To: <20171016103320.GP11332@orbyte.nwl.cc>
[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]
Yes, just get rid of this 'if statement'.
in6addr_any should be represented as '::', not '*'. Otherwise it's
impossible to distinguish IPv4 listening addresses from IPv6. Thank you :)
On 10/16/2017 11:33 AM, Phil Sutter wrote:
> Hi,
>
> On Fri, Oct 13, 2017 at 09:57:37AM +0000, Humberto Alves wrote:
>> Hi! With the last iproute2 release, ss command output does not
>> differentiate between any-address IPv4 sockets from the IPv6 ones.
>> I don't know if this is an expected behaviour, but the old output looks
>> more useful. Below I pasted the difference between the old behaviour and
>> the new one.
>
> Although the change is certainly intentional (it was introduced by
> Stephen Hemminger as a side effect of aba9c23a6e1cb ("ss: enclose IPv6
> address in brackets"), I second reverting to the old display of
> in6addr_any as '::'.
>
>> I am happy to send a patch if you want. Thanks
>
> It should be enough to just getting rid of the
>
> | if (!memcmp(a->data, &in6addr_any, sizeof(in6addr_any))) {
>
> case in inet_addr_print(). The else-case which calls format_host()
> should deal with in6addr_any just fine. This way the address also gets
> enclosed in brackets which helps separating it from the ':port' part.
>
> Cheers, Phil
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3984 bytes --]
^ permalink raw reply
* Re: [iproute2] regression in ss output
From: Humberto Alves @ 2017-10-16 20:34 UTC (permalink / raw)
To: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <20171016092058.470f3424@xeon-e3>
[-- Attachment #1: Type: text/plain, Size: 5750 bytes --]
IMHO that's not ugly.
How is that a feature? Differentiating IPv4 from IPv6 sockets is a
feature to me!
If you want to use '*' in IPv4 and IPv6, add another column please.
Thank you
On 10/16/2017 05:20 PM, Stephen Hemminger wrote:
> On Fri, 13 Oct 2017 09:57:37 +0000
> Humberto Alves <hjalves@live.com> wrote:
>
>> Hi! With the last iproute2 release, ss command output does not
>> differentiate between any-address IPv4 sockets from the IPv6 ones.
>> I don't know if this is an expected behaviour, but the old output looks
>> more useful. Below I pasted the difference between the old behaviour and
>> the new one.
>> I am happy to send a patch if you want. Thanks
>>
>>
>> iproute2-4.12
>> -------------
>>
>> $ ss --version
>> ss utility, iproute2-ss170705
>>
>> $ ss -ntl
>> State Recv-Q Send-Q Local Address:Port Peer
>> Address:Port
>> LISTEN 0 100 *:587 *:*
>>
>> LISTEN 0 100 *:110 *:*
>>
>> LISTEN 0 100 *:143 *:*
>>
>> LISTEN 0 128 *:80 *:*
>>
>> LISTEN 0 128 *:2225 *:*
>>
>> LISTEN 0 10 127.0.0.1:5010 *:*
>>
>> LISTEN 0 128 *:20 *:*
>>
>> LISTEN 0 128 127.0.0.1:20150 *:*
>>
>> LISTEN 0 128 *:61719 *:*
>>
>> LISTEN 0 100 *:25 *:*
>>
>> LISTEN 0 3 *:1723 *:*
>>
>> LISTEN 0 128 *:17500 *:*
>>
>> LISTEN 0 128 127.0.0.1:17600 *:*
>>
>> LISTEN 0 128 *:8000 *:*
>>
>> LISTEN 0 100 *:993 *:*
>>
>> LISTEN 0 128 127.0.0.1:17603 *:*
>>
>> LISTEN 0 100 *:995 *:*
>>
>> LISTEN 0 100 :::587 :::*
>>
>> LISTEN 0 100 :::110 :::*
>>
>> LISTEN 0 100 :::143 :::*
>>
>> LISTEN 0 128 :::22000 :::*
>>
>> LISTEN 0 128 :::80 :::*
>>
>> LISTEN 0 128 :::2225 :::*
>>
>> LISTEN 0 128 :::20 :::*
>>
>> LISTEN 0 128 ::1:20150 :::*
>>
>> LISTEN 0 100 :::25 :::*
>>
>> LISTEN 0 128 :::17500 :::*
>>
>> LISTEN 0 128 :::8384 :::*
>>
>> LISTEN 0 100 :::993 :::*
>>
>> LISTEN 0 100 :::995 :::*
>>
>> iproute2-4.13
>> -------------
>>
>> $ ss --version
>> ss utility, iproute2-ss170905
>>
>> $ ss -ntl
>> State Recv-Q Send-Q Local Address:Port Peer
>> Address:Port
>> LISTEN 0 100 *:587 *:*
>>
>> LISTEN 0 100 *:110 *:*
>>
>> LISTEN 0 100 *:143 *:*
>>
>> LISTEN 0 128 *:80 *:*
>>
>> LISTEN 0 128 *:2225 *:*
>>
>> LISTEN 0 10 127.0.0.1:5010 *:*
>>
>> LISTEN 0 128 *:20 *:*
>>
>> LISTEN 0 128 127.0.0.1:20150 *:*
>>
>> LISTEN 0 128 *:61719 *:*
>>
>> LISTEN 0 100 *:25 *:*
>>
>> LISTEN 0 3 *:1723 *:*
>>
>> LISTEN 0 128 *:17500 *:*
>>
>> LISTEN 0 128 127.0.0.1:17600 *:*
>>
>> LISTEN 0 128 *:8000 *:*
>>
>> LISTEN 0 100 *:993 *:*
>>
>> LISTEN 0 128 127.0.0.1:17603 *:*
>>
>> LISTEN 0 100 *:995 *:*
>>
>> LISTEN 0 100 *:587 *:*
>>
>> LISTEN 0 100 *:110 *:*
>>
>> LISTEN 0 100 *:143 *:*
>>
>> LISTEN 0 128 *:22000 *:*
>>
>> LISTEN 0 128 *:80 *:*
>>
>> LISTEN 0 128 *:2225 *:*
>>
>> LISTEN 0 128 *:20 *:*
>>
>> LISTEN 0 128 [::1]:20150 *:*
>>
>> LISTEN 0 100 *:25 *:*
>>
>> LISTEN 0 128 *:17500 *:*
>>
>> LISTEN 0 128 *:8384 *:*
>>
>> LISTEN 0 100 *:993 *:*
>>
>> LISTEN 0 100 *:995 *:*
>
> All changes are not regressions.
>
> Yes it was intentional because the outputing [::]:20 looked ugly and using * makes IPv4 and IPv6
> look the same.
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3984 bytes --]
^ permalink raw reply
* Re: [patch net-next 0/5] mlxsw: GRE: Offload decap without encap
From: David Miller @ 2017-10-16 20:30 UTC (permalink / raw)
To: jiri; +Cc: netdev, petrm, idosch, mlxsw
In-Reply-To: <20171016142639.2453-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 16 Oct 2017 16:26:34 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Petr says:
>
> The current code doesn't offload GRE decapsulation unless there's a
> corresponding encapsulation route as well. While not strictly incorrect (when
> encap route is absent, the decap route traps traffic to CPU and the kernel
> handles it), it's a missed optimization opportunity.
>
> With this patchset, IPIP entries are created as soon as offloadable tunneling
> netdevice is created. This then leads to offloading of decap route, if one
> exists, or is added afterwards, even when no encap route is present.
>
> In Linux, when there is a decap route, matching IP-in-IP packets are always
> decapsulated. However, with IPv4 overlays in particular, whether the inner
> packet is then forwarded depends on setting of net.ipv4.conf.*.rp_filter. When
> RP filtering is turned on, inner packets aren't forwarded unless there's a
> matching encap route. The mlxsw driver doesn't reflect this behavior in other
> router interfaces, and thus it's not implemented for tunnel types either. A
> better support for this will be subject of follow-up work.
Series applied.
^ permalink raw reply
* Re: [net-next 1/1] tipc: fix rebasing error
From: David Miller @ 2017-10-16 20:29 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, parthasarathy.bhuvaragan, ying.xue, tipc-discussion
In-Reply-To: <1508162691-31392-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 16 Oct 2017 16:04:51 +0200
> In commit 2f487712b893 ("tipc: guarantee that group broadcast doesn't
> bypass group unicast") there was introduced a last-minute rebasing
> error that broke non-group communication.
>
> We fix this here.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: pull-request: mac80211 2017-10-16
From: David Miller @ 2017-10-16 20:29 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20171016134618.30810-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 16 Oct 2017 15:46:17 +0200
> Here's a fix, for a small part of the "KRACK" announced today
> (krackattacks.com).
>
> Please pull and let me know if there's any problem.
Pulled.
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: core: rcuify rtnl af_ops
From: David Miller @ 2017-10-16 20:26 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20171016134436.25282-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Mon, 16 Oct 2017 15:44:34 +0200
> None of the rtnl af_ops callbacks sleep, so they can be called while
> holding rcu read lock.
>
> Switch handling of af_ops to rcu.
>
> This would allow to later call af_ops functions without holding
> the rtnl mutex anymore.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: cdg: make struct tcp_cdg static
From: David Miller @ 2017-10-16 20:25 UTC (permalink / raw)
To: colin.king; +Cc: kuznet, yoshfuji, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20171016133321.15477-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Mon, 16 Oct 2017 14:33:21 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The structure tcp_cdg is local to the source and
> does not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'tcp_cdg' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] dev_ioctl: add missing NETDEV_CHANGE_TX_QUEUE_LEN event notification
From: David Miller @ 2017-10-16 20:24 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev
In-Reply-To: <c7cb587e601d7e27d126d79b6f06c873af1659bc.1508154195.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 16 Oct 2017 19:43:15 +0800
> When changing dev tx_queue_len via netlink or net-sysfs,
> a NETDEV_CHANGE_TX_QUEUE_LEN event notification will be
> called.
>
> But dev_ioctl missed this event notification, which could
> cause no userspace notification would be sent.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xen-netfront, xen-netback: Use correct minimum MTU values
From: David Miller @ 2017-10-16 20:22 UTC (permalink / raw)
To: boris.ostrovsky
Cc: wei.liu2, mgamal, netdev, xen-devel, paul.durrant, linux-kernel,
vkuznets, otubo, cavery, cheshi, jgross
In-Reply-To: <3da3d5ae-c2cb-380e-368d-a90432608cf1@oracle.com>
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Mon, 16 Oct 2017 16:19:07 -0400
> On 10/16/2017 11:05 AM, Wei Liu wrote:
>> On Mon, Oct 16, 2017 at 03:20:32PM +0200, Mohammed Gamal wrote:
>>> RFC791 specifies the minimum MTU to be 68, while xen-net{front|back}
>>> drivers use a minimum value of 0.
>>>
>>> When set MTU to 0~67 with xen_net{front|back} driver, the network
>>> will become unreachable immediately, the guest can no longer be pinged.
>>>
>>> xen_net{front|back} should not allow the user to set this value which causes
>>> network problems.
>>>
>>> Reported-by: Chen Shi <cheshi@redhat.com>
>>> Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
>> Acked-by: Wei Liu <wei.liu2@citrix.com>
>>
>> CC netfront maintainers
>
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> I can take it via Xen tree unless there are objections.
No problem on my end.
^ permalink raw reply
* Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used
From: Steven Rostedt @ 2017-10-16 20:21 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, ast, daniel, netdev
In-Reply-To: <20171016.211106.146432024027343504.davem@davemloft.net>
On Mon, 16 Oct 2017 21:11:06 +0100 (WEST)
David Miller <davem@davemloft.net> wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Date: Mon, 16 Oct 2017 16:01:25 -0400
>
> > On Mon, 16 Oct 2017 20:54:34 +0100 (WEST)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> Steven, I lost track of how this patch is being handled.
> >>
> >> Do you want me to merge it via my net-next tree?
> >
> > If you want. I could take it too if you give me an ack. It's not
> > dependent on any other changes so it doesn't matter which way it goes. I
> > know Alexei was thinking about doing the same for xdp but those appear
> > to be used even without BPF_SYSCALLS.
>
> Ok, applied to my net-next tree and if you want to apply it to your's
> too, here is the ACK:
>
> Acked-by: David S. Miller <davem@davemloft.net>
Thanks! But if you are taking it, I'm fine with that. It may be a while
before I get my tool applied that detects unused tracepoints at compile
time. I have it working at runtime, but rather have a compiler warning.
-- Steve
^ permalink raw reply
* Re: [PATCH] [net-next] net: systemport: add NET_DSA dependency
From: David Miller @ 2017-10-16 20:21 UTC (permalink / raw)
To: arnd
Cc: f.fainelli, michael.chan, sathya.perla, nicolas.pitre, netdev,
linux-kernel
In-Reply-To: <20171016113258.3735473-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 16 Oct 2017 13:32:36 +0200
> The notifier cause a link error when NET_DSA is a loadable
> module:
>
> drivers/net/ethernet/broadcom/bcmsysport.o: In function `bcm_sysport_remove':
> bcmsysport.c:(.text+0x1582): undefined reference to `unregister_dsa_notifier'
> drivers/net/ethernet/broadcom/bcmsysport.o: In function `bcm_sysport_probe':
> bcmsysport.c:(.text+0x278d): undefined reference to `register_dsa_notifier'
>
> This adds a dependency that forces the systemport driver to be
> a loadable module as well when that happens, but otherwise
> allows it to be built normally when DSA is either built-in or
> completely disabled.
>
> Fixes: d156576362c0 ("net: systemport: Establish lower/upper queue mapping")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you.
^ 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