* [PATCH net-next] cxgb4: display number of rx and tx pages free
From: Ganesh Goudar @ 2018-07-18 12:06 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Ganesh Goudar, Casey Leedom
display free rx and tx page count in the meminfo of
an adapter.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 22 +++++++++++++++-------
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 14 ++++++++++++++
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 511606f..631b78b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -2858,6 +2858,7 @@ static int meminfo_show(struct seq_file *seq, void *v)
{
static const char * const memory[] = { "EDC0:", "EDC1:", "MC:",
"MC0:", "MC1:", "HMA:"};
+ unsigned int free_rx_cnt, free_tx_cnt;
struct adapter *adap = seq->private;
struct cudbg_meminfo meminfo;
int i, rc;
@@ -2889,13 +2890,20 @@ static int meminfo_show(struct seq_file *seq, void *v)
mem_region_show(seq, "uP Extmem2:", meminfo.up_extmem2_lo,
meminfo.up_extmem2_hi);
- seq_printf(seq, "\n%u Rx pages of size %uKiB for %u channels\n",
- meminfo.rx_pages_data[0], meminfo.rx_pages_data[1],
- meminfo.rx_pages_data[2]);
-
- seq_printf(seq, "%u Tx pages of size %u%ciB for %u channels\n",
- meminfo.tx_pages_data[0], meminfo.tx_pages_data[1],
- meminfo.tx_pages_data[2], meminfo.tx_pages_data[3]);
+ for (i = 0, free_rx_cnt = 0; i < 2; i++)
+ free_rx_cnt += FREERXPAGECOUNT_G
+ (t4_read_reg(adap, TP_FLM_FREE_RX_CNT_A));
+ seq_printf(seq, "\n%u Rx pages (%u free) of size %uKiB for %u channels\n",
+ meminfo.rx_pages_data[0], free_rx_cnt,
+ meminfo.rx_pages_data[1], meminfo.rx_pages_data[2]);
+
+ for (i = 0, free_tx_cnt = 0; i < 4; i++)
+ free_tx_cnt += FREETXPAGECOUNT_G
+ (t4_read_reg(adap, TP_FLM_FREE_TX_CNT_A));
+ seq_printf(seq, "%u Tx pages (%u free) of size %u%ciB for %u channels\n",
+ meminfo.tx_pages_data[0], free_tx_cnt,
+ meminfo.tx_pages_data[1], meminfo.tx_pages_data[2],
+ meminfo.tx_pages_data[3]);
seq_printf(seq, "%u p-structs\n\n", meminfo.p_structs);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
index 446aaff..da88588 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
@@ -1502,6 +1502,20 @@
#define TP_MIB_DATA_A 0x7e54
#define TP_INT_CAUSE_A 0x7e74
+#define TP_FLM_FREE_RX_CNT_A 0x7e84
+
+#define FREERXPAGECOUNT_S 0
+#define FREERXPAGECOUNT_M 0x1fffffU
+#define FREERXPAGECOUNT_V(x) ((x) << FREERXPAGECOUNT_S)
+#define FREERXPAGECOUNT_G(x) (((x) >> FREERXPAGECOUNT_S) & FREERXPAGECOUNT_M)
+
+#define TP_FLM_FREE_TX_CNT_A 0x7e88
+
+#define FREETXPAGECOUNT_S 0
+#define FREETXPAGECOUNT_M 0x1fffffU
+#define FREETXPAGECOUNT_V(x) ((x) << FREETXPAGECOUNT_S)
+#define FREETXPAGECOUNT_G(x) (((x) >> FREETXPAGECOUNT_S) & FREETXPAGECOUNT_M)
+
#define FLMTXFLSTEMPTY_S 30
#define FLMTXFLSTEMPTY_V(x) ((x) << FLMTXFLSTEMPTY_S)
#define FLMTXFLSTEMPTY_F FLMTXFLSTEMPTY_V(1U)
--
2.1.0
^ permalink raw reply related
* Re: INFO: task hung in vfs_removexattr
From: Dmitry Vyukov @ 2018-07-18 11:45 UTC (permalink / raw)
To: syzbot, Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David Miller, v9fs-developer, netdev
Cc: linux-fsdevel, LKML, syzkaller-bugs, Al Viro
In-Reply-To: <CACT4Y+YJmoeBtdg6KB38pOHWiuFLGxgbkD5v4Oex2rbuxN=YWQ@mail.gmail.com>
On Mon, Jul 9, 2018 at 7:08 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Jul 9, 2018 at 7:07 PM, syzbot
> <syzbot+9d0373cdac2be4979750@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 1e4b044d2251 Linux 4.18-rc4
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=14dc81b2400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
>> dashboard link: https://syzkaller.appspot.com/bug?extid=9d0373cdac2be4979750
>> 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+9d0373cdac2be4979750@syzkaller.appspotmail.com
>
> This looks suspiciously similar to "INFO: task hung in vfs_setxattr":
> https://syzkaller.appspot.com/bug?id=719b006d5ff2c98e95b3db1d442771de9fcbfb93
>
> Also caused by 9p program:
>
> 14:02:00 executing program 5:
> pipe2$9p(&(0x7f0000000100)={<r0=>0xffffffffffffffff,
> <r1=>0xffffffffffffffff}, 0x0)
> write$P9_RUNLINKAT(r1, &(0x7f0000000040)={0xffffffffffffffca, 0x4d}, 0x7)
> mkdir(&(0x7f0000000140)='./file0\x00', 0x0)
> mount$9p_fd(0x0, &(0x7f00000000c0)='./file0\x00',
> &(0x7f0000000340)='9p\x00', 0x0, &(0x7f00000001c0)={'trans=fd,',
> {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c})
> write$P9_RREADDIR(r1, &(0x7f0000000480)={0x2a, 0x29, 0x1, {0x0, [{{},
> 0x0, 0x0, 0x7, './file0'}]}}, 0x2a)
> write$P9_RGETATTR(r1, &(0x7f0000000200)={0xa0, 0x19, 0x1}, 0xa0)
> write$P9_RREADDIR(r1, &(0x7f00000004c0)={0x313, 0x29, 0x1, {0x0,
> [{{0x2, 0x3, 0x7}, 0x10001, 0x3, 0x7, './file0'}, {{0x1d, 0x4, 0x5},
> 0x100000000, 0x8, 0x7, './file1'}, {{0x4, 0x2, 0x4}, 0x3, 0x6, 0x7,
> './file0'}, {{0x120, 0x2, 0x2}, 0x979, 0x4, 0x7, './file0'},
> {{0x4f5f4daf2e09cfcf, 0x4, 0x6}, 0x1000, 0x1, 0x7, './file0'}, {{0x82,
> 0x1, 0x2}, 0x5, 0x2, 0x7, './file0'}, {{0x40, 0x1, 0x7}, 0x2, 0x6,
> 0x7, './file0'}, {{0x40, 0x1, 0x2}, 0x7fffffff, 0x983d, 0x7,
> './file0'}, {{0x40, 0x3, 0x4}, 0x2, 0x5, 0x7, './file0'}, {{0x60, 0x1,
> 0x3}, 0x7ff, 0x7, 0x7, './file0'}]}}, 0x141)
> r2 = openat$pfkey(0xffffffffffffff9c,
> &(0x7f0000000300)='/proc/self/net/pfkey\x00', 0x1, 0x0)
> bind(r2, &(0x7f0000000780)=@ethernet={0x306, @broadcast=[0xff, 0xff,
> 0xff, 0xff, 0xff, 0xff]}, 0x80)
> write$P9_RWSTAT(r1, &(0x7f00000002c0)={0x7, 0x7f, 0x1}, 0x7)
> mount$9p_fd(0x0, &(0x7f0000000000)='./file0\x00',
> &(0x7f0000000900)='9p\x00', 0x0, &(0x7f0000000840)={'trans=fd,',
> {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c,
> {[{@access_uid={'access', 0x3d}, 0x2c}]}})
> removexattr(&(0x7f0000000380)='./file0\x00',
> &(0x7f0000000400)=@known='system.posix_acl_default\x00')
> r3 = syz_open_dev$midi(&(0x7f0000000080)='/dev/midi#\x00', 0x1ff, 0x400)
> r4 = fcntl$getown(r1, 0x9)
> accept4$alg(r2, 0x0, 0x0, 0x0)
> ioctl$SNDRV_CTL_IOCTL_ELEM_INFO(r3, 0xc1105511,
> &(0x7f0000000640)={{0x4, 0x1, 0x81, 0x5b94, '\x00', 0x3b2}, 0x2, 0x1,
> 0x90, r4, 0x3, 0x8, 'syz0\x00', &(0x7f0000000180)=['\x00', '+@,\x00',
> ')\x00'], 0x7, [], [0x6, 0x10000, 0x2, 0x8]})
#syz dup: INFO: task hung in flush_work
>> netlink: 16 bytes leftover after parsing attributes in process
>> `syz-executor0'.
>> netlink: 16 bytes leftover after parsing attributes in process
>> `syz-executor0'.
>> INFO: task syz-executor5:14548 blocked for more than 140 seconds.
>> Not tainted 4.18.0-rc4+ #138
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> syz-executor5 D24752 14548 4547 0x00000004
>> Call Trace:
>> context_switch kernel/sched/core.c:2853 [inline]
>> __schedule+0x87c/0x1ed0 kernel/sched/core.c:3501
>> schedule+0xfb/0x450 kernel/sched/core.c:3545
>> __rwsem_down_write_failed_common+0x95d/0x1630
>> kernel/locking/rwsem-xadd.c:566
>> rwsem_down_write_failed+0xe/0x10 kernel/locking/rwsem-xadd.c:595
>> call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117
>> __down_write arch/x86/include/asm/rwsem.h:142 [inline]
>> down_write+0xaa/0x130 kernel/locking/rwsem.c:72
>> inode_lock include/linux/fs.h:715 [inline]
>> vfs_removexattr+0x82/0x1c0 fs/xattr.c:391
>> removexattr+0xd3/0x130 fs/xattr.c:691
>> path_removexattr+0x1b9/0x210 fs/xattr.c:705
>> __do_sys_removexattr fs/xattr.c:719 [inline]
>> __se_sys_removexattr fs/xattr.c:716 [inline]
>> __x64_sys_removexattr+0x59/0x80 fs/xattr.c:716
>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x455e29
>> Code: cc 64 48 8b 0c 25 f8 ff ff ff 48 3b 61 10 0f 86 ab 04 00 00 48 83 ec
>> 58 48 89 6c 24 50 48 8d 6c 24 50 48 8b 44 24 60 c6 00 00 <48> 8b 4c 24 68 48
>> 89 ca 48 89 50 08 48 8b 59 20 48 01 da 31 db 31
>> RSP: 002b:00007f4465180c68 EFLAGS: 00000246 ORIG_RAX: 00000000000000c5
>> RAX: ffffffffffffffda RBX: 00007f44651816d4 RCX: 0000000000455e29
>> RDX: 0000000000000000 RSI: 0000000020000400 RDI: 0000000020000380
>> RBP: 000000000072bf48 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
>> R13: 00000000004bbfeb R14: 00000000004d1108 R15: 0000000000000001
>>
>> Showing all locks held in the system:
>> 1 lock held by khungtaskd/901:
>> #0: 00000000ebf24c36 (rcu_read_lock){....}, at:
>> debug_show_all_locks+0xd0/0x428 kernel/locking/lockdep.c:4461
>> 1 lock held by rsyslogd/4405:
>> 2 locks held by getty/4495:
>> #0: 00000000692a9d2f (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
>> drivers/tty/tty_ldsem.c:365
>> #1: 0000000072fe5412 (&ldata->atomic_read_lock){+.+.}, at:
>> n_tty_read+0x335/0x1ce0 drivers/tty/n_tty.c:2140
>> 2 locks held by getty/4496:
>> #0: 000000002b623882 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
>> drivers/tty/tty_ldsem.c:365
>> #1: 0000000056c15f7c (&ldata->atomic_read_lock){+.+.}, at:
>> n_tty_read+0x335/0x1ce0 drivers/tty/n_tty.c:2140
>> 2 locks held by getty/4497:
>> #0: 000000002c1f858b (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
>> drivers/tty/tty_ldsem.c:365
>> #1: 0000000048aba06b (&ldata->atomic_read_lock){+.+.}, at:
>> n_tty_read+0x335/0x1ce0 drivers/tty/n_tty.c:2140
>> 2 locks held by getty/4498:
>> #0: 00000000da02f89a (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
>> drivers/tty/tty_ldsem.c:365
>> #1: 000000004a06c40f (&ldata->atomic_read_lock){+.+.}, at:
>> n_tty_read+0x335/0x1ce0 drivers/tty/n_tty.c:2140
>> 2 locks held by getty/4499:
>> #0: 0000000017508207 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
>> drivers/tty/tty_ldsem.c:365
>> #1: 00000000a4b24877 (&ldata->atomic_read_lock){+.+.}, at:
>> n_tty_read+0x335/0x1ce0 drivers/tty/n_tty.c:2140
>> 2 locks held by getty/4500:
>> #0: 0000000079a247d3 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
>> drivers/tty/tty_ldsem.c:365
>> #1: 000000009bcfd45d (&ldata->atomic_read_lock){+.+.}, at:
>> n_tty_read+0x335/0x1ce0 drivers/tty/n_tty.c:2140
>> 2 locks held by getty/4501:
>> #0: 00000000e73958a9 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
>> drivers/tty/tty_ldsem.c:365
>> #1: 000000007d96a629 (&ldata->atomic_read_lock){+.+.}, at:
>> n_tty_read+0x335/0x1ce0 drivers/tty/n_tty.c:2140
>> 2 locks held by syz-executor5/14500:
>> #0: 00000000ba1ef7f9 (sb_writers#19){.+.+}, at: sb_start_write
>> include/linux/fs.h:1554 [inline]
>> #0: 00000000ba1ef7f9 (sb_writers#19){.+.+}, at: mnt_want_write+0x3f/0xc0
>> fs/namespace.c:386
>> #1: 00000000e4cbde96 (&sb->s_type->i_mutex_key#25){++++}, at: inode_lock
>> include/linux/fs.h:715 [inline]
>> #1: 00000000e4cbde96 (&sb->s_type->i_mutex_key#25){++++}, at:
>> vfs_removexattr+0x82/0x1c0 fs/xattr.c:391
>> 2 locks held by syz-executor5/14548:
>> #0: 00000000ba1ef7f9 (sb_writers#19){.+.+}, at: sb_start_write
>> include/linux/fs.h:1554 [inline]
>> #0: 00000000ba1ef7f9 (sb_writers#19){.+.+}, at: mnt_want_write+0x3f/0xc0
>> fs/namespace.c:386
>> #1: 00000000e4cbde96 (&sb->s_type->i_mutex_key#25){++++}, at: inode_lock
>> include/linux/fs.h:715 [inline]
>> #1: 00000000e4cbde96 (&sb->s_type->i_mutex_key#25){++++}, at:
>> vfs_removexattr+0x82/0x1c0 fs/xattr.c:391
>>
>> =============================================
>>
>> NMI backtrace for cpu 0
>> CPU: 0 PID: 901 Comm: khungtaskd Not tainted 4.18.0-rc4+ #138
>> 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+0x1c9/0x2b4 lib/dump_stack.c:113
>> nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
>> nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
>> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
>> trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
>> check_hung_uninterruptible_tasks kernel/hung_task.c:196 [inline]
>> watchdog+0x9c4/0xf80 kernel/hung_task.c:252
>> kthread+0x345/0x410 kernel/kthread.c:246
>> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>> Sending NMI from CPU 0 to CPUs 1:
>> NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0x6/0x10
>> arch/x86/include/asm/irqflags.h:54
>>
>>
>> ---
>> 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.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000cec1940570940acf%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v2 0/5] ARM: dts: sunxi: Remove unused address-cells/size-cells of dwmac-sun8i
From: Corentin Labbe @ 2018-07-18 11:40 UTC (permalink / raw)
To: catalin.marinas, linux, mark.rutland, maxime.ripard, robh+dt,
wens, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev, linux-sunxi,
Corentin Labbe
address-cells/size-cells is unnecessary for dwmac-sun8i node.
It was in early days, but since a mdio node is used, it could be
removed.
This patch fix the following DT warning:
Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Changes since V1:
- splited patch
Corentin Labbe (5):
dt-bindings: net: dwmac-sun8i: Remove unused address-cells/size-cells
ARM: dts: sunxi-h3-h5: Remove unused address-cells/size-cells of
dwmac-sun8i
ARM: dts: sun8i: a83t: Remove unused address-cells/size-cells of
dwmac-sun8i
ARM: dts: sun8i: r40: Remove unused address-cells/size-cells of
dwmac-sun8i
ARM64: dts: sun50i: a64: Remove unused address-cells/size-cells of
dwmac-sun8i
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 8 --------
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 --
arch/arm/boot/dts/sun8i-r40.dtsi | 2 --
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 --
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 --
5 files changed, 16 deletions(-)
--
2.16.4
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Sagi Grimberg @ 2018-07-18 11:38 UTC (permalink / raw)
To: Steve Wise, 'Max Gurtovoy', 'Leon Romanovsky'
Cc: 'Doug Ledford', 'Jason Gunthorpe',
'RDMA mailing list', 'Saeed Mahameed',
'linux-netdev'
In-Reply-To: <01cd01d41dce$992f4f30$cb8ded90$@opengridcomputing.com>
>> IMO we must fulfil the user wish to connect to N queues and not reduce
>> it because of affinity overlaps. So in order to push Leon's patch we
>> must also fix the blk_mq_rdma_map_queues to do a best effort mapping
>> according the affinity and map the rest in naive way (in that way we
>> will *always* map all the queues).
>
> That is what I would expect also. For example, in my node, where there are
> 16 cpus, and 2 numa nodes, I observe much better nvmf IOPS performance by
> setting up my 16 driver completion event queues such that each is bound to a
> node-local cpu. So I end up with each nodel-local cpu having 2 queues bound
> to it. W/O adding support in iw_cxgb4 for ib_get_vector_affinity(), this
> works fine. I assumed adding ib_get_vector_affinity() would allow this to
> all "just work" by default, but I'm running into this connection failure
> issue.
>
> I don't understand exactly what the blk_mq layer is trying to do, but I
> assume it has ingress event queues and processing that it trying to align
> with the drivers ingress cq event handling, so everybody stays on the same
> cpu (or at least node). But something else is going on. Is there
> documentation on how this works somewhere?
Does this (untested) patch help?
--
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 3eb169f15842..dbe962cb537d 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -30,29 +30,34 @@ static int get_first_sibling(unsigned int cpu)
return cpu;
}
-int blk_mq_map_queues(struct blk_mq_tag_set *set)
+void blk_mq_map_queue(struct blk_mq_tag_set *set, unsigned int cpu)
{
unsigned int *map = set->mq_map;
unsigned int nr_queues = set->nr_hw_queues;
- unsigned int cpu, first_sibling;
+ unsigned int first_sibling;
- for_each_possible_cpu(cpu) {
- /*
- * First do sequential mapping between CPUs and queues.
- * In case we still have CPUs to map, and we have some
number of
- * threads per cores then map sibling threads to the
same queue for
- * performace optimizations.
- */
- if (cpu < nr_queues) {
+ /*
+ * First do sequential mapping between CPUs and queues.
+ * In case we still have CPUs to map, and we have some number of
+ * threads per cores then map sibling threads to the same queue for
+ * performace optimizations.
+ */
+ if (cpu < nr_queues) {
+ map[cpu] = cpu_to_queue_index(nr_queues, cpu);
+ } else {
+ first_sibling = get_first_sibling(cpu);
+ if (first_sibling == cpu)
map[cpu] = cpu_to_queue_index(nr_queues, cpu);
- } else {
- first_sibling = get_first_sibling(cpu);
- if (first_sibling == cpu)
- map[cpu] = cpu_to_queue_index(nr_queues,
cpu);
- else
- map[cpu] = map[first_sibling];
- }
+ else
+ map[cpu] = map[first_sibling];
}
+}
+EXPORT_SYMBOL_GPL(blk_mq_map_queue);
+
+int blk_mq_map_queues(struct blk_mq_tag_set *set)
+{
+ for_each_possible_cpu(cpu)
+ blk_mq_map_queue(set, cpu);
return 0;
}
diff --git a/block/blk-mq-rdma.c b/block/blk-mq-rdma.c
index 996167f1de18..5e91789bea5b 100644
--- a/block/blk-mq-rdma.c
+++ b/block/blk-mq-rdma.c
@@ -35,6 +35,10 @@ int blk_mq_rdma_map_queues(struct blk_mq_tag_set *set,
const struct cpumask *mask;
unsigned int queue, cpu;
+ /* reset all to */
+ for_each_possible_cpu(cpu)
+ set->mq_map[cpu] = UINT_MAX;
+
for (queue = 0; queue < set->nr_hw_queues; queue++) {
mask = ib_get_vector_affinity(dev, first_vec + queue);
if (!mask)
@@ -44,6 +48,11 @@ int blk_mq_rdma_map_queues(struct blk_mq_tag_set *set,
set->mq_map[cpu] = queue;
}
+ for_each_possible_cpu(cpu) {
+ if (set->mq_map[cpu] == UINT_MAX)
+ blk_mq_map_queue(set, cpu);
+ }
+
return 0;
fallback:
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index e3147eb74222..7a9848a82475 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -283,6 +283,7 @@ int blk_mq_freeze_queue_wait_timeout(struct
request_queue *q,
unsigned long timeout);
int blk_mq_map_queues(struct blk_mq_tag_set *set);
+void blk_mq_map_queue(struct blk_mq_tag_set *set, unsigned int cpu);
void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int
nr_hw_queues);
void blk_mq_quiesce_queue_nowait(struct request_queue *q);
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Use lock_sock_nested in bt_accept_enqueue
From: Marcel Holtmann @ 2018-07-18 12:11 UTC (permalink / raw)
To: Philipp Puschmann
Cc: Johan Hedberg, David S. Miller, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <20180717114112.857-1-pp@emlix.com>
Hi Philipp,
> Fixes this warning that was provoked by a pairing:
>
> [60258.016221] WARNING: possible recursive locking detected
> [60258.021558] 4.15.0-RD1812-BSP #1 Tainted: G O
> [60258.027146] --------------------------------------------
> [60258.032464] kworker/u5:0/70 is trying to acquire lock:
> [60258.037609] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<87759073>] bt_accept_enqueue+0x3c/0x74
> [60258.046863]
> [60258.046863] but task is already holding lock:
> [60258.052704] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<d22d7106>] l2cap_sock_new_connection_cb+0x1c/0x88
> [60258.062905]
> [60258.062905] other info that might help us debug this:
> [60258.069441] Possible unsafe locking scenario:
> [60258.069441]
> [60258.075368] CPU0
> [60258.077821] ----
> [60258.080272] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [60258.085510] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [60258.090748]
> [60258.090748] *** DEADLOCK ***
> [60258.090748]
> [60258.096676] May be due to missing lock nesting notation
> [60258.096676]
> [60258.103472] 5 locks held by kworker/u5:0/70:
> [60258.107747] #0: ((wq_completion)%shdev->name#2){+.+.}, at: [<9460d092>] process_one_work+0x130/0x4fc
> [60258.117263] #1: ((work_completion)(&hdev->rx_work)){+.+.}, at: [<9460d092>] process_one_work+0x130/0x4fc
> [60258.126942] #2: (&conn->chan_lock){+.+.}, at: [<7877c8c3>] l2cap_connect+0x80/0x4f8
> [60258.134806] #3: (&chan->lock/2){+.+.}, at: [<2e16c724>] l2cap_connect+0x8c/0x4f8
> [60258.142410] #4: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<d22d7106>] l2cap_sock_new_connection_cb+0x1c/0x88
> [60258.153043]
> [60258.153043] stack backtrace:
> [60258.157413] CPU: 1 PID: 70 Comm: kworker/u5:0 Tainted: G O 4.15.0-RD1812-BSP #1
> [60258.165945] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [60258.172485] Workqueue: hci0 hci_rx_work
> [60258.176331] Backtrace:
> [60258.178797] [<8010c9fc>] (dump_backtrace) from [<8010ccbc>] (show_stack+0x18/0x1c)
> [60258.186379] r7:80e55fe4 r6:80e55fe4 r5:20050093 r4:00000000
> [60258.192058] [<8010cca4>] (show_stack) from [<809864e8>] (dump_stack+0xb0/0xdc)
> [60258.199301] [<80986438>] (dump_stack) from [<8016ecc8>] (__lock_acquire+0xffc/0x11d4)
> [60258.207144] r9:5e2bb019 r8:630f974c r7:ba8a5940 r6:ba8a5ed8 r5:815b5220 r4:80fa081c
> [60258.214901] [<8016dccc>] (__lock_acquire) from [<8016f620>] (lock_acquire+0x78/0x98)
> [60258.222655] r10:00000040 r9:00000040 r8:808729f0 r7:00000001 r6:00000000 r5:60050013
> [60258.230491] r4:00000000
> [60258.233045] [<8016f5a8>] (lock_acquire) from [<806ee974>] (lock_sock_nested+0x64/0x88)
> [60258.240970] r7:00000000 r6:b796e870 r5:00000001 r4:b796e800
> [60258.246643] [<806ee910>] (lock_sock_nested) from [<808729f0>] (bt_accept_enqueue+0x3c/0x74)
> [60258.255004] r8:00000001 r7:ba7d3c00 r6:ba7d3ea4 r5:ba7d2000 r4:b796e800
> [60258.261717] [<808729b4>] (bt_accept_enqueue) from [<808aa39c>] (l2cap_sock_new_connection_cb+0x68/0x88)
> [60258.271117] r5:b796e800 r4:ba7d2000
> [60258.274708] [<808aa334>] (l2cap_sock_new_connection_cb) from [<808a294c>] (l2cap_connect+0x190/0x4f8)
> [60258.283933] r5:00000001 r4:ba6dce00
> [60258.287524] [<808a27bc>] (l2cap_connect) from [<808a4a14>] (l2cap_recv_frame+0x744/0x2cf8)
> [60258.295800] r10:ba6dcf24 r9:00000004 r8:b78d8014 r7:00000004 r6:bb05d000 r5:00000004
> [60258.303635] r4:bb05d008
> [60258.306183] [<808a42d0>] (l2cap_recv_frame) from [<808a7808>] (l2cap_recv_acldata+0x210/0x214)
> [60258.314805] r10:b78e7800 r9:bb05d960 r8:00000001 r7:bb05d000 r6:0000000c r5:b7957a80
> [60258.322641] r4:ba6dce00
> [60258.325188] [<808a75f8>] (l2cap_recv_acldata) from [<8087630c>] (hci_rx_work+0x35c/0x4e8)
> [60258.333374] r6:80e5743c r5:bb05d7c8 r4:b7957a80
> [60258.338004] [<80875fb0>] (hci_rx_work) from [<8013dc7c>] (process_one_work+0x1a4/0x4fc)
> [60258.346018] r10:00000001 r9:00000000 r8:baabfef8 r7:ba997500 r6:baaba800 r5:baaa5d00
> [60258.353853] r4:bb05d7c8
> [60258.356401] [<8013dad8>] (process_one_work) from [<8013e028>] (worker_thread+0x54/0x5cc)
> [60258.364503] r10:baabe038 r9:baaba834 r8:80e05900 r7:00000088 r6:baaa5d18 r5:baaba800
> [60258.372338] r4:baaa5d00
> [60258.374888] [<8013dfd4>] (worker_thread) from [<801448f8>] (kthread+0x134/0x160)
> [60258.382295] r10:ba8310b8 r9:bb07dbfc r8:8013dfd4 r7:baaa5d00 r6:00000000 r5:baaa8ac0
> [60258.390130] r4:ba831080
> [60258.392682] [<801447c4>] (kthread) from [<801080b4>] (ret_from_fork+0x14/0x20)
> [60258.399915] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801447c4
> [60258.407751] r4:baaa8ac0 r3:baabe000
>
> Signed-off-by: Philipp Puschmann <pp@emlix.com>
> ---
> net/bluetooth/af_bluetooth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: INFO: task hung in tls_push_record
From: Dmitry Vyukov @ 2018-07-18 11:52 UTC (permalink / raw)
To: syzbot, Herbert Xu,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Jaegeuk Kim
Cc: aviadye, borisp, davejwatson, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <000000000000dde753056c9995b3@google.com>
On Sun, May 20, 2018 at 4:03 AM, syzbot
<syzbot+4006516aae0b06e7050f@syzkaller.appspotmail.com> wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: eb38401c779d net: stmmac: Populate missing callbacks in HW..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16d0820f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
> dashboard link: https://syzkaller.appspot.com/bug?extid=4006516aae0b06e7050f
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10f6927b800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15b7a20f800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4006516aae0b06e7050f@syzkaller.appspotmail.com
Still happens.
Perhaps this is crypto-related, not net-related? That's why net
maintainers are not looking at this? +crypto maintainers
> INFO: task syz-executor793:4489 blocked for more than 120 seconds.
> Not tainted 4.17.0-rc4+ #52
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> syz-executor793 D23464 4489 4486 0x00000000
> Call Trace:
> context_switch kernel/sched/core.c:2848 [inline]
> __schedule+0x801/0x1e30 kernel/sched/core.c:3490
> schedule+0xef/0x430 kernel/sched/core.c:3549
> schedule_timeout+0x1b5/0x240 kernel/time/timer.c:1777
> do_wait_for_common kernel/sched/completion.c:83 [inline]
> __wait_for_common kernel/sched/completion.c:104 [inline]
> wait_for_common kernel/sched/completion.c:115 [inline]
> wait_for_completion+0x3e7/0x870 kernel/sched/completion.c:136
> crypto_wait_req include/linux/crypto.h:512 [inline]
> tls_do_encryption net/tls/tls_sw.c:217 [inline]
> tls_push_record+0xedc/0x13e0 net/tls/tls_sw.c:248
> tls_sw_sendmsg+0x8d7/0x12b0 net/tls/tls_sw.c:440
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> __sys_sendto+0x3d7/0x670 net/socket.c:1789
> __do_sys_sendto net/socket.c:1801 [inline]
> __se_sys_sendto net/socket.c:1797 [inline]
> __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4457d9
> RSP: 002b:00007fa388d06da8 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
> RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004457d9
> RDX: 00000000fffffdef RSI: 00000000200005c0 RDI: 0000000000000022
> RBP: 00000000006dac20 R08: 0000000020000000 R09: 000000000000001c
> R10: 0000000000000000 R11: 0000000000000216 R12: 0000000000000000
> R13: 00007ffd5148ecaf R14: 00007fa388d079c0 R15: 0000000000000001
>
> Showing all locks held in the system:
> 2 locks held by khungtaskd/892:
> #0: 000000009dfaae0c (rcu_read_lock){....}, at:
> check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
> #0: 000000009dfaae0c (rcu_read_lock){....}, at: watchdog+0x1ff/0xf60
> kernel/hung_task.c:249
> #1: 0000000058f79a8d (tasklist_lock){.+.+}, at:
> debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470
> 1 lock held by rsyslogd/4370:
> #0: 0000000059c3c7ae (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x1a9/0x1e0
> fs/file.c:766
> 2 locks held by getty/4460:
> #0: 00000000e25a52c3 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
> drivers/tty/tty_ldsem.c:365
> #1: 000000002caea50f (&ldata->atomic_read_lock){+.+.}, at:
> n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4461:
> #0: 00000000d38c9806 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
> drivers/tty/tty_ldsem.c:365
> #1: 00000000eaffe99d (&ldata->atomic_read_lock){+.+.}, at:
> n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4462:
> #0: 00000000cec6abe7 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
> drivers/tty/tty_ldsem.c:365
> #1: 0000000000afd91c (&ldata->atomic_read_lock){+.+.}, at:
> n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4463:
> #0: 000000003456fca5 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
> drivers/tty/tty_ldsem.c:365
> #1: 0000000038a65d91 (&ldata->atomic_read_lock){+.+.}, at:
> n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4464:
> #0: 0000000001e783b1 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
> drivers/tty/tty_ldsem.c:365
> #1: 000000003ecd2e34 (&ldata->atomic_read_lock){+.+.}, at:
> n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4465:
> #0: 000000007ef8b451 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
> drivers/tty/tty_ldsem.c:365
> #1: 000000006996c3ed (&ldata->atomic_read_lock){+.+.}, at:
> n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4466:
> #0: 00000000d15d9a92 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
> drivers/tty/tty_ldsem.c:365
> #1: 00000000ee44bcf4 (&ldata->atomic_read_lock){+.+.}, at:
> n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
> 1 lock held by syz-executor793/4489:
> #0: 0000000008c84b0d (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 0000000008c84b0d (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4494:
> #0: 00000000f2de7555 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000f2de7555 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4499:
> #0: 0000000058a54751 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 0000000058a54751 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4504:
> #0: 0000000045694cb9 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 0000000045694cb9 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4509:
> #0: 00000000b663e61f (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000b663e61f (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4514:
> #0: 00000000603baf06 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000603baf06 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4519:
> #0: 00000000344afb7e (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000344afb7e (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4524:
> #0: 000000004aa3e1ce (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 000000004aa3e1ce (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4529:
> #0: 00000000b6c4b2ea (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000b6c4b2ea (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4534:
> #0: 000000005bae881e (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 000000005bae881e (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4539:
> #0: 000000004b04f235 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 000000004b04f235 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4544:
> #0: 00000000b5888be7 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000b5888be7 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4549:
> #0: 00000000e902c819 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000e902c819 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4554:
> #0: 000000009cd1d95e (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 000000009cd1d95e (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4559:
> #0: 000000001f3edf17 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 000000001f3edf17 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
> 1 lock held by syz-executor793/4563:
> #0: 00000000802085f8 (sk_lock-AF_INET6){+.+.}, at: lock_sock
> include/net/sock.h:1474 [inline]
> #0: 00000000802085f8 (sk_lock-AF_INET6){+.+.}, at:
> tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384
>
> =============================================
>
> NMI backtrace for cpu 0
> CPU: 0 PID: 892 Comm: khungtaskd Not tainted 4.17.0-rc4+ #52
> 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+0x1b9/0x294 lib/dump_stack.c:113
> nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
> check_hung_task kernel/hung_task.c:132 [inline]
> check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
> watchdog+0xc10/0xf60 kernel/hung_task.c:249
> kthread+0x345/0x410 kernel/kthread.c:238
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
> Sending NMI from CPU 0 to CPUs 1:
> NMI backtrace for cpu 1
> CPU: 1 PID: 4486 Comm: sshd Not tainted 4.17.0-rc4+ #52
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__debug_object_init+0x25/0x12c0 lib/debugobjects.c:371
> RSP: 0018:ffff8801b30f73d0 EFLAGS: 00000a02
> RAX: 1ffff1003661ee3d RBX: ffff8801b30f7440 RCX: ffffffff877175fb
> RDX: 0000000000000001 RSI: ffffffff88d9a5e0 RDI: ffff8801b30f7440
> RBP: ffff8801b30f73f0 R08: ffff8801b0a10740 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801b30f73c8
> R13: dffffc0000000000 R14: ffff8801b30f74c0 R15: 0000000000000001
> FS: 00007f15863b87c0(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f38c25af9ce CR3: 00000001d0b17000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> debug_object_init_on_stack+0x19/0x20 lib/debugobjects.c:444
> hrtimer_init_on_stack kernel/time/hrtimer.c:435 [inline]
> schedule_hrtimeout_range_clock+0xcc/0x470 kernel/time/hrtimer.c:1936
> schedule_hrtimeout_range+0x2a/0x40 kernel/time/hrtimer.c:1989
> poll_schedule_timeout+0x11a/0x200 fs/select.c:243
> do_select+0x1606/0x1ae0 fs/select.c:581
> core_sys_select+0x768/0xb60 fs/select.c:655
> kern_select+0x1b7/0x250 fs/select.c:696
> __do_sys_select fs/select.c:705 [inline]
> __se_sys_select fs/select.c:702 [inline]
> __x64_sys_select+0xbe/0x150 fs/select.c:702
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x7f1584758dd3
> RSP: 002b:00007ffe596ca1f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000017
> RAX: ffffffffffffffda RBX: 00007ffe596ca280 RCX: 00007f1584758dd3
> RDX: 000055a15612aab0 RSI: 000055a15612aad0 RDI: 000000000000000c
> RBP: 000055a1559bf8dc R08: 00007ffe596ca220 R09: 0101010101010101
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe596ca288
> R13: 0000000000000000 R14: 00007ffe596ca278 R15: 00007ffe596ca27c
> Code: 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 48 8d 85 f8 fd ff ff 41 55
> 48 c1 e8 03 49 bd 00 00 00 00 00 fc ff df 41 54 4c 8d 65 d8 <53> 48 89 fb 48
> 81 ec 30 02 00 00 48 89 85 d8 fd ff ff 4c 01 e8
^ permalink raw reply
* [PATCH v2 5/5] ARM64: dts: sun50i: a64: Remove unused address-cells/size-cells of dwmac-sun8i
From: Corentin Labbe @ 2018-07-18 11:40 UTC (permalink / raw)
To: catalin.marinas, linux, mark.rutland, maxime.ripard, robh+dt,
wens, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev, linux-sunxi,
Corentin Labbe
In-Reply-To: <1531914041-14751-1-git-send-email-clabbe@baylibre.com>
address-cells/size-cells is unnecessary for dwmac-sun8i node.
It was in early days, but since a mdio node is used, it could be
removed.
This patch fix the following DT warning:
Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 91dd5dd9e205..357f6cba00cd 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -668,8 +668,6 @@
clocks = <&ccu CLK_BUS_EMAC>;
clock-names = "stmmaceth";
status = "disabled";
- #address-cells = <1>;
- #size-cells = <0>;
mdio: mdio {
compatible = "snps,dwmac-mdio";
--
2.16.4
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: sun8i: r40: Remove unused address-cells/size-cells of dwmac-sun8i
From: Corentin Labbe @ 2018-07-18 11:40 UTC (permalink / raw)
To: catalin.marinas, linux, mark.rutland, maxime.ripard, robh+dt,
wens, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev, linux-sunxi,
Corentin Labbe
In-Reply-To: <1531914041-14751-1-git-send-email-clabbe@baylibre.com>
address-cells/size-cells is unnecessary for dwmac-sun8i node.
It was in early days, but since a mdio node is used, it could be
removed.
This patch fix the following DT warning:
Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 38a3e0dbc824..1e680e4fee60 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -576,8 +576,6 @@
reset-names = "stmmaceth";
clocks = <&ccu CLK_BUS_GMAC>;
clock-names = "stmmaceth";
- #address-cells = <1>;
- #size-cells = <0>;
status = "disabled";
gmac_mdio: mdio {
--
2.16.4
^ permalink raw reply related
* [PATCH v2 3/5] ARM: dts: sun8i: a83t: Remove unused address-cells/size-cells of dwmac-sun8i
From: Corentin Labbe @ 2018-07-18 11:40 UTC (permalink / raw)
To: catalin.marinas, linux, mark.rutland, maxime.ripard, robh+dt,
wens, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev, linux-sunxi,
Corentin Labbe
In-Reply-To: <1531914041-14751-1-git-send-email-clabbe@baylibre.com>
ddress-cells/size-cells is unnecessary for dwmac-sun8i node.
It was in early days, but since a mdio node is used, it could be
removed.
This patch fix the following DT warning:
Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index b047f05e690d..276c99fcfcc8 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -913,8 +913,6 @@
reset-names = "stmmaceth";
clocks = <&ccu 27>;
clock-names = "stmmaceth";
- #address-cells = <1>;
- #size-cells = <0>;
status = "disabled";
mdio: mdio {
--
2.16.4
^ permalink raw reply related
* [PATCH v2 2/5] ARM: dts: sunxi-h3-h5: Remove unused address-cells/size-cells of dwmac-sun8i
From: Corentin Labbe @ 2018-07-18 11:40 UTC (permalink / raw)
To: catalin.marinas, linux, mark.rutland, maxime.ripard, robh+dt,
wens, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev, linux-sunxi,
Corentin Labbe
In-Reply-To: <1531914041-14751-1-git-send-email-clabbe@baylibre.com>
address-cells/size-cells is unnecessary for dwmac-sun8i node.
It was in early days, but since a mdio node is used, it could be
removed.
This patch fix the following DT warning:
Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 90021f38c1ef..f0352b8da19f 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -516,8 +516,6 @@
reset-names = "stmmaceth";
clocks = <&ccu CLK_BUS_EMAC>;
clock-names = "stmmaceth";
- #address-cells = <1>;
- #size-cells = <0>;
status = "disabled";
mdio: mdio {
--
2.16.4
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: net: dwmac-sun8i: Remove unused address-cells/size-cells
From: Corentin Labbe @ 2018-07-18 11:40 UTC (permalink / raw)
To: catalin.marinas, linux, mark.rutland, maxime.ripard, robh+dt,
wens, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, netdev, linux-sunxi,
Corentin Labbe
In-Reply-To: <1531914041-14751-1-git-send-email-clabbe@baylibre.com>
address-cells/size-cells is unnecessary for dwmac-sun8i node.
It was in early days, but since a mdio node is used, it could be
removed.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 8 --------
1 file changed, 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index cfe724398a12..5bb3a18cc38d 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -19,8 +19,6 @@ Required properties:
- reset-names: must be "stmmaceth"
- phy-mode: See ethernet.txt
- phy-handle: See ethernet.txt
-- #address-cells: shall be 1
-- #size-cells: shall be 0
- syscon: A phandle to the device containing the EMAC or GMAC clock register
Optional properties:
@@ -86,8 +84,6 @@ emac: ethernet@1c0b000 {
reset-names = "stmmaceth";
clocks = <&ccu CLK_BUS_EMAC>;
clock-names = "stmmaceth";
- #address-cells = <1>;
- #size-cells = <0>;
phy-handle = <&int_mii_phy>;
phy-mode = "mii";
@@ -137,8 +133,6 @@ emac: ethernet@1c0b000 {
reset-names = "stmmaceth";
clocks = <&ccu CLK_BUS_EMAC>;
clock-names = "stmmaceth";
- #address-cells = <1>;
- #size-cells = <0>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii";
@@ -191,8 +185,6 @@ emac: ethernet@1c0b000 {
reset-names = "stmmaceth";
clocks = <&ccu CLK_BUS_EMAC>;
clock-names = "stmmaceth";
- #address-cells = <1>;
- #size-cells = <0>;
phy-handle = <&ext_rgmii_phy>;
phy-mode = "rgmii";
--
2.16.4
^ permalink raw reply related
* Re: KASAN: use-after-free Read in l2tp_session_create
From: Dmitry Vyukov @ 2018-07-18 11:00 UTC (permalink / raw)
To: jchapman
Cc: David Miller, Reshetova, Elena, g.nault, Hans Liljestrand,
Kees Cook, LKML, netdev, syzkaller-bugs, Greg Hackmann, syzbot
In-Reply-To: <001a11405130a984300562e8e7b3@google.com>
On Tue, Jan 16, 2018 at 7:29 PM, syzbot
<syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzkaller hit the following crash on
> a8750ddca918032d6349adbf9a4b6555e7db20da
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> Unfortunately, I don't have any reproducer for this bug yet.
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
James,
Did you fix this? You asked syzbot to test a fix for this bug some time ago.
If yes, did you include the Reported-by tag in the commit? This bug is
still considered open by syzbot. But it stopped happening ~4 months
ago:
https://syzkaller.appspot.com/bug?id=6fed0854381422329e78d7e16fb9cf4af8c9aef1
We are also seeing these crashes in 4.4 and 4.9, it would be good to
backport the fix.
Thanks
> ==================================================================
> BUG: KASAN: use-after-free in l2tp_session_create+0xa6d/0xc60
> net/l2tp/l2tp_core.c:1757
> Read of size 4 at addr ffff8801d80ad868 by task syz-executor3/5462
>
> CPU: 0 PID: 5462 Comm: syz-executor3 Not tainted 4.15.0-rc8+ #263
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x25b/0x340 mm/kasan/report.c:409
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
> l2tp_session_create+0xa6d/0xc60 net/l2tp/l2tp_core.c:1757
> pppol2tp_connect+0xed7/0x1dd0 net/l2tp/l2tp_ppp.c:748
> SYSC_connect+0x213/0x4a0 net/socket.c:1621
> SyS_connect+0x24/0x30 net/socket.c:1602
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x452df9
> RSP: 002b:00007f93ec47fc58 EFLAGS: 00000212 ORIG_RAX: 000000000000002a
> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452df9
> RDX: 000000000000002e RSI: 00000000205fafd2 RDI: 0000000000000018
> RBP: 00000000000005a9 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6878
> R13: 00000000ffffffff R14: 00007f93ec4806d4 R15: 0000000000000000
>
> Allocated by task 5462:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3610
> kmalloc include/linux/slab.h:499 [inline]
> kzalloc include/linux/slab.h:688 [inline]
> l2tp_tunnel_create+0x5e1/0x17f0 net/l2tp/l2tp_core.c:1554
> pppol2tp_connect+0x14b7/0x1dd0 net/l2tp/l2tp_ppp.c:707
> SYSC_connect+0x213/0x4a0 net/socket.c:1621
> SyS_connect+0x24/0x30 net/socket.c:1602
> entry_SYSCALL_64_fastpath+0x29/0xa0
>
> Freed by task 5484:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> __cache_free mm/slab.c:3488 [inline]
> kfree+0xd6/0x260 mm/slab.c:3803
> __rcu_reclaim kernel/rcu/rcu.h:190 [inline]
> rcu_do_batch kernel/rcu/tree.c:2758 [inline]
> invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
> __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
> rcu_process_callbacks+0xe94/0x17f0 kernel/rcu/tree.c:2996
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>
> The buggy address belongs to the object at ffff8801d80ad780
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 232 bytes inside of
> 512-byte region [ffff8801d80ad780, ffff8801d80ad980)
> The buggy address belongs to the page:
> page:ffffea0007602b40 count:1 mapcount:0 mapping:ffff8801d80ad000 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801d80ad000 0000000000000000 0000000100000006
> raw: ffffea00070e8760 ffffea00070f8ca0 ffff8801dac00940 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801d80ad700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801d80ad780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> ffff8801d80ad800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
> ^
> ffff8801d80ad880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801d80ad900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/001a11405130a984300562e8e7b3%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 0/5] m68k: IO Fixes and Cleanups
From: Geert Uytterhoeven @ 2018-07-18 11:37 UTC (permalink / raw)
To: Greg Ungerer
Cc: Dmitry Torokhov, Helge Deller, linux-m68k, netdev, linux-input,
Linux Kernel Mailing List
In-Reply-To: <0f38c6fd-82f1-7211-3b2e-425bbd44b157@linux-m68k.org>
On Tue, Jul 10, 2018 at 3:48 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 09/07/18 19:30, Geert Uytterhoeven wrote:
> > This patch series contains fixes and cleanups for I/O accessors on m68k
> > platforms (with MMU).
> >
> > The first patch contains small fixes without any dependencies.
> > Patches 2 and 3 make small adjustments to drivers that are dependencies
> > for further cleanup.
> > Patch 4 and 5 complete the cleanup.
> >
> > Changes compared to v1:
> > - Move ARCH_HAS_IOREMAP_WT to fix "ioremap_wt redefined" warnings with
> > m5475evb defconfig,
> > - Add Acked-by.
> >
> > Given the dependencies, I think it's easiest if the respective
> > maintainers would provide their Acked-by, so all patches can go in
> > through the m68k tree.
>
> Retested on ColdFire 5475, looks good.
> For the whole series:
>
> Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Thanks, applied and queued for v4.19.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [RFC net-next 00/15] net: A socket API for LoRa
From: Ben Whitten @ 2018-07-18 11:28 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Jian-Hong Pan, Jiri Pirko,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, contact@snootlab.com, Brian Ray
In-Reply-To: <e08cdcfb-207f-bd73-2afd-f775810b72b7@suse.de>
> Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa
>
> + linux-wireless + Stefan + Seth
>
> Am 11.07.2018 um 17:21 schrieb Ben Whitten:
> >> This patchset is clearly not ready for merging, but is being
> >> submitted for
> >> discussion, as requested by Jiri, in particular of the design
> >> choices:
> >>
> >> 1) PF_LORA/AF_LORA and associated identifiers are
> >> proposed to represent
> >> this technology. While for an SX1276 - case a) above - it
> >> might work to
> >> layer LoRaWAN as a protocol option for PF_LORA and
> add
> >> LoRaWAN address
> >> fields to the union in my sockaddr_lora, how would that
> >> work for devices
> >> that only support LoRaWAN but not pure LoRa? Do we
> >> need both AF_LORA and
> >> AF_LORAWAN, or just a separate ETH_P_LORAWAN or
> >> ARPHRD_LORAWAN?
> >>
> >> 2) PF_LORA is used with SOCK_DGRAM here. The
> >> assumption is that RAW mode
> >> would be DGRAM plus preamble plus optional
> checksum.
> >>
> >> 3) Only the transmit path is partially implemented
> already.
> >> The assumption
> >> is that the devices should go into receive mode by
> default
> >> and only
> >> interrupt that when asked to transmit.
> >>
> >> 4) Some hardware settings need to be supplied
> externally,
> >> such as the radio
> >> frequency for some modules, but many others can be
> >> runtime-configured,
> >> such as Spreading Factor, Bandwidth, Sync Word, or
> which
> >> antenna to use.
> >> What settings should be implemented as socket option
> vs.
> >> netlink layer
> >> vs. ioctl vs. sysfs? What are the criteria to apply?
> >>
> >> 5) Many of the modules support multiple modes, such as
> >> LoRa, LoRaWAN and FSK.
> >> Lacking a LoRaWAN implementation, I am currently
> >> switching them into LoRa
> >> mode at probe time wherever possible. How do we
> deal
> >> with that properly?
> >>
> >> a) Is there any precedence from the Wifi world for
> >> dynamically selecting
> >> between our own trusted Open Source
> implementation
> >> vs. hardware/firmware
> >> accelerated and/or certified implementations?
> >>
> >> b) Would a proof of concept for FSK (non-LoRa) modes
> be
> >> required for
> >> merging any LoRa driver for chipsets that support
> both?
> >> Or is there any
> >> facility or design guidelines that would allow us to
> focus
> >> on LoRa and
> >> LoRaWAN and leave non-LoRa radio modes to later
> >> contributors?
> >
> > Down the line I think we should also plan for a CRDA style
> regdb somewhere in the path for raw LoRa transceivers
> operating as softMAC, much like with WiFi.
>
> Yes, I had raised the topic of wireless-regdb for Stefan's
> conference -
> currently it seems to only cover 2.4 GHz, 5 GHz and 60 GHz.
> Not sure if
> we can easily extend that to cover 433 MHz, 868 MHz, 915
> MHz and 923 MHz
> bands or whether we'd just need something similar... Is
> 802.15.4 able to
> share this database with Wifi?
Well the README in the wireless-regdb doesn't bind itself to 80211, there are references to the other ETSI EN specs so this would be the place rather than duplicating.
There would need a bit of additional information to capture duty-cycle requirements, however the SRD spec states the maximum bandwidths can be 'The whole band', so with a flag set we could hijack this band information for duty-cycle.
I am unsure if 802.15.4 uses this database, most of the naming seems geared towards 80211, nl80211, cfg80211 so perhaps we need our own versions of these with a common component, I hope the maintainers can give some guidance here.
> An argument to share with Wifi might be that Semtech's
> SX1280 and SX1281
> 2.4 GHz transceivers claim to support LoRa modulation, too.
> Having two
> different regulatory DBs interact with LoRa drivers seems a
> bad idea,
> and duplicating 2.4 GHz into a new DB doesn't sound
> appealing either.
Well I'm not sure if the modulation affects regulatory information, just bands, power, and techniques like DFS.
As these chips are 2.4GHz only I expect they are bound by the existing regulatory information we would just need a path to access it.
> https://www.semtech.com/products/wireless-rf/24-ghz-
> transceivers
>
> Meanwhile my attempt to play with netlink during SUSE
> Hackweek has been
> going slow and I could use some guidance or a volunteer to
> contribute: I
> have a bare skeleton of registration, commands, attributes
> and multicast
> groups, but no plan yet how to connect that to the actual
> drivers to
> query or apply the settings...
Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal.
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li
> nux-lora.git/tree/net/lora/netlink.c?h=lora-next
>
> > LoRa radios used in Gateway devices are typically relatively
> high power (capable of 27dBm) and operate in bands with
> certain restrictions, eg the EU has keep out areas within
> 868MHz for alarms and SRD devices must abide by certain
> duty cycle restrictions, there are also maximum powers to
> consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K,
> L, M, N, P, Q)
>
> > The certified AT style modules will (should) already have
> this regulatory data baked in so it only applied to situations
> where we drive the transceivers directly, but it wouldn't
> hurt to check that the frequency being asked to transmit on
> doesn't spill into a restricted band.
>
> Some do have configuration options that will need to be set
> or checked.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v3 net-next 0/3] rds: IPv6 support
From: Sowmini Varadhan @ 2018-07-18 10:33 UTC (permalink / raw)
To: Ka-Cheong Poon; +Cc: netdev, santosh.shilimkar, davem, rds-devel
In-Reply-To: <d2d5363a-8a3f-02f4-9554-ff6eec59c43a@oracle.com>
On (07/18/18 15:19), Ka-Cheong Poon wrote:
> >bind() and connect() are using the sa_family/ss_family to have
> >the application signal to the kernel about whether ipv4 or ipv6 is
> >desired. (and bind and connect are doing the right thing for
> >v4mapped, so that doesnt seem to be a problem there)
> >
> >In this case you want the application to signal that info via
> >the optlen. (And the reason for this inconsistency is that you dont
> >want to deal with the user->kernel copy in the same way?)
>
>
> Because doing that can break existing RDS apps. Existing code
> does not check the address family in processing this socket
> option. It only cares about the address and port. If the new
I'll leave this up to DaveM. Existing code only handles IPv4,
everywhere else, we always check the sa_family or ss_family
first and verify the length afterward. This was DaveM's original
point about bind/connect/sendmsg. I dont know why rds sockopts have
to be special.
> code suddenly checks that and use it to decide on the address
> family, working app will break. As I mentioned before, this
> patch set does not change existing behavior. And doing what
> you mentioned will change existing behavior and break apps.
thank you.
--Sowmini
^ permalink raw reply
* Re: [PATCH net-next 4/4] act_mirred: use ACT_REDIRECT when possible
From: Paolo Abeni @ 2018-07-18 10:05 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger
In-Reply-To: <CAM_iQpVHNGWEsWxNbKzk2kE5QsC=kvg7o67vrWL=NTVGKG+X+A@mail.gmail.com>
Hi,
On Tue, 2018-07-17 at 10:24 -0700, Cong Wang wrote:
> If you goal is to get rid of skb_clone(), why not just do the following?
>
> if (tcf_mirred_is_act_redirect(m_eaction)) {
> skb2 = skb;
> } else {
> skb2 = skb_clone(skb, GFP_ATOMIC);
> if (!skb2)
> goto out;
> }
>
> For redirect, we return TC_ACT_SHOT, so upper layer should not
> touch the skb after that.
>
> What am I missing here?
With ACT_SHOT caller/upper layer will free the skb, too. We will have
an use after free (from either the upper layer and the xmit device).
Similar issues with STOLEN, TRAP, etc.
In the past, Changli Gao attempted to avoid the clone incrementing the
skb usage count:
commit 210d6de78c5d7c785fc532556cea340e517955e1
Author: Changli Gao <xiaosuo@gmail.com>
Date: Thu Jun 24 16:25:12 2010 +0000
act_mirred: don't clone skb when skb isn't shared
but some/many device drivers expect an skb usage count of 1, and that
caused ooops and was revered.
I think the only other option (beyond re-using ACT_MIRROR) is adding
another action value, and let the upper layer re-inject the packet
while handling such action (similar to what ACT_MIRROR currently does,
but preserving the current mirred semantic).
Cheers,
Paolo
^ permalink raw reply
* [PATCH] net/nfc: Avoid stalls when nfc_alloc_send_skb() returned NULL.
From: Tetsuo Handa @ 2018-07-18 9:57 UTC (permalink / raw)
To: Samuel Ortiz
Cc: David S. Miller, linux-wireless, netdev, Tetsuo Handa, syzbot
syzbot is reporting stalls at nfc_llcp_send_ui_frame() [1]. This is
because nfc_llcp_send_ui_frame() is retrying the loop without any delay
when nonblocking nfc_alloc_send_skb() returned NULL.
Since there is no need to use MSG_DONTWAIT if we retry until
sock_alloc_send_pskb() succeeds, let's use blocking call.
Also, in case an unexpected error occurred, let's break the loop
if blocking nfc_alloc_send_skb() failed.
[1] https://syzkaller.appspot.com/bug?id=4a131cc571c3733e0eff6bc673f4e36ae48f19c6
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+d29d18215e477cfbfbdd@syzkaller.appspotmail.com>
---
net/nfc/llcp_commands.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 2ceefa1..6a196e4 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -752,11 +752,14 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8 ssap, u8 dsap,
pr_debug("Fragment %zd bytes remaining %zd",
frag_len, remaining_len);
- pdu = nfc_alloc_send_skb(sock->dev, &sock->sk, MSG_DONTWAIT,
+ pdu = nfc_alloc_send_skb(sock->dev, &sock->sk, 0,
frag_len + LLCP_HEADER_SIZE, &err);
if (pdu == NULL) {
- pr_err("Could not allocate PDU\n");
- continue;
+ pr_err("Could not allocate PDU (error=%d)\n", err);
+ len -= remaining_len;
+ if (len == 0)
+ len = err;
+ break;
}
pdu = llcp_add_header(pdu, dsap, ssap, LLCP_PDU_UI);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH iproute2 5/5] bpf: implement btf handling and map annotation
From: Daniel Borkmann @ 2018-07-18 9:33 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: dsahern, alexei.starovoitov, netdev
In-Reply-To: <d63310f1-fca2-eace-db71-5063ebedc971@iogearbox.net>
On 07/18/2018 10:42 AM, Daniel Borkmann wrote:
> On 07/18/2018 02:27 AM, Jakub Kicinski wrote:
>> On Wed, 18 Jul 2018 01:31:22 +0200, Daniel Borkmann wrote:
>>> # bpftool map dump id 386
>>> [{
>>> "key": 0,
>>> "value": {
>>> "": {
>>> "value": 0,
>>> "ifindex": 0,
>>> "mac": []
>>> }
>>> }
>>> },{
>>> "key": 1,
>>> "value": {
>>> "": {
>>> "value": 0,
>>> "ifindex": 0,
>>> "mac": []
>>> }
>>> }
>>> },{
>>> [...]
>>
>> Ugh, the empty keys ("") look worrying, we should probably improve
>> handling of anonymous structs in bpftool :S
>
> Yeah agree, I think it would be nice to see a more pahole style dump
> where we have types and member names along with the value as otherwise
> it might be a bit confusing.
Another feature that would be super useful imho would be in the /single/
map view e.g. 'bpftool map show id 123' to have a detailed BTF key+value
type dump, so in addition to the basic map info we show pahole like info
of the structs with length/offsets.
>> FWIW all the patches look nice to me! Thanks for keeping the support
>> for loading programs from the ".text" section :)
>
> The test_offload.py from BPF kselftests helped a lot in that! :)
>
> Thanks,
> Daniel
>
^ permalink raw reply
* Re: [PATCH net-next] net: phy: add GBit master / slave error detection
From: Florian Fainelli @ 2018-07-18 9:22 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <60685308-a848-e4d0-e170-f2738f046679@gmail.com>
On 07/17/2018 11:14 PM, Heiner Kallweit wrote:
> Certain PHY's have issues when operating in GBit slave mode and can
> be forced to master mode. Examples are RTL8211C, also the Micrel PHY
> driver has a DT setting to force master mode.
> If two such chips are link partners the autonegotiation will fail.
> Standard defines a self-clearing on read, latched-high bit to
> indicate this error. Check this bit to inform the user.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy_device.c | 5 +++++
> include/uapi/linux/mii.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index b9f5f40a..249c6f75 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1551,6 +1551,11 @@ int genphy_read_status(struct phy_device *phydev)
> if (lpagb < 0)
> return lpagb;
>
> + if (lpagb & LPA_1000MSFAIL) {
> + phydev_err(phydev, "Master/Slave resolution failed, maybe conflicting manual settings?\n");
> + return -ENOLINK;
> + }
> +
You should also be able to read whether Master/Slave was configured as
automatic or manual, and possibly issue a different message when
automatic/forced is specified?
AFAIR there was a patch a while ago from Mellanox guys that was possibly
extending the link notification with an error cause, this sounds like
something that could be useful to report to user space somehow to help
troubleshoot link down events.
Thanks for your improvements to PHYLIB.
--
Florian
^ permalink raw reply
* [PATCH bpf-next] bpf: show in bpftool map overview whether btf is available
From: Daniel Borkmann @ 2018-07-18 9:19 UTC (permalink / raw)
To: alexei.starovoitov; +Cc: jakub.kicinski, netdev, Daniel Borkmann
For a quick overview in 'bpftool map' display 'btf' if it's
available for the dump for a specific map:
# bpftool map list
11: array flags 0x0 btf
key 4B value 20B max_entries 40 memlock 4096B
# bpftool --json --pretty map list
[{
"id": 11,
"type": "array",
"flags": 0,
"btf_available": true,
"bytes_key": 4,
"bytes_value": 20,
"max_entries": 40,
"bytes_memlock": 4096
}
]
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
tools/bpf/bpftool/map.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 9c81918..2cc4741 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -490,6 +490,8 @@ static int show_map_close_json(int fd, struct bpf_map_info *info)
jsonw_name(json_wtr, "flags");
jsonw_printf(json_wtr, "%d", info->map_flags);
+ jsonw_name(json_wtr, "btf_available");
+ jsonw_bool(json_wtr, info->btf_key_type_id && info->btf_value_type_id);
print_dev_json(info->ifindex, info->netns_dev, info->netns_ino);
@@ -535,6 +537,8 @@ static int show_map_close_plain(int fd, struct bpf_map_info *info)
printf("name %s ", info->name);
printf("flags 0x%x", info->map_flags);
+ if (info->btf_key_type_id && info->btf_value_type_id)
+ printf(" btf");
print_dev_plain(info->ifindex, info->netns_dev, info->netns_ino);
printf("\n");
printf("\tkey %uB value %uB max_entries %u",
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-next 6/7] net: systemport: Add support for WAKE_FILTER
From: Florian Fainelli @ 2018-07-18 9:15 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linville, davem, vivien.didelot
In-Reply-To: <20180717170653.GK968@lunn.ch>
On 07/17/2018 10:06 AM, Andrew Lunn wrote:
>>>>>> + if (bitmap_weight(priv->filters, WAKE_FILTER_BITS) >
>>>>>> + RXCHK_BRCM_TAG_MAX) {
>>>>>> + bitmap_zero(priv->filters, WAKE_FILTER_BITS);
>>>>>> + return -ENOSPC;
>>>>>> + }
>>>>>> +
>>>>>> + if (bitmap_weight(priv->filters, WAKE_FILTER_BITS) == 0)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + for_each_set_bit(index, priv->filters, WAKE_FILTER_BITS) {
>>>>>> + /* Write the index we want to match within the CID field */
>>>>>> + reg = rxchk_readl(priv, RXCHK_BRCM_TAG(i));
>>>>>> + reg &= ~(RXCHK_BRCM_TAG_CID_MASK <<
>>>>>> + RXCHK_BRCM_TAG_CID_SHIFT);
>>>>>> + reg |= index << RXCHK_BRCM_TAG_CID_SHIFT;
>>>>>> + rxchk_writel(priv, reg, RXCHK_BRCM_TAG(i));
>>>>>> + rxchk_writel(priv, 0xff00ffff, RXCHK_BRCM_TAG_MASK(i));
>>>>>> + i++;
>>>>>> + }
>>>>>> + }
>>>>>
>
> Just to convince me, can you dump the contents of reg. And execute the
> commands:
>
> ethtool -s gphy wol f filters 0x1
> ethtool -s gphy wol f filters 0x2
>
> After these two commands, we expect only one filter bit to be set, bit
> 1. Filter Bit 0 should of been cleared when the second command was
> executed.
In both of your examples, only one bit is set, what will change is the
value being programmed to RXHCK_BRCM_TAG(i), which will be either 0, or
1, but the value programmed to RXCHK_CONTROL as far as which filter is
enabled will be the same because we can use filter position 0.
What the code basically does is look at how many bits are set in the
filters bitmap, and then it starts populating the filters from filter 0
up to filter 7 with the value of the bit.
Dumps below are:
<physiscal offset>,<value>,<constant name>
ethtool -s gphy wol f filters 0x1:
0x09400300,0x01d91019,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_CONTROL
0x09400304,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_0
0x09400308,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_1
0x0940030c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_2
0x09400310,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_3
0x09400314,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_4
0x09400318,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_5
0x0940031c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_6
0x09400320,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_7
0x09400324,0xff00ffff,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_0
0x09400328,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_1
0x0940032c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_2
0x09400330,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_3
0x09400334,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_4
0x09400338,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_5
0x0940033c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_6
0x09400340,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_7
0x09400344,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MATCH_STATUS
0x09400348,0x88a88100,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_ETHERTYPE
0x0940034c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BAD_CHECKSUM_PACKET_DISCARD_COUNTER
0x09400350,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_OTHER_PACKET_DISCARD_COUNTER
ethtool -s gphy wol f filters 0x2:
0x09400300,0x01d91019,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_CONTROL
0x09400304,0x00010000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_0
0x09400308,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_1
0x0940030c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_2
0x09400310,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_3
0x09400314,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_4
0x09400318,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_5
0x0940031c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_6
0x09400320,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_7
0x09400324,0xff00ffff,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_0
0x09400328,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_1
0x0940032c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_2
0x09400330,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_3
0x09400334,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_4
0x09400338,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_5
0x0940033c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_6
0x09400340,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_7
0x09400344,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MATCH_STATUS
0x09400348,0x88a88100,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_ETHERTYPE
0x0940034c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BAD_CHECKSUM_PACKET_DISCARD_COUNTER
0x09400350,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_OTHER_PACKET_DISCARD_COUNTER
As you can see, the only thing that changes here is that we re-used
BRCM_TAG_0 but programmed a different CID value in there which is the
bit position within the filter.
ethtool -s gphy wol f filters 0x3
0x09400300,0x01d91039,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_CONTROL
0x09400304,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_0
0x09400308,0x00010000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_1
0x0940030c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_2
0x09400310,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_3
0x09400314,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_4
0x09400318,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_5
0x0940031c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_6
0x09400320,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_7
0x09400324,0xff00ffff,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_0
0x09400328,0xff00ffff,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_1
0x0940032c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_2
0x09400330,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_3
0x09400334,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_4
0x09400338,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_5
0x0940033c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_6
0x09400340,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_7
0x09400344,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MATCH_STATUS
0x09400348,0x88a88100,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_ETHERTYPE
0x0940034c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BAD_CHECKSUM_PACKET_DISCARD_COUNTER
0x09400350,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_OTHER_PACKET_DISCARD_COUNTER
Here we are using two filters, which gets reflected by programming
BRCM_TAG_0 and BRCM_TAG_1 and setting the bitmask of enabled filters in
RXHCK_CONTROL (0x30)
ethtool -s gphy wol f filters 0x1
0x09400300,0x01d91019,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_CONTROL
0x09400304,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_0
0x09400308,0x00010000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_1
0x0940030c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_2
0x09400310,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_3
0x09400314,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_4
0x09400318,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_5
0x0940031c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_6
0x09400320,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_7
0x09400324,0xff00ffff,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_0
0x09400328,0xff00ffff,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_1
0x0940032c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_2
0x09400330,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_3
0x09400334,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_4
0x09400338,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_5
0x0940033c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_6
0x09400340,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MASK_7
0x09400344,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BRCM_TAG_MATCH_STATUS
0x09400348,0x88a88100,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_ETHERTYPE
0x0940034c,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_BAD_CHECKSUM_PACKET_DISCARD_COUNTER
0x09400350,0x00000000,SYSTEMPORTLITE_TOP_1_SYSTEMPORTLITE_1_RXCHK_OTHER_PACKET_DISCARD_COUNTER
Here we left the filter that we previously programmed into BRCM_TAG_1,
but as you can see from RHCHK_CONTROL set to 0x10, we are not activating
it, so it will not be part of the wake-up process.
Register programming is always a bit expensive, which is why the code
does not try to clear previously programmed filters because we have this
active/deactive bit instead which is more efficient to manage.
Hope this is convincing you :)
--
Florian
^ permalink raw reply
* KASAN: use-after-free Write in __xfrm_policy_unlink
From: syzbot @ 2018-07-18 8:50 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: fcaccc829382 liquidio: correct error msg text when removin..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13c6b368400000
kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
dashboard link: https://syzkaller.appspot.com/bug?extid=9d971dd21eb26567036b
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+9d971dd21eb26567036b@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in __write_once_size
include/linux/compiler.h:215 [inline]
BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:679 [inline]
BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:440
[inline]
BUG: KASAN: use-after-free in __xfrm_policy_unlink+0x735/0x7e0
net/xfrm/xfrm_policy.c:1222
Write of size 8 at addr ffff8801a94744c8 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0-rc3+ #126
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__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_store8_noabort+0x17/0x20 mm/kasan/report.c:438
__write_once_size include/linux/compiler.h:215 [inline]
__hlist_del include/linux/list.h:679 [inline]
hlist_del_rcu include/linux/rculist.h:440 [inline]
__xfrm_policy_unlink+0x735/0x7e0 net/xfrm/xfrm_policy.c:1222
xfrm_policy_delete+0x49/0x90 net/xfrm/xfrm_policy.c:1247
xfrm_policy_timer+0x453/0x670 net/xfrm/xfrm_policy.c:247
call_timer_fn+0x242/0x970 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x7a6/0xc70 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e8/0xb17 kernel/softirq.c:288
invoke_softirq kernel/softirq.c:368 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:408
exiting_irq arch/x86/include/asm/apic.h:527 [inline]
smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
Code: c7 48 89 45 d8 e8 8a 2d 23 fa 48 8b 45 d8 e9 d2 fe ff ff 48 89 df e8
79 2d 23 fa eb 8a 90 90 90 90 90 90 90 55 48 89 e5 fb f4 <5d> c3 0f 1f 84
00 00 00 00 00 55 48 89 e5 f4 5d c3 90 90 90 90 90
RSP: 0018:ffffffff88e07bc0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
RAX: dffffc0000000000 RBX: 1ffffffff11c0f7b RCX: ffffffff81667982
RDX: 1ffffffff11e3610 RSI: 0000000000000004 RDI: ffffffff88f1b080
RBP: ffffffff88e07bc0 R08: ffffed003b5c46d7 R09: ffffed003b5c46d6
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: 0000000000000000
R13: ffffffff88e07c78 R14: ffffffff899ee920 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc7/0x450 arch/x86/kernel/process.c:500
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x3aa/0x570 kernel/sched/idle.c:262
cpu_startup_entry+0x10c/0x120 kernel/sched/idle.c:368
rest_init+0xe1/0xe4 init/main.c:442
start_kernel+0x90e/0x949 init/main.c:738
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
Allocated by task 30004:
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
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
xfrm_policy_alloc+0xd9/0x480 net/xfrm/xfrm_policy.c:260
xfrm_policy_construct+0x2f/0x590 net/xfrm/xfrm_user.c:1545
xfrm_add_policy+0x20f/0x750 net/xfrm/xfrm_user.c:1591
xfrm_user_rcv_msg+0x455/0x8b0 net/xfrm/xfrm_user.c:2590
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
xfrm_netlink_rcv+0x6f/0x90 net/xfrm/xfrm_user.c:2598
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1336
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:651
___sys_sendmsg+0x7fd/0x930 net/socket.c:2125
__sys_sendmsg+0x11d/0x290 net/socket.c:2163
__do_sys_sendmsg net/socket.c:2172 [inline]
__se_sys_sendmsg net/socket.c:2170 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2170
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 516:
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]
kfree+0xd9/0x260 mm/slab.c:3813
xfrm_policy_destroy_rcu+0x4a/0x60 net/xfrm/xfrm_policy.c:283
__rcu_reclaim kernel/rcu/rcu.h:178 [inline]
rcu_do_batch kernel/rcu/tree.c:2558 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2818 [inline]
__rcu_process_callbacks kernel/rcu/tree.c:2785 [inline]
rcu_process_callbacks+0xed5/0x1850 kernel/rcu/tree.c:2802
__do_softirq+0x2e8/0xb17 kernel/softirq.c:288
The buggy address belongs to the object at ffff8801a94744c0
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 8 bytes inside of
1024-byte region [ffff8801a94744c0, ffff8801a94748c0)
The buggy address belongs to the page:
page:ffffea0006a51d00 count:1 mapcount:0 mapping:ffff8801da800ac0
index:0xffff8801a9475b40 compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0006ae8a08 ffffea00075d3c08 ffff8801da800ac0
raw: ffff8801a9475b40 ffff8801a9474040 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801a9474380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801a9474400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff8801a9474480: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801a9474500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801a9474580: 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.
^ permalink raw reply
* Re: [PATCH iproute2 5/5] bpf: implement btf handling and map annotation
From: Daniel Borkmann @ 2018-07-18 8:42 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: dsahern, alexei.starovoitov, netdev
In-Reply-To: <20180717172743.6e5e1231@cakuba.lan>
On 07/18/2018 02:27 AM, Jakub Kicinski wrote:
> On Wed, 18 Jul 2018 01:31:22 +0200, Daniel Borkmann wrote:
>> # bpftool map dump id 386
>> [{
>> "key": 0,
>> "value": {
>> "": {
>> "value": 0,
>> "ifindex": 0,
>> "mac": []
>> }
>> }
>> },{
>> "key": 1,
>> "value": {
>> "": {
>> "value": 0,
>> "ifindex": 0,
>> "mac": []
>> }
>> }
>> },{
>> [...]
>
> Ugh, the empty keys ("") look worrying, we should probably improve
> handling of anonymous structs in bpftool :S
Yeah agree, I think it would be nice to see a more pahole style dump
where we have types and member names along with the value as otherwise
it might be a bit confusing.
> FWIW all the patches look nice to me! Thanks for keeping the support
> for loading programs from the ".text" section :)
The test_offload.py from BPF kselftests helped a lot in that! :)
Thanks,
Daniel
^ permalink raw reply
* [PATCH net-next 12/16] mlxsw: spectrum_acl: Prepare for Spectrum-2 block encoding
From: Ido Schimmel @ 2018-07-18 8:14 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20180718081445.9445-1-idosch@mellanox.com>
In Spectrum the key (and mask) block layout is very straight forward and
every block is 16 bytes aligned.
However, in Spectrum-2 the blocks are not even byte aligned, which makes
it difficult to encode them using current method.
Instead, first encode each block and then encode the block in the
general blocks layout.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../ethernet/mellanox/mlxsw/core_acl_flex_keys.c | 70 ++++++++++++++++++----
.../ethernet/mellanox/mlxsw/core_acl_flex_keys.h | 3 +-
.../mellanox/mlxsw/spectrum_acl_flex_keys.c | 46 ++------------
3 files changed, 66 insertions(+), 53 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c
index bf645215f514..5f8485c7640e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c
@@ -416,24 +416,74 @@ void mlxsw_afk_values_add_buf(struct mlxsw_afk_element_values *values,
}
EXPORT_SYMBOL(mlxsw_afk_values_add_buf);
+static void mlxsw_sp_afk_encode_u32(const struct mlxsw_item *storage_item,
+ const struct mlxsw_item *output_item,
+ char *storage, char *output)
+{
+ u32 value;
+
+ value = __mlxsw_item_get32(storage, storage_item, 0);
+ __mlxsw_item_set32(output, output_item, 0, value);
+}
+
+static void mlxsw_sp_afk_encode_buf(const struct mlxsw_item *storage_item,
+ const struct mlxsw_item *output_item,
+ char *storage, char *output)
+{
+ char *storage_data = __mlxsw_item_data(storage, storage_item, 0);
+ char *output_data = __mlxsw_item_data(output, output_item, 0);
+ size_t len = output_item->size.bytes;
+
+ memcpy(output_data, storage_data, len);
+}
+
+static void
+mlxsw_sp_afk_encode_one(const struct mlxsw_afk_element_inst *elinst,
+ char *output, char *storage)
+{
+ const struct mlxsw_item *storage_item = &elinst->info->item;
+ const struct mlxsw_item *output_item = &elinst->item;
+
+ if (elinst->type == MLXSW_AFK_ELEMENT_TYPE_U32)
+ mlxsw_sp_afk_encode_u32(storage_item, output_item,
+ storage, output);
+ else if (elinst->type == MLXSW_AFK_ELEMENT_TYPE_BUF)
+ mlxsw_sp_afk_encode_buf(storage_item, output_item,
+ storage, output);
+}
+
+#define MLXSW_SP_AFK_KEY_BLOCK_MAX_SIZE 16
+
void mlxsw_afk_encode(struct mlxsw_afk *mlxsw_afk,
struct mlxsw_afk_key_info *key_info,
struct mlxsw_afk_element_values *values,
char *key, char *mask)
{
+ char block_mask[MLXSW_SP_AFK_KEY_BLOCK_MAX_SIZE];
+ char block_key[MLXSW_SP_AFK_KEY_BLOCK_MAX_SIZE];
const struct mlxsw_afk_element_inst *elinst;
enum mlxsw_afk_element element;
- int block_index;
+ int block_index, i;
+
+ for (i = 0; i < key_info->blocks_count; i++) {
+ memset(block_key, 0, MLXSW_SP_AFK_KEY_BLOCK_MAX_SIZE);
+ memset(block_mask, 0, MLXSW_SP_AFK_KEY_BLOCK_MAX_SIZE);
+
+ mlxsw_afk_element_usage_for_each(element, &values->elusage) {
+ elinst = mlxsw_afk_key_info_elinst_get(key_info,
+ element,
+ &block_index);
+ if (!elinst || block_index != i)
+ continue;
+
+ mlxsw_sp_afk_encode_one(elinst, block_key,
+ values->storage.key);
+ mlxsw_sp_afk_encode_one(elinst, block_mask,
+ values->storage.mask);
+ }
- mlxsw_afk_element_usage_for_each(element, &values->elusage) {
- elinst = mlxsw_afk_key_info_elinst_get(key_info, element,
- &block_index);
- if (!elinst)
- continue;
- mlxsw_afk->ops->encode_one(elinst, block_index,
- values->storage.key, key);
- mlxsw_afk->ops->encode_one(elinst, block_index,
- values->storage.mask, mask);
+ mlxsw_afk->ops->encode_block(block_key, i, key);
+ mlxsw_afk->ops->encode_block(block_mask, i, mask);
}
}
EXPORT_SYMBOL(mlxsw_afk_encode);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h
index 441636cd13d8..2ffde915349b 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.h
@@ -219,8 +219,7 @@ struct mlxsw_afk;
struct mlxsw_afk_ops {
const struct mlxsw_afk_block *blocks;
unsigned int blocks_count;
- void (*encode_one)(const struct mlxsw_afk_element_inst *elinst,
- int block_index, char *storage, char *output);
+ void (*encode_block)(char *block, int block_index, char *output);
};
struct mlxsw_afk *mlxsw_afk_create(unsigned int max_blocks,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_flex_keys.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_flex_keys.c
index fe46338f0087..21be0987a93a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_flex_keys.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_flex_keys.c
@@ -127,50 +127,21 @@ static const struct mlxsw_afk_block mlxsw_sp1_afk_blocks[] = {
MLXSW_AFK_BLOCK(0xB0, mlxsw_sp_afk_element_info_packet_type),
};
-static void mlxsw_sp1_afk_encode_u32(const struct mlxsw_item *storage_item,
- const struct mlxsw_item *output_item,
- char *storage, char *output_indexed)
-{
- u32 value;
-
- value = __mlxsw_item_get32(storage, storage_item, 0);
- __mlxsw_item_set32(output_indexed, output_item, 0, value);
-}
-
-static void mlxsw_sp1_afk_encode_buf(const struct mlxsw_item *storage_item,
- const struct mlxsw_item *output_item,
- char *storage, char *output_indexed)
-{
- char *storage_data = __mlxsw_item_data(storage, storage_item, 0);
- char *output_data = __mlxsw_item_data(output_indexed, output_item, 0);
- size_t len = output_item->size.bytes;
-
- memcpy(output_data, storage_data, len);
-}
-
#define MLXSW_SP1_AFK_KEY_BLOCK_SIZE 16
-static void
-mlxsw_sp1_afk_encode_one(const struct mlxsw_afk_element_inst *elinst,
- int block_index, char *storage, char *output)
+static void mlxsw_sp1_afk_encode_block(char *block, int block_index,
+ char *output)
{
unsigned int offset = block_index * MLXSW_SP1_AFK_KEY_BLOCK_SIZE;
char *output_indexed = output + offset;
- const struct mlxsw_item *storage_item = &elinst->info->item;
- const struct mlxsw_item *output_item = &elinst->item;
-
- if (elinst->type == MLXSW_AFK_ELEMENT_TYPE_U32)
- mlxsw_sp1_afk_encode_u32(storage_item, output_item,
- storage, output_indexed);
- else if (elinst->type == MLXSW_AFK_ELEMENT_TYPE_BUF)
- mlxsw_sp1_afk_encode_buf(storage_item, output_item,
- storage, output_indexed);
+
+ memcpy(output_indexed, block, MLXSW_SP1_AFK_KEY_BLOCK_SIZE);
}
const struct mlxsw_afk_ops mlxsw_sp1_afk_ops = {
.blocks = mlxsw_sp1_afk_blocks,
.blocks_count = ARRAY_SIZE(mlxsw_sp1_afk_blocks),
- .encode_one = mlxsw_sp1_afk_encode_one,
+ .encode_block = mlxsw_sp1_afk_encode_block,
};
static struct mlxsw_afk_element_inst mlxsw_sp_afk_element_info_mac_0[] = {
@@ -271,14 +242,7 @@ static const struct mlxsw_afk_block mlxsw_sp2_afk_blocks[] = {
MLXSW_AFK_BLOCK(0x92, mlxsw_sp_afk_element_info_l4_2),
};
-static void
-mlxsw_sp2_afk_encode_one(const struct mlxsw_afk_element_inst *elinst,
- int block_index, char *storage, char *output)
-{
-}
-
const struct mlxsw_afk_ops mlxsw_sp2_afk_ops = {
.blocks = mlxsw_sp2_afk_blocks,
.blocks_count = ARRAY_SIZE(mlxsw_sp2_afk_blocks),
- .encode_one = mlxsw_sp2_afk_encode_one,
};
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 16/16] mlxsw: spectrum: Extend to support Spectrum-2 ASIC
From: Ido Schimmel @ 2018-07-18 8:14 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, mlxsw, Ido Schimmel
In-Reply-To: <20180718081445.9445-1-idosch@mellanox.com>
From: Jiri Pirko <jiri@mellanox.com>
Extend existing driver for Spectrum ASIC to support Spectrum-2 ASIC.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/pci.h | 1 +
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 170 ++++++++++++++++++++-----
2 files changed, 139 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.h b/drivers/net/ethernet/mellanox/mlxsw/pci.h
index d65582325cd5..7461f8fe1133 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.h
@@ -39,6 +39,7 @@
#define PCI_DEVICE_ID_MELLANOX_SWITCHX2 0xc738
#define PCI_DEVICE_ID_MELLANOX_SPECTRUM 0xcb84
+#define PCI_DEVICE_ID_MELLANOX_SPECTRUM2 0xcf6c
#define PCI_DEVICE_ID_MELLANOX_SWITCHIB 0xcb20
#define PCI_DEVICE_ID_MELLANOX_SWITCHIB2 0xcf08
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 62c5f1c5bf62..317c92d6496e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -91,7 +91,8 @@ static const struct mlxsw_fw_rev mlxsw_sp1_fw_rev = {
"." __stringify(MLXSW_SP1_FWREV_MINOR) \
"." __stringify(MLXSW_SP1_FWREV_SUBMINOR) ".mfa2"
-static const char mlxsw_sp_driver_name[] = "mlxsw_spectrum";
+static const char mlxsw_sp1_driver_name[] = "mlxsw_spectrum";
+static const char mlxsw_sp2_driver_name[] = "mlxsw_spectrum2";
static const char mlxsw_sp_driver_version[] = "1.0";
/* tx_hdr_version
@@ -1727,7 +1728,8 @@ static void mlxsw_sp_port_get_drvinfo(struct net_device *dev,
struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(dev);
struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
- strlcpy(drvinfo->driver, mlxsw_sp_driver_name, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->driver, mlxsw_sp->bus_info->device_kind,
+ sizeof(drvinfo->driver));
strlcpy(drvinfo->version, mlxsw_sp_driver_version,
sizeof(drvinfo->version));
snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
@@ -3696,14 +3698,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
struct mlxsw_sp *mlxsw_sp = mlxsw_core_driver_priv(mlxsw_core);
int err;
- mlxsw_sp->req_rev = &mlxsw_sp1_fw_rev;
- mlxsw_sp->fw_filename = MLXSW_SP1_FW_FILENAME;
- mlxsw_sp->kvdl_ops = &mlxsw_sp1_kvdl_ops;
- mlxsw_sp->afa_ops = &mlxsw_sp1_act_afa_ops;
- mlxsw_sp->afk_ops = &mlxsw_sp1_afk_ops;
- mlxsw_sp->mr_tcam_ops = &mlxsw_sp1_mr_tcam_ops;
- mlxsw_sp->acl_tcam_ops = &mlxsw_sp1_acl_tcam_ops;
-
mlxsw_sp->core = mlxsw_core;
mlxsw_sp->bus_info = mlxsw_bus_info;
@@ -3842,6 +3836,36 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
return err;
}
+static int mlxsw_sp1_init(struct mlxsw_core *mlxsw_core,
+ const struct mlxsw_bus_info *mlxsw_bus_info)
+{
+ struct mlxsw_sp *mlxsw_sp = mlxsw_core_driver_priv(mlxsw_core);
+
+ mlxsw_sp->req_rev = &mlxsw_sp1_fw_rev;
+ mlxsw_sp->fw_filename = MLXSW_SP1_FW_FILENAME;
+ mlxsw_sp->kvdl_ops = &mlxsw_sp1_kvdl_ops;
+ mlxsw_sp->afa_ops = &mlxsw_sp1_act_afa_ops;
+ mlxsw_sp->afk_ops = &mlxsw_sp1_afk_ops;
+ mlxsw_sp->mr_tcam_ops = &mlxsw_sp1_mr_tcam_ops;
+ mlxsw_sp->acl_tcam_ops = &mlxsw_sp1_acl_tcam_ops;
+
+ return mlxsw_sp_init(mlxsw_core, mlxsw_bus_info);
+}
+
+static int mlxsw_sp2_init(struct mlxsw_core *mlxsw_core,
+ const struct mlxsw_bus_info *mlxsw_bus_info)
+{
+ struct mlxsw_sp *mlxsw_sp = mlxsw_core_driver_priv(mlxsw_core);
+
+ mlxsw_sp->kvdl_ops = &mlxsw_sp2_kvdl_ops;
+ mlxsw_sp->afa_ops = &mlxsw_sp2_act_afa_ops;
+ mlxsw_sp->afk_ops = &mlxsw_sp2_afk_ops;
+ mlxsw_sp->mr_tcam_ops = &mlxsw_sp2_mr_tcam_ops;
+ mlxsw_sp->acl_tcam_ops = &mlxsw_sp2_acl_tcam_ops;
+
+ return mlxsw_sp_init(mlxsw_core, mlxsw_bus_info);
+}
+
static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
{
struct mlxsw_sp *mlxsw_sp = mlxsw_core_driver_priv(mlxsw_core);
@@ -3862,7 +3886,7 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
mlxsw_sp_kvdl_fini(mlxsw_sp);
}
-static const struct mlxsw_config_profile mlxsw_sp_config_profile = {
+static const struct mlxsw_config_profile mlxsw_sp1_config_profile = {
.used_max_mid = 1,
.max_mid = MLXSW_SP_MID_MAX,
.used_flood_tables = 1,
@@ -3888,6 +3912,28 @@ static const struct mlxsw_config_profile mlxsw_sp_config_profile = {
},
};
+static const struct mlxsw_config_profile mlxsw_sp2_config_profile = {
+ .used_max_mid = 1,
+ .max_mid = MLXSW_SP_MID_MAX,
+ .used_flood_tables = 1,
+ .used_flood_mode = 1,
+ .flood_mode = 3,
+ .max_fid_offset_flood_tables = 3,
+ .fid_offset_flood_table_size = VLAN_N_VID - 1,
+ .max_fid_flood_tables = 3,
+ .fid_flood_table_size = MLXSW_SP_FID_8021D_MAX,
+ .used_max_ib_mc = 1,
+ .max_ib_mc = 0,
+ .used_max_pkey = 1,
+ .max_pkey = 0,
+ .swid_config = {
+ {
+ .used_type = 1,
+ .type = MLXSW_PORT_SWID_TYPE_ETH,
+ }
+ },
+};
+
static void
mlxsw_sp_resource_size_params_prepare(struct mlxsw_core *mlxsw_core,
struct devlink_resource_size_params *kvd_size_params,
@@ -3924,7 +3970,7 @@ mlxsw_sp_resource_size_params_prepare(struct mlxsw_core *mlxsw_core,
DEVLINK_RESOURCE_UNIT_ENTRY);
}
-static int mlxsw_sp_resources_register(struct mlxsw_core *mlxsw_core)
+static int mlxsw_sp1_resources_kvd_register(struct mlxsw_core *mlxsw_core)
{
struct devlink *devlink = priv_to_devlink(mlxsw_core);
struct devlink_resource_size_params hash_single_size_params;
@@ -3935,7 +3981,7 @@ static int mlxsw_sp_resources_register(struct mlxsw_core *mlxsw_core)
const struct mlxsw_config_profile *profile;
int err;
- profile = &mlxsw_sp_config_profile;
+ profile = &mlxsw_sp1_config_profile;
if (!MLXSW_CORE_RES_VALID(mlxsw_core, KVD_SIZE))
return -EIO;
@@ -3990,6 +4036,16 @@ static int mlxsw_sp_resources_register(struct mlxsw_core *mlxsw_core)
return 0;
}
+static int mlxsw_sp1_resources_register(struct mlxsw_core *mlxsw_core)
+{
+ return mlxsw_sp1_resources_kvd_register(mlxsw_core);
+}
+
+static int mlxsw_sp2_resources_register(struct mlxsw_core *mlxsw_core)
+{
+ return 0;
+}
+
static int mlxsw_sp_kvd_sizes_get(struct mlxsw_core *mlxsw_core,
const struct mlxsw_config_profile *profile,
u64 *p_single_size, u64 *p_double_size,
@@ -4045,10 +4101,10 @@ static int mlxsw_sp_kvd_sizes_get(struct mlxsw_core *mlxsw_core,
return 0;
}
-static struct mlxsw_driver mlxsw_sp_driver = {
- .kind = mlxsw_sp_driver_name,
+static struct mlxsw_driver mlxsw_sp1_driver = {
+ .kind = mlxsw_sp1_driver_name,
.priv_size = sizeof(struct mlxsw_sp),
- .init = mlxsw_sp_init,
+ .init = mlxsw_sp1_init,
.fini = mlxsw_sp_fini,
.basic_trap_groups_set = mlxsw_sp_basic_trap_groups_set,
.port_split = mlxsw_sp_port_split,
@@ -4064,10 +4120,35 @@ static struct mlxsw_driver mlxsw_sp_driver = {
.sb_occ_port_pool_get = mlxsw_sp_sb_occ_port_pool_get,
.sb_occ_tc_port_bind_get = mlxsw_sp_sb_occ_tc_port_bind_get,
.txhdr_construct = mlxsw_sp_txhdr_construct,
- .resources_register = mlxsw_sp_resources_register,
+ .resources_register = mlxsw_sp1_resources_register,
.kvd_sizes_get = mlxsw_sp_kvd_sizes_get,
.txhdr_len = MLXSW_TXHDR_LEN,
- .profile = &mlxsw_sp_config_profile,
+ .profile = &mlxsw_sp1_config_profile,
+ .res_query_enabled = true,
+};
+
+static struct mlxsw_driver mlxsw_sp2_driver = {
+ .kind = mlxsw_sp2_driver_name,
+ .priv_size = sizeof(struct mlxsw_sp),
+ .init = mlxsw_sp2_init,
+ .fini = mlxsw_sp_fini,
+ .basic_trap_groups_set = mlxsw_sp_basic_trap_groups_set,
+ .port_split = mlxsw_sp_port_split,
+ .port_unsplit = mlxsw_sp_port_unsplit,
+ .sb_pool_get = mlxsw_sp_sb_pool_get,
+ .sb_pool_set = mlxsw_sp_sb_pool_set,
+ .sb_port_pool_get = mlxsw_sp_sb_port_pool_get,
+ .sb_port_pool_set = mlxsw_sp_sb_port_pool_set,
+ .sb_tc_pool_bind_get = mlxsw_sp_sb_tc_pool_bind_get,
+ .sb_tc_pool_bind_set = mlxsw_sp_sb_tc_pool_bind_set,
+ .sb_occ_snapshot = mlxsw_sp_sb_occ_snapshot,
+ .sb_occ_max_clear = mlxsw_sp_sb_occ_max_clear,
+ .sb_occ_port_pool_get = mlxsw_sp_sb_occ_port_pool_get,
+ .sb_occ_tc_port_bind_get = mlxsw_sp_sb_occ_tc_port_bind_get,
+ .txhdr_construct = mlxsw_sp_txhdr_construct,
+ .resources_register = mlxsw_sp2_resources_register,
+ .txhdr_len = MLXSW_TXHDR_LEN,
+ .profile = &mlxsw_sp2_config_profile,
.res_query_enabled = true,
};
@@ -4846,14 +4927,24 @@ static struct notifier_block mlxsw_sp_inet6addr_nb __read_mostly = {
.notifier_call = mlxsw_sp_inet6addr_event,
};
-static const struct pci_device_id mlxsw_sp_pci_id_table[] = {
+static const struct pci_device_id mlxsw_sp1_pci_id_table[] = {
{PCI_VDEVICE(MELLANOX, PCI_DEVICE_ID_MELLANOX_SPECTRUM), 0},
{0, },
};
-static struct pci_driver mlxsw_sp_pci_driver = {
- .name = mlxsw_sp_driver_name,
- .id_table = mlxsw_sp_pci_id_table,
+static struct pci_driver mlxsw_sp1_pci_driver = {
+ .name = mlxsw_sp1_driver_name,
+ .id_table = mlxsw_sp1_pci_id_table,
+};
+
+static const struct pci_device_id mlxsw_sp2_pci_id_table[] = {
+ {PCI_VDEVICE(MELLANOX, PCI_DEVICE_ID_MELLANOX_SPECTRUM2), 0},
+ {0, },
+};
+
+static struct pci_driver mlxsw_sp2_pci_driver = {
+ .name = mlxsw_sp2_driver_name,
+ .id_table = mlxsw_sp2_pci_id_table,
};
static int __init mlxsw_sp_module_init(void)
@@ -4865,19 +4956,31 @@ static int __init mlxsw_sp_module_init(void)
register_inet6addr_validator_notifier(&mlxsw_sp_inet6addr_valid_nb);
register_inet6addr_notifier(&mlxsw_sp_inet6addr_nb);
- err = mlxsw_core_driver_register(&mlxsw_sp_driver);
+ err = mlxsw_core_driver_register(&mlxsw_sp1_driver);
+ if (err)
+ goto err_sp1_core_driver_register;
+
+ err = mlxsw_core_driver_register(&mlxsw_sp2_driver);
+ if (err)
+ goto err_sp2_core_driver_register;
+
+ err = mlxsw_pci_driver_register(&mlxsw_sp1_pci_driver);
if (err)
- goto err_core_driver_register;
+ goto err_sp1_pci_driver_register;
- err = mlxsw_pci_driver_register(&mlxsw_sp_pci_driver);
+ err = mlxsw_pci_driver_register(&mlxsw_sp2_pci_driver);
if (err)
- goto err_pci_driver_register;
+ goto err_sp2_pci_driver_register;
return 0;
-err_pci_driver_register:
- mlxsw_core_driver_unregister(&mlxsw_sp_driver);
-err_core_driver_register:
+err_sp2_pci_driver_register:
+ mlxsw_pci_driver_unregister(&mlxsw_sp2_pci_driver);
+err_sp1_pci_driver_register:
+ mlxsw_core_driver_unregister(&mlxsw_sp2_driver);
+err_sp2_core_driver_register:
+ mlxsw_core_driver_unregister(&mlxsw_sp1_driver);
+err_sp1_core_driver_register:
unregister_inet6addr_notifier(&mlxsw_sp_inet6addr_nb);
unregister_inet6addr_validator_notifier(&mlxsw_sp_inet6addr_valid_nb);
unregister_inetaddr_notifier(&mlxsw_sp_inetaddr_nb);
@@ -4887,8 +4990,10 @@ static int __init mlxsw_sp_module_init(void)
static void __exit mlxsw_sp_module_exit(void)
{
- mlxsw_pci_driver_unregister(&mlxsw_sp_pci_driver);
- mlxsw_core_driver_unregister(&mlxsw_sp_driver);
+ mlxsw_pci_driver_unregister(&mlxsw_sp2_pci_driver);
+ mlxsw_pci_driver_unregister(&mlxsw_sp1_pci_driver);
+ mlxsw_core_driver_unregister(&mlxsw_sp2_driver);
+ mlxsw_core_driver_unregister(&mlxsw_sp1_driver);
unregister_inet6addr_notifier(&mlxsw_sp_inet6addr_nb);
unregister_inet6addr_validator_notifier(&mlxsw_sp_inet6addr_valid_nb);
unregister_inetaddr_notifier(&mlxsw_sp_inetaddr_nb);
@@ -4901,5 +5006,6 @@ module_exit(mlxsw_sp_module_exit);
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Jiri Pirko <jiri@mellanox.com>");
MODULE_DESCRIPTION("Mellanox Spectrum driver");
-MODULE_DEVICE_TABLE(pci, mlxsw_sp_pci_id_table);
+MODULE_DEVICE_TABLE(pci, mlxsw_sp1_pci_id_table);
+MODULE_DEVICE_TABLE(pci, mlxsw_sp2_pci_id_table);
MODULE_FIRMWARE(MLXSW_SP1_FW_FILENAME);
--
2.14.4
^ permalink raw reply related
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