* [bpf-next v2 PATCH 2/3] samples/bpf: make xdp_fwd more practically usable via devmap lookup
From: Jesper Dangaard Brouer @ 2019-08-08 15:46 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov
Cc: a.s.protopopov, dsahern, Toke Høiland-Jørgensen,
ys114321, Jesper Dangaard Brouer
In-Reply-To: <156527914510.20297.12225832190052744019.stgit@firesoul>
This address the TODO in samples/bpf/xdp_fwd_kern.c, which points out
that the chosen egress index should be checked for existence in the
devmap. This can now be done via taking advantage of Toke's work in
commit 0cdbb4b09a06 ("devmap: Allow map lookups from eBPF").
This change makes xdp_fwd more practically usable, as this allows for
a mixed environment, where IP-forwarding fallback to network stack, if
the egress device isn't configured to use XDP.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
---
samples/bpf/xdp_fwd_kern.c | 17 +++++++++++------
samples/bpf/xdp_fwd_user.c | 36 +++++++++++++++++++++++++-----------
2 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/samples/bpf/xdp_fwd_kern.c b/samples/bpf/xdp_fwd_kern.c
index e6ffc4ea06f4..a43d6953c054 100644
--- a/samples/bpf/xdp_fwd_kern.c
+++ b/samples/bpf/xdp_fwd_kern.c
@@ -104,13 +104,18 @@ static __always_inline int xdp_fwd_flags(struct xdp_md *ctx, u32 flags)
rc = bpf_fib_lookup(ctx, &fib_params, sizeof(fib_params), flags);
- /* verify egress index has xdp support
- * TO-DO bpf_map_lookup_elem(&tx_port, &key) fails with
- * cannot pass map_type 14 into func bpf_map_lookup_elem#1:
- * NOTE: without verification that egress index supports XDP
- * forwarding packets are dropped.
- */
if (rc == 0) {
+ /* Verify egress index has been configured as TX-port.
+ * (Note: User can still have inserted an egress ifindex that
+ * doesn't support XDP xmit, which will result in packet drops).
+ *
+ * Note: lookup in devmap supported since 0cdbb4b09a0.
+ * If not supported will fail with:
+ * cannot pass map_type 14 into func bpf_map_lookup_elem#1:
+ */
+ if (!bpf_map_lookup_elem(&xdp_tx_ports, &fib_params.ifindex))
+ return XDP_PASS;
+
if (h_proto == htons(ETH_P_IP))
ip_decrease_ttl(iph);
else if (h_proto == htons(ETH_P_IPV6))
diff --git a/samples/bpf/xdp_fwd_user.c b/samples/bpf/xdp_fwd_user.c
index ba012d9f93dd..20951bc27477 100644
--- a/samples/bpf/xdp_fwd_user.c
+++ b/samples/bpf/xdp_fwd_user.c
@@ -27,14 +27,20 @@
#include "libbpf.h"
#include <bpf/bpf.h>
-
-static int do_attach(int idx, int fd, const char *name)
+static int do_attach(int idx, int prog_fd, int map_fd, const char *name)
{
int err;
- err = bpf_set_link_xdp_fd(idx, fd, 0);
- if (err < 0)
+ err = bpf_set_link_xdp_fd(idx, prog_fd, 0);
+ if (err < 0) {
printf("ERROR: failed to attach program to %s\n", name);
+ return err;
+ }
+
+ /* Adding ifindex as a possible egress TX port */
+ err = bpf_map_update_elem(map_fd, &idx, &idx, 0);
+ if (err)
+ printf("ERROR: failed using device %s as TX-port\n", name);
return err;
}
@@ -47,6 +53,9 @@ static int do_detach(int idx, const char *name)
if (err < 0)
printf("ERROR: failed to detach program from %s\n", name);
+ /* TODO: Remember to cleanup map, when adding use of shared map
+ * bpf_map_delete_elem((map_fd, &idx);
+ */
return err;
}
@@ -67,10 +76,10 @@ int main(int argc, char **argv)
};
const char *prog_name = "xdp_fwd";
struct bpf_program *prog;
+ int prog_fd, map_fd = -1;
char filename[PATH_MAX];
struct bpf_object *obj;
int opt, i, idx, err;
- int prog_fd, map_fd;
int attach = 1;
int ret = 0;
@@ -103,8 +112,17 @@ int main(int argc, char **argv)
return 1;
}
- if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd))
+ err = bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd);
+ if (err) {
+ if (err == -22) {
+ printf("Does kernel support devmap lookup?\n");
+ /* If not, the error message will be:
+ * "cannot pass map_type 14 into func
+ * bpf_map_lookup_elem#1"
+ */
+ }
return 1;
+ }
prog = bpf_object__find_program_by_title(obj, prog_name);
prog_fd = bpf_program__fd(prog);
@@ -119,10 +137,6 @@ int main(int argc, char **argv)
return 1;
}
}
- if (attach) {
- for (i = 1; i < 64; ++i)
- bpf_map_update_elem(map_fd, &i, &i, 0);
- }
for (i = optind; i < argc; ++i) {
idx = if_nametoindex(argv[i]);
@@ -138,7 +152,7 @@ int main(int argc, char **argv)
if (err)
ret = err;
} else {
- err = do_attach(idx, prog_fd, argv[i]);
+ err = do_attach(idx, prog_fd, map_fd, argv[i]);
if (err)
ret = err;
}
^ permalink raw reply related
* [bpf-next v2 PATCH 3/3] samples/bpf: xdp_fwd explain bpf_fib_lookup return codes
From: Jesper Dangaard Brouer @ 2019-08-08 15:46 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov
Cc: a.s.protopopov, dsahern, Toke Høiland-Jørgensen,
ys114321, Jesper Dangaard Brouer
In-Reply-To: <156527914510.20297.12225832190052744019.stgit@firesoul>
Make it clear that this XDP program depend on the network
stack to do the ARP resolution. This is connected with the
BPF_FIB_LKUP_RET_NO_NEIGH return code from bpf_fib_lookup().
Another common mistake (seen via XDP-tutorial) is that users
don't realize that sysctl net.ipv{4,6}.conf.all.forwarding
setting is honored by bpf_fib_lookup.
Reported-by: Anton Protopopov <a.s.protopopov@gmail.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
samples/bpf/xdp_fwd_kern.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/samples/bpf/xdp_fwd_kern.c b/samples/bpf/xdp_fwd_kern.c
index a43d6953c054..701a30f258b1 100644
--- a/samples/bpf/xdp_fwd_kern.c
+++ b/samples/bpf/xdp_fwd_kern.c
@@ -103,8 +103,23 @@ static __always_inline int xdp_fwd_flags(struct xdp_md *ctx, u32 flags)
fib_params.ifindex = ctx->ingress_ifindex;
rc = bpf_fib_lookup(ctx, &fib_params, sizeof(fib_params), flags);
-
- if (rc == 0) {
+ /*
+ * Some rc (return codes) from bpf_fib_lookup() are important,
+ * to understand how this XDP-prog interacts with network stack.
+ *
+ * BPF_FIB_LKUP_RET_NO_NEIGH:
+ * Even if route lookup was a success, then the MAC-addresses are also
+ * needed. This is obtained from arp/neighbour table, but if table is
+ * (still) empty then BPF_FIB_LKUP_RET_NO_NEIGH is returned. To avoid
+ * doing ARP lookup directly from XDP, then send packet to normal
+ * network stack via XDP_PASS and expect it will do ARP resolution.
+ *
+ * BPF_FIB_LKUP_RET_FWD_DISABLED:
+ * The bpf_fib_lookup respect sysctl net.ipv{4,6}.conf.all.forwarding
+ * setting, and will return BPF_FIB_LKUP_RET_FWD_DISABLED if not
+ * enabled this on ingress device.
+ */
+ if (rc == BPF_FIB_LKUP_RET_SUCCESS) {
/* Verify egress index has been configured as TX-port.
* (Note: User can still have inserted an egress ifindex that
* doesn't support XDP xmit, which will result in packet drops).
^ permalink raw reply related
* Re: [PATCH net-next] r8169: make use of xmit_more
From: Holger Hoffstätte @ 2019-08-08 15:53 UTC (permalink / raw)
To: Heiner Kallweit, Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Sander Eikelenboom, Eric Dumazet
In-Reply-To: <acd65426-0c7e-8c5f-a002-a36286f09122@applied-asynchrony.com>
On 8/8/19 4:37 PM, Holger Hoffstätte wrote:
>
> Hello Heiner -
>
> On 7/28/19 11:25 AM, Heiner Kallweit wrote:
>> There was a previous attempt to use xmit_more, but the change had to be
>> reverted because under load sometimes a transmit timeout occurred [0].
>> Maybe this was caused by a missing memory barrier, the new attempt
>> keeps the memory barrier before the call to netif_stop_queue like it
>> is used by the driver as of today. The new attempt also changes the
>> order of some calls as suggested by Eric.
>>
>> [0] https://lkml.org/lkml/2019/2/10/39
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> I decided to take one for the team and merged this into my 5.2.x tree (just
> fixing up the path) and it has been working fine for the last 2 weeks in two
> machines..until today, when for the first time in forever some random NFS traffic
> made this old friend come out from under the couch:
>
> [Aug 8 14:13] ------------[ cut here ]------------
> [ +0.000006] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
> [ +0.000021] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x21f/0x230
> [ +0.000001] Modules linked in: lz4 lz4_compress lz4_decompress nfsd auth_rpcgss oid_registry lockd grace sunrpc sch_fq_codel btrfs xor zstd_compress raid6_pq zstd_decompress bfq jitterentropy_rng nct6775 hwmon_vid coretemp hwmon x86_pkg_temp_thermal aesni_intel aes_x86_64 i915 glue_helper crypto_simd cryptd i2c_i801 intel_gtt i2c_algo_bit iosf_mbi drm_kms_helper syscopyarea usbhid sysfillrect r8169 sysimgblt fb_sys_fops realtek drm libphy drm_panel_orientation_quirks i2c_core video backlight mq_deadline
> [ +0.000026] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.2.7 #1
> [ +0.000001] Hardware name: System manufacturer System Product Name/P8Z68-V LX, BIOS 4105 07/01/2013
> [ +0.000004] RIP: 0010:dev_watchdog+0x21f/0x230
> [ +0.000002] Code: 3b 00 75 ea eb ad 4c 89 ef c6 05 1c 45 bd 00 01 e8 66 35 fc ff 44 89 e1 4c 89 ee 48 c7 c7 e8 5e fc 81 48 89 c2 e8 90 df 92 ff <0f> 0b eb 8e 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 66 66 66 66 90
> [ +0.000002] RSP: 0018:ffffc90000118e68 EFLAGS: 00010286
> [ +0.000002] RAX: 0000000000000000 RBX: ffff8887f7837600 RCX: 0000000000000303
> [ +0.000001] RDX: 0000000000000001 RSI: 0000000000000092 RDI: ffffffff827a488c
> [ +0.000001] RBP: ffff8887f9fbc440 R08: 0000000000000303 R09: 0000000000000003
> [ +0.000001] R10: 000000000001004c R11: 0000000000000001 R12: 0000000000000000
> [ +0.000009] R13: ffff8887f9fbc000 R14: ffffffff8173aa20 R15: dead000000000200
> [ +0.000001] FS: 0000000000000000(0000) GS:ffff8887ff580000(0000) knlGS:0000000000000000
> [ +0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ +0.000001] CR2: 00007f8d1c04d000 CR3: 0000000002209001 CR4: 00000000000606e0
> [ +0.000000] Call Trace:
> [ +0.000002] <IRQ>
> [ +0.000005] call_timer_fn+0x2b/0x120
> [ +0.000002] expire_timers+0xa4/0x100
> [ +0.000001] run_timer_softirq+0x8c/0x170
> [ +0.000002] ? __hrtimer_run_queues+0x13a/0x290
> [ +0.000003] ? sched_clock_cpu+0xe/0x130
> [ +0.000003] __do_softirq+0xeb/0x2de
> [ +0.000003] irq_exit+0x9d/0xe0
> [ +0.000002] smp_apic_timer_interrupt+0x60/0x110
> [ +0.000003] apic_timer_interrupt+0xf/0x20
> [ +0.000001] </IRQ>
> [ +0.000003] RIP: 0010:cpuidle_enter_state+0xad/0x930
> [ +0.000001] Code: c5 66 66 66 66 90 31 ff e8 90 99 9e ff 80 7c 24 0b 00 74 12 9c 58 f6 c4 02 0f 85 39 08 00 00 31 ff e8 e7 26 a2 ff fb 45 85 e4 <0f> 88 34 02 00 00 49 63 cc 4c 2b 2c 24 48 8d 04 49 48 c1 e0 05 8b
> [ +0.000000] RSP: 0018:ffffc9000008be50 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
> [ +0.000001] RAX: ffff8887ff5a9180 RBX: ffffffff822b6c40 RCX: 000000000000001f
> [ +0.000001] RDX: 0000000000000000 RSI: 0000000033087154 RDI: 0000000000000000
> [ +0.000001] RBP: ffff8887ff5b1310 R08: 000030d021fae397 R09: ffff8887ff59c8c0
> [ +0.000000] R10: ffff8887ff59c8c0 R11: 0000000000000006 R12: 0000000000000004
> [ +0.000001] R13: 000030d021fae397 R14: 0000000000000004 R15: ffff8887fc281600
> [ +0.000001] cpuidle_enter+0x29/0x40
> [ +0.000002] do_idle+0x1e5/0x280
> [ +0.000001] cpu_startup_entry+0x19/0x20
> [ +0.000002] start_secondary+0x186/0x1c0
> [ +0.000001] secondary_startup_64+0xa4/0xb0
> [ +0.000001] ---[ end trace 99493c768580f4fd ]---
>
> The device is:
>
> Aug 7 23:19:09 tux kernel: libphy: r8169: probed
> Aug 7 23:19:09 tux kernel: r8169 0000:04:00.0 eth0: RTL8168evl/8111evl, c8:60:00:68:33:cc, XID 2c9, IRQ 36
> Aug 7 23:19:09 tux kernel: r8169 0000:04:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
> Aug 7 23:19:12 tux kernel: RTL8211E Gigabit Ethernet r8169-400:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-400:00, irq=IGNORE)
> Aug 7 23:19:13 tux kernel: r8169 0000:04:00.0 eth0: No native access to PCI extended config space, falling back to CSI
>
> and using fq_codel, of course.
>
> This cpuidle hiccup used to be completely gone without xmit_more and this was
> the first (and so far only) time since merging it (regardless of load).
> Also, while I'm using BMQ as CPU scheduler, that hasn't made a difference for
> this particular problem in the past (with MuQSS/PDS) either; way back when I had
> Eric's previous attempt(s) it also hiccupped with CFS.
>
> Revert or wait for more reports when -next is merged in 5.4?
Another question/data point: I've had the whole basket of offloads activated:
ethtool --offload eth0 rx on tx on gro on gso on sg on tso on
and this caused zero problems without the xmit_more patch. However I just saw
that net-next has a patch where TSO is disabled due to a known HW defect in
RTL8168evl, which is of course what I have. Could this be the reason for the
stall/hiccup when xmit_more has its fingers in the pie? I kind of know what
xmit_more does, just not how it could interact with a possibly broken TSO that
nevertheless seems to work fine otherwise..
thanks
Holger
^ permalink raw reply
* Re: [bpf-next v2 PATCH 2/3] samples/bpf: make xdp_fwd more practically usable via devmap lookup
From: Jesper Dangaard Brouer @ 2019-08-08 15:58 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov
Cc: a.s.protopopov, dsahern, Toke Høiland-Jørgensen,
ys114321, brouer
In-Reply-To: <156527920658.20297.5634629362034006298.stgit@firesoul>
On Thu, 08 Aug 2019 17:46:46 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> @@ -103,8 +112,17 @@ int main(int argc, char **argv)
> return 1;
> }
>
> - if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd))
> + err = bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd);
> + if (err) {
> + if (err == -22) {
Darn - I forgot this, need to be changed.
I'll send a V3.
> + printf("Does kernel support devmap lookup?\n");
> + /* If not, the error message will be:
> + * "cannot pass map_type 14 into func
> + * bpf_map_lookup_elem#1"
> + */
> + }
> return 1;
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net v3] net/tls: prevent skb_orphan() from leaking TLS plain text with offload
From: Willem de Bruijn @ 2019-08-08 15:59 UTC (permalink / raw)
To: Jakub Kicinski, John Fastabend
Cc: David Miller, Network Development, davejwatson, borisp, aviadye,
Daniel Borkmann, Eric Dumazet, Alexei Starovoitov, oss-drivers
In-Reply-To: <20190808000359.20785-1-jakub.kicinski@netronome.com>
On Wed, Aug 7, 2019 at 8:04 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> sk_validate_xmit_skb() and drivers depend on the sk member of
> struct sk_buff to identify segments requiring encryption.
> Any operation which removes or does not preserve the original TLS
> socket such as skb_orphan() or skb_clone() will cause clear text
> leaks.
>
> Make the TCP socket underlying an offloaded TLS connection
> mark all skbs as decrypted, if TLS TX is in offload mode.
> Then in sk_validate_xmit_skb() catch skbs which have no socket
> (or a socket with no validation) and decrypted flag set.
>
> Note that CONFIG_SOCK_VALIDATE_XMIT, CONFIG_TLS_DEVICE and
> sk->sk_validate_xmit_skb are slightly interchangeable right now,
> they all imply TLS offload. The new checks are guarded by
> CONFIG_TLS_DEVICE because that's the option guarding the
> sk_buff->decrypted member.
>
> Second, smaller issue with orphaning is that it breaks
> the guarantee that packets will be delivered to device
> queues in-order. All TLS offload drivers depend on that
> scheduling property. This means skb_orphan_partial()'s
> trick of preserving partial socket references will cause
> issues in the drivers. We need a full orphan, and as a
> result netem delay/throttling will cause all TLS offload
> skbs to be dropped.
>
> Reusing the sk_buff->decrypted flag also protects from
> leaking clear text when incoming, decrypted skb is redirected
> (e.g. by TC).
>
> See commit 0608c69c9a80 ("bpf: sk_msg, sock{map|hash} redirect
> through ULP") for justification why the internal flag is safe.
> The only location which could leak the flag in is tcp_bpf_sendmsg(),
> which is taken care of by clearing the previously unused bit.
>
> v2:
> - remove superfluous decrypted mark copy (Willem);
> - remove the stale doc entry (Boris);
> - rely entirely on EOR marking to prevent coalescing (Boris);
> - use an internal sendpages flag instead of marking the socket
> (Boris).
> v3 (Willem):
> - reorganize the can_skb_orphan_partial() condition;
> - fix the flag leak-in through tcp_bpf_sendmsg.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
> index 3d1e15401384..8a56e09cfb0e 100644
> --- a/net/ipv4/tcp_bpf.c
> +++ b/net/ipv4/tcp_bpf.c
> @@ -398,10 +398,14 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock,
> static int tcp_bpf_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> {
> struct sk_msg tmp, *msg_tx = NULL;
> - int flags = msg->msg_flags | MSG_NO_SHARED_FRAGS;
> int copied = 0, err = 0;
> struct sk_psock *psock;
> long timeo;
> + int flags;
> +
> + /* Don't let internal do_tcp_sendpages() flags through */
> + flags = (msg->msg_flags & ~MSG_SENDPAGE_DECRYPTED);
> + flags |= MSG_NO_SHARED_FRAGS;
Not for this patch, but for tcp_bpf itself: should this more
aggressively filter flags?
Both those that are valid in sendmsg, but not expected in sendpage,
and other internal flags passed to sendpage, but should never be
passable from userspace.
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index 7c0b2b778703..43922d86e510 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
> @@ -373,9 +373,9 @@ static int tls_push_data(struct sock *sk,
> struct tls_context *tls_ctx = tls_get_ctx(sk);
> struct tls_prot_info *prot = &tls_ctx->prot_info;
> struct tls_offload_context_tx *ctx = tls_offload_ctx_tx(tls_ctx);
> - int tls_push_record_flags = flags | MSG_SENDPAGE_NOTLAST;
> int more = flags & (MSG_SENDPAGE_NOTLAST | MSG_MORE);
> struct tls_record_info *record = ctx->open_record;
> + int tls_push_record_flags;
> struct page_frag *pfrag;
> size_t orig_size = size;
> u32 max_open_record_len;
> @@ -390,6 +390,9 @@ static int tls_push_data(struct sock *sk,
> if (sk->sk_err)
> return -sk->sk_err;
>
> + flags |= MSG_SENDPAGE_DECRYPTED;
> + tls_push_record_flags = flags | MSG_SENDPAGE_NOTLAST;
> +
Without being too familiar with this code: can this plaintext flag be
set once, closer to the call to do_tcp_sendpages, in tls_push_sg?
Instead of two locations with multiple non-trivial codepaths between
them and do_tcp_sendpages.
Or are there paths where the flag is not set? Which I imagine would
imply already passing s/w encrypted ciphertext.
> timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
> if (tls_is_partially_sent_record(tls_ctx)) {
> rc = tls_push_partial_record(sk, tls_ctx, flags);
> @@ -576,7 +579,9 @@ void tls_device_write_space(struct sock *sk, struct tls_context *ctx)
> gfp_t sk_allocation = sk->sk_allocation;
>
> sk->sk_allocation = GFP_ATOMIC;
> - tls_push_partial_record(sk, ctx, MSG_DONTWAIT | MSG_NOSIGNAL);
> + tls_push_partial_record(sk, ctx,
> + MSG_DONTWAIT | MSG_NOSIGNAL |
> + MSG_SENDPAGE_DECRYPTED);
> sk->sk_allocation = sk_allocation;
> }
> }
> --
> 2.21.0
>
^ permalink raw reply
* [bpf-next v3 PATCH 0/3] bpf: improvements to xdp_fwd sample
From: Jesper Dangaard Brouer @ 2019-08-08 16:17 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov
Cc: a.s.protopopov, dsahern, Toke Høiland-Jørgensen,
ys114321, Jesper Dangaard Brouer
V3: Hopefully fixed all issues point out by Yonghong Song
V2: Addressed issues point out by Yonghong Song
- Please ACK patch 2/3 again
- Added ACKs and reviewed-by to other patches
This patchset is focused on improvements for XDP forwarding sample
named xdp_fwd, which leverage the existing FIB routing tables as
described in LPC2018[1] talk by David Ahern.
The primary motivation is to illustrate how Toke's recent work
improves usability of XDP_REDIRECT via lookups in devmap. The other
patches are to help users understand the sample.
I have more improvements to xdp_fwd, but those might requires changes
to libbpf. Thus, sending these patches first as they are isolated.
[1] http://vger.kernel.org/lpc-networking2018.html#session-1
---
Jesper Dangaard Brouer (3):
samples/bpf: xdp_fwd rename devmap name to be xdp_tx_ports
samples/bpf: make xdp_fwd more practically usable via devmap lookup
samples/bpf: xdp_fwd explain bpf_fib_lookup return codes
samples/bpf/xdp_fwd_kern.c | 39 ++++++++++++++++++++++++++++++---------
samples/bpf/xdp_fwd_user.c | 35 +++++++++++++++++++++++------------
2 files changed, 53 insertions(+), 21 deletions(-)
--
^ permalink raw reply
* [bpf-next v3 PATCH 1/3] samples/bpf: xdp_fwd rename devmap name to be xdp_tx_ports
From: Jesper Dangaard Brouer @ 2019-08-08 16:17 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov
Cc: a.s.protopopov, dsahern, Toke Høiland-Jørgensen,
ys114321, Jesper Dangaard Brouer
In-Reply-To: <156528102557.22124.261409336813472418.stgit@firesoul>
The devmap name 'tx_port' came from a copy-paste from xdp_redirect_map
which only have a single TX port. Change name to xdp_tx_ports
to make it more descriptive.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
samples/bpf/xdp_fwd_kern.c | 5 +++--
samples/bpf/xdp_fwd_user.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/samples/bpf/xdp_fwd_kern.c b/samples/bpf/xdp_fwd_kern.c
index a7e94e7ff87d..e6ffc4ea06f4 100644
--- a/samples/bpf/xdp_fwd_kern.c
+++ b/samples/bpf/xdp_fwd_kern.c
@@ -23,7 +23,8 @@
#define IPV6_FLOWINFO_MASK cpu_to_be32(0x0FFFFFFF)
-struct bpf_map_def SEC("maps") tx_port = {
+/* For TX-traffic redirect requires net_device ifindex to be in this devmap */
+struct bpf_map_def SEC("maps") xdp_tx_ports = {
.type = BPF_MAP_TYPE_DEVMAP,
.key_size = sizeof(int),
.value_size = sizeof(int),
@@ -117,7 +118,7 @@ static __always_inline int xdp_fwd_flags(struct xdp_md *ctx, u32 flags)
memcpy(eth->h_dest, fib_params.dmac, ETH_ALEN);
memcpy(eth->h_source, fib_params.smac, ETH_ALEN);
- return bpf_redirect_map(&tx_port, fib_params.ifindex, 0);
+ return bpf_redirect_map(&xdp_tx_ports, fib_params.ifindex, 0);
}
return XDP_PASS;
diff --git a/samples/bpf/xdp_fwd_user.c b/samples/bpf/xdp_fwd_user.c
index 5b46ee12c696..ba012d9f93dd 100644
--- a/samples/bpf/xdp_fwd_user.c
+++ b/samples/bpf/xdp_fwd_user.c
@@ -113,7 +113,7 @@ int main(int argc, char **argv)
return 1;
}
map_fd = bpf_map__fd(bpf_object__find_map_by_name(obj,
- "tx_port"));
+ "xdp_tx_ports"));
if (map_fd < 0) {
printf("map not found: %s\n", strerror(map_fd));
return 1;
^ permalink raw reply related
* [bpf-next v3 PATCH 2/3] samples/bpf: make xdp_fwd more practically usable via devmap lookup
From: Jesper Dangaard Brouer @ 2019-08-08 16:17 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov
Cc: a.s.protopopov, dsahern, Toke Høiland-Jørgensen,
ys114321, Jesper Dangaard Brouer
In-Reply-To: <156528102557.22124.261409336813472418.stgit@firesoul>
This address the TODO in samples/bpf/xdp_fwd_kern.c, which points out
that the chosen egress index should be checked for existence in the
devmap. This can now be done via taking advantage of Toke's work in
commit 0cdbb4b09a06 ("devmap: Allow map lookups from eBPF").
This change makes xdp_fwd more practically usable, as this allows for
a mixed environment, where IP-forwarding fallback to network stack, if
the egress device isn't configured to use XDP.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
---
samples/bpf/xdp_fwd_kern.c | 17 +++++++++++------
samples/bpf/xdp_fwd_user.c | 33 ++++++++++++++++++++++-----------
2 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/samples/bpf/xdp_fwd_kern.c b/samples/bpf/xdp_fwd_kern.c
index e6ffc4ea06f4..a43d6953c054 100644
--- a/samples/bpf/xdp_fwd_kern.c
+++ b/samples/bpf/xdp_fwd_kern.c
@@ -104,13 +104,18 @@ static __always_inline int xdp_fwd_flags(struct xdp_md *ctx, u32 flags)
rc = bpf_fib_lookup(ctx, &fib_params, sizeof(fib_params), flags);
- /* verify egress index has xdp support
- * TO-DO bpf_map_lookup_elem(&tx_port, &key) fails with
- * cannot pass map_type 14 into func bpf_map_lookup_elem#1:
- * NOTE: without verification that egress index supports XDP
- * forwarding packets are dropped.
- */
if (rc == 0) {
+ /* Verify egress index has been configured as TX-port.
+ * (Note: User can still have inserted an egress ifindex that
+ * doesn't support XDP xmit, which will result in packet drops).
+ *
+ * Note: lookup in devmap supported since 0cdbb4b09a0.
+ * If not supported will fail with:
+ * cannot pass map_type 14 into func bpf_map_lookup_elem#1:
+ */
+ if (!bpf_map_lookup_elem(&xdp_tx_ports, &fib_params.ifindex))
+ return XDP_PASS;
+
if (h_proto == htons(ETH_P_IP))
ip_decrease_ttl(iph);
else if (h_proto == htons(ETH_P_IPV6))
diff --git a/samples/bpf/xdp_fwd_user.c b/samples/bpf/xdp_fwd_user.c
index ba012d9f93dd..97ff1dad7669 100644
--- a/samples/bpf/xdp_fwd_user.c
+++ b/samples/bpf/xdp_fwd_user.c
@@ -27,14 +27,20 @@
#include "libbpf.h"
#include <bpf/bpf.h>
-
-static int do_attach(int idx, int fd, const char *name)
+static int do_attach(int idx, int prog_fd, int map_fd, const char *name)
{
int err;
- err = bpf_set_link_xdp_fd(idx, fd, 0);
- if (err < 0)
+ err = bpf_set_link_xdp_fd(idx, prog_fd, 0);
+ if (err < 0) {
printf("ERROR: failed to attach program to %s\n", name);
+ return err;
+ }
+
+ /* Adding ifindex as a possible egress TX port */
+ err = bpf_map_update_elem(map_fd, &idx, &idx, 0);
+ if (err)
+ printf("ERROR: failed using device %s as TX-port\n", name);
return err;
}
@@ -47,6 +53,9 @@ static int do_detach(int idx, const char *name)
if (err < 0)
printf("ERROR: failed to detach program from %s\n", name);
+ /* TODO: Remember to cleanup map, when adding use of shared map
+ * bpf_map_delete_elem((map_fd, &idx);
+ */
return err;
}
@@ -67,10 +76,10 @@ int main(int argc, char **argv)
};
const char *prog_name = "xdp_fwd";
struct bpf_program *prog;
+ int prog_fd, map_fd = -1;
char filename[PATH_MAX];
struct bpf_object *obj;
int opt, i, idx, err;
- int prog_fd, map_fd;
int attach = 1;
int ret = 0;
@@ -103,8 +112,14 @@ int main(int argc, char **argv)
return 1;
}
- if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd))
+ err = bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd);
+ if (err) {
+ printf("Does kernel support devmap lookup?\n");
+ /* If not, the error message will be:
+ * "cannot pass map_type 14 into func bpf_map_lookup_elem#1"
+ */
return 1;
+ }
prog = bpf_object__find_program_by_title(obj, prog_name);
prog_fd = bpf_program__fd(prog);
@@ -119,10 +134,6 @@ int main(int argc, char **argv)
return 1;
}
}
- if (attach) {
- for (i = 1; i < 64; ++i)
- bpf_map_update_elem(map_fd, &i, &i, 0);
- }
for (i = optind; i < argc; ++i) {
idx = if_nametoindex(argv[i]);
@@ -138,7 +149,7 @@ int main(int argc, char **argv)
if (err)
ret = err;
} else {
- err = do_attach(idx, prog_fd, argv[i]);
+ err = do_attach(idx, prog_fd, map_fd, argv[i]);
if (err)
ret = err;
}
^ permalink raw reply related
* [bpf-next v3 PATCH 3/3] samples/bpf: xdp_fwd explain bpf_fib_lookup return codes
From: Jesper Dangaard Brouer @ 2019-08-08 16:17 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov
Cc: a.s.protopopov, dsahern, Toke Høiland-Jørgensen,
ys114321, Jesper Dangaard Brouer
In-Reply-To: <156528102557.22124.261409336813472418.stgit@firesoul>
Make it clear that this XDP program depend on the network
stack to do the ARP resolution. This is connected with the
BPF_FIB_LKUP_RET_NO_NEIGH return code from bpf_fib_lookup().
Another common mistake (seen via XDP-tutorial) is that users
don't realize that sysctl net.ipv{4,6}.conf.all.forwarding
setting is honored by bpf_fib_lookup.
Reported-by: Anton Protopopov <a.s.protopopov@gmail.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
samples/bpf/xdp_fwd_kern.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/samples/bpf/xdp_fwd_kern.c b/samples/bpf/xdp_fwd_kern.c
index a43d6953c054..701a30f258b1 100644
--- a/samples/bpf/xdp_fwd_kern.c
+++ b/samples/bpf/xdp_fwd_kern.c
@@ -103,8 +103,23 @@ static __always_inline int xdp_fwd_flags(struct xdp_md *ctx, u32 flags)
fib_params.ifindex = ctx->ingress_ifindex;
rc = bpf_fib_lookup(ctx, &fib_params, sizeof(fib_params), flags);
-
- if (rc == 0) {
+ /*
+ * Some rc (return codes) from bpf_fib_lookup() are important,
+ * to understand how this XDP-prog interacts with network stack.
+ *
+ * BPF_FIB_LKUP_RET_NO_NEIGH:
+ * Even if route lookup was a success, then the MAC-addresses are also
+ * needed. This is obtained from arp/neighbour table, but if table is
+ * (still) empty then BPF_FIB_LKUP_RET_NO_NEIGH is returned. To avoid
+ * doing ARP lookup directly from XDP, then send packet to normal
+ * network stack via XDP_PASS and expect it will do ARP resolution.
+ *
+ * BPF_FIB_LKUP_RET_FWD_DISABLED:
+ * The bpf_fib_lookup respect sysctl net.ipv{4,6}.conf.all.forwarding
+ * setting, and will return BPF_FIB_LKUP_RET_FWD_DISABLED if not
+ * enabled this on ingress device.
+ */
+ if (rc == BPF_FIB_LKUP_RET_SUCCESS) {
/* Verify egress index has been configured as TX-port.
* (Note: User can still have inserted an egress ifindex that
* doesn't support XDP xmit, which will result in packet drops).
^ permalink raw reply related
* RE: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Weiny, Ira @ 2019-08-08 16:25 UTC (permalink / raw)
To: John Hubbard, Michal Hocko
Cc: Jan Kara, Matthew Wilcox, Andrew Morton, Christoph Hellwig,
Williams, Dan J, Dave Chinner, Dave Hansen, Jason Gunthorpe,
Jérôme Glisse, LKML, amd-gfx@lists.freedesktop.org,
ceph-devel@vger.kernel.org, devel@driverdev.osuosl.org,
devel@lists.orangefs.org, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-block@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-media@vger.kernel.org,
linux-mm@kvack.org, linux-nfs@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
linux-xfs@vger.kernel.org, netdev@vger.kernel.org,
rds-devel@oss.oracle.com, sparclinux@vger.kernel.org,
x86@kernel.org, xen-devel@lists.xenproject.org
In-Reply-To: <e648a7f3-6a1b-c9ea-1121-7ab69b6b173d@nvidia.com>
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> >>>> On 8/2/19 7:52 AM, Jan Kara wrote:
> >>>>> On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> >>>>>> On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> >>>>>>> On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> >>>>>>>> On Thu 01-08-19 19:19:31, john.hubbard@gmail.com wrote:
> [...]
> > Before I go on, I would like to say that the "imbalance" of
> > get_user_pages() and put_page() bothers me from a purist standpoint...
> > However, since this discussion cropped up I went ahead and ported my
> > work to Linus' current master
> > (5.3-rc3+) and in doing so I only had to steal a bit of Johns code...
> > Sorry John... :-(
> >
> > I don't have the commit messages all cleaned up and I know there may
> > be some discussion on these new interfaces but I wanted to throw this
> > series out there because I think it may be what Jan and Michal are
> > driving at (or at least in that direction.
> >
> > Right now only RDMA and DAX FS's are supported. Other users of GUP
> > will still fail on a DAX file and regular files will still be at
> > risk.[2]
> >
> > I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
> >
> > https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
> >
> > I think the most relevant patch to this conversation is:
> >
> > https://github.com/weiny2/linux-
> kernel/commit/5d377653ba5cf11c3b716f90
> > 4b057bee6641aaf6
> >
>
> ohhh...can you please avoid using the old __put_user_pages_dirty()
> function?
Agreed... I did not like that. Part of the reason I did not post this is I'm still trying to figure out what has landed and what I can and can't depend on.
For example, Christoph H. was proposing changes to some of the GUP calls which may conflict. But I'm not sure his changes are moving forward. So rather than waiting for the dust to settle I decided to see how hard it would be to get this rebased against mainline and working. Turns out it was not too hard.
I think that is because, as time has moved on it seems that, for some users such as RDMA, a simple put_user_page() is not going to be sufficient. We need something else to allow GUP to keep track of the file pins as we discussed. So I'm starting to think some of this could go in at the same time.
> I thought I'd caught things early enough to get away with the
> rename and deletion of that. You could either:
>
> a) open code an implementation of vaddr_put_pages_dirty_lock() that
> doesn't call any of the *put_user_pages_dirty*() variants, or
>
> b) include my first patch ("") are part of your series, or
>
> c) base this on Andrews's tree, which already has merged in my first patch.
>
Yep I can do this. I did not realize that Andrew had accepted any of this work. I'll check out his tree. But I don't think he is going to accept this series through his tree. So what is the ETA on that landing in Linus' tree?
To that point I'm still not sure who would take all this as I am now touching mm, procfs, rdma, ext4, and xfs.
I just thought I would chime in with my progress because I'm to a point where things are working and so I can submit the code but I'm not sure what I can/should depend on landing... Also, now that 0day has run overnight it has found issues with this rebase so I need to clean those up... Perhaps I will base on Andrew's tree prior to doing that...
Thanks,
Ira
>
> thanks,
> --
> John Hubbard
> NVIDIA
^ permalink raw reply
* Re: [net] ixgbe: fix possible deadlock in ixgbe_service_task()
From: Jeff Kirsher @ 2019-08-08 16:36 UTC (permalink / raw)
To: Taehee Yoo, David Miller; +Cc: Netdev, nhorman, sassmann, andrewx.bowers
In-Reply-To: <CAMArcTXWBHUpy+p18UJ6RZm2W=vhnLRezste=kHSSv=dyd0kBA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
On Wed, 2019-08-07 at 15:08 +0900, Taehee Yoo wrote:
> On Wed, 7 Aug 2019 at 08:36, David Miller <davem@davemloft.net>
> wrote:
>
> Hi David
> Thank you for the review!
>
> > From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Date: Mon, 5 Aug 2019 13:04:03 -0700
> >
> > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > index cbaf712d6529..3386e752e458 100644
> > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > @@ -7898,9 +7898,7 @@ static void ixgbe_service_task(struct
> > > work_struct *work)
> > > }
> > > if (ixgbe_check_fw_error(adapter)) {
> > > if (!test_bit(__IXGBE_DOWN, &adapter->state)) {
> > > - rtnl_lock();
> > > unregister_netdev(adapter->netdev);
> > > - rtnl_unlock();
> > > }
> >
> > Please remove the (now unnecessary) curly braces for this basic
> > block.
> >
>
> I will send a v2 patch.
> Thank you!
I have already created a v2 on your behalf Taechee and will submit to
Dave here shortly.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [net v2] ixgbe: fix possible deadlock in ixgbe_service_task()
From: Jeff Kirsher @ 2019-08-08 16:37 UTC (permalink / raw)
To: davem; +Cc: Taehee Yoo, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
From: Taehee Yoo <ap420073@gmail.com>
ixgbe_service_task() calls unregister_netdev() under rtnl_lock().
But unregister_netdev() internally calls rtnl_lock().
So deadlock would occur.
Fixes: 59dd45d550c5 ("ixgbe: firmware recovery mode")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
v2: removed unnecessary curly brackets
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712d6529..7882148abb43 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7897,11 +7897,8 @@ static void ixgbe_service_task(struct work_struct *work)
return;
}
if (ixgbe_check_fw_error(adapter)) {
- if (!test_bit(__IXGBE_DOWN, &adapter->state)) {
- rtnl_lock();
+ if (!test_bit(__IXGBE_DOWN, &adapter->state))
unregister_netdev(adapter->netdev);
- rtnl_unlock();
- }
ixgbe_service_event_complete(adapter);
return;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] isdn: hysdn: Fix error spaces around '*'
From: Greg KH @ 2019-08-08 16:39 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, Jose Carlos Cazarin Filho, isdn, devel, netdev,
linux-kernel
In-Reply-To: <2ecfbf8dda354fe47912446bf5c3fe30ca905aa0.camel@perches.com>
On Fri, Aug 02, 2019 at 03:05:05PM -0700, Joe Perches wrote:
> On Fri, 2019-08-02 at 14:55 -0700, Stephen Hemminger wrote:
> > On Fri, 2 Aug 2019 19:56:02 +0000
> > Jose Carlos Cazarin Filho <joseespiriki@gmail.com> wrote:
> >
> > > Fix checkpath error:
> > > CHECK: spaces preferred around that '*' (ctx:WxV)
> > > +extern hysdn_card *card_root; /* pointer to first card */
> > >
> > > Signed-off-by: Jose Carlos Cazarin Filho <joseespiriki@gmail.com>
> >
> > Read the TODO, these drivers are scheduled for removal, so changes
> > are not helpful at this time.
>
> Maybe better to mark the MAINTAINERS entry obsolete so
> checkpatch bleats a message about unnecessary changes.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 30bf852e6d6b..b5df91032574 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8628,7 +8628,7 @@ M: Karsten Keil <isdn@linux-pingi.de>
> L: isdn4linux@listserv.isdn4linux.de (subscribers-only)
> L: netdev@vger.kernel.org
> W: http://www.isdn4linux.de
> -S: Odd Fixes
> +S: Obsolete
> F: Documentation/isdn/
> F: drivers/isdn/capi/
> F: drivers/staging/isdn/
>
Good idea, will take this patch now, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH] isdn: hysdn: Fix error spaces around '*'
From: Greg KH @ 2019-08-08 16:40 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, Jose Carlos Cazarin Filho, isdn, devel, netdev,
linux-kernel
In-Reply-To: <20190808163905.GA9224@kroah.com>
On Thu, Aug 08, 2019 at 06:39:05PM +0200, Greg KH wrote:
> On Fri, Aug 02, 2019 at 03:05:05PM -0700, Joe Perches wrote:
> > On Fri, 2019-08-02 at 14:55 -0700, Stephen Hemminger wrote:
> > > On Fri, 2 Aug 2019 19:56:02 +0000
> > > Jose Carlos Cazarin Filho <joseespiriki@gmail.com> wrote:
> > >
> > > > Fix checkpath error:
> > > > CHECK: spaces preferred around that '*' (ctx:WxV)
> > > > +extern hysdn_card *card_root; /* pointer to first card */
> > > >
> > > > Signed-off-by: Jose Carlos Cazarin Filho <joseespiriki@gmail.com>
> > >
> > > Read the TODO, these drivers are scheduled for removal, so changes
> > > are not helpful at this time.
> >
> > Maybe better to mark the MAINTAINERS entry obsolete so
> > checkpatch bleats a message about unnecessary changes.
> > ---
> > MAINTAINERS | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 30bf852e6d6b..b5df91032574 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -8628,7 +8628,7 @@ M: Karsten Keil <isdn@linux-pingi.de>
> > L: isdn4linux@listserv.isdn4linux.de (subscribers-only)
> > L: netdev@vger.kernel.org
> > W: http://www.isdn4linux.de
> > -S: Odd Fixes
> > +S: Obsolete
> > F: Documentation/isdn/
> > F: drivers/isdn/capi/
> > F: drivers/staging/isdn/
> >
>
> Good idea, will take this patch now, thanks.
Can you resend this with a s-o-b so I can apply it?
thanks,
greg k-h
^ permalink raw reply
* general protection fault in tls_tx_records
From: syzbot @ 2019-08-08 16:44 UTC (permalink / raw)
To: ast, aviadye, borisp, bpf, daniel, davejwatson, davem,
jakub.kicinski, john.fastabend, kafai, linux-kernel, netdev,
songliubraving, syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: ce96e791 Add linux-next specific files for 20190731
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13ce4fd0600000
kernel config: https://syzkaller.appspot.com/x/.config?x=fca5b9d53db6585c
dashboard link: https://syzkaller.appspot.com/bug?extid=97d0cf528b9c8e9be7f4
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+97d0cf528b9c8e9be7f4@syzkaller.appspotmail.com
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc2-next-20190731 #56
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events tx_work_handler
RIP: 0010:tls_tx_records+0x5e/0x740 net/tls/tls_sw.c:365
Code: 80 3c 02 00 0f 85 31 06 00 00 49 8b 87 b0 06 00 00 48 8d 78 28 48 89
45 c0 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 1b 06 00 00 48 8b 45 c0 48 8d 78 60 48 8b 58 28
RSP: 0018:ffff8880a98d7cb0 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 1ffffffff134c016
RDX: 0000000000000005 RSI: ffffffff862e74fc RDI: 0000000000000028
RBP: ffff8880a98d7d00 R08: ffff8880a98c8300 R09: 0000000000000000
R10: fffffbfff134b9d8 R11: ffff8880a98c8300 R12: ffff88808eb47cc0
R13: ffff8880a9ac4c40 R14: ffff88808eb47de8 R15: ffff8880a9ac4c40
FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001b30e80 CR3: 000000009c1a0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
tx_work_handler+0x134/0x180 net/tls/tls_sw.c:2176
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace c75bda97ceb541bf ]---
RIP: 0010:tls_tx_records+0x5e/0x740 net/tls/tls_sw.c:365
Code: 80 3c 02 00 0f 85 31 06 00 00 49 8b 87 b0 06 00 00 48 8d 78 28 48 89
45 c0 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 1b 06 00 00 48 8b 45 c0 48 8d 78 60 48 8b 58 28
RSP: 0018:ffff8880a98d7cb0 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 1ffffffff134c016
RDX: 0000000000000005 RSI: ffffffff862e74fc RDI: 0000000000000028
RBP: ffff8880a98d7d00 R08: ffff8880a98c8300 R09: 0000000000000000
R10: fffffbfff134b9d8 R11: ffff8880a98c8300 R12: ffff88808eb47cc0
R13: ffff8880a9ac4c40 R14: ffff88808eb47de8 R15: ffff8880a9ac4c40
FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd4f4eadac CR3: 00000000987e6000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* KASAN: use-after-free Read in tls_wait_data
From: syzbot @ 2019-08-08 16:44 UTC (permalink / raw)
To: ast, aviadye, borisp, bpf, daniel, davejwatson, davem,
jakub.kicinski, john.fastabend, kafai, linux-kernel, netdev,
songliubraving, syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: 7b4980e0 Add linux-next specific files for 20190802
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14a749b4600000
kernel config: https://syzkaller.appspot.com/x/.config?x=7e1348afd44b5e02
dashboard link: https://syzkaller.appspot.com/bug?extid=30c791a76814a3c6c9f9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+30c791a76814a3c6c9f9@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in tls_wait_data+0x884/0x980
net/tls/tls_sw.c:1261
Read of size 8 at addr ffff88808ea9f890 by task syz-executor.2/31898
CPU: 1 PID: 31898 Comm: syz-executor.2 Not tainted 5.3.0-rc2-next-20190802
#58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x17 mm/kasan/common.c:610
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
tls_wait_data+0x884/0x980 net/tls/tls_sw.c:1261
tls_sw_recvmsg+0x57d/0x17c0 net/tls/tls_sw.c:1730
inet_recvmsg+0x136/0x620 net/ipv4/af_inet.c:838
sock_recvmsg_nosec+0x89/0xb0 net/socket.c:871
___sys_recvmsg+0x271/0x5a0 net/socket.c:2480
do_recvmmsg+0x27e/0x7a0 net/socket.c:2601
__sys_recvmmsg+0x259/0x270 net/socket.c:2680
__do_sys_recvmmsg net/socket.c:2703 [inline]
__se_sys_recvmmsg net/socket.c:2696 [inline]
__x64_sys_recvmmsg+0xe6/0x140 net/socket.c:2696
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f6093e3ec78 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000459829
RDX: 0000000000000004 RSI: 00000000200031c0 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6093e3f6d4
R13: 00000000004c6d67 R14: 00000000004dc0a8 R15: 00000000ffffffff
Allocated by task 31898:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:486 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:459
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:500
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:686 [inline]
tls_set_sw_offload+0x110a/0x1567 net/tls/tls_sw.c:2243
do_tls_setsockopt_conf net/tls/tls_main.c:594 [inline]
do_tls_setsockopt net/tls/tls_main.c:630 [inline]
tls_setsockopt+0x68d/0x8d0 net/tls/tls_main.c:649
sock_common_setsockopt+0x94/0xd0 net/core/sock.c:3130
__sys_setsockopt+0x261/0x4c0 net/socket.c:2084
__do_sys_setsockopt net/socket.c:2100 [inline]
__se_sys_setsockopt net/socket.c:2097 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:2097
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 17:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:448
kasan_slab_free+0xe/0x10 mm/kasan/common.c:456
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
tls_sw_free_ctx_rx+0x31/0x40 net/tls/tls_sw.c:2145
tls_ctx_free_deferred+0xc4/0x130 net/tls/tls_main.c:279
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff88808ea9f680
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 528 bytes inside of
1024-byte region [ffff88808ea9f680, ffff88808ea9fa80)
The buggy address belongs to the page:
page:ffffea00023aa780 refcount:1 mapcount:0 mapping:ffff8880aa400c40
index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea000295f888 ffffea00021f7908 ffff8880aa400c40
raw: 0000000000000000 ffff88808ea9e000 0000000100000007 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88808ea9f780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808ea9f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88808ea9f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88808ea9f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808ea9f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* INFO: rcu detected stall in tcp_write_timer
From: syzbot @ 2019-08-08 16:45 UTC (permalink / raw)
To: ast, bpf, daniel, davem, edumazet, kafai, kuznet, linux-kernel,
netdev, songliubraving, syzkaller-bugs, yhs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: ce96e791 Add linux-next specific files for 20190731
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12b2efd0600000
kernel config: https://syzkaller.appspot.com/x/.config?x=fca5b9d53db6585c
dashboard link: https://syzkaller.appspot.com/bug?extid=1f80b70f1e8f1df46319
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1f80b70f1e8f1df46319@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
(detected by 1, t=10502 jiffies, g=28777, q=38)
rcu: All QSes seen, last rcu_preempt kthread activity 10503
(4294973637-4294963134), jiffies_till_next_fqs=1, root ->qsmask 0x0
syz-executor.5 R running task 27376 17588 10322 0x00004008
Call Trace:
<IRQ>
sched_show_task kernel/sched/core.c:5814 [inline]
sched_show_task.cold+0x2ed/0x34e kernel/sched/core.c:5789
print_other_cpu_stall kernel/rcu/tree_stall.h:410 [inline]
check_cpu_stall kernel/rcu/tree_stall.h:536 [inline]
rcu_pending kernel/rcu/tree.c:2736 [inline]
rcu_sched_clock_irq.cold+0xac8/0xc13 kernel/rcu/tree.c:2183
update_process_times+0x32/0x80 kernel/time/timer.c:1639
tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:167
tick_sched_timer+0x53/0x140 kernel/time/tick-sched.c:1296
__run_hrtimer kernel/time/hrtimer.c:1389 [inline]
__hrtimer_run_queues+0x364/0xe40 kernel/time/hrtimer.c:1451
hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1068 [inline]
smp_apic_timer_interrupt+0x160/0x610 arch/x86/kernel/apic/apic.c:1093
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:828
RIP: 0010:__kasan_check_read+0x0/0x20 mm/kasan/common.c:91
Code: e8 e9 c0 ae ff 0f 0b 4c 8b 4d d0 e9 27 ee ff ff 48 8b 73 58 89 c2 48
c7 c7 e0 c2 89 88 f7 da e8 ca c0 ae ff e9 da ee ff ff 90 <55> 89 f6 31 d2
48 89 e5 48 8b 4d 08 e8 cf 26 00 00 5d c3 0f 1f 00
RSP: 0018:ffff8880ae909b40 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000000 RBX: ffff8880601cce08 RCX: ffffffff8158f467
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff8880601cce08
RBP: ffff8880ae909c08 R08: 1ffff1100c0399c1 R09: ffffed100c0399c2
R10: ffffed100c0399c1 R11: ffff8880601cce0b R12: 0000000000000001
R13: 0000000000000003 R14: ffffed100c0399c1 R15: 0000000000000001
pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:642 [inline]
queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:50 [inline]
queued_spin_lock include/asm-generic/qspinlock.h:81 [inline]
do_raw_spin_lock+0x20e/0x2e0 kernel/locking/spinlock_debug.c:113
__raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
_raw_spin_lock+0x37/0x40 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:338 [inline]
tcp_write_timer+0x2b/0x1e0 net/ipv4/tcp_timer.c:610
call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1322
expire_timers kernel/time/timer.c:1366 [inline]
__run_timers kernel/time/timer.c:1685 [inline]
__run_timers kernel/time/timer.c:1653 [inline]
run_timer_softirq+0x697/0x17a0 kernel/time/timer.c:1698
__do_softirq+0x262/0x98c kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x19b/0x1e0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1a3/0x610 arch/x86/kernel/apic/apic.c:1095
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:828
</IRQ>
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:756
[inline]
RIP: 0010:slab_alloc mm/slab.c:3312 [inline]
RIP: 0010:__do_kmalloc mm/slab.c:3653 [inline]
RIP: 0010:__kmalloc+0x2b8/0x770 mm/slab.c:3664
Code: 7e 0f 85 d6 fe ff ff e8 26 c5 53 ff e9 cc fe ff ff e8 1c ff ca ff 48
83 3d e4 52 26 07 00 0f 84 4f 03 00 00 48 8b 7d c0 57 9d <0f> 1f 44 00 00
e9 5e fe ff ff 31 d2 be 35 02 00 00 48 c7 c7 ce c0
RSP: 0018:ffff888069e978c0 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000007 RBX: 0000000000000dc0 RCX: 1ffffffff134c016
RDX: 0000000000000000 RSI: ffffffff8177a12e RDI: 0000000000000286
RBP: ffff888069e97938 R08: ffff888064bee240 R09: ffffed10154802c1
R10: ffffed10154802c0 R11: ffff8880aa401603 R12: 0000000000000100
R13: 0000000000000dc0 R14: ffff8880aa4008c0 R15: ffff88805f8e7dc0
kmalloc_array include/linux/slab.h:614 [inline]
kcalloc include/linux/slab.h:625 [inline]
iter_file_splice_write+0x16e/0xbe0 fs/splice.c:690
do_splice_from fs/splice.c:848 [inline]
direct_splice_actor+0x123/0x190 fs/splice.c:1020
splice_direct_to_actor+0x366/0x970 fs/splice.c:975
do_splice_direct+0x1da/0x2a0 fs/splice.c:1063
do_sendfile+0x597/0xd00 fs/read_write.c:1464
__do_sys_sendfile64 fs/read_write.c:1519 [inline]
__se_sys_sendfile64 fs/read_write.c:1511 [inline]
__x64_sys_sendfile64+0x15a/0x220 fs/read_write.c:1511
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f9691478c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000000459829
RDX: 0000000020001000 RSI: 0000000000000003 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000ffff R11: 0000000000000246 R12: 00007f96914796d4
R13: 00000000004c6ff7 R14: 00000000004dc558 R15: 00000000ffffffff
rcu: rcu_preempt kthread starved for 10569 jiffies! g28777 f0x2
RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: RCU grace-period kthread stack dump:
rcu_preempt R running task 29688 10 2 0x80004000
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x755/0x15b0 kernel/sched/core.c:3921
schedule+0xa8/0x270 kernel/sched/core.c:3985
schedule_timeout+0x486/0xc50 kernel/time/timer.c:1807
rcu_gp_fqs_loop kernel/rcu/tree.c:1611 [inline]
rcu_gp_kthread+0x9b2/0x18c0 kernel/rcu/tree.c:1768
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* WARNING in xfrm_policy_inexact_list_reinsert
From: syzbot @ 2019-08-08 16:45 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 4010b622 Merge branch 'dax-fix-5.3-rc3' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13e2829fa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=e397351d2615e10
dashboard link: https://syzkaller.appspot.com/bug?extid=8cc27ace5f6972910b31
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8cc27ace5f6972910b31@syzkaller.appspotmail.com
WARNING: CPU: 1 PID: 6756 at net/xfrm/xfrm_policy.c:877
xfrm_policy_inexact_list_reinsert+0x625/0x6e0 net/xfrm/xfrm_policy.c:877
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 6756 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #57
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
panic+0x29b/0x7d9 kernel/panic.c:219
__warn+0x22f/0x230 kernel/panic.c:576
report_bug+0x190/0x290 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
do_error_trap+0xd7/0x440 arch/x86/kernel/traps.c:272
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:291
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1026
RIP: 0010:xfrm_policy_inexact_list_reinsert+0x625/0x6e0
net/xfrm/xfrm_policy.c:877
Code: ef e8 6f 32 0f fb 4d 8b 6d 00 4c 39 6d 90 0f 85 81 fa ff ff e9 b0 00
00 00 e8 c7 87 d4 fa 0f 0b e9 fa fa ff ff e8 bb 87 d4 fa <0f> 0b e9 75 ff
ff ff e8 af 87 d4 fa 0f 0b eb a9 44 89 f1 80 e1 07
RSP: 0018:ffff888052caf080 EFLAGS: 00010283
RAX: ffffffff86a35975 RBX: 00000000ffffff20 RCX: 0000000000040000
RDX: ffffc9000816a000 RSI: 00000000000005cd RDI: 00000000000005ce
RBP: ffff888052caf110 R08: ffffffff86a358ac R09: ffffffff86a3514c
R10: ffff88805914c380 R11: 0000000000000002 R12: 0000000000000000
R13: ffff888092fa6aa0 R14: 000000000000007e R15: 000000000000000a
xfrm_policy_inexact_node_reinsert net/xfrm/xfrm_policy.c:922 [inline]
xfrm_policy_inexact_node_merge net/xfrm/xfrm_policy.c:958 [inline]
xfrm_policy_inexact_insert_node+0x537/0xb50 net/xfrm/xfrm_policy.c:1023
xfrm_policy_inexact_alloc_chain+0x62b/0xbd0 net/xfrm/xfrm_policy.c:1139
xfrm_policy_inexact_insert+0xe8/0x1540 net/xfrm/xfrm_policy.c:1182
xfrm_policy_insert+0xdf/0xce0 net/xfrm/xfrm_policy.c:1574
xfrm_add_policy+0x4cf/0x9b0 net/xfrm/xfrm_user.c:1670
xfrm_user_rcv_msg+0x46b/0x720 net/xfrm/xfrm_user.c:2676
netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2477
xfrm_netlink_rcv+0x74/0x90 net/xfrm/xfrm_user.c:2684
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x809/0x9a0 net/netlink/af_netlink.c:1328
netlink_sendmsg+0xa70/0xd30 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg net/socket.c:657 [inline]
___sys_sendmsg+0x66b/0x9a0 net/socket.c:2311
__sys_sendmsg net/socket.c:2356 [inline]
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x1cf/0x290 net/socket.c:2363
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f16cc51ec78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f16cc51f6d4
R13: 00000000004c776b R14: 00000000004dceb8 R15: 00000000ffffffff
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* KASAN: use-after-free Read in tomoyo_socket_sendmsg_permission
From: syzbot @ 2019-08-08 16:45 UTC (permalink / raw)
To: jmorris, linux-kernel, linux-security-module, netdev, serge,
syzkaller-bugs, takedakn
Hello,
syzbot found the following crash on:
HEAD commit: 107e47cc vrf: make sure skb->data contains ip header to ma..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=139506d8600000
kernel config: https://syzkaller.appspot.com/x/.config?x=4dba67bf8b8c9ad7
dashboard link: https://syzkaller.appspot.com/bug?extid=b91501546ab4037f685f
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b91501546ab4037f685f@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in tomoyo_sock_family
security/tomoyo/network.c:632 [inline]
BUG: KASAN: use-after-free in tomoyo_socket_sendmsg_permission+0x37e/0x3cb
security/tomoyo/network.c:762
Read of size 2 at addr ffff8880a066f410 by task syz-executor.3/2063
CPU: 1 PID: 2063 Comm: syz-executor.3 Not tainted 5.2.0+ #97
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x17 mm/kasan/common.c:612
__asan_report_load2_noabort+0x14/0x20 mm/kasan/generic_report.c:130
tomoyo_sock_family security/tomoyo/network.c:632 [inline]
tomoyo_socket_sendmsg_permission+0x37e/0x3cb security/tomoyo/network.c:762
tomoyo_socket_sendmsg+0x26/0x30 security/tomoyo/tomoyo.c:486
security_socket_sendmsg+0x77/0xc0 security/security.c:1973
sock_sendmsg+0x45/0x130 net/socket.c:654
__sys_sendto+0x262/0x380 net/socket.c:1952
__do_sys_sendto net/socket.c:1964 [inline]
__se_sys_sendto net/socket.c:1960 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1960
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f8413a51c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459829
RDX: 00000000000000ed RSI: 0000000020000280 RDI: 0000000000000005
RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8413a526d4
R13: 00000000004c77f1 R14: 00000000004dcfc0 R15: 00000000ffffffff
Allocated by task 0:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
__do_kmalloc mm/slab.c:3655 [inline]
__kmalloc+0x163/0x770 mm/slab.c:3664
kmalloc include/linux/slab.h:557 [inline]
sk_prot_alloc+0x23a/0x310 net/core/sock.c:1603
sk_alloc+0x39/0xf70 net/core/sock.c:1657
nr_make_new net/netrom/af_netrom.c:476 [inline]
nr_rx_frame+0x733/0x1e73 net/netrom/af_netrom.c:959
nr_loopback_timer+0x7b/0x170 net/netrom/nr_loopback.c:59
call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1322
expire_timers kernel/time/timer.c:1366 [inline]
__run_timers kernel/time/timer.c:1685 [inline]
__run_timers kernel/time/timer.c:1653 [inline]
run_timer_softirq+0x697/0x17a0 kernel/time/timer.c:1698
__do_softirq+0x262/0x98c kernel/softirq.c:292
Freed by task 2063:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
sk_prot_free net/core/sock.c:1640 [inline]
__sk_destruct+0x4f7/0x6e0 net/core/sock.c:1726
sk_destruct+0x86/0xa0 net/core/sock.c:1734
__sk_free+0xfb/0x360 net/core/sock.c:1745
sk_free+0x42/0x50 net/core/sock.c:1756
sock_put include/net/sock.h:1725 [inline]
sock_efree+0x61/0x80 net/core/sock.c:2042
skb_release_head_state+0xeb/0x250 net/core/skbuff.c:652
skb_release_all+0x16/0x60 net/core/skbuff.c:663
__kfree_skb net/core/skbuff.c:679 [inline]
kfree_skb net/core/skbuff.c:697 [inline]
kfree_skb+0x101/0x3c0 net/core/skbuff.c:691
nr_accept+0x56e/0x700 net/netrom/af_netrom.c:819
__sys_accept4+0x34e/0x6a0 net/socket.c:1754
__do_sys_accept net/socket.c:1795 [inline]
__se_sys_accept net/socket.c:1792 [inline]
__x64_sys_accept+0x75/0xb0 net/socket.c:1792
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8880a066f400
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 16 bytes inside of
2048-byte region [ffff8880a066f400, ffff8880a066fc00)
The buggy address belongs to the page:
page:ffffea0002819b80 refcount:1 mapcount:0 mapping:ffff8880aa400e00
index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0001849388 ffffea000235a788 ffff8880aa400e00
raw: 0000000000000000 ffff8880a066e300 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a066f300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880a066f380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8880a066f400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880a066f480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880a066f500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 1 PID: 2063 at lib/refcount.c:105 refcount_add_checked
lib/refcount.c:105 [inline]
WARNING: CPU: 1 PID: 2063 at lib/refcount.c:105
refcount_add_checked+0x6b/0x70 lib/refcount.c:103
Modules linked in:
CPU: 1 PID: 2063 Comm: syz-executor.3 Tainted: G B 5.2.0+ #97
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:refcount_add_checked lib/refcount.c:105 [inline]
RIP: 0010:refcount_add_checked+0x6b/0x70 lib/refcount.c:103
Code: 1d e7 77 64 06 31 ff 89 de e8 71 dc 35 fe 84 db 75 db e8 28 db 35 fe
48 c7 c7 20 08 c6 87 c6 05 c7 77 64 06 01 e8 1d 43 07 fe <0f> 0b eb bf 90
48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41 54 49
RSP: 0018:ffff88805d55f9f8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815c3a26 RDI: ffffed100baabf31
RBP: ffff88805d55fa10 R08: ffff888098124480 R09: fffffbfff1349ef0
R10: fffffbfff1349eef R11: ffffffff89a4f77f R12: 0000000000000500
R13: ffff8880a066f644 R14: ffff88808f271e60 R15: 00000000000000ed
FS: 00007f8413a52700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000075c000 CR3: 0000000097173000 CR4: 00000000001406e0
Call Trace:
skb_set_owner_w+0x216/0x320 net/core/sock.c:1991
sock_alloc_send_pskb+0x7c9/0x920 net/core/sock.c:2226
sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2240
nr_sendmsg+0x557/0xb00 net/netrom/af_netrom.c:1094
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
__sys_sendto+0x262/0x380 net/socket.c:1952
__do_sys_sendto net/socket.c:1964 [inline]
__se_sys_sendto net/socket.c:1960 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1960
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f8413a51c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459829
RDX: 00000000000000ed RSI: 0000000020000280 RDI: 0000000000000005
RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8413a526d4
R13: 00000000004c77f1 R14: 00000000004dcfc0 R15: 00000000ffffffff
irq event stamp: 344
hardirqs last enabled at (343): [<ffffffff8100a206>]
do_syscall_64+0x26/0x6a0 arch/x86/entry/common.c:283
hardirqs last disabled at (344): [<ffffffff87391ddf>]
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
hardirqs last disabled at (344): [<ffffffff87391ddf>]
_raw_spin_lock_irqsave+0x6f/0xcd kernel/locking/spinlock.c:159
softirqs last enabled at (314): [<ffffffff858fb1b6>] spin_unlock_bh
include/linux/spinlock.h:383 [inline]
softirqs last enabled at (314): [<ffffffff858fb1b6>]
release_sock+0x156/0x1c0 net/core/sock.c:2945
softirqs last disabled at (312): [<ffffffff858fb080>] spin_lock_bh
include/linux/spinlock.h:343 [inline]
softirqs last disabled at (312): [<ffffffff858fb080>]
release_sock+0x20/0x1c0 net/core/sock.c:2932
---[ end trace 2fe47c842e5d598a ]---
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH] isdn: hysdn: Fix error spaces around '*'
From: Joe Perches @ 2019-08-08 16:48 UTC (permalink / raw)
To: Greg KH, Karsten Keil
Cc: Stephen Hemminger, Jose Carlos Cazarin Filho, isdn, devel, netdev,
linux-kernel
In-Reply-To: <20190808164020.GA9453@kroah.com>
On Thu, 2019-08-08 at 18:40 +0200, Greg KH wrote:
> On Thu, Aug 08, 2019 at 06:39:05PM +0200, Greg KH wrote:
> > On Fri, Aug 02, 2019 at 03:05:05PM -0700, Joe Perches wrote:
> > > On Fri, 2019-08-02 at 14:55 -0700, Stephen Hemminger wrote:
> > > > On Fri, 2 Aug 2019 19:56:02 +0000
> > > > Jose Carlos Cazarin Filho <joseespiriki@gmail.com> wrote:
> > > >
> > > > > Fix checkpath error:
> > > > > CHECK: spaces preferred around that '*' (ctx:WxV)
> > > > > +extern hysdn_card *card_root; /* pointer to first card */
> > > > >
> > > > > Signed-off-by: Jose Carlos Cazarin Filho <joseespiriki@gmail.com>
> > > >
> > > > Read the TODO, these drivers are scheduled for removal, so changes
> > > > are not helpful at this time.
> > >
> > > Maybe better to mark the MAINTAINERS entry obsolete so
> > > checkpatch bleats a message about unnecessary changes.
> > > ---
> > > MAINTAINERS | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 30bf852e6d6b..b5df91032574 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -8628,7 +8628,7 @@ M: Karsten Keil <isdn@linux-pingi.de>
> > > L: isdn4linux@listserv.isdn4linux.de (subscribers-only)
> > > L: netdev@vger.kernel.org
> > > W: http://www.isdn4linux.de
> > > -S: Odd Fixes
> > > +S: Obsolete
> > > F: Documentation/isdn/
> > > F: drivers/isdn/capi/
> > > F: drivers/staging/isdn/
> > >
> >
> > Good idea, will take this patch now, thanks.
>
> Can you resend this with a s-o-b so I can apply it?
>
> thanks,
Hey Greg. It was just an idea and an example.
I'm sure you can figure out if you want it.
No need for my SOB really.
btw: Karsten hasn't acked a patch or been active
in 3+ years. Maybe he should go into CREDITS.
^ permalink raw reply
* Re: [v3,3/4] tools: bpftool: add bash-completion for net attach/detach
From: Quentin Monnet @ 2019-08-08 16:48 UTC (permalink / raw)
To: Daniel T. Lee, Daniel Borkmann, Alexei Starovoitov; +Cc: netdev
In-Reply-To: <20190807022509.4214-4-danieltimlee@gmail.com>
2019-08-07 11:25 UTC+0900 ~ Daniel T. Lee <danieltimlee@gmail.com>
> This commit adds bash-completion for new "net attach/detach"
> subcommand for attaching XDP program on interface.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
> ---
> tools/bpf/bpftool/bash-completion/bpftool | 64 +++++++++++++++++++----
> 1 file changed, 55 insertions(+), 9 deletions(-)
>
> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index c8f42e1fcbc9..1d81cb09d478 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool
> @@ -201,6 +201,10 @@ _bpftool()
> _bpftool_get_prog_tags
> return 0
> ;;
> + dev)
> + _sysfs_get_netdevs
> + return 0
> + ;;
Makes sense to have this for "dev", thanks! But it seems you missed one
place where it was used, for "bpftool feature probe" (We have "[[ $prev
== "dev" ]] && _sysfs_get_netdevs && return 0"). Could you also remove
that one please?
Other than this looks good, thanks:
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
^ permalink raw reply
* Re: [v3,4/4] tools: bpftool: add documentation for net attach/detach
From: Quentin Monnet @ 2019-08-08 16:48 UTC (permalink / raw)
To: Daniel T. Lee, Daniel Borkmann, Alexei Starovoitov; +Cc: netdev
In-Reply-To: <20190807022509.4214-5-danieltimlee@gmail.com>
2019-08-07 11:25 UTC+0900 ~ Daniel T. Lee <danieltimlee@gmail.com>
> Since, new sub-command 'net attach/detach' has been added for
> attaching XDP program on interface,
> this commit documents usage and sample output of `net attach/detach`.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
> ---
> .../bpf/bpftool/Documentation/bpftool-net.rst | 51 +++++++++++++++++--
> 1 file changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-net.rst b/tools/bpf/bpftool/Documentation/bpftool-net.rst
> index d8e5237a2085..4ad1a380e186 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-net.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-net.rst
> @@ -15,17 +15,22 @@ SYNOPSIS
> *OPTIONS* := { [{ **-j** | **--json** }] [{ **-p** | **--pretty** }] }
>
> *COMMANDS* :=
> - { **show** | **list** } [ **dev** name ] | **help**
> + { **show** | **list** | **attach** | **detach** | **help** }
>
> NET COMMANDS
> ============
>
> -| **bpftool** **net { show | list } [ dev name ]**
> +| **bpftool** **net { show | list }** [ **dev** *name* ]
> +| **bpftool** **net attach** *ATTACH_TYPE* *PROG* **dev** *name* [ **overwrite** ]
> +| **bpftool** **net detach** *ATTACH_TYPE* **dev** *name*
Nit: Could we have "name" in capital letters (everywhere in the file),
to make this file consistent with the formatting used for
bpftool-prog.rst and bpftool-map.rst?
> | **bpftool** **net help**
> +|
> +| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
> +| *ATTACH_TYPE* := { **xdp** | **xdpgeneric** | **xdpdrv** | **xdpoffload** }
>
> DESCRIPTION
> ===========
> - **bpftool net { show | list } [ dev name ]**
> + **bpftool net { show | list }** [ **dev** *name* ]
> List bpf program attachments in the kernel networking subsystem.
>
> Currently, only device driver xdp attachments and tc filter
> @@ -47,6 +52,18 @@ DESCRIPTION
> all bpf programs attached to non clsact qdiscs, and finally all
> bpf programs attached to root and clsact qdisc.
>
> + **bpftool** **net attach** *ATTACH_TYPE* *PROG* **dev** *name* [ **overwrite** ]
> + Attach bpf program *PROG* to network interface *name* with
> + type specified by *ATTACH_TYPE*. Previously attached bpf program
> + can be replaced by the command used with **overwrite** option.
> + Currently, *ATTACH_TYPE* only contains XDP programs.
Other nit: "ATTACH_TYPE only contains XDP programs" sounds odd to me.
Could we maybe phrase this something like: "Currently, only XDP-related
modes are supported for ATTACH_TYPE"?
Also, could you please provide a brief description of the different
attach types? In particular, explaining what "xdp" alone stands for
might be useful.
Thanks,
Quentin
> +
> + **bpftool** **net detach** *ATTACH_TYPE* **dev** *name*
> + Detach bpf program attached to network interface *name* with
> + type specified by *ATTACH_TYPE*. To detach bpf program, same
> + *ATTACH_TYPE* previously used for attach must be specified.
> + Currently, *ATTACH_TYPE* only contains XDP programs.
^ permalink raw reply
* Re: memory leak in kobject_set_name_vargs (2)
From: Dmitry Vyukov @ 2019-08-08 17:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: syzbot, Catalin Marinas, David Miller, Herbert Xu,
Alexey Kuznetsov, Kalle Valo, Linux List Kernel Mailing, Linux-MM,
luciano.coelho, Netdev, Steffen Klassert, syzkaller-bugs,
Hideaki YOSHIFUJI
In-Reply-To: <CAHk-=why-PdP_HNbskRADMp1bnj+FwUDYpUZSYoNLNHMRPtoVA@mail.gmail.com>
On Sat, Jul 27, 2019 at 4:29 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Jul 26, 2019 at 4:26 PM syzbot
> <syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit 0e034f5c4bc408c943f9c4a06244415d75d7108c
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date: Wed May 18 18:51:25 2016 +0000
> >
> > iwlwifi: fix mis-merge that breaks the driver
>
> While this bisection looks more likely than the other syzbot entry
> that bisected to a version change, I don't think it is correct eitger.
>
> The bisection ended up doing a lot of "git bisect skip" because of the
>
> undefined reference to `nf_nat_icmp_reply_translation'
>
> issue. Also, the memory leak doesn't seem to be entirely reliable:
> when the bisect does 10 runs to verify that some test kernel is bad,
> there are a couple of cases where only one or two of the ten run
> failed.
>
> Which makes me wonder if one or two of the "everything OK" runs were
> actually buggy, but just happened to have all ten pass...
I agree this is unrelated.
Bisection of memory leaks is now turned off completely after a
week-long experiment (details:
https://groups.google.com/d/msg/syzkaller/sR8aAXaWEF4/k34t365JBgAJ)
FWIW 'git bisect skip' is not a problem in itself. If the bisection
will end up being inconclusive due to this, then syzbot will not
attribute it to any commit (won't send an email at all), it will just
show the commit range in the web UI for the bug.
Low probability wasn't the root cause as well, first runs ended with
10/10 precision:
bisecting cause commit starting from 3bfe1fc46794631366faa3ef075e1b0ff7ba120a
building syzkaller on 1656845f45f284c574eb4f8bfe85dd7916a47a3a
testing commit 3bfe1fc46794631366faa3ef075e1b0ff7ba120a with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v5.2
testing commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v5.1
testing commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v5.0
testing commit 1c163f4c7b3f621efff9b28a47abb36f7378d783 with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v4.20
testing commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
testing release v4.19
testing commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d with gcc (GCC) 8.1.0
all runs: crashed: memory leak in kobject_set_name_vargs
But it was distracted by other bugs and other memory leaks (which
reproduce with lower probability) and then the process went random
(which confirms the bisection analysis results).
^ permalink raw reply
* Re: [bpf-next PATCH 0/3] bpf: improvements to xdp_fwd sample
From: Zvi Effron @ 2019-08-08 17:21 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Xdp, Anton Protopopov, dsahern, Toke Høiland-Jørgensen,
netdev@vger.kernel.org
In-Reply-To: <20190808112955.5a29c9e1@carbon>
On Thu, Aug 8, 2019 at 4:30 AM Jesper Dangaard Brouer <brouer@redhat.com> wrote:
>
> Another improvement from Toke, is that the bpf_redirect_map() helper,
> now also check if the redirect index is valid in the map. If not, then
> it returns another value than XDP_REDIRECT. You can choose the
> alternative return value yourself, via "flags" e.g. XDP_PASS. Thus,
> you don't even need to check/validate devmap in your BPF-code, as it is
> part of the bpf_redirect_map() call now.
>
> action = bpf_redirect_map(&map, &index, flags_as_xdp_value)
>
> The default flags used in most programs today is 0, which maps to
> XDP_ABORTED. This is sort of a small UAPI change, but for the better.
> As today, the packet is dropped later, only diagnose/seen via
> tracepoint xdp:xdp_redirect_map_err.
>
That's great to hear, as I'd thought it already worked that way (minus
the flags to specify what the alternate action is).
Thanks for explaining!
--Zvi
^ permalink raw reply
* general protection fault in perf_tp_event_match (2)
From: syzbot @ 2019-08-08 17:24 UTC (permalink / raw)
To: acme, alexander.shishkin, ast, bpf, daniel, jolsa, kafai,
linux-kernel, mingo, namhyung, netdev, peterz, songliubraving,
syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: 1e78030e Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1011831a600000
kernel config: https://syzkaller.appspot.com/x/.config?x=4c7b914a2680c9c6
dashboard link: https://syzkaller.appspot.com/bug?extid=076ba900c4a9a0f67aba
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+076ba900c4a9a0f67aba@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 22070 Comm: syz-executor.3 Not tainted 5.3.0-rc2+ #86
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:perf_tp_event_match+0x31/0x260 kernel/events/core.c:8560
Code: 89 f6 41 55 49 89 d5 41 54 53 48 89 fb e8 b7 0e ea ff 48 8d bb d0 01
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 08 3c 03 0f 8e cc 01 00 00 44 8b a3 d0 01 00
RSP: 0018:ffff88804ffa7790 EFLAGS: 00010007
RAX: dffffc0000000000 RBX: 00000000ffffff9f RCX: ffffffff818bcb73
RDX: 000000002000002d RSI: ffffffff818890b9 RDI: 000000010000016f
RBP: ffff88804ffa77b0 R08: ffff8880531ba640 R09: ffffed100a6374c9
R10: ffffed100a6374c8 R11: ffff8880531ba647 R12: ffff8880ae830860
R13: ffff8880ae830860 R14: ffff88804ffa7880 R15: dffffc0000000000
FS: 00005555556d7940(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000738008 CR3: 000000004cad5000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
perf_tp_event+0x1ea/0x730 kernel/events/core.c:8611
perf_trace_run_bpf_submit+0x131/0x190 kernel/events/core.c:8586
perf_trace_sched_wakeup_template+0x42d/0x5d0
include/trace/events/sched.h:57
trace_sched_wakeup_new include/trace/events/sched.h:103 [inline]
wake_up_new_task+0x70f/0xbd0 kernel/sched/core.c:2848
_do_fork+0x26c/0xfa0 kernel/fork.c:2393
__do_sys_clone kernel/fork.c:2524 [inline]
__se_sys_clone kernel/fork.c:2505 [inline]
__x64_sys_clone+0x18d/0x250 kernel/fork.c:2505
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457dfa
Code: f7 d8 64 89 04 25 d4 02 00 00 64 4c 8b 0c 25 10 00 00 00 31 d2 4d 8d
91 d0 02 00 00 31 f6 bf 11 00 20 01 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff
ff 0f 87 f5 00 00 00 85 c0 41 89 c5 0f 85 fc 00 00
RSP: 002b:00007ffcf0b1c640 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 00007ffcf0b1c640 RCX: 0000000000457dfa
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000001200011
RBP: 00007ffcf0b1c680 R08: 0000000000000001 R09: 00005555556d7940
R10: 00005555556d7c10 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffcf0b1c6d0
Modules linked in:
---[ end trace 8f4efeb0ada52ec1 ]---
RIP: 0010:perf_tp_event_match+0x31/0x260 kernel/events/core.c:8560
Code: 89 f6 41 55 49 89 d5 41 54 53 48 89 fb e8 b7 0e ea ff 48 8d bb d0 01
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
c0 74 08 3c 03 0f 8e cc 01 00 00 44 8b a3 d0 01 00
RSP: 0018:ffff88804ffa7790 EFLAGS: 00010007
RAX: dffffc0000000000 RBX: 00000000ffffff9f RCX: ffffffff818bcb73
RDX: 000000002000002d RSI: ffffffff818890b9 RDI: 000000010000016f
RBP: ffff88804ffa77b0 R08: ffff8880531ba640 R09: ffffed100a6374c9
R10: ffffed100a6374c8 R11: ffff8880531ba647 R12: ffff8880ae830860
R13: ffff8880ae830860 R14: ffff88804ffa7880 R15: dffffc0000000000
FS: 00005555556d7940(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000738008 CR3: 000000004cad5000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ 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