* [PATCH v6 00/13] firmware_loader changes for v4.18
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
Greg,
Here is what I have queued up for the firmware_loader for v4.18. It
includes a slew of cleanup work, and the new firmware_request_nowarn()
which is quiet but enables the sysfs fallback mechanism. I've gone ahead
and also queued up a few minor fixes for the firmware loader documentation
which have come up recently. These changes are available on my git tree
both based on linux-next [0] and Linus' latest tree [1]. Folks working
on new developments for the firmware loader can use my linux-next
branch 20180508-firmware_loader_for-v4.18-try2 for now.
0-day sends its blessings.
The patches from Mimi's series still require a bit more discussion and
review. The discussion over the EFI firmware fallback mechanism is still
ongoing.
As for the rename that you wanted, perhaps we can do this late in the
merge window considering we're at rc4 now. I can prep something up for
that later.
Question, and specially rants are warmly welcomed.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20180508-firmware_loader_for-v4.18-try2
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20180508-firmware_loader_for-v4.18-try2
Andres Rodriguez (6):
firmware: wrap FW_OPT_* into an enum
firmware: use () to terminate kernel-doc function names
firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
firmware: add firmware_request_nowarn() - load firmware without
warnings
ath10k: use firmware_request_nowarn() to load firmware
ath10k: re-enable the firmware fallback mechanism for testmode
Luis R. Rodriguez (7):
firmware_loader: document firmware_sysfs_fallback()
firmware_loader: enhance Kconfig documentation over FW_LOADER
firmware_loader: move kconfig FW_LOADER entries to its own file
firmware_loader: make firmware_fallback_sysfs() print more useful
Documentation: fix few typos and clarifications for the firmware
loader
Documentation: remove stale firmware API reference
Documentation: clarify firmware_class provenance and why we can't
rename the module
Documentation/dell_rbu.txt | 3 -
.../firmware/fallback-mechanisms.rst | 14 +-
.../driver-api/firmware/firmware_cache.rst | 4 +-
.../driver-api/firmware/request_firmware.rst | 5 +
drivers/base/Kconfig | 90 ++--------
drivers/base/firmware_loader/Kconfig | 154 ++++++++++++++++++
drivers/base/firmware_loader/fallback.c | 53 ++++--
drivers/base/firmware_loader/fallback.h | 18 +-
drivers/base/firmware_loader/firmware.h | 37 ++++-
drivers/base/firmware_loader/main.c | 57 +++++--
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/testmode.c | 2 +-
include/linux/firmware.h | 10 ++
13 files changed, 319 insertions(+), 130 deletions(-)
create mode 100644 drivers/base/firmware_loader/Kconfig
--
2.17.0
^ permalink raw reply
* Re: Failed to clone net-next.git
From: Konstantin Ryabitsev @ 2018-05-08 18:06 UTC (permalink / raw)
To: Song Liu, Networking; +Cc: Alexei Starovoitov
In-Reply-To: <FB252D9C-2FB2-437C-8646-4F61406AC96D@fb.com>
[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]
On 05/08/18 13:46, Song Liu wrote:
> We are seeing the following error on multiple different systems while
> cloning net-next tree.
>
> $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> Cloning into 'net-next'...
> remote: Counting objects: 6017287, done.
> remote: Compressing objects: 100% (2458/2458), done.
> fatal: The remote end hung up unexpectedly 1.00 GiB | 8.13 MiB/s
> fatal: early EOF
> fatal: index-pack failed
>
> It looks like the size of the data being fetched reached server side
> limit of 1.00 GiB. So we probably need change server side configuration.
> Could someone please look into it?
It was probably due to a timeout value. Can you try it now, I've bumped
it to a much larger number.
Regards,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [net-next PATCH 0/3] Symmetric queue selection using XPS for Rx queues
From: Nambiar, Amritha @ 2018-05-08 17:56 UTC (permalink / raw)
To: Alexander Duyck, Eric Dumazet
Cc: Tom Herbert, Eric Dumazet, netdev, David Miller, Alexander Duyck,
Samudrala, Sridhar, Hannes Frederic Sowa
In-Reply-To: <CAKgT0Ud=msT46kmEASzxD-0gL7EEKSB6hkSJ6BDx0gE3wpMxow@mail.gmail.com>
On 5/8/2018 10:19 AM, Alexander Duyck wrote:
> On Tue, May 8, 2018 at 10:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>
>> On 05/08/2018 09:02 AM, Alexander Duyck wrote:
>>> On Tue, May 8, 2018 at 8:15 AM, Tom Herbert <tom@herbertland.com> wrote:
>>>> On Thu, Apr 19, 2018 at 7:41 PM, Eric Dumazet <edumazet@google.com> wrote:
>>>>> On Thu, Apr 19, 2018 at 6:07 PM Amritha Nambiar <amritha.nambiar@intel.com>
>>>>> wrote:
>>>>>
>>>>>> This patch series implements support for Tx queue selection based on
>>>>>> Rx queue map. This is done by configuring Rx queue map per Tx-queue
>>>>>> using sysfs attribute. If the user configuration for Rx queues does
>>>>>> not apply, then the Tx queue selection falls back to XPS using CPUs and
>>>>>> finally to hashing.
>>>>>
>>>>>> XPS is refactored to support Tx queue selection based on either the
>>>>>> CPU map or the Rx-queue map. The config option CONFIG_XPS needs to be
>>>>>> enabled. By default no receive queues are configured for the Tx queue.
>>>>>
>>>>>> - /sys/class/net/eth0/queues/tx-*/xps_rxqs
>>>>>
>>>>>> This is to enable sending packets on the same Tx-Rx queue pair as this
>>>>>> is useful for busy polling multi-threaded workloads where it is not
>>>>>> possible to pin the threads to a CPU. This is a rework of Sridhar's
>>>>>> patch for symmetric queueing via socket option:
>>>>>> https://www.spinics.net/lists/netdev/msg453106.html
>>>>>
>>>> I suspect this is an artifact of flow director which I believe
>>>> required queue pairs to be able to work (i.e. receive queue chose
>>>> hardware is determined send queue). But that was only required because
>>>> of hardware design, I don't see the rationale for introducing queue
>>>> pairs in the software stack. There's no need to correlate the transmit
>>>> path with receive path, no need to enforce a 1-1 mapping between RX
>>>> and TX queues, and the OOO mitigations should be sufficient when TX
>>>> queue changes for a flow.
>>>>
>>>> Tom
>>>
>>> If I am not mistaken I think there are benefits to doing this sort of
>>> thing with polling as it keeps the Tx work locked into the same queue
>>> pair that a given application is polling on. So as a result you can
>>> keep the interrupts contained to the queue pair that is being busy
>>> polled on and if the application cleans up the packets during the busy
>>> poll it ends up being a net savings in terms of both latency and power
>>> since the Tx clean-up happens sooner, and it happens on the queue that
>>> is already busy polling instead of possibly triggering an interrupt on
>>> another CPU.
>>>
>>> So for example in the case of routing and bridging workloads we
>>> already had code that would take the Rx queue and associate it to a Tx
>>> queue. One of the ideas behind doing this is to try and keep the CPU
>>> overhead low by having a 1:1 mapping. In the case of this code we
>>> allow for a little more flexibility in that you could have
>>> many-to-many mappings but the general idea and common use case is the
>>> same which is a 1:1 mapping.
>>
>>
>> I thought we had everything in place to be able to have this already.
>>
>> Setting IRQ affinities and XPS is certainly something doable.
>>
>> This is why I wanted a proper documentation of yet another way to reach the
>> same behavior.
>
> IRQ affinities and XPS work for pure NAPI setups, but the problem is
> you have to also do application affinity in the case of busy polling
> which can provide some additional challenges since then you have to
> add code in your application to associate a given queue/CPU to a given
> application thread. I believe this is a way of simplifying this.
>
> I agree on the documentation aspect. The usage of this should be well
> documented as well as the why of using it.
>
> - Alex
>
I'll submit another version of the series with the documentation added.
- Amritha
^ permalink raw reply
* Failed to clone net-next.git
From: Song Liu @ 2018-05-08 17:46 UTC (permalink / raw)
To: Networking; +Cc: Alexei Starovoitov, Konstantin Ryabitsev
We are seeing the following error on multiple different systems while
cloning net-next tree.
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
Cloning into 'net-next'...
remote: Counting objects: 6017287, done.
remote: Compressing objects: 100% (2458/2458), done.
fatal: The remote end hung up unexpectedly 1.00 GiB | 8.13 MiB/s
fatal: early EOF
fatal: index-pack failed
It looks like the size of the data being fetched reached server side
limit of 1.00 GiB. So we probably need change server side configuration.
Could someone please look into it?
If you see same problem. Here is a work-around for it:
1. clone a smaller tree, for example net.git;
2. add net-next as a new remote, and fetch it.
Thanks,
Song
^ permalink raw reply
* Re: general protection fault in encode_rpcb_string
From: Bruce Fields @ 2018-05-08 17:44 UTC (permalink / raw)
To: Chuck Lever
Cc: Trond Myklebust,
syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com, Anna Schumaker,
davem@davemloft.net, linux-kernel@vger.kernel.org,
Linux NFS Mailing List, jlayton@kernel.org,
netdev@vger.kernel.org
In-Reply-To: <4B24FAE4-C7E8-4D01-9808-B8F4E9E59D64@gmail.com>
On Tue, May 08, 2018 at 12:34:48PM -0400, Chuck Lever wrote:
>
>
> > On May 8, 2018, at 12:15 PM, bfields@fieldses.org wrote:
> >
> > On Tue, Apr 17, 2018 at 09:54:36PM +0000, Trond Myklebust wrote:
> >> Yes, and we can probably convert it, and the other GFP_ATOMIC
> >> allocations in the rpcbind client to use GFP_NOFS in order to improve
> >> reliability.
> >
> > Chuck, I think the GFP_ATOMIC is unnecessary here as well?
> >
> > --b.
> >
> > diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
> > index e8adad33d0bb..de90c6c90cde 100644
> > --- a/net/sunrpc/xprtrdma/rpc_rdma.c
> > +++ b/net/sunrpc/xprtrdma/rpc_rdma.c
> > @@ -228,7 +228,7 @@ rpcrdma_convert_iovs(struct rpcrdma_xprt *r_xprt, struct xdr_buf *xdrbuf,
> > /* XXX: Certain upper layer operations do
> > * not provide receive buffer pages.
> > */
> > - *ppages = alloc_page(GFP_ATOMIC);
> > + *ppages = alloc_page(GFP_NOFS);
> > if (!*ppages)
> > return -EAGAIN;
> > }
>
> This code can't sleep, as I understand it. Caller is holding
> the transport write lock. This logic was copied from
> xdr_partial_copy_from_skb, which uses GFP_ATOMIC.
OK.
> Recall that this is here because of GETACL. As I've stated in
> the past, the correct solution is to ensure that these pages
> are provided in every case by the upper layer, making this
> alloc_page call site unnecessary.
Got it.
--b.
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_do_sm
From: Xin Long @ 2018-05-08 17:41 UTC (permalink / raw)
To: syzbot
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <000000000000c10690056bb22ccd@google.com>
On Tue, May 8, 2018 at 9:58 PM, syzbot
<syzbot+141d898c5f24489db4aa@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f142f08bf7ec Fix typo in comment.
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1159ade7800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79
> dashboard link: https://syzkaller.appspot.com/bug?extid=141d898c5f24489db4aa
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+141d898c5f24489db4aa@syzkaller.appspotmail.com
>
> RDX: 0000000000000008 RSI: 0000000020000000 RDI: 0000000000000014
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
> R13: 000000000000071e R14: 00000000006feb70 R15: 0000000000000007
> ==================================================================
> BUG: KASAN: use-after-free in sctp_cmd_interpreter
> net/sctp/sm_sideeffect.c:1817 [inline]
> BUG: KASAN: use-after-free in sctp_side_effects
> net/sctp/sm_sideeffect.c:1220 [inline]
> BUG: KASAN: use-after-free in sctp_do_sm+0x6015/0x7160
> net/sctp/sm_sideeffect.c:1191
> Read of size 1 at addr ffff8801c7883cb8 by task syz-executor6/18616
>
> CPU: 1 PID: 18616 Comm: syz-executor6 Not tainted 4.17.0-rc4+ #38
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1817 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x6015/0x7160 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x30f/0x520 net/sctp/associola.c:1065
> sctp_inq_push+0x263/0x320 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x192/0xc00 net/sctp/input.c:350
> sk_backlog_rcv include/net/sock.h:909 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2335
> release_sock+0xa4/0x2b0 net/core/sock.c:2850
> sctp_sendmsg+0x13cc/0x1d70 net/sctp/socket.c:2128
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> sock_write_iter+0x35a/0x5a0 net/socket.c:908
> call_write_iter include/linux/fs.h:1784 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x64d/0x960 fs/read_write.c:487
> vfs_write+0x1f8/0x560 fs/read_write.c:549
> ksys_write+0xf9/0x250 fs/read_write.c:598
> __do_sys_write fs/read_write.c:610 [inline]
> __se_sys_write fs/read_write.c:607 [inline]
> __x64_sys_write+0x73/0xb0 fs/read_write.c:607
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x455979
> RSP: 002b:00007f6fad842c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007f6fad8436d4 RCX: 0000000000455979
> RDX: 0000000000000008 RSI: 0000000020000000 RDI: 0000000000000014
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000015
> R13: 000000000000071e R14: 00000000006feb70 R15: 0000000000000007
>
> Allocated by task 18616:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
> kmem_cache_zalloc include/linux/slab.h:691 [inline]
> sctp_chunkify+0xce/0x400 net/sctp/sm_make_chunk.c:1355
> sctp_rcv+0xc65/0x3a60 net/sctp/input.c:221
> sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1045
> ip6_input_finish+0x3ff/0x1a30 net/ipv6/ip6_input.c:284
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ip6_input+0xe1/0x5e0 net/ipv6/ip6_input.c:327
> dst_input include/net/dst.h:450 [inline]
> ip6_rcv_finish+0x29c/0xa10 net/ipv6/ip6_input.c:71
> NF_HOOK include/linux/netfilter.h:288 [inline]
> ipv6_rcv+0xed6/0x22a0 net/ipv6/ip6_input.c:208
> __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> process_backlog+0x219/0x760 net/core/dev.c:5337
> napi_poll net/core/dev.c:5735 [inline]
> net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>
> Freed by task 18616:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
> sctp_chunk_destroy net/sctp/sm_make_chunk.c:1481 [inline]
> sctp_chunk_put+0x321/0x440 net/sctp/sm_make_chunk.c:1504
> sctp_ulpevent_make_rcvmsg+0x955/0xd40 net/sctp/ulpevent.c:718
There's no reason to put the chunk in sctp_ulpevent_make_rcvmsg's
fail_mark err path before holding this chunk later there.
We should just remove it.
@@ -715,7 +715,6 @@ struct sctp_ulpevent
*sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
return event;
fail_mark:
- sctp_chunk_put(chunk);
kfree_skb(skb);
fail:
return NULL;
> sctp_ulpq_tail_data+0xa8/0x12b0 net/sctp/ulpqueue.c:108
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1478 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x1658/0x7160 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x30f/0x520 net/sctp/associola.c:1065
> sctp_inq_push+0x263/0x320 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x192/0xc00 net/sctp/input.c:350
> sk_backlog_rcv include/net/sock.h:909 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2335
> release_sock+0xa4/0x2b0 net/core/sock.c:2850
> sctp_sendmsg+0x13cc/0x1d70 net/sctp/socket.c:2128
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> sock_write_iter+0x35a/0x5a0 net/socket.c:908
> call_write_iter include/linux/fs.h:1784 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x64d/0x960 fs/read_write.c:487
> vfs_write+0x1f8/0x560 fs/read_write.c:549
> ksys_write+0xf9/0x250 fs/read_write.c:598
> __do_sys_write fs/read_write.c:610 [inline]
> __se_sys_write fs/read_write.c:607 [inline]
> __x64_sys_write+0x73/0xb0 fs/read_write.c:607
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8801c7883bc0
> which belongs to the cache sctp_chunk of size 256
> The buggy address is located 248 bytes inside of
> 256-byte region [ffff8801c7883bc0, ffff8801c7883cc0)
> The buggy address belongs to the page:
> page:ffffea00071e20c0 count:1 mapcount:0 mapping:ffff8801c7883080 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801c7883080 0000000000000000 000000010000000c
> raw: ffffea000723a220 ffff8801cdb66f48 ffff8801cdb65600 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801c7883b80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff8801c7883c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> ffff8801c7883c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>
> ^
> ffff8801c7883d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c7883d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [net-next 2/6] fm10k: reduce duplicate fm10k_stat macro code
From: Keller, Jacob E @ 2018-05-08 17:40 UTC (permalink / raw)
To: Joe Perches, Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <63a9f68a10b1b4754918df527b0697ee9d435753.camel@perches.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Joe Perches
> Sent: Tuesday, May 08, 2018 10:00 AM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; davem@davemloft.net
> Cc: Keller, Jacob E <jacob.e.keller@intel.com>; netdev@vger.kernel.org;
> nhorman@redhat.com; sassmann@redhat.com; jogreene@redhat.com
> Subject: Re: [net-next 2/6] fm10k: reduce duplicate fm10k_stat macro code
>
> On Mon, 2018-05-07 at 07:45 -0700, Jeff Kirsher wrote:
> > Share some of the code for setting up fm10k_stat macros by implementing
> > an FM10K_STAT_FIELDS macro which we can use when setting up the type
> > specific macros.
> []
> > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> []
> > @@ -11,12 +11,16 @@ struct fm10k_stats {
> > int stat_offset;
> > };o
> >
> > -#define FM10K_NETDEV_STAT(_net_stat) { \
> > - .stat_string = #_net_stat, \
> > - .sizeof_stat = FIELD_SIZEOF(struct net_device_stats, _net_stat), \
> > - .stat_offset = offsetof(struct net_device_stats, _net_stat) \
> > +#define FM10K_STAT_FIELDS(_type, _name, _stat) { \
> > + .stat_string = _name, \
> > + .sizeof_stat = FIELD_SIZEOF(_type, _stat), \
> > + .stat_offset = offsetof(_type, _stat) \
> > }
> >
> > +/* netdevice statistics */
> > +#define FM10K_NETDEV_STAT(_net_stat) \
> > + FM10K_STAT_FIELDS(struct net_device_stats, #_net_stat, _net_stat)
>
> trivia:
>
> It's somewhat unusual to use # in a macro argument.
> Perhaps this would be slightly easier to understand using __stringify
>
> #define FM10K_NETDEV_STAT(_net_stat) \
> FM10K_STAT_FIELDS(struct net_device_stats, __stringify(_net_stat),
> _net_stat)
Makes sense. Will change.
Thanks,
Jake
^ permalink raw reply
* [PATCH] hv_netvsc: Fix net device attach on older Windows hosts
From: Mohammed Gamal @ 2018-05-08 17:40 UTC (permalink / raw)
To: netdev, sthemmin
Cc: kys, haiyangz, devel, vkuznets, linux-kernel, Mohammed Gamal
On older windows hosts the net_device instance is returned to
the caller of rndis_filter_device_add() without having the presence
bit set first. This would cause any subsequent calls to network device
operations (e.g. MTU change, channel change) to fail after the device
is detached once, returning -ENODEV.
Make sure we explicitly call netif_device_attach() before returning
the net_device instance to make sure the presence bit is set
Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/rndis_filter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 6b127be..09a3c1d 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1287,8 +1287,10 @@ struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
rndis_device->hw_mac_adr,
rndis_device->link_state ? "down" : "up");
- if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
+ if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5) {
+ netif_device_attach(net);
return net_device;
+ }
rndis_filter_query_link_speed(rndis_device, net_device);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Dan Murphy @ 2018-05-08 17:21 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: netdev, linux-kernel
In-Reply-To: <cc5acc63-bcb5-2bda-9c9d-fd18e0a7740a@gmail.com>
Florian
On 05/08/2018 12:14 PM, Florian Fainelli wrote:
> On 05/08/2018 10:13 AM, Dan Murphy wrote:
>> Andrew
>>
>> On 05/08/2018 11:49 AM, Andrew Lunn wrote:
>>> On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
>>>> All
>>>>
>>>> On 05/08/2018 09:11 AM, Dan Murphy wrote:
>>>>> Add support for the DP83811 phy by extending
>>>>> the DP83822 driver to recognize the PHY IDs.
>>>>>
>>>>> The DP83811 supports both rgmii and sgmii interfaces.
>>>>> There are 2 part numbers for this the DP83811R does not
>>>>> reliably support the SGMII interface but the DP83811S will.
>>>>>
>>>>> There is not a way to differentiate these parts from the
>>>>> hardware or register set. So this is controlled via the DT
>>>>> to indicate which phy mode is required. Or the part can be
>>>>> strapped to a certain interface.
>>>>>
>>>>> Data sheet can be found here:
>>>>> http://www.ti.com/product/DP83TC811S-Q1/description
>>>>> http://www.ti.com/product/DP83TC811R-Q1/description
>>>>>
>>>>
>>>> I am withdrawing this patch for comment.
>>>> Some of the future features have varying register definitions between the DP83811
>>>> and DP83822
>>>
>>> Hi Dan
>>>
>>> It might be worth talking to the ASIC engineers and the
>>> test/qualification engineers. There are sometime undocumented
>>> registers for testing. You might be able to identify the exact device
>>> from these registers.
>>>
>>
>> Thanks. I talked to them prior to submitting this patch about determining which part is on the board.
>> I will ping them again and poke a little harder.
>>
>> It turns out that we will probably need a new driver for this part anyway as there are
>> additional features that need to be supported that the 811 just does not support.
>>
>> They want to support Master/Slave configurations.
>> The 822 supports fiber and eee while the 811 does not.
>> The 811 supports the IEEE802.3bw specific fields in MMD1 and MMD3, which are not in the 822.
>> The 811 does not support auto-negotiation on the MDI so all the auto-neg registers are invalid for the 811 but are valid for the 822.
>>
>> Our Customer engineers felt that combining these two devices into a single driver may confuse the customer.
>
> Why? Having a single Kconfig option to enable and "automatically"
> gaining support for new hardware is nice.
>
I do agree that it is nice to have. But with additional features or lack of features the driver source will get pretty messy
differentiating between devices.
What I added was just the basic if 811 & SGMII check.
Dan
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [net-next PATCH 0/3] Symmetric queue selection using XPS for Rx queues
From: Alexander Duyck @ 2018-05-08 17:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, Eric Dumazet, Amritha Nambiar, netdev, David Miller,
Alexander Duyck, Samudrala, Sridhar, Hannes Frederic Sowa
In-Reply-To: <439f729f-8a1d-1d2b-b59a-3f13786aab77@gmail.com>
On Tue, May 8, 2018 at 10:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 05/08/2018 09:02 AM, Alexander Duyck wrote:
>> On Tue, May 8, 2018 at 8:15 AM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Thu, Apr 19, 2018 at 7:41 PM, Eric Dumazet <edumazet@google.com> wrote:
>>>> On Thu, Apr 19, 2018 at 6:07 PM Amritha Nambiar <amritha.nambiar@intel.com>
>>>> wrote:
>>>>
>>>>> This patch series implements support for Tx queue selection based on
>>>>> Rx queue map. This is done by configuring Rx queue map per Tx-queue
>>>>> using sysfs attribute. If the user configuration for Rx queues does
>>>>> not apply, then the Tx queue selection falls back to XPS using CPUs and
>>>>> finally to hashing.
>>>>
>>>>> XPS is refactored to support Tx queue selection based on either the
>>>>> CPU map or the Rx-queue map. The config option CONFIG_XPS needs to be
>>>>> enabled. By default no receive queues are configured for the Tx queue.
>>>>
>>>>> - /sys/class/net/eth0/queues/tx-*/xps_rxqs
>>>>
>>>>> This is to enable sending packets on the same Tx-Rx queue pair as this
>>>>> is useful for busy polling multi-threaded workloads where it is not
>>>>> possible to pin the threads to a CPU. This is a rework of Sridhar's
>>>>> patch for symmetric queueing via socket option:
>>>>> https://www.spinics.net/lists/netdev/msg453106.html
>>>>
>>> I suspect this is an artifact of flow director which I believe
>>> required queue pairs to be able to work (i.e. receive queue chose
>>> hardware is determined send queue). But that was only required because
>>> of hardware design, I don't see the rationale for introducing queue
>>> pairs in the software stack. There's no need to correlate the transmit
>>> path with receive path, no need to enforce a 1-1 mapping between RX
>>> and TX queues, and the OOO mitigations should be sufficient when TX
>>> queue changes for a flow.
>>>
>>> Tom
>>
>> If I am not mistaken I think there are benefits to doing this sort of
>> thing with polling as it keeps the Tx work locked into the same queue
>> pair that a given application is polling on. So as a result you can
>> keep the interrupts contained to the queue pair that is being busy
>> polled on and if the application cleans up the packets during the busy
>> poll it ends up being a net savings in terms of both latency and power
>> since the Tx clean-up happens sooner, and it happens on the queue that
>> is already busy polling instead of possibly triggering an interrupt on
>> another CPU.
>>
>> So for example in the case of routing and bridging workloads we
>> already had code that would take the Rx queue and associate it to a Tx
>> queue. One of the ideas behind doing this is to try and keep the CPU
>> overhead low by having a 1:1 mapping. In the case of this code we
>> allow for a little more flexibility in that you could have
>> many-to-many mappings but the general idea and common use case is the
>> same which is a 1:1 mapping.
>
>
> I thought we had everything in place to be able to have this already.
>
> Setting IRQ affinities and XPS is certainly something doable.
>
> This is why I wanted a proper documentation of yet another way to reach the
> same behavior.
IRQ affinities and XPS work for pure NAPI setups, but the problem is
you have to also do application affinity in the case of busy polling
which can provide some additional challenges since then you have to
add code in your application to associate a given queue/CPU to a given
application thread. I believe this is a way of simplifying this.
I agree on the documentation aspect. The usage of this should be well
documented as well as the why of using it.
- Alex
^ permalink raw reply
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Florian Fainelli @ 2018-05-08 17:14 UTC (permalink / raw)
To: Dan Murphy, Andrew Lunn; +Cc: netdev, linux-kernel
In-Reply-To: <f4cfe325-f462-e965-3bd8-629acf460fbf@ti.com>
On 05/08/2018 10:13 AM, Dan Murphy wrote:
> Andrew
>
> On 05/08/2018 11:49 AM, Andrew Lunn wrote:
>> On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
>>> All
>>>
>>> On 05/08/2018 09:11 AM, Dan Murphy wrote:
>>>> Add support for the DP83811 phy by extending
>>>> the DP83822 driver to recognize the PHY IDs.
>>>>
>>>> The DP83811 supports both rgmii and sgmii interfaces.
>>>> There are 2 part numbers for this the DP83811R does not
>>>> reliably support the SGMII interface but the DP83811S will.
>>>>
>>>> There is not a way to differentiate these parts from the
>>>> hardware or register set. So this is controlled via the DT
>>>> to indicate which phy mode is required. Or the part can be
>>>> strapped to a certain interface.
>>>>
>>>> Data sheet can be found here:
>>>> http://www.ti.com/product/DP83TC811S-Q1/description
>>>> http://www.ti.com/product/DP83TC811R-Q1/description
>>>>
>>>
>>> I am withdrawing this patch for comment.
>>> Some of the future features have varying register definitions between the DP83811
>>> and DP83822
>>
>> Hi Dan
>>
>> It might be worth talking to the ASIC engineers and the
>> test/qualification engineers. There are sometime undocumented
>> registers for testing. You might be able to identify the exact device
>> from these registers.
>>
>
> Thanks. I talked to them prior to submitting this patch about determining which part is on the board.
> I will ping them again and poke a little harder.
>
> It turns out that we will probably need a new driver for this part anyway as there are
> additional features that need to be supported that the 811 just does not support.
>
> They want to support Master/Slave configurations.
> The 822 supports fiber and eee while the 811 does not.
> The 811 supports the IEEE802.3bw specific fields in MMD1 and MMD3, which are not in the 822.
> The 811 does not support auto-negotiation on the MDI so all the auto-neg registers are invalid for the 811 but are valid for the 822.
>
> Our Customer engineers felt that combining these two devices into a single driver may confuse the customer.
Why? Having a single Kconfig option to enable and "automatically"
gaining support for new hardware is nice.
--
Florian
^ permalink raw reply
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Dan Murphy @ 2018-05-08 17:13 UTC (permalink / raw)
To: Andrew Lunn; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <20180508164944.GE2888@lunn.ch>
Andrew
On 05/08/2018 11:49 AM, Andrew Lunn wrote:
> On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
>> All
>>
>> On 05/08/2018 09:11 AM, Dan Murphy wrote:
>>> Add support for the DP83811 phy by extending
>>> the DP83822 driver to recognize the PHY IDs.
>>>
>>> The DP83811 supports both rgmii and sgmii interfaces.
>>> There are 2 part numbers for this the DP83811R does not
>>> reliably support the SGMII interface but the DP83811S will.
>>>
>>> There is not a way to differentiate these parts from the
>>> hardware or register set. So this is controlled via the DT
>>> to indicate which phy mode is required. Or the part can be
>>> strapped to a certain interface.
>>>
>>> Data sheet can be found here:
>>> http://www.ti.com/product/DP83TC811S-Q1/description
>>> http://www.ti.com/product/DP83TC811R-Q1/description
>>>
>>
>> I am withdrawing this patch for comment.
>> Some of the future features have varying register definitions between the DP83811
>> and DP83822
>
> Hi Dan
>
> It might be worth talking to the ASIC engineers and the
> test/qualification engineers. There are sometime undocumented
> registers for testing. You might be able to identify the exact device
> from these registers.
>
Thanks. I talked to them prior to submitting this patch about determining which part is on the board.
I will ping them again and poke a little harder.
It turns out that we will probably need a new driver for this part anyway as there are
additional features that need to be supported that the 811 just does not support.
They want to support Master/Slave configurations.
The 822 supports fiber and eee while the 811 does not.
The 811 supports the IEEE802.3bw specific fields in MMD1 and MMD3, which are not in the 822.
The 811 does not support auto-negotiation on the MDI so all the auto-neg registers are invalid for the 811 but are valid for the 822.
Our Customer engineers felt that combining these two devices into a single driver may confuse the customer.
Dan
> Andrew
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: Performance regression between 4.13 and 4.14
From: Eric Dumazet @ 2018-05-08 17:10 UTC (permalink / raw)
To: Ben Greear, netdev
In-Reply-To: <9115910b-dd8b-e7f3-be53-f739b8382032@candelatech.com>
On 05/08/2018 09:44 AM, Ben Greear wrote:
> Hello,
>
> I am trying to track down a performance regression that appears to be between 4.13
> and 4.14.
>
> I first saw the problem with a hacked version of pktgen on some ixgbe NICs. 4.13 can do
> right at 10G bi-directional on two ports, and 4.14 and later can do only about 6Gbps.
>
> I also tried with user-space UDP traffic on a stock kernel, and I can get about 3.2Gbps combined tx+rx
> on 4.14 and about 4.4Gbps on 4.13.
>
> Attempting to bisect seems to be triggering a weirdness in git, and also lots of commits
> crash or do not bring up networking, which makes the bisect difficult.
>
> Looking at perf top, it would appear that some lock is probably to blame.
perf record -a -g -e cycles:pp sleep 5
perf report
Then you'll be able to tell us which lock (or call graph) is killing your perf.
^ permalink raw reply
* Re: [net-next PATCH 0/3] Symmetric queue selection using XPS for Rx queues
From: Eric Dumazet @ 2018-05-08 17:07 UTC (permalink / raw)
To: Alexander Duyck, Tom Herbert
Cc: Eric Dumazet, Amritha Nambiar, netdev, David Miller,
Alexander Duyck, Samudrala, Sridhar, Hannes Frederic Sowa
In-Reply-To: <CAKgT0UdtjZeY8-vw-BGKW-QRqqpkJSS83VUM9Dgueh312h1omg@mail.gmail.com>
On 05/08/2018 09:02 AM, Alexander Duyck wrote:
> On Tue, May 8, 2018 at 8:15 AM, Tom Herbert <tom@herbertland.com> wrote:
>> On Thu, Apr 19, 2018 at 7:41 PM, Eric Dumazet <edumazet@google.com> wrote:
>>> On Thu, Apr 19, 2018 at 6:07 PM Amritha Nambiar <amritha.nambiar@intel.com>
>>> wrote:
>>>
>>>> This patch series implements support for Tx queue selection based on
>>>> Rx queue map. This is done by configuring Rx queue map per Tx-queue
>>>> using sysfs attribute. If the user configuration for Rx queues does
>>>> not apply, then the Tx queue selection falls back to XPS using CPUs and
>>>> finally to hashing.
>>>
>>>> XPS is refactored to support Tx queue selection based on either the
>>>> CPU map or the Rx-queue map. The config option CONFIG_XPS needs to be
>>>> enabled. By default no receive queues are configured for the Tx queue.
>>>
>>>> - /sys/class/net/eth0/queues/tx-*/xps_rxqs
>>>
>>>> This is to enable sending packets on the same Tx-Rx queue pair as this
>>>> is useful for busy polling multi-threaded workloads where it is not
>>>> possible to pin the threads to a CPU. This is a rework of Sridhar's
>>>> patch for symmetric queueing via socket option:
>>>> https://www.spinics.net/lists/netdev/msg453106.html
>>>
>> I suspect this is an artifact of flow director which I believe
>> required queue pairs to be able to work (i.e. receive queue chose
>> hardware is determined send queue). But that was only required because
>> of hardware design, I don't see the rationale for introducing queue
>> pairs in the software stack. There's no need to correlate the transmit
>> path with receive path, no need to enforce a 1-1 mapping between RX
>> and TX queues, and the OOO mitigations should be sufficient when TX
>> queue changes for a flow.
>>
>> Tom
>
> If I am not mistaken I think there are benefits to doing this sort of
> thing with polling as it keeps the Tx work locked into the same queue
> pair that a given application is polling on. So as a result you can
> keep the interrupts contained to the queue pair that is being busy
> polled on and if the application cleans up the packets during the busy
> poll it ends up being a net savings in terms of both latency and power
> since the Tx clean-up happens sooner, and it happens on the queue that
> is already busy polling instead of possibly triggering an interrupt on
> another CPU.
>
> So for example in the case of routing and bridging workloads we
> already had code that would take the Rx queue and associate it to a Tx
> queue. One of the ideas behind doing this is to try and keep the CPU
> overhead low by having a 1:1 mapping. In the case of this code we
> allow for a little more flexibility in that you could have
> many-to-many mappings but the general idea and common use case is the
> same which is a 1:1 mapping.
I thought we had everything in place to be able to have this already.
Setting IRQ affinities and XPS is certainly something doable.
This is why I wanted a proper documentation of yet another way to reach the
same behavior.
^ permalink raw reply
* Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()
From: Paul Moore @ 2018-05-08 17:05 UTC (permalink / raw)
To: Alexey Kodanev, Richard Haines
Cc: selinux, Stephen Smalley, Eric Paris, linux-security-module,
netdev
In-Reply-To: <1525788303-23244-1-git-send-email-alexey.kodanev@oracle.com>
On Tue, May 8, 2018 at 10:05 AM, Alexey Kodanev
<alexey.kodanev@oracle.com> wrote:
> Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility
> with the old programs that can pass sockaddr_in with AF_UNSPEC and
> INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error.
> It was found with LTP/asapi_01 test.
>
> Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in
> bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC
> case to AF_INET and make sure that the address is INADDR_ANY.
>
> Also, in the end of selinux_socket_bind(), instead of adding AF_UNSPEC
> to 'address->sa_family == AF_INET', verify AF_INET6 first.
>
> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
> ---
> security/selinux/hooks.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Thanks for finding and reporting this regression.
I think I would prefer to avoid having to duplicate the
AF_UNSPEC/INADDR_ANY checking logic in the SELinux hook, even though
it is a small bit of code and unlikely to change. I'm wondering if it
would be better to check both the socket and sockaddr address family
in the main if conditional inside selinux_socket_bind(), what do you
think? Another option would be to go back to just checking the
soackaddr address family; we moved away from that for a reason which
escapes at the moment (code cleanliness?), but perhaps that was a
mistake.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4cafe6a19167..a3789b167667 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4577,6 +4577,7 @@ static int selinux_socket_bind(struct socket *sock, struc>
{
struct sock *sk = sock->sk;
u16 family;
+ u16 family_sa;
int err;
err = sock_has_perm(sk, SOCKET__BIND);
@@ -4585,7 +4586,9 @@ static int selinux_socket_bind(struct socket *sock, struc>
/* If PF_INET or PF_INET6, check name_bind permission for the port. */
family = sk->sk_family;
- if (family == PF_INET || family == PF_INET6) {
+ family_sa = address->sa_family;
+ if ((family == PF_INET || family == PF_INET6) &&
+ (family_sa == PF_INET || family_sa == PF_INET6)) {
char *addrp;
struct sk_security_struct *sksec = sk->sk_security;
struct common_audit_data ad;
@@ -4601,7 +4604,7 @@ static int selinux_socket_bind(struct socket *sock, struc>
* need to check address->sa_family as it is possible to have
* sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
*/
- switch (address->sa_family) {
+ switch (family_sa) {
case AF_INET:
if (addrlen < sizeof(struct sockaddr_in))
return -EINVAL;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4cafe6a..649a3be 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4602,10 +4602,16 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
> */
> switch (address->sa_family) {
> + case AF_UNSPEC:
> case AF_INET:
> if (addrlen < sizeof(struct sockaddr_in))
> return -EINVAL;
> addr4 = (struct sockaddr_in *)address;
> +
> + if (address->sa_family == AF_UNSPEC &&
> + addr4->sin_addr.s_addr != htonl(INADDR_ANY))
> + return -EAFNOSUPPORT;
> +
> snum = ntohs(addr4->sin_port);
> addrp = (char *)&addr4->sin_addr.s_addr;
> break;
> @@ -4681,10 +4687,10 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
> ad.u.net->sport = htons(snum);
> ad.u.net->family = family;
>
> - if (address->sa_family == AF_INET)
> - ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
> - else
> + if (address->sa_family == AF_INET6)
> ad.u.net->v6info.saddr = addr6->sin6_addr;
> + else
> + ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
>
> err = avc_has_perm(&selinux_state,
> sksec->sid, sid,
> --
> 1.8.3.1
>
--
paul moore
www.paul-moore.com
^ permalink raw reply related
* Re: [net-next 2/6] fm10k: reduce duplicate fm10k_stat macro code
From: Joe Perches @ 2018-05-08 16:59 UTC (permalink / raw)
To: Jeff Kirsher, davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180507144521.6979-3-jeffrey.t.kirsher@intel.com>
On Mon, 2018-05-07 at 07:45 -0700, Jeff Kirsher wrote:
> Share some of the code for setting up fm10k_stat macros by implementing
> an FM10K_STAT_FIELDS macro which we can use when setting up the type
> specific macros.
[]
> diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
[]
> @@ -11,12 +11,16 @@ struct fm10k_stats {
> int stat_offset;
> };o
>
> -#define FM10K_NETDEV_STAT(_net_stat) { \
> - .stat_string = #_net_stat, \
> - .sizeof_stat = FIELD_SIZEOF(struct net_device_stats, _net_stat), \
> - .stat_offset = offsetof(struct net_device_stats, _net_stat) \
> +#define FM10K_STAT_FIELDS(_type, _name, _stat) { \
> + .stat_string = _name, \
> + .sizeof_stat = FIELD_SIZEOF(_type, _stat), \
> + .stat_offset = offsetof(_type, _stat) \
> }
>
> +/* netdevice statistics */
> +#define FM10K_NETDEV_STAT(_net_stat) \
> + FM10K_STAT_FIELDS(struct net_device_stats, #_net_stat, _net_stat)
trivia:
It's somewhat unusual to use # in a macro argument.
Perhaps this would be slightly easier to understand using __stringify
#define FM10K_NETDEV_STAT(_net_stat) \
FM10K_STAT_FIELDS(struct net_device_stats, __stringify(_net_stat), _net_stat)
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: dsa: Remove unnecessary #address/#size-cells
From: Rob Herring @ 2018-05-08 16:53 UTC (permalink / raw)
To: Fabio Estevam
Cc: davem, f.fainelli, andrew, netdev, devicetree, Fabio Estevam
In-Reply-To: <1525695471-19984-1-git-send-email-festevam@gmail.com>
On Mon, May 07, 2018 at 09:17:51AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> If the example binding is used on a real dts file, the following DTC
> warning is seen with W=1:
>
> arch/arm/boot/dts/imx6q-b450v3.dtb: Warning (avoid_unnecessary_addr_size): /mdio-gpio/switch@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Remove unnecessary #address-cells/#size-cells to improve the binding
> document examples.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Documentation/devicetree/bindings/net/dsa/dsa.txt | 6 ------
> 1 file changed, 6 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: phy: DP83811: Add support for the phy
From: Andrew Lunn @ 2018-05-08 16:49 UTC (permalink / raw)
To: Dan Murphy; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <1b6877db-61cf-101a-054e-9c1fbe95a813@ti.com>
On Tue, May 08, 2018 at 10:56:55AM -0500, Dan Murphy wrote:
> All
>
> On 05/08/2018 09:11 AM, Dan Murphy wrote:
> > Add support for the DP83811 phy by extending
> > the DP83822 driver to recognize the PHY IDs.
> >
> > The DP83811 supports both rgmii and sgmii interfaces.
> > There are 2 part numbers for this the DP83811R does not
> > reliably support the SGMII interface but the DP83811S will.
> >
> > There is not a way to differentiate these parts from the
> > hardware or register set. So this is controlled via the DT
> > to indicate which phy mode is required. Or the part can be
> > strapped to a certain interface.
> >
> > Data sheet can be found here:
> > http://www.ti.com/product/DP83TC811S-Q1/description
> > http://www.ti.com/product/DP83TC811R-Q1/description
> >
>
> I am withdrawing this patch for comment.
> Some of the future features have varying register definitions between the DP83811
> and DP83822
Hi Dan
It might be worth talking to the ASIC engineers and the
test/qualification engineers. There are sometime undocumented
registers for testing. You might be able to identify the exact device
from these registers.
Andrew
^ permalink raw reply
* Performance regression between 4.13 and 4.14
From: Ben Greear @ 2018-05-08 16:44 UTC (permalink / raw)
To: netdev
Hello,
I am trying to track down a performance regression that appears to be between 4.13
and 4.14.
I first saw the problem with a hacked version of pktgen on some ixgbe NICs. 4.13 can do
right at 10G bi-directional on two ports, and 4.14 and later can do only about 6Gbps.
I also tried with user-space UDP traffic on a stock kernel, and I can get about 3.2Gbps combined tx+rx
on 4.14 and about 4.4Gbps on 4.13.
Attempting to bisect seems to be triggering a weirdness in git, and also lots of commits
crash or do not bring up networking, which makes the bisect difficult.
Looking at perf top, it would appear that some lock is probably to blame.
Any ideas what might have been introduced during this interval that
would cause this?
Anyone else seen similar?
I'm going to attempt some more manual steps to try to find the commit that
introduces this...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: general protection fault in encode_rpcb_string
From: Chuck Lever @ 2018-05-08 16:34 UTC (permalink / raw)
To: Bruce Fields
Cc: Trond Myklebust,
syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com, Anna Schumaker,
davem@davemloft.net, linux-kernel@vger.kernel.org,
Linux NFS Mailing List, jlayton@kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20180508161529.GD6151@fieldses.org>
> On May 8, 2018, at 12:15 PM, bfields@fieldses.org wrote:
>
> On Tue, Apr 17, 2018 at 09:54:36PM +0000, Trond Myklebust wrote:
>> Yes, and we can probably convert it, and the other GFP_ATOMIC
>> allocations in the rpcbind client to use GFP_NOFS in order to improve
>> reliability.
>
> Chuck, I think the GFP_ATOMIC is unnecessary here as well?
>
> --b.
>
> diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
> index e8adad33d0bb..de90c6c90cde 100644
> --- a/net/sunrpc/xprtrdma/rpc_rdma.c
> +++ b/net/sunrpc/xprtrdma/rpc_rdma.c
> @@ -228,7 +228,7 @@ rpcrdma_convert_iovs(struct rpcrdma_xprt *r_xprt, struct xdr_buf *xdrbuf,
> /* XXX: Certain upper layer operations do
> * not provide receive buffer pages.
> */
> - *ppages = alloc_page(GFP_ATOMIC);
> + *ppages = alloc_page(GFP_NOFS);
> if (!*ppages)
> return -EAGAIN;
> }
This code can't sleep, as I understand it. Caller is holding
the transport write lock. This logic was copied from
xdr_partial_copy_from_skb, which uses GFP_ATOMIC.
Recall that this is here because of GETACL. As I've stated in
the past, the correct solution is to ensure that these pages
are provided in every case by the upper layer, making this
alloc_page call site unnecessary.
--
Chuck Lever
chucklever@gmail.com
^ permalink raw reply
* [PATCH net-next] tun: Do SIOCGSKNS out of rtnl_lock()
From: Kirill Tkhai @ 2018-05-08 16:21 UTC (permalink / raw)
To: davem, jasowang, edumazet, mst, brouer, peterpenkov96, sd, netdev,
ktkhai
Since net ns of tun device is assigned on the device creation,
and it never changes, we do not need to use any lock to get it
from alive tun.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
drivers/net/tun.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index d3c04ab9752a..44d4f3d25350 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2850,10 +2850,10 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
unsigned long arg, int ifreq_len)
{
struct tun_file *tfile = file->private_data;
+ struct net *net = sock_net(&tfile->sk);
struct tun_struct *tun;
void __user* argp = (void __user*)arg;
struct ifreq ifr;
- struct net *net;
kuid_t owner;
kgid_t group;
int sndbuf;
@@ -2877,14 +2877,18 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
*/
return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
(unsigned int __user*)argp);
- } else if (cmd == TUNSETQUEUE)
+ } else if (cmd == TUNSETQUEUE) {
return tun_set_queue(file, &ifr);
+ } else if (cmd == SIOCGSKNS) {
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
+ return -EPERM;
+ return open_related_ns(&net->ns, get_net_ns);
+ }
ret = 0;
rtnl_lock();
tun = tun_get(tfile);
- net = sock_net(&tfile->sk);
if (cmd == TUNSETIFF) {
ret = -EEXIST;
if (tun)
@@ -2914,14 +2918,6 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
tfile->ifindex = ifindex;
goto unlock;
}
- if (cmd == SIOCGSKNS) {
- ret = -EPERM;
- if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
- goto unlock;
-
- ret = open_related_ns(&net->ns, get_net_ns);
- goto unlock;
- }
ret = -EBADFD;
if (!tun)
^ permalink raw reply related
* Re: [net PATCH v2] net: sched, fix OOO packets with pfifo_fast
From: Paolo Abeni @ 2018-05-08 16:17 UTC (permalink / raw)
To: John Fastabend, Cong Wang, Jamal Hadi Salim
Cc: Eric Dumazet, Jiri Pirko, David Miller,
Linux Kernel Network Developers
In-Reply-To: <36a89ed1-d6ff-ddad-c736-4e68909d61c4@gmail.com>
Hi all,
I'm still crashing my head on this item...
On Wed, 2018-04-18 at 09:44 -0700, John Fastabend wrote:
> There is a set of conditions
> that if met we can run without the lock. Possibly ONETXQUEUE and
> aligned cpu_map is sufficient. We could detect this case and drop
> the locking. For existing systems and high Gbps NICs I think (feel
> free to correct me) assuming a core per cpu is OK. At some point
> though we probably need to revisit this assumption.
I think we can improve measurably moving the __QDISC_STATE_RUNNING bit
fiddling around the __qdisc_run() call in the 'lockless' path, instead
of keeping it inside __qdisc_restart().
Currently, in the single sender, pkt rate below link-limit scenario we
hit the atomic bit overhead twice per xmitted packet: one for each
dequeue, plus another one for the next, failing, dequeue attempt. With
the wider scope we will hit it always only once.
After that change __QDISC_STATE_RUNNING usage will look a bit like
qdisc_lock(), for the dequeue part at least. So I'm wondering if we
could replace __QDISC_STATE_RUNNING with spin_trylock(qdisc_lock())
_and_ keep such lock held for the whole qdisc_run() !?!
The comment above qdisc_restart() states clearly we can't, but I don't
see why !?! Acquiring qdisc_lock() and xmit lock always in the given
sequence looks safe to me. Can someone please explain? Is there some
possible deathlock condition I'm missing ?!?
It looks like the comment itself cames directly from the pre-bitkeeper
era (modulo locks name change).
Performance wise, acquiring the qdisc_lock only once per xmitted packet
should improve considerably 'locked' qdisc performance, both in the
contented and in the uncontended scenario (and some quick experiments
seems to confirm that).
Thanks,
Paolo
^ permalink raw reply
* Re: [RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020
From: Rob Herring @ 2018-05-08 16:16 UTC (permalink / raw)
To: Andrea Greco
Cc: m.grzeschik, Andrea Greco, Mark Rutland, netdev, devicetree,
linux-kernel
In-Reply-To: <20180505213448.8180-1-andrea.greco.gapmilano@gmail.com>
On Sat, May 05, 2018 at 11:34:45PM +0200, Andrea Greco wrote:
> From: Andrea Greco <a.greco@4sigma.it>
>
> Add support for com20022I/com20020, memory mapped chip version.
> Support bus: Intel 80xx and Motorola 68xx.
> Bus size: Only 8 bit bus size is supported.
> Added related device tree bindings
>
> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
> ---
> .../devicetree/bindings/net/smsc-com20020.txt | 23 +++
Please split bindings to separate patch.
> drivers/net/arcnet/Kconfig | 12 +-
> drivers/net/arcnet/Makefile | 1 +
> drivers/net/arcnet/arcdevice.h | 27 ++-
> drivers/net/arcnet/com20020-membus.c | 191 +++++++++++++++++++++
> drivers/net/arcnet/com20020.c | 9 +-
> 6 files changed, 253 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
> create mode 100644 drivers/net/arcnet/com20020-membus.c
>
> diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> new file mode 100644
> index 000000000000..39c5b19c55af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> @@ -0,0 +1,23 @@
> +SMSC com20020, com20022I
What does this device do?
> +
> +timeout: Arcnet timeout, checkout datashet
> +clockp: Clock Prescaler, checkout datashet
s/datashet/datasheet/
> +clockm: Clock multiplier, checkout datasheet
Would these 3 properties be common for arcnet devices? If not, then they
should have a vendor prefix.
> +
> +phy-reset-gpios: Chip reset ppin
Use 'reset-gpios' as that is standard.
> +phy-irq-gpios: Chip irq pin
Use 'interrupts'. Interrupt capable gpio controllers are also interrupt
controllers.
> +
> +com20020_A@0 {
Node names should be generic based on the class of device. I don't think
we have one defined, but how about 'arcnet'.
Unit addresses must have a corresponding reg property. How is this
device accessed?
> + compatible = "smsc,com20020";
Not documented.
> +
> + timeout = <0x3>;
> + backplane = <0x0>;
> +
> + clockp = <0x0>;
> + clockm = <0x3>;
> +
> + phy-reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>;
> + phy-irq-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> +
> + status = "okay";
Don't should status in examples.
> +};
^ permalink raw reply
* Re: general protection fault in encode_rpcb_string
From: bfields @ 2018-05-08 16:15 UTC (permalink / raw)
To: Trond Myklebust
Cc: syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com, anna.schumaker@netapp.com,
davem@davemloft.net, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org, jlayton@kernel.org,
netdev@vger.kernel.org, Chuck Lever
In-Reply-To: <1524002074.63751.5.camel@hammer.space>
On Tue, Apr 17, 2018 at 09:54:36PM +0000, Trond Myklebust wrote:
> Yes, and we can probably convert it, and the other GFP_ATOMIC
> allocations in the rpcbind client to use GFP_NOFS in order to improve
> reliability.
Chuck, I think the GFP_ATOMIC is unnecessary here as well?
--b.
diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
index e8adad33d0bb..de90c6c90cde 100644
--- a/net/sunrpc/xprtrdma/rpc_rdma.c
+++ b/net/sunrpc/xprtrdma/rpc_rdma.c
@@ -228,7 +228,7 @@ rpcrdma_convert_iovs(struct rpcrdma_xprt *r_xprt, struct xdr_buf *xdrbuf,
/* XXX: Certain upper layer operations do
* not provide receive buffer pages.
*/
- *ppages = alloc_page(GFP_ATOMIC);
+ *ppages = alloc_page(GFP_NOFS);
if (!*ppages)
return -EAGAIN;
}
^ permalink raw reply related
* Re: general protection fault in encode_rpcb_string
From: bfields @ 2018-05-08 16:11 UTC (permalink / raw)
To: Trond Myklebust
Cc: syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com, anna.schumaker@netapp.com,
davem@davemloft.net, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org, jlayton@kernel.org,
netdev@vger.kernel.org
In-Reply-To: <1524002074.63751.5.camel@hammer.space>
From: "J. Bruce Fields" <bfields@redhat.com>
Date: Tue, 8 May 2018 11:47:03 -0400
Subject: [PATCH 2/2] sunrpc: convert unnecessary GFP_ATOMIC to GFP_NOFS
It's OK to sleep here, we just don't want to recurse into the filesystem
as this writeout could be waiting on this.
As a next step: the documentation for GFP_NOFS says "Please try to avoid
using this flag directly and instead use memalloc_nofs_{save,restore} to
mark the whole scope which cannot/shouldn't recurse into the FS layer
with a short explanation why. All allocation requests will inherit
GFP_NOFS implicitly."
But I'm not sure where to do this. Should the workqueue could be
arranging that for us in the case of workqueues created with
WQ_MEM_RECLAIM?
Reported-by: Trond Myklebust <trondmy@hammer.space>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
net/sunrpc/rpcb_clnt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Tue, Apr 17, 2018 at 09:54:36PM +0000, Trond Myklebust wrote:
> Yes, and we can probably convert it, and the other GFP_ATOMIC
> allocations in the rpcbind client to use GFP_NOFS in order to improve
> reliability.
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index 82c120e51d64..576e84a1adee 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -752,7 +752,7 @@ void rpcb_getport_async(struct rpc_task *task)
goto bailout_nofree;
}
- map = kzalloc(sizeof(struct rpcbind_args), GFP_ATOMIC);
+ map = kzalloc(sizeof(struct rpcbind_args), GFP_NOFS);
if (!map) {
status = -ENOMEM;
dprintk("RPC: %5u %s: no memory available\n",
@@ -770,7 +770,7 @@ void rpcb_getport_async(struct rpc_task *task)
case RPCBVERS_4:
case RPCBVERS_3:
map->r_netid = xprt->address_strings[RPC_DISPLAY_NETID];
- map->r_addr = rpc_sockaddr2uaddr(sap, GFP_ATOMIC);
+ map->r_addr = rpc_sockaddr2uaddr(sap, GFP_NOFS);
if (!map->r_addr) {
status = -ENOMEM;
dprintk("RPC: %5u %s: no memory available\n",
--
2.17.0
^ 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