* Re: [PATCH bpf-next 6/9] bpftool: add support for PERCPU_CGROUP_STORAGE maps
From: Jakub Kicinski @ 2018-09-22 0:11 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180921171353.11050-6-guro@fb.com>
On Fri, 21 Sep 2018 17:14:12 +0000, Roman Gushchin wrote:
> This commit adds support for BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE
> map type.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [PATCH rdma-next 0/4] mlx5 vport loopback
From: Doug Ledford @ 2018-09-22 0:15 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jason Gunthorpe, RDMA mailing list, Mark Bloch, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180921214017.GX3519@mtr-leonro.mtl.com>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Sat, 2018-09-22 at 00:40 +0300, Leon Romanovsky wrote:
> On Fri, Sep 21, 2018 at 04:05:53PM -0400, Doug Ledford wrote:
> > On Fri, 2018-09-21 at 22:33 +0300, Leon Romanovsky wrote:
> > > Hope it makes it clear now.
> >
> > Clear enough. Between yours and Jason's explanation I think it's well
> > covered.
> >
> > > Are you ok with me/Saeed taking first patch to our branch so you will be
> > > able to take the rest?
> >
> > Yep. Let me know a tag when it's ready to merge.
>
> Done, it doesn't have tag.
> Commit d773ff41a7c ("net/mlx5: Rename incorrect naming in IFC file")
You confused me for a minute! There is a copy-paste issue in the above.
The actual commit hash is 5d773ff41a7c. Thanks, got it.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: KASAN: use-after-free Read in vhost_transport_send_pkt
From: syzbot @ 2018-09-22 6:46 UTC (permalink / raw)
To: dvyukov, jasowang, kvm, linux-kernel, mst, netdev, stefanha,
stefanha, syzkaller-bugs, virtualization
In-Reply-To: <000000000000b4f77905723b70ee@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 10dc890d4228 Merge tag 'pinctrl-v4.19-3' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11be7111400000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=bd391451452fb0b93039
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=127cbf99400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
hrtimer: interrupt took 32480 ns
==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x37c2/0x4ec0
kernel/locking/lockdep.c:3290
Read of size 8 at addr ffff8801b192a110 by task syz-executor0/7102
CPU: 0 PID: 7102 Comm: syz-executor0 Not tainted 4.19.0-rc4+ #249
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+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
__lock_acquire+0x37c2/0x4ec0 kernel/locking/lockdep.c:3290
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:334 [inline]
vhost_transport_send_pkt+0x12e/0x380 drivers/vhost/vsock.c:223
virtio_transport_send_pkt_info+0x31d/0x460
net/vmw_vsock/virtio_transport_common.c:190
virtio_transport_connect+0x17c/0x220
net/vmw_vsock/virtio_transport_common.c:588
vsock_stream_connect+0x4ed/0xe40 net/vmw_vsock/af_vsock.c:1200
__sys_connect+0x37d/0x4c0 net/socket.c:1664
__do_sys_connect net/socket.c:1675 [inline]
__se_sys_connect net/socket.c:1672 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1672
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457679
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff9deebf38 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 000000000141d914 RCX: 0000000000457679
RDX: 0000000000000010 RSI: 0000000020000200 RDI: 0000000000000009
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004cc658 R14: 00000000004bdcb3 R15: 0000000000000000
Allocated by task 7102:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:555 [inline]
kvmalloc_node+0xb9/0xf0 mm/util.c:423
kvmalloc include/linux/mm.h:577 [inline]
vhost_vsock_dev_open+0xa2/0x5a0 drivers/vhost/vsock.c:511
misc_open+0x3ca/0x560 drivers/char/misc.c:141
chrdev_open+0x25a/0x710 fs/char_dev.c:417
do_dentry_open+0x499/0x1250 fs/open.c:771
vfs_open+0xa0/0xd0 fs/open.c:880
do_last fs/namei.c:3418 [inline]
path_openat+0x12bf/0x5160 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_sys_open+0x568/0x700 fs/open.c:1063
__do_sys_openat fs/open.c:1090 [inline]
__se_sys_openat fs/open.c:1084 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1084
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 7104:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
kvfree+0x61/0x70 mm/util.c:452
vhost_vsock_free drivers/vhost/vsock.c:499 [inline]
vhost_vsock_dev_release+0x4f4/0x720 drivers/vhost/vsock.c:604
__fput+0x385/0xa30 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801b1921400
which belongs to the cache kmalloc-65536 of size 65536
The buggy address is located 36112 bytes inside of
65536-byte region [ffff8801b1921400, ffff8801b1931400)
The buggy address belongs to the page:
page:ffffea0006c64800 count:1 mapcount:0 mapping:ffff8801da802500 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0006c64008 ffffea0006c69008 ffff8801da802500
raw: 0000000000000000 ffff8801b1921400 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b192a000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b192a080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801b192a100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801b192a180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b192a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* Re: [bpf PATCH v4 0/3] bpf, sockmap ESTABLISHED state only
From: Daniel Borkmann @ 2018-09-22 1:05 UTC (permalink / raw)
To: John Fastabend, edumazet, ast; +Cc: netdev
In-Reply-To: <20180918155826.22728.71788.stgit@john-Precision-Tower-5810>
On 09/18/2018 06:01 PM, John Fastabend wrote:
> Eric noted that using the close callback is not sufficient
> to catch all transitions from ESTABLISHED state to a LISTEN
> state. So this series does two things. First, only allow
> adding socks in ESTABLISH state and second use unhash callback
> to catch tcp_disconnect() transitions.
>
> v2: added check for ESTABLISH state in hash update sockmap as well
> v3: Do not release lock from unhash in error path, no lock was
> used in the first place. And drop not so useful code comments
> v4: convert,
> if (unhash()) return unhash(); return
> to if (unhash()) unhash(); return;
>
> Thanks for reviewing Yonghong I carried your ACKs forward.
>
> ---
>
> John Fastabend (3):
> bpf: sockmap only allow ESTABLISHED sock state
> bpf: sockmap, fix transition through disconnect without close
> bpf: test_maps, only support ESTABLISHED socks
>
>
> kernel/bpf/sockmap.c | 91 ++++++++++++++++++++++++-------
> tools/testing/selftests/bpf/test_maps.c | 10 ++-
> 2 files changed, 78 insertions(+), 23 deletions(-)
Applied to bpf, thanks John!
^ permalink raw reply
* Re: [PATCH bpf-next] samples/bpf: fix compilation failure
From: Daniel Borkmann @ 2018-09-22 1:07 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov; +Cc: netdev
In-Reply-To: <20180920075203.2464-1-bhole_prashant_q7@lab.ntt.co.jp>
On 09/20/2018 09:52 AM, Prashant Bhole wrote:
> following commit:
> commit d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> added struct bpf_flow_keys which conflicts with the struct with
> same name in sockex2_kern.c and sockex3_kern.c
>
> similar to commit:
> commit 534e0e52bc23 ("samples/bpf: fix a compilation failure")
> we tried the rename it "flow_keys" but it also conflicted with struct
> having same name in include/net/flow_dissector.h. Hence renaming the
> struct to "flow_key_record". Also, this commit doesn't fix the
> compilation error completely because the similar struct is present in
> sockex3_kern.c. Hence renaming it in both files sockex3_user.c and
> sockex3_kern.c
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Applied to bpf-next, thanks Prashant!
^ permalink raw reply
* Re: [PATCH] bpf: remove redundant null pointer check before consume_skb
From: Daniel Borkmann @ 2018-09-22 1:08 UTC (permalink / raw)
To: zhong jiang, ast; +Cc: netdev, linux-kernel
In-Reply-To: <1537436772-42545-1-git-send-email-zhongjiang@huawei.com>
On 09/20/2018 11:46 AM, zhong jiang wrote:
> consume_skb has taken the null pointer into account. hence it is safe
> to remove the redundant null pointer check before consume_skb.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied to bpf-next, thanks Zhong!
^ permalink raw reply
* RE: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: Yelena Krivosheev @ 2018-09-22 7:07 UTC (permalink / raw)
To: Gregory CLEMENT, Antoine Tenart
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
maxime.chevallier@bootlin.com, miquel.raynal@bootlin.com,
Nadav Haklai, Stefan Chulski, Yan Markman, mw@semihalf.com
In-Reply-To: <87k1ngjjtd.fsf@bootlin.com>
Hi Gregory.
I want to clarify static mvneta_rxq_drop_pkts():
static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
struct mvneta_rx_queue *rxq)
{
int rx_done, i;
rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq);
if (rx_done)
mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done);
if (pp->bm_priv) { <---------------------------- this is case for HWBM
for (i = 0; i < rx_done; i++) {
struct mvneta_rx_desc *rx_desc =
mvneta_rxq_next_desc_get(rxq);
u8 pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
struct mvneta_bm_pool *bm_pool;
bm_pool = &pp->bm_priv->bm_pools[pool_id];
/* Return dropped buffer to the pool */
mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
rx_desc->buf_phys_addr);
}
return;
}
<-------- this is case for SWBM only
for (i = 0; i < rxq->size; i++) {
struct mvneta_rx_desc *rx_desc = rxq->descs + i;
void *data = rxq->buf_virt_addr[i];
if (!data || !(rx_desc->buf_phys_addr))
continue;
dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
__free_page(data);
}
}
So I suggest to fix dma_unmap_single() call too.
Thanks.
Yelena
-----Original Message-----
From: Gregory CLEMENT [mailto:gregory.clement@bootlin.com]
Sent: Thursday, September 20, 2018 6:00 PM
To: Antoine Tenart <antoine.tenart@bootlin.com>
Cc: Yelena Krivosheev <yelena@marvell.com>; davem@davemloft.net; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Stefan Chulski <stefanc@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw@semihalf.com
Subject: Re: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
Hi Antoine,
On jeu., sept. 20 2018, Antoine Tenart <antoine.tenart@bootlin.com> wrote:
> Hi Yelena,
>
> On Thu, Sep 20, 2018 at 10:14:56AM +0000, Yelena Krivosheev wrote:
>>
>> Please, check and fix all cases of dma_unmap_single() usage.
>> See mvneta_rxq_drop_pkts()
>> ...
>> if (!data || !(rx_desc->buf_phys_addr))
>> continue;
>> dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
>> MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
>> __free_page(data);
>> ...
>
> I had a look at the one reported by CONFIG_DMA_API_DEBUG, and at DMA
> unmapping calls using PAGE_SIZE. As you pointed out there might be
> others parts, thanks!
Actually Jisheng had submitted a similar patch few weeks ago and as I pointed at this time, the dma_unmap in mvneta_rxq_drop_pkts can be called when the allocation is done in with HWBM in this case which use a dma_map_single.
I though that in this case using dma_map_single is the things to do even if in the SWBM case it is less optimal.
Gregory
>
> Antoine
>
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* Re: [PATCH rdma-next 0/4] mlx5 vport loopback
From: Doug Ledford @ 2018-09-22 1:38 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Mark Bloch, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180917103049.18235-1-leon@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]
On Mon, 2018-09-17 at 13:30 +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Hi,
>
> This is short series from Mark which extends handling of loopback
> traffic. Originally mlx5 IB dynamically enabled/disabled both unicast
> and multicast based on number of users. However RAW ethernet QPs need
> more granular access.
>
> Thanks
>
> Mark Bloch (4):
> net/mlx5: Rename incorrect naming in IFC file
> RDMA/mlx5: Refactor transport domain bookkeeping logic
> RDMA/mlx5: Allow creating RAW ethernet QP with loopback support
> RDMA/mlx5: Enable vport loopback when user context or QP mandate
>
> drivers/infiniband/hw/mlx5/main.c | 61 ++++++++++----
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 16 +++-
> drivers/infiniband/hw/mlx5/qp.c | 96 +++++++++++++++++-----
> .../net/ethernet/mellanox/mlx5/core/en_common.c | 2 +-
> include/linux/mlx5/mlx5_ifc.h | 4 +-
> include/uapi/rdma/mlx5-abi.h | 2 +
> 6 files changed, 138 insertions(+), 43 deletions(-)
>
> --
> 2.14.4
>
Thanks, first patch pulled from mlx5-next, remainder of series applied.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: KASAN: use-after-free Read in vhost_work_queue
From: syzbot @ 2018-09-22 6:01 UTC (permalink / raw)
To: cavery, jasowang, kvm, linux-kernel, mst, netdev, stefanha,
syzkaller-bugs, virtualization
In-Reply-To: <000000000000863e0205747fdfef@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 46c163a036b4 Add linux-next specific files for 20180921
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10c6792a400000
kernel config: https://syzkaller.appspot.com/x/.config?x=20ea07a946ad19d7
dashboard link: https://syzkaller.appspot.com/bug?extid=d5a0a170c5069658b141
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=130cec76400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KASAN: use-after-free in vhost_work_queue+0xc3/0xe0
drivers/vhost/vhost.c:258
Read of size 8 at addr ffff8801b05432a8 by task syz-executor0/9644
CPU: 1 PID: 9644 Comm: syz-executor0 Not tainted 4.19.0-rc4-next-20180921+
#77
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+0x1d3/0x2c4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
vhost_work_queue+0xc3/0xe0 drivers/vhost/vhost.c:258
vhost_transport_send_pkt+0x28a/0x380 drivers/vhost/vsock.c:227
virtio_transport_send_pkt_info+0x31d/0x460
net/vmw_vsock/virtio_transport_common.c:190
virtio_transport_connect+0x17c/0x220
net/vmw_vsock/virtio_transport_common.c:588
vsock_stream_connect+0x4ed/0xe40 net/vmw_vsock/af_vsock.c:1200
__sys_connect+0x37d/0x4c0 net/socket.c:1665
__do_sys_connect net/socket.c:1676 [inline]
__se_sys_connect net/socket.c:1673 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1673
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457679
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f746bbf5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f746bbf66d4 RCX: 0000000000457679
RDX: 0000000000000010 RSI: 0000000020000200 RDI: 0000000000000009
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004cc658 R14: 00000000004bdcb3 R15: 0000000000000000
Allocated by task 9654:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:589 [inline]
kvmalloc_node+0xb9/0xf0 mm/util.c:423
kvmalloc include/linux/mm.h:577 [inline]
vhost_vsock_dev_open+0xa2/0x5a0 drivers/vhost/vsock.c:511
misc_open+0x3ca/0x560 drivers/char/misc.c:141
chrdev_open+0x25a/0x710 fs/char_dev.c:417
do_dentry_open+0x499/0x1250 fs/open.c:771
vfs_open+0xa0/0xd0 fs/open.c:880
do_last fs/namei.c:3418 [inline]
path_openat+0x12bc/0x5160 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_sys_open+0x568/0x700 fs/open.c:1063
__do_sys_openat fs/open.c:1090 [inline]
__se_sys_openat fs/open.c:1084 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1084
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 9643:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
kvfree+0x61/0x70 mm/util.c:452
vhost_vsock_free drivers/vhost/vsock.c:499 [inline]
vhost_vsock_dev_release+0x4f4/0x720 drivers/vhost/vsock.c:604
__fput+0x3bc/0xa70 fs/file_table.c:279
____fput+0x15/0x20 fs/file_table.c:312
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801b0543200
which belongs to the cache kmalloc-64k of size 65536
The buggy address is located 168 bytes inside of
65536-byte region [ffff8801b0543200, ffff8801b0553200)
The buggy address belongs to the page:
page:ffffea0006c15000 count:1 mapcount:0 mapping:ffff8801da802500 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000010200(slab|head)
raw: 02fffc0000010200 ffffea0006c14808 ffffea0006c15808 ffff8801da802500
raw: 0000000000000000 ffff8801b0543200 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b0543180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801b0543200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801b0543280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801b0543300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b0543380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* Re: [PATCH net] VSOCK: check sk state before receive
From: Hangbin Liu @ 2018-09-22 6:27 UTC (permalink / raw)
To: Jorgen S. Hansen; +Cc: Stefan Hajnoczi, netdev@vger.kernel.org, David S. Miller
In-Reply-To: <MWHPR05MB3376DF7EC1FEC4E9A4112F3BDA120@MWHPR05MB3376.namprd05.prod.outlook.com>
On Fri, Sep 21, 2018 at 07:48:25AM +0000, Jorgen S. Hansen wrote:
> Hi Hangbin,
>
> I finaly got to the bottom of this - the issue was indeed in the VMCI driver. The patch is posted here:
>
> https://lkml.org/lkml/2018/9/21/326
>
> I used your reproduce.log to test the fix. Thanks for discovering this issue.
Hi Jorgen,
Thanks for your patch. I built a test kernel with your fix, run my
reproducer and syzkaller socket vnet test for a while. There is no such
error. So I think your patch fixed this issue.
BTW, with FAULT_INJECTION enabled. I got another call trace:
[ 251.166377] FAULT_INJECTION: forcing a failure.
[ 251.178736] CPU: 15 PID: 10448 Comm: syz-executor7 Not tainted 4.19.0-rc4.syz.vnet+ #3
[ 251.187577] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.1.5 04/11/2016
[ 251.187578] Call Trace:
[ 251.187586] dump_stack+0x8c/0xce
[ 251.187594] should_fail+0x5dd/0x6b0
[ 251.199932] ? fault_create_debugfs_attr+0x1d0/0x1d0
[ 251.199937] __should_failslab+0xe8/0x120
[ 251.199945] should_failslab+0xa/0x20
[ 251.228430] kmem_cache_alloc_trace+0x43/0x1f0
[ 251.233392] ? vhost_dev_set_owner+0x366/0x790 [vhost]
[ 251.239129] vhost_dev_set_owner+0x366/0x790 [vhost]
[ 251.244672] ? vhost_poll_wakeup+0xa0/0xa0 [vhost]
[ 251.250018] ? kasan_unpoison_shadow+0x30/0x40
[ 251.254978] ? vhost_worker+0x370/0x370 [vhost]
[ 251.260035] ? kasan_kmalloc_large+0x71/0xe0
[ 251.264799] ? kmalloc_order+0x54/0x60
[ 251.268985] vhost_net_ioctl+0xc2e/0x14c0 [vhost_net]
[ 251.274635] ? avc_ss_reset+0x150/0x150
[ 251.278915] ? kstrtouint_from_user+0xe5/0x140
[ 251.283876] ? handle_tx_kick+0x40/0x40 [vhost_net]
[ 251.289320] ? save_stack+0x89/0xb0
[ 251.293213] ? __kasan_slab_free+0x12e/0x180
[ 251.297979] ? kmem_cache_free+0x7a/0x210
[ 251.302452] ? putname+0xe2/0x120
[ 251.306151] ? get_pid_task+0x6e/0x90
[ 251.310238] ? proc_fail_nth_write+0x91/0x1c0
[ 251.315100] ? map_files_get_link+0x3c0/0x3c0
[ 251.319963] ? exit_robust_list+0x1c0/0x1c0
[ 251.324633] ? __vfs_write+0xf7/0x6a0
[ 251.328711] ? handle_tx_kick+0x40/0x40 [vhost_net]
[ 251.334154] do_vfs_ioctl+0x1a5/0xfb0
[ 251.338241] ? ioctl_preallocate+0x1c0/0x1c0
[ 251.343009] ? selinux_file_ioctl+0x382/0x560
[ 251.347872] ? selinux_capable+0x40/0x40
[ 251.352250] ? __fget+0x211/0x2e0
[ 251.355949] ? iterate_fd+0x1c0/0x1c0
[ 251.360038] ? syscall_trace_enter+0x285/0xaa0
[ 251.365011] ? security_file_ioctl+0x5d/0xb0
[ 251.369776] ? selinux_capable+0x40/0x40
[ 251.374153] ksys_ioctl+0x89/0xa0
[ 251.377853] __x64_sys_ioctl+0x74/0xb0
[ 251.382036] do_syscall_64+0xc3/0x390
[ 251.386123] ? syscall_return_slowpath+0x14c/0x230
[ 251.391473] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 251.397111] RIP: 0033:0x451b89
[ 251.400519] Code: fc ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 0b 67 fc ff c3 66 2e 0f 1f 84 00 00 00 00
[ 251.421476] RSP: 002b:00007fc0d9673c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 251.429927] RAX: ffffffffffffffda RBX: 00007fc0d96746b4 RCX: 0000000000451b89
[ 251.437889] RDX: 0000000000000000 RSI: 000000000000af01 RDI: 0000000000000003
[ 251.445852] RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
[ 251.453815] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
[ 251.461778] R13: 0000000000006450 R14: 00000000004d3090 R15: 00007fc0d9674700
Thanks
Hangbin
^ permalink raw reply
* bpf: Massive skbuff_head_cache memory leak?
From: Tetsuo Handa @ 2018-09-22 13:25 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Network Development, LKML, David S. Miller
Hello.
syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
INFO: rcu detected stall in br_multicast_port_group_expired (2)
https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
INFO: rcu detected stall in tun_chr_close
https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
INFO: rcu detected stall in discover_timer
https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
INFO: rcu detected stall in ret_from_fork (2)
https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
INFO: rcu detected stall in addrconf_rs_timer
https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
INFO: rcu detected stall in kthread (2)
https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
INFO: rcu detected stall in ext4_filemap_fault
https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
INFO: rcu detected stall in run_timer_softirq (2)
https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
INFO: rcu detected stall in bpf_prog_ADDR
https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
INFO: rcu detected stall in __run_timers (2)
https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
The cause of lockup seems to be flood of printk() messages from memory allocation
failures, and one of out_of_memory() messages indicates that skbuff_head_cache
usage is huge enough to suspect in-kernel memory leaks.
[ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
Unfortunately, we cannot find from logs what syzbot is trying to do
because constant printk() messages is flooding away syzkaller messages.
Can you try running your testcases with kmemleak enabled?
^ permalink raw reply
* [PATCH] net-ethtool: ETHTOOL_GUFO did not and should not require CAP_NET_ADMIN
From: Maciej Żenczykowski @ 2018-09-22 8:34 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller; +Cc: netdev
From: Maciej Żenczykowski <maze@google.com>
So it should not fail with EPERM even though it is no longer implemented...
This is a fix for:
(userns)$ egrep ^Cap /proc/self/status
CapInh: 0000003fffffffff
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000003fffffffff
(userns)$ tcpdump -i usb_rndis0
tcpdump: WARNING: usb_rndis0: SIOCETHTOOL(ETHTOOL_GUFO) ioctl failed: Operation not permitted
Warning: Kernel filter failed: Bad file descriptor
tcpdump: can't remove kernel filter: Bad file descriptor
With this change it returns EOPNOTSUPP instead of EPERM.
See also https://github.com/the-tcpdump-group/libpcap/issues/689
Fixes: 08a00fea6de2 "net: Remove references to NETIF_F_UFO from ethtool."
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
net/core/ethtool.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 9d4e56d97080..96afc55aa61e 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -2536,6 +2536,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_GPHYSTATS:
case ETHTOOL_GTSO:
case ETHTOOL_GPERMADDR:
+ case ETHTOOL_GUFO:
case ETHTOOL_GGSO:
case ETHTOOL_GGRO:
case ETHTOOL_GFLAGS:
--
2.19.0.444.g18242da7ef-goog
^ permalink raw reply related
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Arnd Bergmann @ 2018-09-22 16:11 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Ard Biesheuvel, Eric Biggers, Linux Kernel Mailing List,
Networking, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
David Miller, gregkh, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <CAHmME9rJq=q7xj_E_84GN5FuzSW2KdP4Ch=y527Lem0ME4GnLg@mail.gmail.com>
On Thu, Sep 20, 2018 at 5:12 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hey Arnd,
>
> On Thu, Sep 20, 2018 at 6:02 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > Right, if you hit a stack requirement like this, it's usually the compiler
> > doing something bad, not just using too much stack but also generating
> > rather slow object code in the process. It's better to fix the bug by
> > optimizing the code to not spill registers to the stack.
> >
> > In the long run, I'd like to reduce the stack frame size further, so
> > best assume that anything over 1024 bytes (on 32-bit) or 1280 bytes
> > (on 64-bit) is a bug in the code, and stay below that.
> >
> > For prototyping, you can just mark the broken functions individually
> > by setting the warning limit for a specific function that is known to
> > be misoptimized by the compiler (with a comment about which compiler
> > and architectures are affected), but not override the limit for the
> > entire file.
>
> Thanks for the explanation. Fortunately in my case, the issues were
> trivially fixable to get it under 1024/1280
A lot of these bugs are not trivial, but we still need a full analysis of what
failed and what the possible mititgations are. Can you describe more
specifically what causes it?
> (By the way, why does
> 64-bit have a slightly larger stack frame? To account for 32 pointers
> taking double the space or something?) That will be rectified in v6.
Correct. We have some functions in the kernel that take 128 pointers
on the stack. This fits fine within the 1024 byte limit on 32 bit, but goes
beyond the same limit on 64 bit. Everything that took more than 1280
bytes (without KASAN) in my analysis was a real problem and reducing
the stack size fixed a bug or improved the code in other ways. I never got
around to reposting all those bug fixes I made back then, and there are
probably a couple new ones we'd need.
> There is one exception though: sometimes KASAN bloats the frame on
> 64-bit compiles. How would you feel about me adding
> 'ccflags-$(CONFIG_KASAN) += -Wframe-larger-than=16384' in my makefile?
I ran into several ciphers in the kernel that required a large stack allocation,
with or without KASAN. Typically these turned out to be optimization bugs
in gcc where gcc tried to be smart about optimizing part of the cipher that
was intentionally designed to not be optimizable, but in the process it
ended up spilling registers to the stack. Adding KASAN into the mix then
added an extra redzone around each of those.
My best approach here was to figure out which optimization step in gcc
caused the register spilling in the first place, and adjust the set of
optimizations done to a specific function in that cipher.
Note that some crypto ciphers are rather performance sensitive and we
have users that care about every percent of performance one can get
out. The bugs that cause the stack size explode beyond a few hundred
bytes that one might expect are usually the same bugs that make the
ciphers much slower than they should be even without KASAN.
For a cryptographic library it might therefore even make sense to have an
even smaller limit (e.g. 400 bytes) in the Makefile and then audit each
case that does not fit into that after determining what exactly caused the
problem, and making sure we find workaround that produces optmized
object code. When you end up with a function that gcc-8 still
misoptimizes in all optmization levels and you find no other workaround,
please set the higher limit specifically for that function with a gcc version
check in it, and add a comment pointing to the gcc bugzilla report you
have. gcc developers tend to be good about fixing these issues in new
compilers, but the version check helps to ensure we find it if a future
version regresses again, and of course we have to make sure we apply
the hack on all unpatched compilers.
> I'm not remotely close to reaching that limit (it's just a tiny bit
> over 1280), but it does seem like telling gcc to quiet down about
> stack frames when KASAN is being used might make sense. Alternatively,
> I see the defaults for FRAME_WARN are:
>
> config FRAME_WARN
> int "Warn for stack frames larger than (needs gcc 4.4)"
> range 0 8192
> default 3072 if KASAN_EXTRA
> default 2048 if GCC_PLUGIN_LATENT_ENTROPY
> default 1280 if (!64BIT && PARISC)
> default 1024 if (!64BIT && !PARISC)
> default 2048 if 64BIT
>
> What about changing that KASAN_EXTRA into just KASAN? This seems
> cleanest; I'll send a patch for it.
I saw you already posted a patch for that, sorry for not being able to
reply earlier. I actually spent several months of my work to introduce
the KASAN_EXTRA option specifically in order to have a separate
stack size limit for that, so I definitely object to that one. We need the
default (allmodconfig) stack size check to be as small as we can in
order to catch kernel and gcc bugs that bloat the stack more than
it is currently at.
> On the other hand, this KASAN behavior is only observable on 64-bit
> systems when I force it to be 1280, whereas the default is still 2048,
> so probably this isn't a problem *now* for this patchset. But it is
> something to think about for down the road when you lower the default
> frame.
Right. Some background about that limit: 2048 has been what we used
traditionally on 64-bit before KASAN. When I first saw the problems
with KASAN, I had a more detailed look at it and found that we can
significantly reduce it without KASAN, but obviously KASAN needs a
little extra space. I got all my patches upstream to get the KASAN
limit below 2048 and remove that special case for it, and I sent a
lot of the other patches to reduce the limit further to 1280/1535
without/with KASAN, but not all those patches got accepted, so for
the moment that traditional limit is still in place.
clang with KASAN still has known bugs that make it go beyond
2048 bytes, as I said in the other thread, and this is something that
first needs to be addressed in clang before we can take specific
measures in the kernel to work around any remaining unrelated
bugs with clang building our kernel with KASAN.
Arnd
^ permalink raw reply
* Re: [PATCH net 02/15] bonding: use netpoll_poll_dev() helper
From: Jay Vosburgh @ 2018-09-22 10:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, netdev, Michael Chan, Ariel Elior, Eric Dumazet,
Tariq Toukan, Saeed Mahameed, Jeff Kirsher, Jakub Kicinski,
Song Liu, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <20180921222752.101307-3-edumazet@google.com>
Eric Dumazet <edumazet@google.com> wrote:
>We want to allow NAPI drivers to no longer provide
>ndo_poll_controller() method, as it has been proven problematic.
>
>team driver must not look at its presence, but instead call
>netpoll_poll_dev() which factorize the needed actions.
This patch is for bonding, not team; otherwise LGTM.
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
-J
>Signed-off-by: Eric Dumazet <edumazet@google.com>
>Cc: Jay Vosburgh <j.vosburgh@gmail.com>
>Cc: Veaceslav Falico <vfalico@gmail.com>
>Cc: Andy Gospodarek <andy@greyhouse.net>
>---
> drivers/net/bonding/bond_main.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index a764a83f99dabe54585dbad7dba40b6601177c03..0d87e11e7f1d84537fe43d95249b1bd3a2ce291d 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -971,16 +971,13 @@ static void bond_poll_controller(struct net_device *bond_dev)
> struct slave *slave = NULL;
> struct list_head *iter;
> struct ad_info ad_info;
>- struct netpoll_info *ni;
>- const struct net_device_ops *ops;
>
> if (BOND_MODE(bond) == BOND_MODE_8023AD)
> if (bond_3ad_get_active_agg_info(bond, &ad_info))
> return;
>
> bond_for_each_slave_rcu(bond, slave, iter) {
>- ops = slave->dev->netdev_ops;
>- if (!bond_slave_is_up(slave) || !ops->ndo_poll_controller)
>+ if (!bond_slave_is_up(slave))
> continue;
>
> if (BOND_MODE(bond) == BOND_MODE_8023AD) {
>@@ -992,11 +989,7 @@ static void bond_poll_controller(struct net_device *bond_dev)
> continue;
> }
>
>- ni = rcu_dereference_bh(slave->dev->npinfo);
>- if (down_trylock(&ni->dev_lock))
>- continue;
>- ops->ndo_poll_controller(slave->dev);
>- up(&ni->dev_lock);
>+ netpoll_poll_dev(slave->dev);
> }
> }
>
>--
>2.19.0.444.g18242da7ef-goog
>
^ permalink raw reply
* [PATCH net] net: sched: act_ipt: check for underflow in __tcf_ipt_init()
From: Dan Carpenter @ 2018-09-22 13:46 UTC (permalink / raw)
To: Jamal Hadi Salim, Patrick McHardy
Cc: Cong Wang, Jiri Pirko, David S. Miller, netdev, kernel-janitors
If "td->u.target_size" is larger than sizeof(struct xt_entry_target) we
return -EINVAL. But we don't check whether it's smaller than
sizeof(struct xt_entry_target) and that could lead to an out of bounds
read.
Fixes: 7ba699c604ab ("[NET_SCHED]: Convert actions from rtnetlink to new netlink API")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
I haven't tested this. Please review carefully.
diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index 1efbfb10b1fc..8af6c11d2482 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -135,7 +135,7 @@ static int __tcf_ipt_init(struct net *net, unsigned int id, struct nlattr *nla,
}
td = (struct xt_entry_target *)nla_data(tb[TCA_IPT_TARG]);
- if (nla_len(tb[TCA_IPT_TARG]) < td->u.target_size) {
+ if (nla_len(tb[TCA_IPT_TARG]) != td->u.target_size) {
if (exists)
tcf_idr_release(*a, bind);
else
^ permalink raw reply related
* Re: [PATCH net] net: phy: fix WoL handling when suspending the PHY
From: Andrew Lunn @ 2018-09-22 16:44 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <4dbcdd2c-96c2-2921-5016-affc8fce1d19@gmail.com>
On Sat, Sep 22, 2018 at 01:32:55AM +0200, Heiner Kallweit wrote:
> Actually there's nothing wrong with the two changes, they just
> revealed a problem which has been existing before.
Hi Heiner
This is missing a bit of context. Which two changes? I assume you mean
the two Fixes:
>
> Core of the problem is that phy_suspend() suspends the PHY when it
> should not because of WoL. phy_suspend() checks for WoL already, but
> this works only if the PHY driver handles WoL (what is rarely the case).
> Typically WoL is handled by the MAC driver.
>
> phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
> but that's used only when suspending the system, not in other cases
> like shutdown.
>
> This patch basically moves the check for WoL having been activated
> by the MAC driver into phy_suspend(). mdio_bus_phy_resume() now
> resumes the PHY only if it's actually suspended. Also don't do
> anything in phy_suspend() if the PHY is suspended already.
>
> Last but not least change phy_detach() to call phy_suspend() before
> attached_dev is set to NULL. phy_suspend() accesses attached_dev
> when checking whether the MAC driver activated WoL.
This sounds like it should be multiple patches, not one. Can it be
split, or is there two much inter connectivity? Being able to bisect
could be useful here.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH rdma-next v1 0/7] Preparation to DevX extension series
From: Jason Gunthorpe @ 2018-09-22 17:02 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180920183526.13995-1-leon@kernel.org>
On Thu, Sep 20, 2018 at 09:35:19PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Changelog v0->v1:
> * Update commit messages
> * Split DevX series to small sub-series.
> * Change static initialization from {0} to be {}
>
>
> Set uid as part of various IB commands so that the firmware can manage
> the IB object in a secured way.
>
> The firmware should mark this IB object with the given uid so that it
> can be used later on only by objects with the same uid.
>
> Upon DEVX flows that use this objec, the pointed object must have
> the same uid as of the issuer uid command.
>
> When a command is issued with uid=0 it means that the issuer of the
> command is trusted (i.e. kernel), in that case any pointed object
> can be used regardless of its uid.
>
> Thanks
>
> Leon Romanovsky (1):
> net/mlx5: Update mlx5_ifc with DEVX UID bits
>
> Yishai Hadas (6):
> net/mlx5: Set uid as part of CQ commands
> net/mlx5: Set uid as part of QP commands
> net/mlx5: Set uid as part of RQ commands
> net/mlx5: Set uid as part of SQ commands
> net/mlx5: Set uid as part of SRQ commands
> net/mlx5: Set uid as part of DCT commands
This and the next series look OK to me. Let me know when it is applied
to the mlx branch
Thanks,
Jason
^ permalink raw reply
* [net-next:master 569/583] htmldocs: include/linux/skbuff.h:860: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff'
From: kbuild test robot @ 2018-09-22 10:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 19318 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: bd4d08daeb959234a9f8365037b0fefa6ae790c6
commit: d3edd06ea8ea9e03de6567fda80b8be57e21a537 [569/583] tcp: provide earliest departure time in skb->tstamp
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
include/net/cfg80211.h:4882: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4882: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4882: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4882: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4882: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/mac80211.h:2367: warning: Function parameter or member 'radiotap_timestamp.units_pos' not described in 'ieee80211_hw'
include/net/mac80211.h:2367: warning: Function parameter or member 'radiotap_timestamp.accuracy' not described in 'ieee80211_hw'
include/net/mac80211.h:978: warning: Function parameter or member 'control.rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info'
include/net/mac80211.h:978: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info'
net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.cb' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.poll' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.active' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.cb' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.poll' not described in 'dma_buf'
include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.active' not described in 'dma_buf'
include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array'
include/linux/gpio/driver.h:142: warning: Function parameter or member 'request_key' not described in 'gpio_irq_chip'
include/linux/iio/hw-consumer.h:1: warning: no structured comments found
include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not described in 'key_entry'
drivers/pci/pci.c:218: warning: Excess function parameter 'p' description in 'pci_dev_str_match_path'
include/linux/regulator/driver.h:227: warning: Function parameter or member 'resume' not described in 'regulator_ops'
drivers/regulator/core.c:4479: warning: Excess function parameter 'state' description in 'regulator_suspend'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw0' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw1' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw2' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw3' not described in 'irb'
arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.eadm' not described in 'irb'
drivers/slimbus/stream.c:1: warning: no structured comments found
drivers/target/target_core_device.c:1: warning: no structured comments found
drivers/usb/typec/bus.c:1: warning: no structured comments found
drivers/usb/typec/class.c:1: warning: no structured comments found
include/linux/w1.h:281: warning: Function parameter or member 'of_match_table' not described in 'w1_family'
fs/direct-io.c:257: warning: Excess function parameter 'offset' description in 'dio_complete'
fs/file_table.c:1: warning: no structured comments found
fs/libfs.c:477: warning: Excess function parameter 'available' description in 'simple_write_end'
fs/posix_acl.c:646: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode'
fs/posix_acl.c:646: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode'
fs/posix_acl.c:646: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode'
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:183: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock'
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:254: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_invalidate_range_start_gfx'
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:302: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_invalidate_range_start_hsa'
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3011: warning: Excess function parameter 'dev' description in 'amdgpu_vm_get_task_info'
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3012: warning: Function parameter or member 'adev' not described in 'amdgpu_vm_get_task_info'
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3012: warning: Excess function parameter 'dev' description in 'amdgpu_vm_get_task_info'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_pin' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_unpin' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_res_obj' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_get_sg_table' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_import_sg_table' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_vmap' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_vunmap' not described in 'drm_driver'
include/drm/drm_drv.h:610: warning: Function parameter or member 'gem_prime_mmap' not described in 'drm_driver'
include/drm/drm_panel.h:98: warning: Function parameter or member 'link' not described in 'drm_panel'
drivers/gpu/drm/i915/i915_vma.h:49: warning: cannot understand function prototype: 'struct i915_vma '
drivers/gpu/drm/i915/i915_vma.h:1: warning: no structured comments found
drivers/gpu/drm/i915/intel_guc_fwif.h:553: warning: cannot understand function prototype: 'struct guc_log_buffer_state '
drivers/gpu/drm/i915/i915_trace.h:1: warning: no structured comments found
include/linux/skbuff.h:860: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'list' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff'
>> include/linux/skbuff.h:860: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'head_frag' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'encapsulation' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'encap_hdr_csum' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'csum_valid' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'csum_complete_sw' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'csum_level' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'inner_protocol_type' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'remcsum_offload' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'offload_fwd_mark' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'offload_mr_fwd_mark' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'sender_cpu' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'reserved_tailroom' not described in 'sk_buff'
include/linux/skbuff.h:860: warning: Function parameter or member 'inner_ipproto' not described in 'sk_buff'
include/net/sock.h:238: warning: Function parameter or member 'skc_addrpair' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_portpair' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_ipv6only' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_net_refcnt' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_v6_daddr' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_v6_rcv_saddr' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_cookie' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_listener' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_tw_dr' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_rcv_wnd' not described in 'sock_common'
include/net/sock.h:238: warning: Function parameter or member 'skc_tw_rcv_nxt' not described in 'sock_common'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.rmem_alloc' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.len' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.head' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_backlog.tail' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_wq_raw' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'tcp_rtx_queue' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_route_forced_caps' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_txtime_report_errors' not described in 'sock'
include/net/sock.h:509: warning: Function parameter or member 'sk_validate_xmit_skb' not described in 'sock'
include/linux/netdevice.h:2043: warning: Function parameter or member 'adj_list.upper' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'adj_list.lower' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'gso_partial_features' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'switchdev_ops' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'l3mdev_ops' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'xfrmdev_ops' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'tlsdev_ops' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'name_assign_type' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'ieee802154_ptr' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'mpls_ptr' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'xdp_prog' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'gro_flush_timeout' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'nf_hooks_ingress' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member '____cacheline_aligned_in_smp' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'qdisc_hash' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'xps_cpus_map' not described in 'net_device'
include/linux/netdevice.h:2043: warning: Function parameter or member 'xps_rxqs_map' not described in 'net_device'
include/linux/phylink.h:56: warning: Function parameter or member '__ETHTOOL_DECLARE_LINK_MODE_MASK(advertising' not described in 'phylink_link_state'
include/linux/phylink.h:56: warning: Function parameter or member '__ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising' not described in 'phylink_link_state'
sound/soc/soc-core.c:2918: warning: Excess function parameter 'legacy_dai_naming' description in 'snd_soc_register_dais'
Documentation/admin-guide/cgroup-v2.rst:1485: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/admin-guide/cgroup-v2.rst:1487: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/admin-guide/cgroup-v2.rst:1488: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/core-api/boot-time-mm.rst:78: ERROR: Error in "kernel-doc" directive:
unknown option: "nodocs".
vim +860 include/linux/skbuff.h
^1da177e Linus Torvalds 2005-04-16 @860
:::::: The code at line 860 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6571 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: phy: fix WoL handling when suspending the PHY
From: Heiner Kallweit @ 2018-09-22 17:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <20180922164441.GB13316@lunn.ch>
On 22.09.2018 18:44, Andrew Lunn wrote:
> On Sat, Sep 22, 2018 at 01:32:55AM +0200, Heiner Kallweit wrote:
>> Actually there's nothing wrong with the two changes, they just
>> revealed a problem which has been existing before.
>
> Hi Heiner
>
> This is missing a bit of context. Which two changes? I assume you mean
> the two Fixes:
>
Right. I should have mentioned that the actual trigger were
reported problems with WoL.
>>
>> Core of the problem is that phy_suspend() suspends the PHY when it
>> should not because of WoL. phy_suspend() checks for WoL already, but
>> this works only if the PHY driver handles WoL (what is rarely the case).
>> Typically WoL is handled by the MAC driver.
>>
>> phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
>> but that's used only when suspending the system, not in other cases
>> like shutdown.
>>
>> This patch basically moves the check for WoL having been activated
>> by the MAC driver into phy_suspend(). mdio_bus_phy_resume() now
>> resumes the PHY only if it's actually suspended. Also don't do
>> anything in phy_suspend() if the PHY is suspended already.
>>
>> Last but not least change phy_detach() to call phy_suspend() before
>> attached_dev is set to NULL. phy_suspend() accesses attached_dev
>> when checking whether the MAC driver activated WoL.
>
> This sounds like it should be multiple patches, not one. Can it be
> split, or is there two much inter connectivity? Being able to bisect
> could be useful here.
>
I could split it to two patches:
1. Add phy_may_suspend() and use it in phy_suspend()
2. Remove mdio_bus_phy_may_suspend() and change mdio_bus_phy_suspend()
and mdio_bus_phy_resume()
Heiner
> Thanks
> Andrew
>
^ permalink raw reply
* Re: [PATCH net-next,v2,0/3] hv_netvsc: Support LRO/RSC in the vSwitch
From: David Miller @ 2018-09-23 0:23 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: olaf, sthemmin, netdev, linux-kernel, devel, vkuznets
In-Reply-To: <20180921182037.10077-1-haiyangz@linuxonhyperv.com>
From: Haiyang Zhang <haiyangz@linuxonhyperv.com>
Date: Fri, 21 Sep 2018 18:20:34 +0000
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> The patch adds support for LRO/RSC in the vSwitch feature. It reduces
> the per packet processing overhead by coalescing multiple TCP segments
> when possible. The feature is enabled by default on VMs running on
> Windows Server 2019 and later.
>
> The patch set also adds ethtool command handler and documents.
Series applied, thank you.
^ permalink raw reply
* [PATCH] net: phy: phylink: fix SFP interface autodetection
From: Baruch Siach @ 2018-09-22 19:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli
Cc: netdev, Russell King, Antoine Tenart, Gregory CLEMENT,
Baruch Siach
When connecting a PHY to phylink use the detected interface. Otherwise,
the link fails to come up when the configured 'phy-mode' differs from
the SFP detected mode.
This fixes 1GB SFP module link up on eth3 of the Macchiatobin board that
is configured in the DT to "2500base-x" phy-mode.
Fixes: 9525ae83959b6 ("phylink: add phylink infrastructure")
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/phy/phylink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 3ba5cf2a8a5f..aa745decc81d 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -738,7 +738,7 @@ int phylink_connect_phy(struct phylink *pl, struct phy_device *phy)
if (WARN_ON(pl->link_an_mode == MLO_AN_FIXED ||
(pl->link_an_mode == MLO_AN_INBAND &&
- phy_interface_mode_is_8023z(pl->link_interface))))
+ phy_interface_mode_is_8023z(pl->link_config.interface))))
return -EINVAL;
if (pl->phydev)
@@ -750,7 +750,7 @@ int phylink_connect_phy(struct phylink *pl, struct phy_device *phy)
pl->link_config.interface = pl->link_interface;
}
- ret = phy_attach_direct(pl->netdev, phy, 0, pl->link_interface);
+ ret = phy_attach_direct(pl->netdev, phy, 0, pl->link_config.interface);
if (ret)
return ret;
--
2.19.0
^ permalink raw reply related
* Re: [PATCH] net: phy: phylink: fix SFP interface autodetection
From: Russell King - ARM Linux @ 2018-09-22 19:18 UTC (permalink / raw)
To: Baruch Siach
Cc: Andrew Lunn, Florian Fainelli, netdev, Antoine Tenart,
Gregory CLEMENT
In-Reply-To: <be339ca81893a87e382a41da84d17850a4cfe940.1537643384.git.baruch@tkos.co.il>
On Sat, Sep 22, 2018 at 10:09:44PM +0300, Baruch Siach wrote:
> When connecting a PHY to phylink use the detected interface. Otherwise,
> the link fails to come up when the configured 'phy-mode' differs from
> the SFP detected mode.
>
> This fixes 1GB SFP module link up on eth3 of the Macchiatobin board that
> is configured in the DT to "2500base-x" phy-mode.
What I actually meant is that a PHY attached from a SFP interface
should use link_config.interface. A PHY attached as not part of
a SFP interface should continue using the DT-parsed link_interface.
What I envisaged seeing is phylink_connect_phy() being renamed to
__phylink_connect_phy(), and taking the phy interface,
phylink_sfp_connect_phy() calling __phylink_connect_phy() with
link_config.interface, and a replacement phylink_connect_phy() which
called __phylink_connect_phy() with link_interface.
Sorry I wasn't explicit enough last time around.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH net-next v2] net: phy: don't reschedule state machine when PHY is halted
From: Florian Fainelli @ 2018-09-22 19:21 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <47ddfc78-61ce-3ebd-df10-ca291620c61f@gmail.com>
On September 20, 2018 1:34:25 PM PDT, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>When being in state PHY_HALTED we don't have to reschedule the
>state machine, phy_start() will start it again.
>
>Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH iproute2 0/7] Minor shell code cleanup
From: Petr Vorel @ 2018-09-22 21:24 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel, Stephen Hemminger
Hi,
this patchset does minor cleanup in shell scripts:
* remove bashisms
* use /bin/sh shebang
* remove obsolete code from examples
* remove unused code
Kind regards,
Petr
Petr Vorel (7):
man: rtpr: Rename s/bash/shell/
tests: Use /bin/sh shebang
configure: Remove unused function check_prog()
configure: Remove non-posix shell expansion
configure: Code cleanup
examples: Remove dhcp-client-script
examples: Remove cbq.init-v0.7.3
configure | 76 +--
examples/cbq.init-v0.7.3 | 983 -------------------------------
examples/dhcp-client-script | 446 --------------
man/man8/rtpr.8 | 2 +-
testsuite/tests/tc/cls-testbed.t | 4 +-
testsuite/tests/tc/dsmark.t | 2 +-
6 files changed, 25 insertions(+), 1488 deletions(-)
delete mode 100644 examples/cbq.init-v0.7.3
delete mode 100644 examples/dhcp-client-script
--
2.19.0.rc2
^ permalink raw reply
* [PATCH iproute2 1/7] man: rtpr: Rename s/bash/shell/
From: Petr Vorel @ 2018-09-22 21:24 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel, Stephen Hemminger
In-Reply-To: <20180922212451.327-1-petr.vorel@gmail.com>
ip/rtpr mentioned in man as bash script is actually posix shell script
(doesn't require to use bash).
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
---
man/man8/rtpr.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man8/rtpr.8 b/man/man8/rtpr.8
index 1b04a821..87f291ab 100644
--- a/man/man8/rtpr.8
+++ b/man/man8/rtpr.8
@@ -5,7 +5,7 @@ rtpr \- replace backslashes with newlines.
.SH DESCRIPTION
.B rtpr
-is a trivial bash script which converts backslashes in standard input to newlines. It's sole purpose is to be fed with input from
+is a trivial shell script which converts backslashes in standard input to newlines. It's sole purpose is to be fed with input from
.B ip
when executed with it's
.B --oneline
--
2.19.0.rc2
^ 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