* Re: [PATCH net-next] net: mscc: simplify retrieving the tag type from the frame header
From: Alexandre Belloni @ 2018-07-16 14:17 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, f.fainelli, andrew, netdev, linux-kernel, thomas.petazzoni,
quentin.schulz, allan.nielsen
In-Reply-To: <20180713145757.3574-1-antoine.tenart@bootlin.com>
On 13/07/2018 16:57:57+0200, Antoine Ténart wrote:
> The tag type in the frame extraction header is only a bit wide. There's
> no need to use GENMASK when retrieving the information. This patch
> simplify the code by dropping GENMASK and using BIT instead.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/net/ethernet/mscc/ocelot_board.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
> index 18df7d934e81..26bb3b18f3be 100644
> --- a/drivers/net/ethernet/mscc/ocelot_board.c
> +++ b/drivers/net/ethernet/mscc/ocelot_board.c
> @@ -29,7 +29,7 @@ static int ocelot_parse_ifh(u32 *ifh, struct frame_info *info)
> info->port = (ifh[2] & GENMASK(14, 11)) >> 11;
>
> info->cpuq = (ifh[3] & GENMASK(27, 20)) >> 20;
> - info->tag_type = (ifh[3] & GENMASK(16, 16)) >> 16;
> + info->tag_type = (ifh[3] & BIT(16)) >> 16;
> info->vid = ifh[3] & GENMASK(11, 0);
>
> return 0;
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next] cxgb4: collect ASIC LA dumps from ULP TX
From: Rahul Lakkireddy @ 2018-07-16 14:10 UTC (permalink / raw)
To: netdev; +Cc: davem, surendra, ganeshgr, nirranjan, indranil, Rahul Lakkireddy
From: Surendra Mobiya <surendra@chelsio.com>
Signed-off-by: Surendra Mobiya <surendra@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cudbg_entity.h | 6 +++++
drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 32 +++++++++++++++++++++--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c | 3 ++-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 10 +++++++
4 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cudbg_entity.h b/drivers/net/ethernet/chelsio/cxgb4/cudbg_entity.h
index 3c5057868ab3..aaf7985aef4c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cudbg_entity.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cudbg_entity.h
@@ -281,12 +281,18 @@ struct cudbg_tid_data {
#define CUDBG_NUM_ULPTX 11
#define CUDBG_NUM_ULPTX_READ 512
+#define CUDBG_NUM_ULPTX_ASIC 6
+#define CUDBG_NUM_ULPTX_ASIC_READ 128
+
+#define CUDBG_ULPTX_LA_REV 1
struct cudbg_ulptx_la {
u32 rdptr[CUDBG_NUM_ULPTX];
u32 wrptr[CUDBG_NUM_ULPTX];
u32 rddata[CUDBG_NUM_ULPTX];
u32 rd_data[CUDBG_NUM_ULPTX][CUDBG_NUM_ULPTX_READ];
+ u32 rdptr_asic[CUDBG_NUM_ULPTX_ASIC_READ];
+ u32 rddata_asic[CUDBG_NUM_ULPTX_ASIC_READ][CUDBG_NUM_ULPTX_ASIC];
};
#define CUDBG_CHAC_PBT_ADDR 0x2800
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
index 0afcfe99bff3..b1eb843035ee 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
@@ -2586,15 +2586,24 @@ int cudbg_collect_ulptx_la(struct cudbg_init *pdbg_init,
struct adapter *padap = pdbg_init->adap;
struct cudbg_buffer temp_buff = { 0 };
struct cudbg_ulptx_la *ulptx_la_buff;
+ struct cudbg_ver_hdr *ver_hdr;
u32 i, j;
int rc;
- rc = cudbg_get_buff(pdbg_init, dbg_buff, sizeof(struct cudbg_ulptx_la),
+ rc = cudbg_get_buff(pdbg_init, dbg_buff,
+ sizeof(struct cudbg_ver_hdr) +
+ sizeof(struct cudbg_ulptx_la),
&temp_buff);
if (rc)
return rc;
- ulptx_la_buff = (struct cudbg_ulptx_la *)temp_buff.data;
+ ver_hdr = (struct cudbg_ver_hdr *)temp_buff.data;
+ ver_hdr->signature = CUDBG_ENTITY_SIGNATURE;
+ ver_hdr->revision = CUDBG_ULPTX_LA_REV;
+ ver_hdr->size = sizeof(struct cudbg_ulptx_la);
+
+ ulptx_la_buff = (struct cudbg_ulptx_la *)(temp_buff.data +
+ sizeof(*ver_hdr));
for (i = 0; i < CUDBG_NUM_ULPTX; i++) {
ulptx_la_buff->rdptr[i] = t4_read_reg(padap,
ULP_TX_LA_RDPTR_0_A +
@@ -2610,6 +2619,25 @@ int cudbg_collect_ulptx_la(struct cudbg_init *pdbg_init,
t4_read_reg(padap,
ULP_TX_LA_RDDATA_0_A + 0x10 * i);
}
+
+ for (i = 0; i < CUDBG_NUM_ULPTX_ASIC_READ; i++) {
+ t4_write_reg(padap, ULP_TX_ASIC_DEBUG_CTRL_A, 0x1);
+ ulptx_la_buff->rdptr_asic[i] =
+ t4_read_reg(padap, ULP_TX_ASIC_DEBUG_CTRL_A);
+ ulptx_la_buff->rddata_asic[i][0] =
+ t4_read_reg(padap, ULP_TX_ASIC_DEBUG_0_A);
+ ulptx_la_buff->rddata_asic[i][1] =
+ t4_read_reg(padap, ULP_TX_ASIC_DEBUG_1_A);
+ ulptx_la_buff->rddata_asic[i][2] =
+ t4_read_reg(padap, ULP_TX_ASIC_DEBUG_2_A);
+ ulptx_la_buff->rddata_asic[i][3] =
+ t4_read_reg(padap, ULP_TX_ASIC_DEBUG_3_A);
+ ulptx_la_buff->rddata_asic[i][4] =
+ t4_read_reg(padap, ULP_TX_ASIC_DEBUG_4_A);
+ ulptx_la_buff->rddata_asic[i][5] =
+ t4_read_reg(padap, PM_RX_BASE_ADDR);
+ }
+
return cudbg_write_and_release_buff(pdbg_init, &temp_buff, dbg_buff);
}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
index 8d751efcb90e..55b46592af28 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
@@ -273,7 +273,8 @@ static u32 cxgb4_get_entity_length(struct adapter *adap, u32 entity)
}
break;
case CUDBG_ULPTX_LA:
- len = sizeof(struct cudbg_ulptx_la);
+ len = sizeof(struct cudbg_ver_hdr) +
+ sizeof(struct cudbg_ulptx_la);
break;
case CUDBG_UP_CIM_INDIRECT:
n = 0;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
index 6b55aa2eb2a5..446aaff15bae 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
@@ -1683,6 +1683,16 @@
#define ULP_TX_LA_RDPTR_0_A 0x8ec0
#define ULP_TX_LA_RDDATA_0_A 0x8ec4
#define ULP_TX_LA_WRPTR_0_A 0x8ec8
+#define ULP_TX_ASIC_DEBUG_CTRL_A 0x8f70
+
+#define ULP_TX_ASIC_DEBUG_0_A 0x8f74
+#define ULP_TX_ASIC_DEBUG_1_A 0x8f78
+#define ULP_TX_ASIC_DEBUG_2_A 0x8f7c
+#define ULP_TX_ASIC_DEBUG_3_A 0x8f80
+#define ULP_TX_ASIC_DEBUG_4_A 0x8f84
+
+/* registers for module PM_RX */
+#define PM_RX_BASE_ADDR 0x8fc0
#define PMRX_E_PCMD_PAR_ERROR_S 0
#define PMRX_E_PCMD_PAR_ERROR_V(x) ((x) << PMRX_E_PCMD_PAR_ERROR_S)
--
2.14.1
^ permalink raw reply related
* Re: [PATCH net,v2] tcp: Fix broken repair socket window probe patch
From: Eric Dumazet @ 2018-07-16 14:16 UTC (permalink / raw)
To: Stefan Baranoff
Cc: Andrey Vagin, Pavel Emelyanov, Eric Dumazet, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev
In-Reply-To: <1531668997-1439-1-git-send-email-sbaranoff@gmail.com>
On 07/15/2018 08:36 AM, Stefan Baranoff wrote:
> Correct previous bad attempt at allowing sockets to come out of TCP
> repair without sending window probes. To avoid changing size of
> the repair variable in struct tcp_sock, this lets the decision for
> sending probes or not to be made when coming out of repair by
> introducing two ways to turn it off.
>
Thanks for the fix.
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* general protection fault in do_raw_spin_unlock
From: syzbot @ 2018-07-16 14:59 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
Hello,
syzbot found the following crash on:
HEAD commit: 1d4eb636f0ab Add linux-next specific files for 20180716
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1186bf0c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=ea5926dddb0db97a
dashboard link: https://syzkaller.appspot.com/bug?extid=83a25334ef203851dc81
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=179ed444400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+83a25334ef203851dc81@syzkaller.appspotmail.com
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 1 PID: 24 Comm: kworker/1:1 Not tainted 4.18.0-rc5-next-20180716+ #8
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events p9_poll_workfn
RIP: 0010:debug_spin_unlock kernel/locking/spinlock_debug.c:97 [inline]
RIP: 0010:do_raw_spin_unlock+0x65/0x2f0 kernel/locking/spinlock_debug.c:134
Code: 0a bd 88 48 c7 85 78 ff ff ff b3 8a b5 41 48 c7 45 88 d0 3c 60 81 c7
02 f1 f1 f1 f1 c7 42 04 04 f2 f2 f2 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48
89 f8 65 48 8b 0c 25 28 00 00 00 48 89 4d d0 31 c9
RSP: 0018:ffff8801d945f288 EFLAGS: 00010047
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8770a045
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000004
RBP: ffff8801d945f310 R08: 1ffff1003b28be45 R09: ffffed0035e7bd88
R10: ffffed0035e7bd88 R11: ffff8801af3dec43 R12: 0000000000000000
R13: 1ffff1003b28be51 R14: ffff8801d945f2e8 R15: ffff8801c5811d50
FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000072c029 CR3: 00000001b19fd000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:159 [inline]
_raw_spin_unlock_irqrestore+0x27/0xc0 kernel/locking/spinlock.c:184
spin_unlock_irqrestore include/linux/spinlock.h:384 [inline]
p9_conn_cancel+0x9b6/0xd30 net/9p/trans_fd.c:208
p9_poll_mux net/9p/trans_fd.c:620 [inline]
p9_poll_workfn+0x4b2/0x6d0 net/9p/trans_fd.c:1107
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 4d86351f63a12683 ]---
RIP: 0010:debug_spin_unlock kernel/locking/spinlock_debug.c:97 [inline]
RIP: 0010:do_raw_spin_unlock+0x65/0x2f0 kernel/locking/spinlock_debug.c:134
Code: 0a bd 88 48 c7 85 78 ff ff ff b3 8a b5 41 48 c7 45 88 d0 3c 60 81 c7
02 f1 f1 f1 f1 c7 42 04 04 f2 f2 f2 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48
89 f8 65 48 8b 0c 25 28 00 00 00 48 89 4d d0 31 c9
RSP: 0018:ffff8801d945f288 EFLAGS: 00010047
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8770a045
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000004
RBP: ffff8801d945f310 R08: 1ffff1003b28be45 R09: ffffed0035e7bd88
R10: ffffed0035e7bd88 R11: ffff8801af3dec43 R12: 0000000000000000
R13: 1ffff1003b28be51 R14: ffff8801d945f2e8 R15: ffff8801c5811d50
FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000072c029 CR3: 00000001b19fd000 CR4: 00000000001406e0
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#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next] sch_cake: Fix tin order when set through skb->priority
From: Toke Høiland-Jørgensen @ 2018-07-16 14:45 UTC (permalink / raw)
To: netdev; +Cc: cake, Toke Høiland-Jørgensen
In diffserv mode, CAKE stores tins in a different order internally than
the logical order exposed to userspace. The order remapping was missing
in the handling of 'tc filter' priority mappings through skb->priority,
resulting in bulk and best effort mappings being reversed relative to
how they are displayed.
Fix this by adding the missing mapping when reading skb->priority.
Fixes: 83f8fd69af4f ("sch_cake: Add DiffServ handling")
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
net/sched/sch_cake.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index 30695691e9ff..539c9490c308 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -1546,7 +1546,7 @@ static struct cake_tin_data *cake_select_tin(struct Qdisc *sch,
if (TC_H_MAJ(skb->priority) == sch->handle &&
TC_H_MIN(skb->priority) > 0 &&
TC_H_MIN(skb->priority) <= q->tin_cnt) {
- tin = TC_H_MIN(skb->priority) - 1;
+ tin = q->tin_order[TC_H_MIN(skb->priority) - 1];
if (q->rate_flags & CAKE_FLAG_WASH)
cake_wash_diffserv(skb);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH iproute2] ip: add support for seg6local End.BPF action
From: Stephen Hemminger @ 2018-07-16 14:48 UTC (permalink / raw)
To: Mathieu Xhonneux; +Cc: netdev, dsahern, dlebrun
In-Reply-To: <20180716144741.20478-1-m.xhonneux@gmail.com>
On Mon, 16 Jul 2018 14:47:41 +0000
Mathieu Xhonneux <m.xhonneux@gmail.com> wrote:
> This patch adds support for the End.BPF action of the seg6local
> lightweight tunnel. Functions from the BPF lightweight tunnel are
> re-used in this patch. Example:
>
> $ ip -6 route add fc00::18 encap seg6local action End.BPF obj my_bpf.o
> sec my_func dev eth0
>
> $ ip -6 route show fc00::18
> fc00::18 encap seg6local action End.BPF my_bpf.o:[my_func] dev eth0
> metric 1024 pref medium
>
> Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
> ---
> ip/iproute_lwtunnel.c | 122 +++++++++++++++++++++++++++++---------------------
> lib/bpf.c | 5 +++
> 2 files changed, 77 insertions(+), 50 deletions(-)
>
> diff --git a/ip/iproute_lwtunnel.c b/ip/iproute_lwtunnel.c
> index 46a212c8..71c3d8a4 100644
> --- a/ip/iproute_lwtunnel.c
> +++ b/ip/iproute_lwtunnel.c
> @@ -177,6 +177,7 @@ static const char *seg6_action_names[SEG6_LOCAL_ACTION_MAX + 1] = {
> [SEG6_LOCAL_ACTION_END_S] = "End.S",
> [SEG6_LOCAL_ACTION_END_AS] = "End.AS",
> [SEG6_LOCAL_ACTION_END_AM] = "End.AM",
> + [SEG6_LOCAL_ACTION_END_BPF] = "End.BPF",
> };
>
> static const char *format_action_type(int action)
> @@ -250,6 +251,15 @@ static void print_encap_seg6local(FILE *fp, struct rtattr *encap)
> print_string(PRINT_ANY, "oif",
> "oif %s ", ll_index_to_name(oif));
> }
> +
> + if (tb[SEG6_LOCAL_BPF]) {
> + struct rtattr *tb_bpf[LWT_BPF_PROG_MAX+1];
> +
> + parse_rtattr_nested(tb_bpf, LWT_BPF_PROG_MAX, tb[SEG6_LOCAL_BPF]);
> +
> + if (tb_bpf[LWT_BPF_PROG_NAME])
> + fprintf(fp, "%s ", rta_getattr_str(tb_bpf[LWT_BPF_PROG_NAME]));
> + }
> }
Please use print_string to support JSON output.
^ permalink raw reply
* WARNING in bpf_jit_free
From: syzbot @ 2018-07-16 15:18 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 9d3cce1e8b85 Linux 4.18-rc5
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1127970c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=6d0ccc9273f0e539
dashboard link: https://syzkaller.appspot.com/bug?extid=2ff1e7cb738fd3c41113
compiler: gcc (GCC) 8.0.1 20180413 (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+2ff1e7cb738fd3c41113@syzkaller.appspotmail.com
WARNING: CPU: 0 PID: 12000 at kernel/bpf/core.c:628 bpf_jit_free+0x2e5/0x3f0
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:bpf_jit_free+0x2e5/0x3f0
Code: 07 38 c8 7f 08 84 c0 0f 85 85 00 00 00 48 b8 00 02 00 00 00 00 ad de
44 0f b6 63 02 48 39 c2 0f 84 d9 fd ff ff e8 db a3 f3 ff <0f> 0b e9 cd fd
ff ff e8 cf a3 f3 ff 4c 89 f0 48 ba 00 00 00 00 00
RSP: 0018:ffff880194267640 EFLAGS: 00010293
RAX: ffff8801aa76e6c0 RBX: ffffc9000192e000 RCX: 0000000000000002
RDX: 0000000000000000 RSI: ffffffff81886765 RDI: ffff8801d9223768
RBP: ffff8801942676d8 R08: ffff8801aa76eef8 R09: 0000000000000006
R10: ffff8801aa76e6c0 R11: 0000000000000000 R12: 000000000000000f
R13: 1ffff1003284ceca R14: ffffc9000192e002 R15: ffffc9000192e020
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#1] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194266f80 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff8801942670f8 R08: ffff8801aa76e6c0 R09: ffffed003b5c46d6
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#2] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194266818 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194266990 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#3] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff8801942660a8 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194266220 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#4] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194265938 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194265ab0 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#5] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff8801942651c8 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194265340 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#6] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194264a58 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194264bd0 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#7] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff8801942642e8 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194264460 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#8] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194263b78 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194263cf0 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#9] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194263408 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194263580 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#10] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194262c98 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194262e10 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#11] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194262528 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff8801942626a0 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#12] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194261db8 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194261f30 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#13] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194261648 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff8801942617c0 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Oops: 0000 [#14] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:435 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x2f8/0x4c0 kernel/bpf/core.c:509
Code: e7 f3 ff 0f 0b e8 38 e7 f3 ff 4c 89 e6 4c 89 ef e8 dd e7 f3 ff 4d 39
e5 0f 82 a0 00 00 00 e8 1f e7 f3 ff 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 30
84 c0 74 08 3c 03 0f 8e 4e 01 00 00 41 8b 04 24 4c
RSP: 0018:ffff880194260ed8 EFLAGS: 00010806
RAX: 1ffffffff4002000 RBX: ffff8801d9223730 RCX: ffffffff81882413
RDX: 0000000000000000 RSI: ffffffff81882421 RDI: 0000000000000006
RBP: ffff880194261050 R08: ffff8801aa76e6c0 R09: 0000000000000001
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: ffffffffa0010000
R13: ffffffffffffffff R14: dffffc0000000000 R15: ffff8801d9223730
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff4002000 CR3: 00000001817e0000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at fffffbfff4002000
PGD 21fbea067 P4D 21fbea067 PUD 21fa5e067 PMD 1c4b80067 PTE 0
Thread overran stack, or stack corrupted
Oops: 0000 [#15] SMP KASAN
CPU: 0 PID: 12000 Comm: kworker/0:5 Not tainted 4.18.0-rc5+ #149
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
usercopy: Kernel memory overwrite attempt detected to process stack (offset
0, size 8)!
usercopy: Kernel memory overwrite attempt detected to SLAB
object 'kmalloc-4096' (offset 4120, size 2)!
------------[ cut here ]------------
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Max Gurtovoy @ 2018-07-16 14:54 UTC (permalink / raw)
To: Leon Romanovsky, Sagi Grimberg
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, Saeed Mahameed,
Steve Wise, linux-netdev
In-Reply-To: <20180716103046.GJ3152@mtr-leonro.mtl.com>
Hi,
I've tested this patch and seems problematic at this moment.
maybe this is because of the bug that Steve mentioned in the NVMe
mailing list. Sagi mentioned that we should fix it in the NVMe/RDMA
initiator and I'll run his suggestion as well.
BTW, when I run the blk_mq_map_queues it works for every irq affinity.
On 7/16/2018 1:30 PM, Leon Romanovsky wrote:
> On Mon, Jul 16, 2018 at 01:23:24PM +0300, Sagi Grimberg wrote:
>> Leon, I'd like to see a tested-by tag for this (at least
>> until I get some time to test it).
>
> Of course.
>
> Thanks
>
>>
>> The patch itself looks fine to me.
-Max.
^ permalink raw reply
* KASAN: use-after-free Read in kernel_accept
From: syzbot @ 2018-07-16 14:59 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 6bed5e260709 Merge branch 'fix-DCTCP-delayed-ACK'
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=176b25d0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=b88de6eac8694da6
dashboard link: https://syzkaller.appspot.com/bug?extid=0bf2e01269f1274b4b03
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=159dd178400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13b76d62400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0bf2e01269f1274b4b03@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in kernel_accept+0x2a4/0x310 net/socket.c:3251
Read of size 8 at addr ffff8801a772c5e8 by task kworker/1:3/4569
CPU: 1 PID: 4569 Comm: kworker/1:3 Not tainted 4.18.0-rc3+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events smc_tcp_listen_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
kernel_accept+0x2a4/0x310 net/socket.c:3251
smc_clcsock_accept net/smc/af_smc.c:701 [inline]
smc_tcp_listen_work+0x222/0xef0 net/smc/af_smc.c:1114
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Allocated by task 4568:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
sock_alloc_inode+0x78/0x320 net/socket.c:243
alloc_inode+0x63/0x190 fs/inode.c:210
new_inode_pseudo+0x71/0x1a0 fs/inode.c:895
sock_alloc+0x41/0x270 net/socket.c:567
__sock_create+0x175/0x940 net/socket.c:1250
sock_create_kern+0x3b/0x50 net/socket.c:1332
smc_create+0x141/0x360 net/smc/af_smc.c:1701
__sock_create+0x53c/0x940 net/socket.c:1286
sock_create net/socket.c:1326 [inline]
__sys_socket+0x106/0x260 net/socket.c:1356
__do_sys_socket net/socket.c:1365 [inline]
__se_sys_socket net/socket.c:1363 [inline]
__x64_sys_socket+0x73/0xb0 net/socket.c:1363
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 4568:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
sock_destroy_inode+0x56/0x70 net/socket.c:273
destroy_inode+0x159/0x200 fs/inode.c:267
evict+0x5d5/0x990 fs/inode.c:575
iput_final fs/inode.c:1506 [inline]
iput+0x635/0xaa0 fs/inode.c:1532
__sock_release+0x1f1/0x260 net/socket.c:610
sock_release+0x17/0x20 net/socket.c:618
smc_release+0x1a8/0x720 net/smc/af_smc.c:146
__sock_release+0xd7/0x260 net/socket.c:599
sock_close+0x19/0x20 net/socket.c:1150
__fput+0x355/0x8b0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:192 [inline]
exit_to_usermode_loop+0x313/0x370 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801a772c5c0
which belongs to the cache sock_inode_cache of size 992
The buggy address is located 40 bytes inside of
992-byte region [ffff8801a772c5c0, ffff8801a772c9a0)
The buggy address belongs to the page:
page:ffffea00069dcb00 count:1 mapcount:0 mapping:ffff8801d9be93c0
index:0xffff8801a772cffd
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea00069dcac8 ffffea00069dd408 ffff8801d9be93c0
raw: ffff8801a772cffd ffff8801a772c140 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801a772c480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801a772c500: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801a772c580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801a772c600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801a772c680: 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#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Sagi Grimberg @ 2018-07-16 14:59 UTC (permalink / raw)
To: Max Gurtovoy, Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, Saeed Mahameed,
Steve Wise, linux-netdev
In-Reply-To: <1cb63259-9fb6-59b0-3a34-0659973228ea@mellanox.com>
> Hi,
> I've tested this patch and seems problematic at this moment.
Problematic how? what are you seeing?
> maybe this is because of the bug that Steve mentioned in the NVMe
> mailing list. Sagi mentioned that we should fix it in the NVMe/RDMA
> initiator and I'll run his suggestion as well.
Is your device irq affinity linear?
> BTW, when I run the blk_mq_map_queues it works for every irq affinity.
But its probably not aligned to the device vector affinity.
^ permalink raw reply
* [PATCH net-next 0/9] Bug fixes and some minor changes to HNS3 driver
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
This patch-set presents some fixes and minor changes to the HNS3 Ethernet Driver.
Fuyun Liang (2):
net: hns3: Fix for using wrong mask and shift in
hclge_get_ring_chain_from_mbx
net: hns3: Fix comments for hclge_get_ring_chain_from_mbx
Huazhong Tan (6):
net: hns3: Modify the order of initializing command queue register
net: hns3: Reset net device with rtnl_lock
net: hns3: Prevent to request reset frequently
net: hns3: Correct reset event status register
net: hns3: Fix return value error in hns3_reset_notify_down_enet
net: hns3: remove unnecessary ring configuration operation while
resetting
Yunsheng Lin (1):
net: hns3: Fix for reset_level default assignment probelm
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 16 ++++++----------
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 ++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 20 +++++++++++++-------
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 14 ++++++++------
5 files changed, 30 insertions(+), 25 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 1/9] net: hns3: Modify the order of initializing command queue register
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Huazhong Tan
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
According to hardware's description, the head pointer register should
be written before the tail pointer register while doing command queue
initialization.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index eca4b23..cf40afc 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -119,8 +119,8 @@ static void hclge_cmd_config_regs(struct hclge_cmq_ring *ring)
hclge_write_dev(hw, HCLGE_NIC_CSQ_DEPTH_REG,
(ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S) |
HCLGE_NIC_CMQ_ENABLE);
- hclge_write_dev(hw, HCLGE_NIC_CSQ_TAIL_REG, 0);
hclge_write_dev(hw, HCLGE_NIC_CSQ_HEAD_REG, 0);
+ hclge_write_dev(hw, HCLGE_NIC_CSQ_TAIL_REG, 0);
} else {
hclge_write_dev(hw, HCLGE_NIC_CRQ_BASEADDR_L_REG,
lower_32_bits(dma));
@@ -129,8 +129,8 @@ static void hclge_cmd_config_regs(struct hclge_cmq_ring *ring)
hclge_write_dev(hw, HCLGE_NIC_CRQ_DEPTH_REG,
(ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S) |
HCLGE_NIC_CMQ_ENABLE);
- hclge_write_dev(hw, HCLGE_NIC_CRQ_TAIL_REG, 0);
hclge_write_dev(hw, HCLGE_NIC_CRQ_HEAD_REG, 0);
+ hclge_write_dev(hw, HCLGE_NIC_CRQ_TAIL_REG, 0);
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/9] net: hns3: Reset net device with rtnl_lock
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Huazhong Tan
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Since current locking was not covering certain code where
netdev was being accessed or manipulated, this patch fixes
it.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 8bbf4e5..3886290 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2820,15 +2820,13 @@ static void hclge_clear_reset_cause(struct hclge_dev *hdev)
static void hclge_reset(struct hclge_dev *hdev)
{
/* perform reset of the stack & ae device for a client */
-
+ rtnl_lock();
hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
if (!hclge_reset_wait(hdev)) {
- rtnl_lock();
hclge_notify_client(hdev, HNAE3_UNINIT_CLIENT);
hclge_reset_ae_dev(hdev->ae_dev);
hclge_notify_client(hdev, HNAE3_INIT_CLIENT);
- rtnl_unlock();
hclge_clear_reset_cause(hdev);
} else {
@@ -2838,6 +2836,7 @@ static void hclge_reset(struct hclge_dev *hdev)
}
hclge_notify_client(hdev, HNAE3_UP_CLIENT);
+ rtnl_unlock();
}
static void hclge_reset_event(struct hnae3_handle *handle)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/9] net: hns3: Prevent to request reset frequently
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Huazhong Tan
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Netdevice reset should not be requested frequently, a new one
must wait a moment since there may be some work not completed.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3886290..a1886a3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2819,7 +2819,10 @@ static void hclge_clear_reset_cause(struct hclge_dev *hdev)
static void hclge_reset(struct hclge_dev *hdev)
{
+ struct hnae3_handle *handle;
+
/* perform reset of the stack & ae device for a client */
+ handle = &hdev->vport[0].nic;
rtnl_lock();
hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
@@ -2836,6 +2839,7 @@ static void hclge_reset(struct hclge_dev *hdev)
}
hclge_notify_client(hdev, HNAE3_UP_CLIENT);
+ handle->last_reset_time = jiffies;
rtnl_unlock();
}
@@ -2849,8 +2853,13 @@ static void hclge_reset_event(struct hnae3_handle *handle)
* know this if last reset request did not occur very recently (watchdog
* timer = 5*HZ, let us check after sufficiently large time, say 4*5*Hz)
* In case of new request we reset the "reset level" to PF reset.
+ * And if it is a repeat reset request of the most recent one then we
+ * want to make sure we throttle the reset request. Therefore, we will
+ * not allow it again before 3*HZ times.
*/
- if (time_after(jiffies, (handle->last_reset_time + 4 * 5 * HZ)))
+ if (time_before(jiffies, (handle->last_reset_time + 3 * HZ)))
+ return;
+ else if (time_after(jiffies, (handle->last_reset_time + 4 * 5 * HZ)))
handle->reset_level = HNAE3_FUNC_RESET;
dev_info(&hdev->pdev->dev, "received reset event , reset type is %d",
@@ -2862,8 +2871,6 @@ static void hclge_reset_event(struct hnae3_handle *handle)
if (handle->reset_level < HNAE3_GLOBAL_RESET)
handle->reset_level++;
-
- handle->last_reset_time = jiffies;
}
static void hclge_reset_subtask(struct hclge_dev *hdev)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 4/9] net: hns3: Correct reset event status register
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Huazhong Tan
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
According to hardware's description, driver should get reset event
from VECTOR0_PF_OTHER_INT_ST(0x20800) instead of
VECTOR0_PF_OTHER_INT_SRC(0x20700).
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index a1886a3..266c686 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2495,7 +2495,7 @@ static u32 hclge_check_event_cause(struct hclge_dev *hdev, u32 *clearval)
u32 cmdq_src_reg;
/* fetch the events from their corresponding regs */
- rst_src_reg = hclge_read_dev(&hdev->hw, HCLGE_MISC_RESET_STS_REG);
+ rst_src_reg = hclge_read_dev(&hdev->hw, HCLGE_MISC_VECTOR_INT_STS);
cmdq_src_reg = hclge_read_dev(&hdev->hw, HCLGE_VECTOR0_CMDQ_SRC_REG);
/* Assumption: If by any chance reset and mailbox events are reported
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 20abe82..a5abf8e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -89,6 +89,7 @@
/* Reset related Registers */
#define HCLGE_MISC_RESET_STS_REG 0x20700
+#define HCLGE_MISC_VECTOR_INT_STS 0x20800
#define HCLGE_GLOBAL_RESET_REG 0x20A00
#define HCLGE_GLOBAL_RESET_BIT 0x0
#define HCLGE_CORE_RESET_BIT 0x1
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 5/9] net: hns3: Fix return value error in hns3_reset_notify_down_enet
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Huazhong Tan
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
When doing reset, netdev has not been brought up is not an error,
it means that we do not need do the stop operation, so just return
zero.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index c211450..8296446 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3396,7 +3396,7 @@ static int hns3_reset_notify_down_enet(struct hnae3_handle *handle)
struct net_device *ndev = kinfo->netdev;
if (!netif_running(ndev))
- return -EIO;
+ return 0;
return hns3_nic_net_stop(ndev);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 6/9] net: hns3: remove unnecessary ring configuration operation while resetting
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Huazhong Tan
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
The configuration of the ring will be used to reinitialize the
ring after the hardware reset is completed. So we should not
release and reacquire this configuration during reset.
Fixes: bb6b94a896d4 ("net: hns3: Add reset interface implementation in client")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 8296446..24f82b7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3436,10 +3436,6 @@ static int hns3_reset_notify_init_enet(struct hnae3_handle *handle)
/* Carrier off reporting is important to ethtool even BEFORE open */
netif_carrier_off(netdev);
- ret = hns3_get_ring_config(priv);
- if (ret)
- return ret;
-
ret = hns3_nic_init_vector_data(priv);
if (ret)
return ret;
@@ -3471,10 +3467,6 @@ static int hns3_reset_notify_uninit_enet(struct hnae3_handle *handle)
if (ret)
netdev_err(netdev, "uninit ring error\n");
- hns3_put_ring_config(priv);
-
- priv->ring_data = NULL;
-
hns3_uninit_mac_addr(netdev);
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 7/9] net: hns3: Fix for reset_level default assignment probelm
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
handle->reset_level is assigned to HNAE3_NONE_RESET when client is
initialized, if a tx timeout happens right after initialization,
then handle->reset_level is not resetted to HNAE3_FUNC_RESET in
hclge_reset_event, which will cause reset event not properly
handled problem.
This patch fixes it by setting handle->reset_level properly when
client is initialized.
Fixes: 6d4c3981a8d8 ("net: hns3: Changes to make enet watchdog timeout func common for PF/VF")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 24f82b7..29be96e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3085,7 +3085,6 @@ static int hns3_client_init(struct hnae3_handle *handle)
priv->dev = &pdev->dev;
priv->netdev = netdev;
priv->ae_handle = handle;
- priv->ae_handle->reset_level = HNAE3_NONE_RESET;
priv->ae_handle->last_reset_time = jiffies;
priv->tx_timeout_count = 0;
@@ -3106,6 +3105,11 @@ static int hns3_client_init(struct hnae3_handle *handle)
/* Carrier off reporting is important to ethtool even BEFORE open */
netif_carrier_off(netdev);
+ if (handle->flags & HNAE3_SUPPORT_VF)
+ handle->reset_level = HNAE3_VF_RESET;
+ else
+ handle->reset_level = HNAE3_FUNC_RESET;
+
ret = hns3_get_ring_config(priv);
if (ret) {
ret = -ENOMEM;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 8/9] net: hns3: Fix for using wrong mask and shift in hclge_get_ring_chain_from_mbx
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
HCLGE_INT_GL_IDX_M and HCLGE_INT_GL_IDX_S are used to set fireware
cmd. When getting int_gl value from mailbox message, we should use
HNAE3_RING_GL_IDX_M and HNAE3_RING_GL_IDX_S.
Fixes: 79eee4108541 ("net: hns3: add int_gl_idx setup for VF")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index 50ae2f8..9d36bcc 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -131,8 +131,8 @@ static int hclge_get_ring_chain_from_mbx(
hnae3_set_bit(ring_chain->flag, HNAE3_RING_TYPE_B, req->msg[3]);
ring_chain->tqp_index =
hclge_get_queue_id(vport->nic.kinfo.tqp[req->msg[4]]);
- hnae3_set_field(ring_chain->int_gl_idx, HCLGE_INT_GL_IDX_M,
- HCLGE_INT_GL_IDX_S,
+ hnae3_set_field(ring_chain->int_gl_idx, HNAE3_RING_GL_IDX_M,
+ HNAE3_RING_GL_IDX_S,
req->msg[5]);
cur_chain = ring_chain;
@@ -151,8 +151,8 @@ static int hclge_get_ring_chain_from_mbx(
[req->msg[HCLGE_MBX_RING_NODE_VARIABLE_NUM * i +
HCLGE_MBX_RING_MAP_BASIC_MSG_NUM + 1]]);
- hnae3_set_field(new_chain->int_gl_idx, HCLGE_INT_GL_IDX_M,
- HCLGE_INT_GL_IDX_S,
+ hnae3_set_field(new_chain->int_gl_idx, HNAE3_RING_GL_IDX_M,
+ HNAE3_RING_GL_IDX_S,
req->msg[HCLGE_MBX_RING_NODE_VARIABLE_NUM * i +
HCLGE_MBX_RING_MAP_BASIC_MSG_NUM + 2]);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 9/9] net: hns3: Fix comments for hclge_get_ring_chain_from_mbx
From: Salil Mehta @ 2018-07-16 15:36 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180716153627.476-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
Actually, hclge_get_ring_chain_from_mbx is used to get ring type, tqp id,
and int_gl index from mailbox message. So the comments is incorrect. This
patch fixes it.
Fixes: dde1a86e93ca ("net: hns3: Add mailbox support to PF driver")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index 9d36bcc..f34851c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -104,13 +104,15 @@ static void hclge_free_vector_ring_chain(struct hnae3_ring_chain_node *head)
}
}
-/* hclge_get_ring_chain_from_mbx: get ring type & tqpid from mailbox message
+/* hclge_get_ring_chain_from_mbx: get ring type & tqp id & int_gl idx
+ * from mailbox message
* msg[0]: opcode
* msg[1]: <not relevant to this function>
* msg[2]: ring_num
* msg[3]: first ring type (TX|RX)
* msg[4]: first tqp id
- * msg[5] ~ msg[14]: other ring type and tqp id
+ * msg[5]: first int_gl idx
+ * msg[6] ~ msg[14]: other ring type, tqp id and int_gl idx
*/
static int hclge_get_ring_chain_from_mbx(
struct hclge_mbx_vf_to_pf_cmd *req,
--
2.7.4
^ permalink raw reply related
* editing
From: Simon Dike @ 2018-07-16 13:38 UTC (permalink / raw)
To: netdev
We can process 400+ images per day.
If you need any image editing, please let us know.
Photos cut out;
Photos clipping path;
Photos masking;
Photo shadow creation;
Photos retouching;
Beauty Model retouching on skin, face, body;
Glamour retouching;
Products retouching.
We can give you testing for your photos.
Turnaround time is fast
Thanks,
Simon
^ permalink raw reply
* [net-next:master 715/721] drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:172:52: sparse: incorrect type in argument 2 (different base types)
From: kbuild test robot @ 2018-07-16 15:23 UTC (permalink / raw)
To: Boris Pismenny; +Cc: kbuild-all, netdev, Ilya Lesokhin
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: aea06eb276d99590f400c877ca2bd74b4db91330
commit: ca942c78f3237e09567d80ac19dffe9690c74d79 [715/721] net/mlx5e: TLS, add innova rx support
reproduce:
# apt-get install sparse
git checkout ca942c78f3237e09567d80ac19dffe9690c74d79
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:172:52: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned int [unsigned] [usertype] handle @@ got ed int [unsigned] [usertype] handle @@
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:172:52: expected unsigned int [unsigned] [usertype] handle
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:172:52: got restricted __be32 [usertype] handle
vim +172 drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
162
163 static void mlx5e_tls_resync_rx(struct net_device *netdev, struct sock *sk,
164 u32 seq, u64 rcd_sn)
165 {
166 struct tls_context *tls_ctx = tls_get_ctx(sk);
167 struct mlx5e_priv *priv = netdev_priv(netdev);
168 struct mlx5e_tls_offload_context_rx *rx_ctx;
169
170 rx_ctx = mlx5e_get_tls_rx_context(tls_ctx);
171
> 172 mlx5_accel_tls_resync_rx(priv->mdev, rx_ctx->handle, seq, rcd_sn);
173 }
174
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH net] ibmvnic: Fix error recovery on login failure
From: John Allen @ 2018-07-16 15:29 UTC (permalink / raw)
To: tlfalcon, netdev; +Cc: John Allen
Testing has uncovered a failure case that is not handled properly. In the
event that a login fails and we are not able to recover on the spot, we
return 0 from do_reset, preventing any error recovery code from being
triggered. Additionally, the state is set to "probed" meaning that when we
are able to trigger the error recovery, the driver always comes up in the
probed state. To handle the case properly, we need to return a failure code
here and set the adapter state to the state that we entered the reset in
indicating the state that we would like to come out of the recovery reset
in.
Signed-off-by: John Allen <jallen@linux.vnet.ibm.com>
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index d0e196b..c1e23bb 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1825,8 +1825,8 @@ static int do_reset(struct ibmvnic_adapter *adapter,
rc = ibmvnic_login(netdev);
if (rc) {
- adapter->state = VNIC_PROBED;
- return 0;
+ adapter->state = reset_state;
+ return rc;
}
if (adapter->reset_reason == VNIC_RESET_CHANGE_PARAM ||
^ permalink raw reply related
* Re: [RFC] Add BPF_SYNCHRONIZE bpf(2) command
From: Daniel Colascione @ 2018-07-16 15:29 UTC (permalink / raw)
To: Joel Fernandes
Cc: Alexei Starovoitov, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Joel Fernandes, Alexei Starovoitov, lkml,
Tim Murray, Daniel Borkmann, netdev
In-Reply-To: <20180714181815.GA199777@joelaf.mtv.corp.google.com>
On Sat, Jul 14, 2018 at 11:18 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
> On Tue, Jul 10, 2018 at 08:40:19PM -0700, Alexei Starovoitov wrote:
> [..]
>> > The kernel program might do:
>> >
>> > =====
>> > const int current_map_key = 1;
>> > void *current_map = bpf_map_lookup_elem(outer_map, ¤t_map_key);
>> >
>> > int stats_key = 42;
>> > uint64_t *stats_value = bpf_map_lookup_elem(current_map, &stats_key);
>> > __sync_fetch_and_add(&stats_value, 1);
>> > =====
>> >
>> > If a userspace does:
>> >
>> > 1. Write new fd to outer_map[1].
>> > 2. Call BPF_SYNC_MAP_ACCESS.
>> > 3. Start deleting everything in the old map.
>> >
>> > How can we guarantee that the __sync_fetch_and_add will not add to the
>> > old map?
>>
>> without any changes to the kernel sys_membarrier will work.
>> And that's what folks use already.
>> BPF_SYNC_MAP_ACCESS implemented via synchronize_rcu() will work
>> as well whether in the current implementation where rcu_lock/unlock
>> is done outside of the program and in the future when
>> rcu_lock/unlock are called by the program itself.
>
> Cool Alexei and Lorenzo, sounds great to me. Daniel want to send a follow up
> patch with BPF_SYNC_MAP_ACCESS changes then?
Will do. Mind if I just mine this thread for the doc comment?
^ permalink raw reply
* Re: [net-next, 2/3] tcp: convert icsk_user_timeout from jiffies to msecs
From: Eric Dumazet @ 2018-07-16 15:58 UTC (permalink / raw)
To: Jon Maxwell, davem
Cc: edumazet, ncardwell, David.Laight, kuznet, yoshfuji, netdev,
linux-kernel, jmaxwell
In-Reply-To: <20180713000241.17608-1-jmaxwell37@gmail.com>
On 07/12/2018 05:02 PM, Jon Maxwell wrote:
> Create a seperate helper routine called tcp_retransmit_stamp() as per Neal
> Cardwells suggestion. To be used by the final commit in this series and
> retransmits_timed_out().
>
> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
> ---
> net/ipv4/tcp_timer.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index fa34984d0b12..8ab8c9645294 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -22,6 +22,20 @@
> #include <linux/gfp.h>
> #include <net/tcp.h>
>
> +u32 tcp_retransmit_stamp(const struct sock *sk)
> +{
> + u32 start_ts = tcp_sk(sk)->retrans_stamp;
> +
> + if (unlikely(!start_ts)) {
> + struct sk_buff *head = tcp_rtx_queue_head(sk);
> +
> + if (!head)
> + return 0;
> + start_ts = tcp_skb_timestamp(head);
> + }?
Indentation is fuzzy.
Can you send a new version, with a cover letter ?
git format-patch -o ../output --cover-letter --subject-prefix "PATCH net-next" origin
...
Thanks !
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox