* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 10:38 UTC (permalink / raw)
To: Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <be1aebb5-fee7-e079-d864-a2e4aa13007f@gmail.com>
On 2019/7/24 18:13, Eric Dumazet wrote:
>
>
> On 7/24/19 12:01 PM, Eric Dumazet wrote:
>>
>>
>> On 7/24/19 11:17 AM, Mao Wenan wrote:
>>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>>
>> Current stable 4.4 is 4.4.186
>>
>> Can you check the bug is still there ?
>>
>
> BTW, I tried the C repro and another bug showed up.
>
> It looks like 4.4.186 misses other fixes :/
I will try 4.4.186.
>
> [ 180.811610] skbuff: skb_under_panic: text:ffffffff825ec6ea len:156 put:84 head:ffff8837dd1f0990 data:ffff8837dd1f098c tail:0x98 end:0xc0 dev:ip6gre0
> [ 180.825037] ------------[ cut here ]------------
> [ 180.829688] kernel BUG at net/core/skbuff.c:104!
> [ 180.834316] invalid opcode: 0000 [#1] SMP KASAN
> [ 180.839305] gsmi: Log Shutdown Reason 0x03
> [ 180.843426] Modules linked in: ipip bonding bridge stp llc tun veth w1_therm wire i2c_mux_pca954x i2c_mux cdc_acm ehci_pci ehci_hcd ip_gre mlx4_en ib_uverbs mlx4_ib ib_sa ib_mad ib_core ib_addr mlx4_core
> [ 180.862052] CPU: 22 PID: 1619 Comm: kworker/22:1 Not tainted 4.4.186-smp-DEV #41
> [ 180.869475] Hardware name: Intel BIOS 2.56.0 10/19/2018
> [ 180.876463] Workqueue: ipv6_addrconf addrconf_dad_work
> [ 180.881658] task: ffff8837f1f59d80 ti: ffff8837eeeb8000 task.ti: ffff8837eeeb8000
> [ 180.889171] RIP: 0010:[<ffffffff821ef26f>] [<ffffffff821ef26f>] skb_panic+0x14f/0x210
> [ 180.897162] RSP: 0018:ffff8837eeebf4b8 EFLAGS: 00010282
> [ 180.902504] RAX: 0000000000000088 RBX: ffff8837eeeeb600 RCX: 0000000000000000
> [ 180.909645] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffffffff83508c00
> [ 180.916854] RBP: ffff8837eeebf520 R08: 0000000000000016 R09: 0000000000000000
> [ 180.924029] R10: ffff881fc8abf038 R11: 0000000000000007 R12: ffff881fc8abe720
> [ 180.931213] R13: ffffffff82aa9e80 R14: 00000000000000c0 R15: 0000000000000098
> [ 180.938390] FS: 0000000000000000(0000) GS:ffff8837ff280000(0000) knlGS:0000000000000000
> [ 180.946519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 180.952290] CR2: 00007f519426f530 CR3: 00000037d37f2000 CR4: 0000000000160670
> [ 180.959447] Stack:
> [ 180.961458] ffff8837dd1f098c 0000000000000098 00000000000000c0 ffff881fc8abe720
> [ 180.968909] ffffea00df747c00 ffff881fff404b40 ffff8837ff2a1a20 ffff8837eeebf5b8
> [ 180.976371] ffff8837eeeeb600 ffffffff825ec6ea 1ffff106fddd7eb6 ffff8837eeeeb600
> [ 180.983848] Call Trace:
> [ 180.986297] [<ffffffff825ec6ea>] ? ip6gre_header+0xba/0xd50
> [ 180.991962] [<ffffffff821f0e01>] skb_push+0xc1/0x100
> [ 180.997023] [<ffffffff825ec6ea>] ip6gre_header+0xba/0xd50
> [ 181.002519] [<ffffffff8158dc16>] ? memcpy+0x36/0x40
> [ 181.007509] [<ffffffff825ec630>] ? ip6gre_changelink+0x6d0/0x6d0
> [ 181.013629] [<ffffffff82550741>] ? ndisc_constructor+0x5b1/0x770
> [ 181.019728] [<ffffffff82666861>] ? _raw_write_unlock_bh+0x41/0x50
> [ 181.025924] [<ffffffff8226540b>] ? __neigh_create+0xe6b/0x1670
> [ 181.031851] [<ffffffff8225817f>] neigh_connected_output+0x23f/0x480
> [ 181.038219] [<ffffffff824f61ec>] ip6_finish_output2+0x74c/0x1a90
> [ 181.044324] [<ffffffff810f1d33>] ? print_context_stack+0x73/0xf0
> [ 181.050429] [<ffffffff824f5aa0>] ? ip6_xmit+0x1700/0x1700
> [ 181.055933] [<ffffffff82304a28>] ? nf_hook_slow+0x118/0x1b0
> [ 181.061617] [<ffffffff82502d7a>] ip6_finish_output+0x2ba/0x580
> [ 181.067546] [<ffffffff82503179>] ip6_output+0x139/0x380
> [ 181.072884] [<ffffffff82503040>] ? ip6_finish_output+0x580/0x580
> [ 181.079004] [<ffffffff82502ac0>] ? ip6_fragment+0x31b0/0x31b0
> [ 181.084852] [<ffffffff82251b51>] ? dst_init+0x4b1/0x820
> [ 181.090172] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
> [ 181.096437] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
> [ 181.102712] [<ffffffff8254f3ca>] NF_HOOK_THRESH.constprop.22+0xca/0x180
> [ 181.109421] [<ffffffff8254f300>] ? ndisc_alloc_skb+0x340/0x340
> [ 181.115338] [<ffffffff8254d820>] ? compat_ipv6_setsockopt+0x180/0x180
> [ 181.121874] [<ffffffff8254fbc2>] ndisc_send_skb+0x742/0xd10
> [ 181.127550] [<ffffffff8254f480>] ? NF_HOOK_THRESH.constprop.22+0x180/0x180
> [ 181.134516] [<ffffffff821f2440>] ? skb_complete_tx_timestamp+0x280/0x280
> [ 181.141311] [<ffffffff8254e2b3>] ? ndisc_fill_addr_option+0x193/0x260
> [ 181.147844] [<ffffffff82553bd9>] ndisc_send_rs+0x179/0x2d0
> [ 181.153426] [<ffffffff8251e7df>] addrconf_dad_completed+0x41f/0x7c0
> [ 181.159795] [<ffffffff81297f78>] ? pick_next_entity+0x198/0x470
> [ 181.165807] [<ffffffff8251e3c0>] ? addrconf_rs_timer+0x4a0/0x4a0
> [ 181.171918] [<ffffffff81aab928>] ? find_next_bit+0x18/0x20
> [ 181.177504] [<ffffffff81a99ec9>] ? prandom_seed+0xd9/0x160
> [ 181.183095] [<ffffffff8251eef5>] addrconf_dad_work+0x375/0x9e0
> [ 181.189024] [<ffffffff8251eb80>] ? addrconf_dad_completed+0x7c0/0x7c0
> [ 181.195576] [<ffffffff81249d8f>] process_one_work+0x52f/0xf60
> [ 181.201468] [<ffffffff8124a89d>] worker_thread+0xdd/0xe80
> [ 181.206977] [<ffffffff8265cf0a>] ? __schedule+0x73a/0x16d0
> [ 181.212550] [<ffffffff8124a7c0>] ? process_one_work+0xf60/0xf60
> [ 181.218572] [<ffffffff8125a115>] kthread+0x205/0x2b0
> [ 181.223633] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
> [ 181.229743] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
> [ 181.235834] [<ffffffff8266726f>] ret_from_fork+0x3f/0x70
> [ 181.241232] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
>
>
> .
>
^ permalink raw reply
* [PATCH] net: 9p: Fix possible null-pointer dereferences in p9_cm_event_handler()
From: Jia-Ju Bai @ 2019-07-24 10:39 UTC (permalink / raw)
To: ericvh, lucho, asmadeus, davem
Cc: v9fs-developer, netdev, linux-kernel, Jia-Ju Bai
In p9_cm_event_handler(), there is an if statement on 260 to check
whether rdma is NULL, which indicates that rdma can be NULL.
If so, using rdma->xxx may cause a possible null-pointer dereference.
To fix these bugs, rdma is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/9p/trans_rdma.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
index bac8dad5dd69..eba3c5fc2731 100644
--- a/net/9p/trans_rdma.c
+++ b/net/9p/trans_rdma.c
@@ -242,18 +242,24 @@ p9_cm_event_handler(struct rdma_cm_id *id, struct rdma_cm_event *event)
struct p9_trans_rdma *rdma = c->trans;
switch (event->event) {
case RDMA_CM_EVENT_ADDR_RESOLVED:
- BUG_ON(rdma->state != P9_RDMA_INIT);
- rdma->state = P9_RDMA_ADDR_RESOLVED;
+ if (rdma) {
+ BUG_ON(rdma->state != P9_RDMA_INIT);
+ rdma->state = P9_RDMA_ADDR_RESOLVED;
+ }
break;
case RDMA_CM_EVENT_ROUTE_RESOLVED:
- BUG_ON(rdma->state != P9_RDMA_ADDR_RESOLVED);
- rdma->state = P9_RDMA_ROUTE_RESOLVED;
+ if (rdma) {
+ BUG_ON(rdma->state != P9_RDMA_ADDR_RESOLVED);
+ rdma->state = P9_RDMA_ROUTE_RESOLVED;
+ }
break;
case RDMA_CM_EVENT_ESTABLISHED:
- BUG_ON(rdma->state != P9_RDMA_ROUTE_RESOLVED);
- rdma->state = P9_RDMA_CONNECTED;
+ if (rdma) {
+ BUG_ON(rdma->state != P9_RDMA_ROUTE_RESOLVED);
+ rdma->state = P9_RDMA_CONNECTED;
+ }
break;
case RDMA_CM_EVENT_DISCONNECTED:
@@ -277,12 +283,14 @@ p9_cm_event_handler(struct rdma_cm_id *id, struct rdma_cm_event *event)
case RDMA_CM_EVENT_ADDR_ERROR:
case RDMA_CM_EVENT_UNREACHABLE:
c->status = Disconnected;
- rdma_disconnect(rdma->cm_id);
+ if (rdma)
+ rdma_disconnect(rdma->cm_id);
break;
default:
BUG();
}
- complete(&rdma->cm_done);
+ if (rdma)
+ complete(&rdma->cm_done);
return 0;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Eric Dumazet @ 2019-07-24 10:44 UTC (permalink / raw)
To: maowenan, Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <8e02f190-ec3a-6308-8c59-e5ae9ca39f5d@huawei.com>
On 7/24/19 12:36 PM, maowenan wrote:
> Actually, I have tested 4.4.184, UAF still happen.
>
>
Thanks for testing.
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 10:46 UTC (permalink / raw)
To: Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <2e09f4d1-8a47-27e9-60f9-63d3b19a98ec@gmail.com>
On 2019/7/24 17:45, Eric Dumazet wrote:
>
>
> On 7/24/19 11:17 AM, Mao Wenan wrote:
>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>>
>> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
>> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
>> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
>> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
>>
>> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
>> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
>> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
>> Call Trace:
>> [<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
>> [<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
>> [<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
>> [<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
>> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
>> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
>> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
>> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
>> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
>> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
>> [<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
>> [<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
>> [<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
>> [<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
>> [<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
>> [<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
>> [<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
>> [<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
>> [<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
>> [<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
>> [<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
>> [<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
>> [<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
>> [<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
>> [<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
>> [<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
>> [<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
>>
>> Allocated by task 4194:
>> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
>> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
>> [<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
>> [<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
>> [<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
>> [<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
>> [<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
>> [<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
>> [<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
>> [<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
>> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
>> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
>> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
>> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
>> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
>> [<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
>> [<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
>> [<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
>> [<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
>> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>>
>> Freed by task 4194:
>> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
>> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
>> [<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
>> [<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
>> [<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
>> [<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
>> [<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
>> [<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
>> [<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
>> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
>> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
>> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
>> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
>> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
>> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
>> [<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
>> [<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
>> [<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
>> [<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
>> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>>
>> Syzkaller reproducer():
>> r0 = socket$packet(0x11, 0x3, 0x300)
>> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
>> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
>> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
>> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
>> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
>> r2 = fcntl$dupfd(r1, 0x0, r0)
>> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>>
>> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
>>
>> This is because when tcp_connect_init call tcp_write_queue_purge, it will
>> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
>> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
>>
>> Signed-off-by: Mao Wenan <maowenan@huawei.com>
>> ---
>> include/net/tcp.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index bf8a0dae977a..8f8aace28cf8 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
>>
>> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
>> sk_wmem_free_skb(sk, skb);
>> + sk->sk_send_head = NULL;
>> sk_mem_reclaim(sk);
>> tcp_clear_all_retrans_hints(tcp_sk(sk));
>> inet_csk(sk)->icsk_backoff = 0;
>>
>
> This is strange, because tcp_init_send_head() is called from tcp_disconnect()
> which is the syzkaller way to trigger this kind of bugs.
>
syzkaller reproduce program duplicate one socket that have multiple skb in write queue,
and new socket have purged skb but original socket still try to send skb. In this program,
it does not call tcp_disconnect?
>
> I suspect there is another root cause.
>
>
>
> .
>
^ permalink raw reply
* RE: [PATCH v3 6/7] net: Rename skb_frag_t size to bv_len
From: David Laight @ 2019-07-24 10:49 UTC (permalink / raw)
To: 'Matthew Wilcox', davem@davemloft.net
Cc: hch@lst.de, netdev@vger.kernel.org
In-Reply-To: <20190723030831.11879-7-willy@infradead.org>
From: Matthew Wilcox
> Sent: 23 July 2019 04:09
> Improved compatibility with bvec
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> include/linux/skbuff.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 8076e2ba8349..e849e411d1f3 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -312,7 +312,7 @@ typedef struct skb_frag_struct skb_frag_t;
>
> struct skb_frag_struct {
> struct page *bv_page;
> - __u32 size;
> + unsigned int bv_len;
> __u32 page_offset;
> };
This is 'just plain stupid'.
The 'bv_' prefix of the members of 'struct bvec' is there so that 'grep'
(etc) can be used to find the uses of the members.
In a 'struct skb_frag_struct' a sensible prefix might be 'sf_'.
OTOH it might be sensible to use (or embed) a 'struct bvec'
instead of 'skb_frag_struct'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Greg KH @ 2019-07-24 11:05 UTC (permalink / raw)
To: Mao Wenan; +Cc: stable, davem, netdev, linux-kernel
In-Reply-To: <20190724091715.137033-1-maowenan@huawei.com>
On Wed, Jul 24, 2019 at 05:17:15PM +0800, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
>
> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
> Call Trace:
> [<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
> [<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
> [<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
> [<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
> [<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
> [<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
> [<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
> [<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
> [<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
> [<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
> [<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
> [<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
> [<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
> [<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
> [<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
> [<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
> [<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
> [<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
> [<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
> [<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
> [<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
>
> Allocated by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
> [<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
> [<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
> [<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
> [<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
> [<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
> [<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
> [<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
> [<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
> [<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
> [<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Freed by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
> [<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
> [<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
> [<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
> [<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
> [<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
> [<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
> [<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
> [<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
> [<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Syzkaller reproducer():
> r0 = socket$packet(0x11, 0x3, 0x300)
> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
> r2 = fcntl$dupfd(r1, 0x0, r0)
> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>
> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
>
> This is because when tcp_connect_init call tcp_write_queue_purge, it will
> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> include/net/tcp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index bf8a0dae977a..8f8aace28cf8 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
>
> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
> sk_wmem_free_skb(sk, skb);
> + sk->sk_send_head = NULL;
> sk_mem_reclaim(sk);
> tcp_clear_all_retrans_hints(tcp_sk(sk));
> inet_csk(sk)->icsk_backoff = 0;
Does this corrispond with a specific commit that is already in Linus's
tree? If not, why, did we change/mess something up when doing
backports, or is the code just that different?
Also, is this needed in 4.9.y, 4.14.y, 4.19.y, and/or 5.2.y? Why just
4.4.y?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-24 11:10 UTC (permalink / raw)
To: Jose Abreu, Ilias Apalodimas
Cc: David Miller, robin.murphy@arm.com, lists@bofh.nu,
Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
maxime.ripard@bootlin.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB3269C5766F553438ECFF2C9BD3C60@BYAPR12MB3269.namprd12.prod.outlook.com>
On 24/07/2019 11:04, Jose Abreu wrote:
...
> Jon, I was able to replicate (at some level) your setup:
>
> # dmesg | grep -i arm-smmu
> [ 1.337322] arm-smmu 70040000.iommu: probing hardware
> configuration...
> [ 1.337330] arm-smmu 70040000.iommu: SMMUv2 with:
> [ 1.337338] arm-smmu 70040000.iommu: stage 1 translation
> [ 1.337346] arm-smmu 70040000.iommu: stage 2 translation
> [ 1.337354] arm-smmu 70040000.iommu: nested translation
> [ 1.337363] arm-smmu 70040000.iommu: stream matching with 128
> register groups
> [ 1.337374] arm-smmu 70040000.iommu: 1 context banks (0
> stage-2 only)
> [ 1.337383] arm-smmu 70040000.iommu: Supported page sizes:
> 0x61311000
> [ 1.337393] arm-smmu 70040000.iommu: Stage-1: 48-bit VA ->
> 48-bit IPA
> [ 1.337402] arm-smmu 70040000.iommu: Stage-2: 48-bit IPA ->
> 48-bit PA
>
> # dmesg | grep -i stmmac
> [ 1.344106] stmmaceth 70000000.ethernet: Adding to iommu group 0
> [ 1.344233] stmmaceth 70000000.ethernet: no reset control found
> [ 1.348276] stmmaceth 70000000.ethernet: User ID: 0x10, Synopsys ID:
> 0x51
> [ 1.348285] stmmaceth 70000000.ethernet: DWMAC4/5
> [ 1.348293] stmmaceth 70000000.ethernet: DMA HW capability register
> supported
> [ 1.348302] stmmaceth 70000000.ethernet: RX Checksum Offload Engine
> supported
> [ 1.348311] stmmaceth 70000000.ethernet: TX Checksum insertion
> supported
> [ 1.348320] stmmaceth 70000000.ethernet: TSO supported
> [ 1.348328] stmmaceth 70000000.ethernet: Enable RX Mitigation via HW
> Watchdog Timer
> [ 1.348337] stmmaceth 70000000.ethernet: TSO feature enabled
> [ 1.348409] libphy: stmmac: probed
> [ 4159.140990] stmmaceth 70000000.ethernet eth0: PHY [stmmac-0:01]
> driver [Generic PHY]
> [ 4159.141005] stmmaceth 70000000.ethernet eth0: phy: setting supported
> 00,00000000,000062ff advertising 00,00000000,000062ff
> [ 4159.142359] stmmaceth 70000000.ethernet eth0: No Safety Features
> support found
> [ 4159.142369] stmmaceth 70000000.ethernet eth0: IEEE 1588-2008 Advanced
> Timestamp supported
> [ 4159.142429] stmmaceth 70000000.ethernet eth0: registered PTP clock
> [ 4159.142439] stmmaceth 70000000.ethernet eth0: configuring for
> phy/gmii link mode
> [ 4159.142452] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> mode=phy/gmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0
> an=1
> [ 4159.142466] stmmaceth 70000000.ethernet eth0: phy link up
> gmii/1Gbps/Full
> [ 4159.142475] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> mode=phy/gmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> [ 4159.142481] stmmaceth 70000000.ethernet eth0: Link is Up - 1Gbps/Full
> - flow control rx/tx
>
> The only missing point is the NFS boot that I can't replicate with this
> setup. But I did some sanity checks:
>
> Remote Enpoint:
> # dd if=/dev/urandom of=output.dat bs=128M count=1
> # nc -c 192.168.0.2 1234 < output.dat
> # md5sum output.dat
> fde9e0818281836e4fc0edfede2b8762 output.dat
>
> DUT:
> # nc -l -c -p 1234 > output.dat
> # md5sum output.dat
> fde9e0818281836e4fc0edfede2b8762 output.dat
On my setup, if I do not use NFS to mount the rootfs, but then manually
mount the NFS share after booting, I do not see any problems reading or
writing to files on the share. So I am not sure if it is some sort of
race that is occurring when mounting the NFS share on boot. It is 100%
reproducible when using NFS for the root file-system.
I am using the Jetson TX2 devkit [0] to test this.
Cheers
Jon
[0] https://developer.nvidia.com/embedded/jetson-tx2-developer-kit
--
nvpublic
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Kalle Valo @ 2019-07-24 11:14 UTC (permalink / raw)
To: Eugeniu Rosca
Cc: Geert Uytterhoeven, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Tony Lindgren, Ulf Hansson,
John Stultz, linux-wireless, netdev, linux-kernel,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, Eugeniu Rosca
In-Reply-To: <20190607172958.20745-1-erosca@de.adit-jv.com>
Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
> The wl1837mod datasheet [1] says about the WL_IRQ pin:
>
> ---8<---
> SDIO available, interrupt out. Active high. [..]
> Set to rising edge (active high) on powerup.
> ---8<---
>
> That's the reason of seeing the interrupt configured as:
> - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
>
> We assert that all those platforms have the WL_IRQ pin connected
> to the SoC _directly_ (confirmed on HiKey 970 [2]).
>
> That's not the case for R-Car Kingfisher extension target, which carries
> a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> IRQ_TYPE_LEVEL_LOW.
>
> Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> support platform dependent interrupt types") made a special case out
> of these interrupt types. After this commit, it is impossible to provide
> an IRQ configuration via DTS which would describe an inverter present
> between the WL18* chip and the SoC, generating the need for workarounds
> like [3].
>
> Create a boolean OF property, called "invert-irq" to specify that
> the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
>
> This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> the DTS configuration [4] combined with the "invert-irq" property.
>
> [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> [4] https://patchwork.kernel.org/patch/10895879/
> ("arm64: dts: ulcb-kf: Add support for TI WL1837")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Based on the discussion I'm dropping this. Please resend once there's a
conclusion.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10982491/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next 1/4] sctp: check addr_size with sa_family_t size in __sctp_setsockopt_connectx
From: Neil Horman @ 2019-07-24 11:22 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, davem
In-Reply-To: <CADvbK_eiS26aMZcPrj2oNvZh_42phWiY71M7=UNvjEeB-B9bDQ@mail.gmail.com>
On Wed, Jul 24, 2019 at 03:21:12PM +0800, Xin Long wrote:
> On Tue, Jul 23, 2019 at 11:25 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Tue, Jul 23, 2019 at 01:37:57AM +0800, Xin Long wrote:
> > > Now __sctp_connect() is called by __sctp_setsockopt_connectx() and
> > > sctp_inet_connect(), the latter has done addr_size check with size
> > > of sa_family_t.
> > >
> > > In the next patch to clean up __sctp_connect(), we will remove
> > > addr_size check with size of sa_family_t from __sctp_connect()
> > > for the 1st address.
> > >
> > > So before doing that, __sctp_setsockopt_connectx() should do
> > > this check first, as sctp_inet_connect() does.
> > >
> > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > ---
> > > net/sctp/socket.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > index aa80cda..5f92e4a 100644
> > > --- a/net/sctp/socket.c
> > > +++ b/net/sctp/socket.c
> > > @@ -1311,7 +1311,7 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
> > > pr_debug("%s: sk:%p addrs:%p addrs_size:%d\n",
> > > __func__, sk, addrs, addrs_size);
> > >
> > > - if (unlikely(addrs_size <= 0))
> > > + if (unlikely(addrs_size < sizeof(sa_family_t)))
> > I don't think this is what you want to check for here. sa_family_t is
> > an unsigned short, and addrs_size is the number of bytes in the addrs
> > array. The addrs array should be at least the size of one struct
> > sockaddr (16 bytes iirc), and, if larger, should be a multiple of
> > sizeof(struct sockaddr)
> sizeof(struct sockaddr) is not the right value to check either.
>
> The proper check will be done later in __sctp_connect():
>
> af = sctp_get_af_specific(daddr->sa.sa_family);
> if (!af || af->sockaddr_len > addrs_size)
> return -EINVAL;
>
> So the check 'addrs_size < sizeof(sa_family_t)' in this patch is
> just to make sure daddr->sa.sa_family is accessible. the same
> check is also done in sctp_inet_connect().
>
That doesn't make much sense, if the proper check is done in __sctp_connect with
the size of the families sockaddr_len, then we don't need this check at all, we
can just let memdup_user take the fault on copy_to_user and return -EFAULT. If
we get that from memdup_user, we know its not accessible, and can bail out.
About the only thing we need to check for here is that addr_len isn't some
absurdly high value (i.e. a negative value), so that we avoid trying to kmalloc
upwards of 2G in memdup_user. Your change does that just fine, but its no
better or worse than checking for <=0
Neil
> >
> > Neil
> >
> > > return -EINVAL;
> > >
> > > kaddrs = memdup_user(addrs, addrs_size);
> > > --
> > > 2.1.0
> > >
> > >
>
^ permalink raw reply
* [PATCH net-next 00/10] Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:25 UTC (permalink / raw)
Cc: Mirko Lindner, Stephen Hemminger, Jiri Slaby, Nick Kossifidis,
Luis Chamberlain, Stanislaw Gruszka, Kalle Valo,
QCA ath9k Development, Maya Erez, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Amitkumar Karwar,
Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu, Igor Mitsyanko,
Avinash Patil, Sergey Matyukevich, Ping-Ke Shih,
Intel Linux Wireless, David S . Miller,
Solarflare linux maintainers, Edward Cree, Martin Habets, netdev,
wil6210, linux-wireless, linux-kernel, Chuhong Yuan
These patches use dev_get_drvdata instead of
using to_pci_dev + pci_get_drvdata to make
code simpler.
Chuhong Yuan (10):
net: marvell: Use dev_get_drvdata where possible
forcedeth: Use dev_get_drvdata where possible
sfc: Use dev_get_drvdata where possible
sfc-falcon: Use dev_get_drvdata where possible
ath: Use dev_get_drvdata where possible
iwlegacy: Use dev_get_drvdata where possible
iwlwifi: Use dev_get_drvdata where possible
mwifiex: pcie: Use dev_get_drvdata
qtnfmac_pcie: Use dev_get_drvdata
rtlwifi: rtl_pci: Use dev_get_drvdata
drivers/net/ethernet/marvell/skge.c | 6 ++----
drivers/net/ethernet/marvell/sky2.c | 3 +--
drivers/net/ethernet/nvidia/forcedeth.c | 3 +--
drivers/net/ethernet/sfc/ef10.c | 4 ++--
drivers/net/ethernet/sfc/efx.c | 10 +++++-----
drivers/net/ethernet/sfc/falcon/efx.c | 6 +++---
drivers/net/ethernet/sfc/falcon/falcon_boards.c | 4 ++--
drivers/net/wireless/ath/ath5k/pci.c | 3 +--
drivers/net/wireless/ath/ath9k/pci.c | 5 ++---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 6 ++----
drivers/net/wireless/intel/iwlegacy/common.c | 3 +--
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 12 ++++--------
drivers/net/wireless/marvell/mwifiex/pcie.c | 8 ++------
drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 4 ++--
drivers/net/wireless/realtek/rtlwifi/pci.c | 6 ++----
15 files changed, 32 insertions(+), 51 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net-next 01/10] net: marvell: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:26 UTC (permalink / raw)
Cc: Mirko Lindner, Stephen Hemminger, David S . Miller, netdev,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/marvell/skge.c | 6 ++----
drivers/net/ethernet/marvell/sky2.c | 3 +--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 9ac854c2b371..06dffee81e02 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4078,8 +4078,7 @@ static void skge_remove(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int skge_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct skge_hw *hw = pci_get_drvdata(pdev);
+ struct skge_hw *hw = dev_get_drvdata(dev);
int i;
if (!hw)
@@ -4103,8 +4102,7 @@ static int skge_suspend(struct device *dev)
static int skge_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct skge_hw *hw = pci_get_drvdata(pdev);
+ struct skge_hw *hw = dev_get_drvdata(dev);
int i, err;
if (!hw)
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index f518312ffe69..762fe0821923 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -5160,8 +5160,7 @@ static void sky2_remove(struct pci_dev *pdev)
static int sky2_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct sky2_hw *hw = pci_get_drvdata(pdev);
+ struct sky2_hw *hw = dev_get_drvdata(dev);
int i;
if (!hw)
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 02/10] forcedeth: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:26 UTC (permalink / raw)
Cc: David S . Miller, netdev, linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index b327b29f5d57..ecca794c55e2 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -6126,8 +6126,7 @@ static void nv_remove(struct pci_dev *pci_dev)
#ifdef CONFIG_PM_SLEEP
static int nv_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
int i;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 03/10] sfc: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:26 UTC (permalink / raw)
Cc: Solarflare linux maintainers, Edward Cree, Martin Habets,
David S . Miller, netdev, linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/sfc/ef10.c | 4 ++--
drivers/net/ethernet/sfc/efx.c | 10 +++++-----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 16d6952c312a..0ec13f520e90 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -508,7 +508,7 @@ static ssize_t efx_ef10_show_link_control_flag(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct efx_nic *efx = dev_get_drvdata(dev);
return sprintf(buf, "%d\n",
((efx->mcdi->fn_flags) &
@@ -520,7 +520,7 @@ static ssize_t efx_ef10_show_primary_flag(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct efx_nic *efx = dev_get_drvdata(dev);
return sprintf(buf, "%d\n",
((efx->mcdi->fn_flags) &
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index ab58b837df47..2fef7402233e 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -2517,7 +2517,7 @@ static struct notifier_block efx_netdev_notifier = {
static ssize_t
show_phy_type(struct device *dev, struct device_attribute *attr, char *buf)
{
- struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct efx_nic *efx = dev_get_drvdata(dev);
return sprintf(buf, "%d\n", efx->phy_type);
}
static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
@@ -2526,7 +2526,7 @@ static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
static ssize_t show_mcdi_log(struct device *dev, struct device_attribute *attr,
char *buf)
{
- struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct efx_nic *efx = dev_get_drvdata(dev);
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
return scnprintf(buf, PAGE_SIZE, "%d\n", mcdi->logging_enabled);
@@ -2534,7 +2534,7 @@ static ssize_t show_mcdi_log(struct device *dev, struct device_attribute *attr,
static ssize_t set_mcdi_log(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
- struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct efx_nic *efx = dev_get_drvdata(dev);
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
bool enable = count > 0 && *buf != '0';
@@ -3654,7 +3654,7 @@ static int efx_pci_sriov_configure(struct pci_dev *dev, int num_vfs)
static int efx_pm_freeze(struct device *dev)
{
- struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct efx_nic *efx = dev_get_drvdata(dev);
rtnl_lock();
@@ -3675,7 +3675,7 @@ static int efx_pm_freeze(struct device *dev)
static int efx_pm_thaw(struct device *dev)
{
int rc;
- struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct efx_nic *efx = dev_get_drvdata(dev);
rtnl_lock();
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 04/10] sfc-falcon: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Solarflare linux maintainers, Edward Cree, Martin Habets,
David S . Miller, netdev, linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/sfc/falcon/efx.c | 6 +++---
drivers/net/ethernet/sfc/falcon/falcon_boards.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/sfc/falcon/efx.c b/drivers/net/ethernet/sfc/falcon/efx.c
index 9b15c39ac670..eecc348b1c32 100644
--- a/drivers/net/ethernet/sfc/falcon/efx.c
+++ b/drivers/net/ethernet/sfc/falcon/efx.c
@@ -2256,7 +2256,7 @@ static struct notifier_block ef4_netdev_notifier = {
static ssize_t
show_phy_type(struct device *dev, struct device_attribute *attr, char *buf)
{
- struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct ef4_nic *efx = dev_get_drvdata(dev);
return sprintf(buf, "%d\n", efx->phy_type);
}
static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
@@ -2999,7 +2999,7 @@ static int ef4_pci_probe(struct pci_dev *pci_dev,
static int ef4_pm_freeze(struct device *dev)
{
- struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct ef4_nic *efx = dev_get_drvdata(dev);
rtnl_lock();
@@ -3020,7 +3020,7 @@ static int ef4_pm_freeze(struct device *dev)
static int ef4_pm_thaw(struct device *dev)
{
int rc;
- struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct ef4_nic *efx = dev_get_drvdata(dev);
rtnl_lock();
diff --git a/drivers/net/ethernet/sfc/falcon/falcon_boards.c b/drivers/net/ethernet/sfc/falcon/falcon_boards.c
index 839189dab98e..2d85d1386ed9 100644
--- a/drivers/net/ethernet/sfc/falcon/falcon_boards.c
+++ b/drivers/net/ethernet/sfc/falcon/falcon_boards.c
@@ -357,7 +357,7 @@ static int sfe4001_poweron(struct ef4_nic *efx)
static ssize_t show_phy_flash_cfg(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct ef4_nic *efx = dev_get_drvdata(dev);
return sprintf(buf, "%d\n", !!(efx->phy_mode & PHY_MODE_SPECIAL));
}
@@ -365,7 +365,7 @@ static ssize_t set_phy_flash_cfg(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct ef4_nic *efx = pci_get_drvdata(to_pci_dev(dev));
+ struct ef4_nic *efx = dev_get_drvdata(dev);
enum ef4_phy_mode old_mode, new_mode;
int err;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 05/10] ath: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Jiri Slaby, Nick Kossifidis, Luis Chamberlain, Kalle Valo,
David S . Miller, QCA ath9k Development, Maya Erez,
linux-wireless, netdev, linux-kernel, wil6210, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/wireless/ath/ath5k/pci.c | 3 +--
drivers/net/wireless/ath/ath9k/pci.c | 5 ++---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 6 ++----
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/pci.c b/drivers/net/wireless/ath/ath5k/pci.c
index c6156cc38940..e1378e203611 100644
--- a/drivers/net/wireless/ath/ath5k/pci.c
+++ b/drivers/net/wireless/ath/ath5k/pci.c
@@ -301,8 +301,7 @@ ath5k_pci_remove(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int ath5k_pci_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = dev_get_drvdata(dev);
struct ath5k_hw *ah = hw->priv;
ath5k_led_off(ah);
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 92b2dd396436..f3461b193c7a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -1021,13 +1021,12 @@ static void ath_pci_remove(struct pci_dev *pdev)
static int ath_pci_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = dev_get_drvdata(device);
struct ath_softc *sc = hw->priv;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
if (test_bit(ATH_OP_WOW_ENABLED, &common->op_flags)) {
- dev_info(&pdev->dev, "WOW is enabled, bypassing PCI suspend\n");
+ dev_info(device, "WOW is enabled, bypassing PCI suspend\n");
return 0;
}
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 9f5a914abc18..1b0625987d76 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -631,8 +631,7 @@ static int __maybe_unused wil6210_pm_resume(struct device *dev)
static int __maybe_unused wil6210_pm_runtime_idle(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct wil6210_priv *wil = pci_get_drvdata(pdev);
+ struct wil6210_priv *wil = dev_get_drvdata(dev);
wil_dbg_pm(wil, "Runtime idle\n");
@@ -646,8 +645,7 @@ static int __maybe_unused wil6210_pm_runtime_resume(struct device *dev)
static int __maybe_unused wil6210_pm_runtime_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct wil6210_priv *wil = pci_get_drvdata(pdev);
+ struct wil6210_priv *wil = dev_get_drvdata(dev);
if (test_bit(wil_status_suspended, wil->status)) {
wil_dbg_pm(wil, "trying to suspend while suspended\n");
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 06/10] iwlegacy: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Stanislaw Gruszka, Kalle Valo, David S . Miller, linux-wireless,
netdev, linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/wireless/intel/iwlegacy/common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c
index 4a88e35d58d7..73f7bbf742bc 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -4942,8 +4942,7 @@ EXPORT_SYMBOL(il_add_beacon_time);
static int
il_pci_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct il_priv *il = pci_get_drvdata(pdev);
+ struct il_priv *il = dev_get_drvdata(device);
/*
* This function is called when system goes into suspend state
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 07/10] iwlwifi: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, David S . Miller,
linux-wireless, netdev, linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index ea2a03d4bf55..fe76e1540d39 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -1248,8 +1248,7 @@ int iwl_pci_fw_exit_d0i3(struct iwl_trans *trans)
#ifdef CONFIG_IWLWIFI_PCIE_RTPM
static int iwl_pci_runtime_suspend(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
int ret;
IWL_DEBUG_RPM(trans, "entering runtime suspend\n");
@@ -1269,8 +1268,7 @@ static int iwl_pci_runtime_suspend(struct device *device)
static int iwl_pci_runtime_resume(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
enum iwl_d3_status d3_status;
IWL_DEBUG_RPM(trans, "exiting runtime suspend (resume)\n");
@@ -1285,8 +1283,7 @@ static int iwl_pci_runtime_resume(struct device *device)
static int iwl_pci_system_prepare(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
IWL_DEBUG_RPM(trans, "preparing for system suspend\n");
@@ -1308,8 +1305,7 @@ static int iwl_pci_system_prepare(struct device *device)
static void iwl_pci_system_complete(struct device *device)
{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
+ struct iwl_trans *trans = dev_get_drvdata(device);
IWL_DEBUG_RPM(trans, "completing system suspend\n");
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 08/10] mwifiex: pcie: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Kalle Valo, David S . Miller, linux-wireless, netdev,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index b54f73e3d508..eff06d59e9df 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -150,10 +150,8 @@ static bool mwifiex_pcie_ok_to_access_hw(struct mwifiex_adapter *adapter)
static int mwifiex_pcie_suspend(struct device *dev)
{
struct mwifiex_adapter *adapter;
- struct pcie_service_card *card;
- struct pci_dev *pdev = to_pci_dev(dev);
+ struct pcie_service_card *card = dev_get_drvdata(dev);
- card = pci_get_drvdata(pdev);
/* Might still be loading firmware */
wait_for_completion(&card->fw_done);
@@ -195,10 +193,8 @@ static int mwifiex_pcie_suspend(struct device *dev)
static int mwifiex_pcie_resume(struct device *dev)
{
struct mwifiex_adapter *adapter;
- struct pcie_service_card *card;
- struct pci_dev *pdev = to_pci_dev(dev);
+ struct pcie_service_card *card = dev_get_drvdata(dev);
- card = pci_get_drvdata(pdev);
if (!card->adapter) {
dev_err(dev, "adapter structure is not valid\n");
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 09/10] qtnfmac_pcie: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 11:27 UTC (permalink / raw)
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
David S . Miller, linux-wireless, netdev, linux-kernel,
Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
index e4e9344b6982..8ae318b5fe54 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
@@ -430,7 +430,7 @@ static int qtnf_pcie_suspend(struct device *dev)
struct qtnf_pcie_bus_priv *priv;
struct qtnf_bus *bus;
- bus = pci_get_drvdata(to_pci_dev(dev));
+ bus = dev_get_drvdata(dev);
if (!bus)
return -EFAULT;
@@ -443,7 +443,7 @@ static int qtnf_pcie_resume(struct device *dev)
struct qtnf_pcie_bus_priv *priv;
struct qtnf_bus *bus;
- bus = pci_get_drvdata(to_pci_dev(dev));
+ bus = dev_get_drvdata(dev);
if (!bus)
return -EFAULT;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 10/10] rtlwifi: rtl_pci: Use dev_get_drvdata
From: Chuhong Yuan @ 2019-07-24 11:28 UTC (permalink / raw)
Cc: Ping-Ke Shih, Kalle Valo, David S . Miller, linux-wireless,
netdev, linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 4055e0ab75ba..7d96fe5f1a44 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2409,8 +2409,7 @@ EXPORT_SYMBOL(rtl_pci_disconnect);
****************************************/
int rtl_pci_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = dev_get_drvdata(dev);
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtlpriv->cfg->ops->hw_suspend(hw);
@@ -2422,8 +2421,7 @@ EXPORT_SYMBOL(rtl_pci_suspend);
int rtl_pci_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = dev_get_drvdata(dev);
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtlpriv->cfg->ops->hw_resume(hw);
--
2.20.1
^ permalink raw reply related
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-24 11:34 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, Ilias Apalodimas
Cc: David Miller, robin.murphy@arm.com, lists@bofh.nu,
Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
maxime.ripard@bootlin.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <33de62bf-2f8a-bf00-9260-418b12bed24c@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Jul/24/2019, 12:10:47 (UTC+00:00)
>
> On 24/07/2019 11:04, Jose Abreu wrote:
>
> ...
>
> > Jon, I was able to replicate (at some level) your setup:
> >
> > # dmesg | grep -i arm-smmu
> > [ 1.337322] arm-smmu 70040000.iommu: probing hardware
> > configuration...
> > [ 1.337330] arm-smmu 70040000.iommu: SMMUv2 with:
> > [ 1.337338] arm-smmu 70040000.iommu: stage 1 translation
> > [ 1.337346] arm-smmu 70040000.iommu: stage 2 translation
> > [ 1.337354] arm-smmu 70040000.iommu: nested translation
> > [ 1.337363] arm-smmu 70040000.iommu: stream matching with 128
> > register groups
> > [ 1.337374] arm-smmu 70040000.iommu: 1 context banks (0
> > stage-2 only)
> > [ 1.337383] arm-smmu 70040000.iommu: Supported page sizes:
> > 0x61311000
> > [ 1.337393] arm-smmu 70040000.iommu: Stage-1: 48-bit VA ->
> > 48-bit IPA
> > [ 1.337402] arm-smmu 70040000.iommu: Stage-2: 48-bit IPA ->
> > 48-bit PA
> >
> > # dmesg | grep -i stmmac
> > [ 1.344106] stmmaceth 70000000.ethernet: Adding to iommu group 0
> > [ 1.344233] stmmaceth 70000000.ethernet: no reset control found
> > [ 1.348276] stmmaceth 70000000.ethernet: User ID: 0x10, Synopsys ID:
> > 0x51
> > [ 1.348285] stmmaceth 70000000.ethernet: DWMAC4/5
> > [ 1.348293] stmmaceth 70000000.ethernet: DMA HW capability register
> > supported
> > [ 1.348302] stmmaceth 70000000.ethernet: RX Checksum Offload Engine
> > supported
> > [ 1.348311] stmmaceth 70000000.ethernet: TX Checksum insertion
> > supported
> > [ 1.348320] stmmaceth 70000000.ethernet: TSO supported
> > [ 1.348328] stmmaceth 70000000.ethernet: Enable RX Mitigation via HW
> > Watchdog Timer
> > [ 1.348337] stmmaceth 70000000.ethernet: TSO feature enabled
> > [ 1.348409] libphy: stmmac: probed
> > [ 4159.140990] stmmaceth 70000000.ethernet eth0: PHY [stmmac-0:01]
> > driver [Generic PHY]
> > [ 4159.141005] stmmaceth 70000000.ethernet eth0: phy: setting supported
> > 00,00000000,000062ff advertising 00,00000000,000062ff
> > [ 4159.142359] stmmaceth 70000000.ethernet eth0: No Safety Features
> > support found
> > [ 4159.142369] stmmaceth 70000000.ethernet eth0: IEEE 1588-2008 Advanced
> > Timestamp supported
> > [ 4159.142429] stmmaceth 70000000.ethernet eth0: registered PTP clock
> > [ 4159.142439] stmmaceth 70000000.ethernet eth0: configuring for
> > phy/gmii link mode
> > [ 4159.142452] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> > mode=phy/gmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0
> > an=1
> > [ 4159.142466] stmmaceth 70000000.ethernet eth0: phy link up
> > gmii/1Gbps/Full
> > [ 4159.142475] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> > mode=phy/gmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> > [ 4159.142481] stmmaceth 70000000.ethernet eth0: Link is Up - 1Gbps/Full
> > - flow control rx/tx
> >
> > The only missing point is the NFS boot that I can't replicate with this
> > setup. But I did some sanity checks:
> >
> > Remote Enpoint:
> > # dd if=/dev/urandom of=output.dat bs=128M count=1
> > # nc -c 192.168.0.2 1234 < output.dat
> > # md5sum output.dat
> > fde9e0818281836e4fc0edfede2b8762 output.dat
> >
> > DUT:
> > # nc -l -c -p 1234 > output.dat
> > # md5sum output.dat
> > fde9e0818281836e4fc0edfede2b8762 output.dat
>
> On my setup, if I do not use NFS to mount the rootfs, but then manually
> mount the NFS share after booting, I do not see any problems reading or
> writing to files on the share. So I am not sure if it is some sort of
> race that is occurring when mounting the NFS share on boot. It is 100%
> reproducible when using NFS for the root file-system.
I don't understand how can there be corruption then unless the IP AXI
parameters are misconfigured which can lead to sporadic undefined
behavior.
These prints from your logs:
[ 14.579392] Run /init as init process
/init: line 58: chmod: command not found
[ 10:22:46 ] L4T-INITRD Build DATE: Mon Jul 22 10:22:46 UTC 2019
[ 10:22:46 ] Root device found: nfs
[ 10:22:46 ] Ethernet interfaces: eth0
[ 10:22:46 ] IP Address: 10.21.140.41
Where are they coming from ? Do you have any extra init script ?
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH v2 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset
From: Kalle Valo @ 2019-07-24 11:35 UTC (permalink / raw)
To: Douglas Anderson
Cc: Ulf Hansson, Adrian Hunter, Ganapathi Bhat, linux-wireless,
Andreas Fenkart, Brian Norris, Amitkumar Karwar, linux-rockchip,
Wolfram Sang, Nishant Sarmukadam, netdev, Avri Altman, linux-mmc,
davem, Xinming Hu, Douglas Anderson, linux-kernel
In-Reply-To: <20190722193939.125578-3-dianders@chromium.org>
Douglas Anderson <dianders@chromium.org> wrote:
> As described in the patch ("mmc: core: Add sdio_trigger_replug()
> API"), the current mwifiex_sdio_card_reset() is broken in the cases
> where we're running Bluetooth on a second SDIO func on the same card
> as WiFi. The problem goes away if we just use the
> sdio_trigger_replug() API call.
>
> NOTE: Even though with this new solution there is less of a reason to
> do our work from a workqueue (the unplug / plug mechanism we're using
> is possible for a human to perform at any time so the stack is
> supposed to handle it without it needing to be called from a special
> context), we still need a workqueue because the Marvell reset function
> could called from a context where sleeping is invalid and thus we
> can't claim the host. One example is Marvell's wakeup_timer_fn().
>
> Cc: Andreas Fenkart <afenkart@gmail.com>
> Cc: Brian Norris <briannorris@chromium.org>
> Fixes: b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
I assume this is going via some other tree so I'm dropping this from my
queue. If I should apply this please resend once the dependency is in
wireless-drivers-next.
Patch set to Not Applicable.
--
https://patchwork.kernel.org/patch/11053351/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] Build fixes for skb_frag_size conversion
From: Matthew Wilcox @ 2019-07-24 11:36 UTC (permalink / raw)
To: netdev, davem; +Cc: Matthew Wilcox (Oracle)
From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
I missed a few places. One is in some ifdeffed code which will probably
never be re-enabled; the others are in drivers which can't currently be
compiled on x86.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
drivers/atm/he.c | 7 +++----
drivers/net/ethernet/aeroflex/greth.c | 2 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 ++-
drivers/staging/octeon/ethernet-tx.c | 2 +-
drivers/target/iscsi/cxgbit/cxgbit_target.c | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 211607986134..70b00ae4ec38 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -2580,10 +2580,9 @@ he_send(struct atm_vcc *vcc, struct sk_buff *skb)
slot = 0;
}
- tpd->iovec[slot].addr = dma_map_single(&he_dev->pci_dev->dev,
- (void *) page_address(frag->page) + frag->page_offset,
- frag->size, DMA_TO_DEVICE);
- tpd->iovec[slot].len = frag->size;
+ tpd->iovec[slot].addr = skb_frag_dma_map(&he_dev->pci_dev->dev,
+ frag, 0, skb_frag_size(frag), DMA_TO_DEVICE);
+ tpd->iovec[slot].len = skb_frag_size(frag);
++slot;
}
diff --git a/drivers/net/ethernet/aeroflex/greth.c b/drivers/net/ethernet/aeroflex/greth.c
index 010a2f48aea5..2a9f8643629c 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -110,7 +110,7 @@ static void greth_print_tx_packet(struct sk_buff *skb)
print_hex_dump(KERN_DEBUG, "TX: ", DUMP_PREFIX_OFFSET, 16, 1,
skb_frag_address(&skb_shinfo(skb)->frags[i]),
- skb_shinfo(skb)->frags[i].size, true);
+ skb_frag_size(&skb_shinfo(skb)->frags[i]), true);
}
}
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index f38c3fa7d705..9c4d1afa34e5 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1958,7 +1958,7 @@ static int skb_to_sg_fd(struct dpaa_priv *priv,
/* populate the rest of SGT entries */
for (i = 0; i < nr_frags; i++) {
frag = &skb_shinfo(skb)->frags[i];
- frag_len = frag->size;
+ frag_len = skb_frag_size(frag);
WARN_ON(!skb_frag_page(frag));
addr = skb_frag_dma_map(dev, frag, 0,
frag_len, dma_dir);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 00991df44ed6..e529d86468b8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -787,7 +787,8 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
if (skb_is_gso(skb)) {
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
frag = &skb_shinfo(skb)->frags[i];
- nfrags += DIV_ROUND_UP(frag->size, MTK_TX_DMA_BUF_LEN);
+ nfrags += DIV_ROUND_UP(skb_frag_size(frag),
+ MTK_TX_DMA_BUF_LEN);
}
} else {
nfrags += skb_shinfo(skb)->nr_frags;
diff --git a/drivers/staging/octeon/ethernet-tx.c b/drivers/staging/octeon/ethernet-tx.c
index cc12c78f73f1..46a6fcf1414d 100644
--- a/drivers/staging/octeon/ethernet-tx.c
+++ b/drivers/staging/octeon/ethernet-tx.c
@@ -284,7 +284,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device *dev)
hw_buffer.s.addr =
XKPHYS_TO_PHYS((u64)skb_frag_address(fs));
- hw_buffer.s.size = fs->size;
+ hw_buffer.s.size = skb_drag_size(fs);
CVM_OCT_SKB_CB(skb)[i + 1] = hw_buffer.u64;
}
hw_buffer.s.addr = XKPHYS_TO_PHYS((u64)CVM_OCT_SKB_CB(skb));
diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c b/drivers/target/iscsi/cxgbit/cxgbit_target.c
index 93212b9fd310..c25315431ad0 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
@@ -1448,7 +1448,7 @@ cxgbit_lro_skb_merge(struct cxgbit_sock *csk, struct sk_buff *skb, u8 pdu_idx)
hpdu_cb->frags++;
hpdu_cb->hfrag_idx = hfrag_idx;
- len = skb_frag_size(&hssi->frags[hfrag_idx]);;
+ len = skb_frag_size(&hssi->frags[hfrag_idx]);
hskb->len += len;
hskb->data_len += len;
hskb->truesize += len;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] drivers: net: wireless: rsi: return explicit error values
From: Kalle Valo @ 2019-07-24 11:36 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, amitkarwar, siva8118, linux-wireless, netdev
In-Reply-To: <1561645802-1279-1-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> wrote:
> From: Enrico Weigelt <info@metux.net>
>
> Explicitly return constants instead of variable (and rely on
> it to be explicitly initialized), if the value is supposed
> to be fixed anyways. Align it with the rest of the driver,
> which does it the same way.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
I'll fix the title prefix to only have "rsi:", no need to have the full
directory path there.
--
https://patchwork.kernel.org/patch/11019801/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] marvell wireless: cleanup -- make error values consistent
From: Kalle Valo @ 2019-07-24 11:39 UTC (permalink / raw)
To: Pavel Machek
Cc: amitkarwar, nishants, gbhat, huxinming820, davem, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190724095015.GA6592@amd>
Pavel Machek <pavel@ucw.cz> wrote:
> Surrounding code uses -ERRNO as a result, so don't pass plain -1.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
The title prefix should be "mwifiex:", I'll fix that.
--
https://patchwork.kernel.org/patch/11056525/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox