* Re: [PATCH net] net: thunderx: set tso_hdrs pointer to NULL in nicvf_free_snd_queue
From: Lorenzo Bianconi @ 2018-11-24 8:35 UTC (permalink / raw)
To: David S. Miller; +Cc: Network Development, Sunil.Goutham
In-Reply-To: <20181123.223334.1969691917725314747.davem@davemloft.net>
> From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> Date: Fri, 23 Nov 2018 18:28:01 +0100
>
> > Reset snd_queue tso_hdrs pointer to NULL in nicvf_free_snd_queue routine
> > since it is used to check if tso dma descriptor queue has been previously
> > allocated. The issue can be triggered with the following reproducer:
> >
> > $ip link set dev enP2p1s0v0 xdpdrv obj xdp_dummy.o
> > $ip link set dev enP2p1s0v0 xdpdrv off
> ...
> > where xdp_dummy.c is a simple bpf program that forwards the incoming
> > frames to the network stack (available here:
> > https://github.com/altoor/xdp_walkthrough_examples/blob/master/sample_1/xdp_dummy.c)
> >
> > Fixes: 05c773f52b96 ("net: thunderx: Add basic XDP support")
> > Fixes: 4863dea3fab0 ("net: Adding support for Cavium ThunderX network
> > controller")
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
>
> Applied and queued up for -stable, but please in the future:
>
> 1) Do not break up long "Fixes: " tag lines, it must be keep as a single
> uninterrupted line for grep'ability etc.
>
> 2) Do not put an empty line between "Fixes: " and other tags. All tags
> are equal, and appear in a straight uninterrupted sequence of lines.
>
Hi David,
ack, will do next time.
Regards,
Lorenzo
> Thank you.
^ permalink raw reply
* Re: [PATCH 6/8] socket: Add struct sock_timeval
From: Willem de Bruijn @ 2018-11-24 19:37 UTC (permalink / raw)
To: deepa.kernel
Cc: Arnd Bergmann, y2038 Mailman List, Network Development, LKML,
Al Viro, David Miller
In-Reply-To: <20181124022035.17519-7-deepa.kernel@gmail.com>
On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> The new type is meant to be used as a y2038 safe structure
> to be used as part of cmsg data.
> Presently the SO_TIMESTAMP socket option uses struct timeval
> for timestamps. This is not y2038 safe.
> Subsequent patches in the series add new y2038 safe socket
> option to be used in the place of SO_TIMESTAMP_OLD.
> struct sock_timeval will be used as the timestamp format
> at that time.
>
> struct sock_timeval also maintains the same layout across
> 32 bit and 64 bit ABIs.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> ---
> include/uapi/linux/time.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
> index 04d5587f30d3..106f9398c285 100644
> --- a/include/uapi/linux/time.h
> +++ b/include/uapi/linux/time.h
> @@ -70,6 +70,11 @@ struct __kernel_old_timeval {
> };
> #endif
>
> +struct sock_timeval {
> + long long tv_sec;
> + long long tv_usec;
should these use fixed-width type __u64?
even if all data models define long long as 64-bit, that might be more
descriptive.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* WARNING in csum_and_copy_to_iter
From: syzbot @ 2018-11-24 19:40 UTC (permalink / raw)
To: davem, gregkh, kgraul, linux-kernel, netdev, stranche,
syzkaller-bugs, viro
Hello,
syzbot found the following crash on:
HEAD commit: edeca3a769ad Merge tag 'sound-4.20-rc4' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12bee26d400000
kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446
dashboard link: https://syzkaller.appspot.com/bug?extid=ce18da013d76d837144d
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ccd1f5400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ce18da013d76d837144d@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
WARNING: CPU: 1 PID: 7440 at lib/iov_iter.c:1443
csum_and_copy_to_iter+0x73a/0x14f0 lib/iov_iter.c:1443
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 7440 Comm: syz-executor2 Not tainted 4.20.0-rc3+ #345
kobject: 'loop0' (00000000da2348da): kobject_uevent_env
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+0x244/0x39d lib/dump_stack.c:113
panic+0x2ad/0x55c kernel/panic.c:188
kobject: 'loop0' (00000000da2348da): fill_kobj_path: path
= '/devices/virtual/block/loop0'
__warn.cold.8+0x20/0x45 kernel/panic.c:540
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
WARNING: CPU: 0 PID: 7446 at lib/iov_iter.c:1443
csum_and_copy_to_iter+0x73a/0x14f0 lib/iov_iter.c:1443
Modules linked in:
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
CPU: 0 PID: 7446 Comm: syz-executor0 Not tainted 4.20.0-rc3+ #345
RIP: 0010:csum_and_copy_to_iter+0x73a/0x14f0 lib/iov_iter.c:1443
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Code: ee fd 48 83 bd b0 fe ff ff 00 0f 84 48 fc ff ff e9 91 fe ff ff e8 e6
6d ee fd 49 83 c4 10 31 db e9 70 fc ff ff e8 d6 6d ee fd <0f> 0b 48 c7 85
e8 fe ff ff 00 00 00 00 e9 70 fd ff ff 4c 89 f7 e8
RIP: 0010:csum_and_copy_to_iter+0x73a/0x14f0 lib/iov_iter.c:1443
RSP: 0018:ffff8881bc80f368 EFLAGS: 00010293
Code: ee fd 48 83 bd b0 fe ff ff 00 0f 84 48 fc ff ff e9 91 fe ff ff e8 e6
6d ee fd 49 83 c4 10 31 db e9 70 fc ff ff e8 d6 6d ee fd <0f> 0b 48 c7 85
e8 fe ff ff 00 00 00 00 e9 70 fd ff ff 4c 89 f7 e8
RAX: ffff8881c87ca080 RBX: 000000000000038a RCX: ffffffff839116c2
RSP: 0018:ffff8881bbabf368 EFLAGS: 00010293
RDX: 0000000000000000 RSI: ffffffff83911d1a RDI: 0000000000000005
RAX: ffff8881caf18080 RBX: 000000000000038a RCX: ffffffff839116c2
RBP: ffff8881bc80f4f8 R08: ffff8881c87ca080 R09: 0000000000000006
RDX: 0000000000000000 RSI: ffffffff83911d1a RDI: 0000000000000005
R10: 0000000000000000 R11: ffff8881c87ca080 R12: 0000000000000000
RBP: ffff8881bbabf4f8 R08: ffff8881caf18080 R09: 0000000000000006
R13: 0000000000000008 R14: ffff8881bc80fa50 R15: 000000000000038a
R10: 0000000000000000 R11: ffff8881caf18080 R12: 0000000000000000
R13: 0000000000000008 R14: ffff8881bbabfa50 R15: 000000000000038a
FS: 00007fed2599c700(0000) GS:ffff8881dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004cce48 CR3: 00000001cf367000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
skb_copy_and_csum_datagram+0x1ab/0xae0 net/core/datagram.c:662
skb_copy_and_csum_datagram+0x1ab/0xae0 net/core/datagram.c:662
skb_copy_and_csum_datagram_msg+0x246/0x420 net/core/datagram.c:802
udpv6_recvmsg+0xd62/0x1d80 net/ipv6/udp.c:376
skb_copy_and_csum_datagram_msg+0x246/0x420 net/core/datagram.c:802
udpv6_recvmsg+0xd62/0x1d80 net/ipv6/udp.c:376
inet_recvmsg+0x181/0x6d0 net/ipv4/af_inet.c:830
inet_recvmsg+0x181/0x6d0 net/ipv4/af_inet.c:830
sock_recvmsg_nosec net/socket.c:794 [inline]
sock_recvmsg+0xd0/0x110 net/socket.c:801
sock_read_iter+0x39b/0x570 net/socket.c:878
call_read_iter include/linux/fs.h:1851 [inline]
generic_file_splice_read+0x5a2/0x9a0 fs/splice.c:308
sock_recvmsg_nosec net/socket.c:794 [inline]
sock_recvmsg+0xd0/0x110 net/socket.c:801
sock_read_iter+0x39b/0x570 net/socket.c:878
sock_splice_read+0xef/0x110 net/socket.c:856
do_splice_to+0x12e/0x190 fs/splice.c:880
call_read_iter include/linux/fs.h:1851 [inline]
generic_file_splice_read+0x5a2/0x9a0 fs/splice.c:308
do_splice+0x1014/0x1430 fs/splice.c:1173
sock_splice_read+0xef/0x110 net/socket.c:856
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_splice_to+0x12e/0x190 fs/splice.c:880
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
do_splice+0x1014/0x1430 fs/splice.c:1173
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f6517086c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000113
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000457569
RDX: 0000000000000004 RSI: 0000000000000000 RDI: 0000000000000003
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RBP: 000000000072bfa0 R08: 0000000010000200 R09: 0000000000000000
RIP: 0033:0x457569
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f65170876d4
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
R13: 00000000004c5719 R14: 00000000004d8c08 R15: 00000000ffffffff
RSP: 002b:00007fed2599bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000113
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000457569
RDX: 0000000000000004 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 000000000072bfa0 R08: 0000000010000200 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fed2599c6d4
R13: 00000000004c5719 R14: 00000000004d8c08 R15: 00000000ffffffff
irq event stamp: 352
hardirqs last enabled at (351): [<ffffffff814ad030>]
__local_bh_enable_ip+0x160/0x260 kernel/softirq.c:194
hardirqs last disabled at (352): [<ffffffff81007ced>]
trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last enabled at (350): [<ffffffff86aef3ab>] spin_unlock_bh
include/linux/spinlock.h:374 [inline]
softirqs last enabled at (350): [<ffffffff86aef3ab>]
__skb_recv_udp+0x4ab/0xaf0 net/ipv4/udp.c:1611
softirqs last disabled at (348): [<ffffffff86aef190>] spin_lock_bh
include/linux/spinlock.h:334 [inline]
softirqs last disabled at (348): [<ffffffff86aef190>]
__skb_recv_udp+0x290/0xaf0 net/ipv4/udp.c:1583
---[ end trace fcfb475d82d5a575 ]---
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH] net: fixup type in netdev_start_xmit()
From: Alexey Dobriyan @ 2018-11-24 9:01 UTC (permalink / raw)
To: davem; +Cc: netdev
Return code should be formally "netdev_tx_t".
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
include/linux/netdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4373,7 +4373,7 @@ static inline netdev_tx_t netdev_start_xmit(struct sk_buff *skb, struct net_devi
struct netdev_queue *txq, bool more)
{
const struct net_device_ops *ops = dev->netdev_ops;
- int rc;
+ netdev_tx_t rc;
rc = __netdev_start_xmit(ops, skb, dev, more);
if (rc == NETDEV_TX_OK)
^ permalink raw reply
* Donation,Reply, New email
From: =?utf-8?q?Marina_Jo=C3=A3o_Jose_=3Chelpdesk=40petrochina=2Ecom=2Ecn=3E?= @ 2018-11-24 9:45 UTC (permalink / raw)
To: Recipients
Good Day To You,I am sending you this Mail, and using this opportunity to informed you about the $2 Million that has been donated to you. From Mr.Pedro Hills.Please contact him for more Info, mrpedrohills@yandex.com
Note: All mail must be sent to: mrpedrohills@yandex.com
Thank you
^ permalink raw reply
* Re: [RFC v2 11/19] batman-adv: Add gateway mesh genl configuration
From: Sven Eckelmann @ 2018-11-24 20:52 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Jiri Pirko
In-Reply-To: <20181123161359.13342-12-sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
On Freitag, 23. November 2018 17:13:51 CET Sven Eckelmann wrote:
> + /** @BATADV_GW_MODE_CLIENT: announce itself as gatway server */
> + BATADV_GW_MODE_SERVER,
The kernel-doc should actually be for BATADV_GW_MODE_SERVER.
[...]
> + if (sel_class < 1 || sel_class > sel_class_max) {
> + atomic_set(&bat_priv->gw.sel_class, sel_class);
> + batadv_gw_reselect(bat_priv);
> + }
Should have been:
if (sel_class >= 1 && sel_class <= sel_class_max) {
Kind regards,
Sven
^ permalink raw reply
* [PATCH net] ixgbe: recognize 1000BaseLX SFP modules as 1Gbps
From: Josh Elsasser @ 2018-11-24 20:57 UTC (permalink / raw)
To: intel-wired-lan
Cc: Josh Elsasser, Jeff Kirsher, David S. Miller, netdev,
linux-kernel
Add the two 1000BaseLX enum values to the X550's check for 1Gbps modules,
allowing the core driver code to establish a link over this SFP type.
This is done by the out-of-tree driver but the fix wasn't in mainline.
Fixes: 6a14ee0cfb19 ("ixgbe: Add X550 support function pointers")
Signed-off-by: Josh Elsasser <jelsasser@appneta.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index 10dbaf4f6e80..9c42f741ed5e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -2262,7 +2262,9 @@ static s32 ixgbe_get_link_capabilities_X550em(struct ixgbe_hw *hw,
*autoneg = false;
if (hw->phy.sfp_type == ixgbe_sfp_type_1g_sx_core0 ||
- hw->phy.sfp_type == ixgbe_sfp_type_1g_sx_core1) {
+ hw->phy.sfp_type == ixgbe_sfp_type_1g_sx_core1 ||
+ hw->phy.sfp_type == ixgbe_sfp_type_1g_lx_core0 ||
+ hw->phy.sfp_type == ixgbe_sfp_type_1g_lx_core1) {
*speed = IXGBE_LINK_SPEED_1GB_FULL;
return 0;
}
--
2.19.1
^ permalink raw reply related
* Re: WARNING in csum_and_copy_to_iter
From: Slavomir Kaslev @ 2018-11-24 21:20 UTC (permalink / raw)
To: Al Viro
Cc: syzbot, davem, gregkh, kgraul, linux-kernel, netdev, stranche,
syzkaller-bugs
In-Reply-To: <20181124200357.GC2217@ZenIV.linux.org.uk>
On Sat, Nov 24, 2018 at 08:03:57PM +0000, Al Viro wrote:
> On Sat, Nov 24, 2018 at 11:40:03AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: edeca3a769ad Merge tag 'sound-4.20-rc4' of git://git.kerne..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12bee26d400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446
> > dashboard link: https://syzkaller.appspot.com/bug?extid=ce18da013d76d837144d
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ccd1f5400000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+ce18da013d76d837144d@syzkaller.appspotmail.com
>
> Caused by commit 95506588d2c1d72ca29adef8ae9bf771bcfb4ced
> Author: Slavomir Kaslev <kaslevs@vmware.com>
> Date: Fri Nov 16 11:27:53 2018 +0200
>
> socket: do a generic_file_splice_read when proto_ops has no splice_read
>
> exposing all ->recvmsg() instances to pipe-backed iov_iter as possible destination.
> It's not all that hard to fix (I'll probably have a candidate patch by tonight,
> it's just a matter of adding the only missing primitive), but... shouldn't that
> patch have sat in -next for at least some testing first? Because it's very
> easy to reproduce - splice from e.g. UDP socket will step into it. Sure, the
> sky is not falling (unless you set panic-on-WARN, that is); the damn thing
> would've failed anyway, but...
My bad for not sending the patch tagged as net-next, feel free to revert it.
^ permalink raw reply
* Re: [PATCH perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs
From: David Ahern @ 2018-11-24 22:17 UTC (permalink / raw)
To: Alexei Starovoitov, Song Liu
Cc: netdev, linux-kernel, ast, daniel, acme, peterz, kernel-team
In-Reply-To: <20181121221145.2cxph7zv27x7lbg6@ast-mbp>
On 11/21/18 3:11 PM, Alexei Starovoitov wrote:
> On Wed, Nov 21, 2018 at 11:55:02AM -0800, Song Liu wrote:
>> This patch enables perf-record to listen to bpf_event and generate
>> bpf_prog_info_event for bpf programs loaded and unloaded during
>> perf-record run.
>>
>> To minimize latency between bpf_event and following bpf calls, separate
>> mmap with watermark of 1 is created to process these vip events. Then
>> a separate dummy event is attached to the special mmap. A separate thread
>> is used to only poll bpf events.
>>
>> By default, perf-record will listen to bpf_event. Option no-bpf-event is
>> added in case the user would opt out.
>
> I think only default perf-record for sampling should include it.
> perf record -e for tracepoints, kprobes and anything else should imply no-bpf-event.
>
It should default off for those, but as I have said before users should
be able to add bpf load and unload events to the mix of tracepoints,
probes, etc they are monitoring.
^ permalink raw reply
* Can you supply us
From: DEBENHAMS RETAIL PLC @ 2018-11-24 9:27 UTC (permalink / raw)
Hi
DEBENHAMS RETAIL PLC is a retailer shop furnished by European products. We
are looking to buy ( Fashion items, Perfumes, Lighters, Tiles
Marbles,Wooden Floors, Smart-phones, Tablets, Laptops, TVs, Air
conditioner etc...)and find a new partnership with companies dealing with
different products so can you please send us your Catalog or your website
to learn more about your products or prices list by email and if we can
make some order with you and start a long-term partnership. Could you also
tell us if you can supply us, more information about the possibility to
become one of your regular customers? Our Payment Policy is payment by
swift within 30 days after delivery.
Waiting for your response.
Kind Regards,
Richard Jones
Purchasing Director
DEBENHAMS RETAIL PLC
www.debenhams.com
www.debenhamsplus.com
Directline: +44 (0) 7417 446 994
Fax no: +44 (0) 3456 049 050
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: remove set but not used variables 'multitrc, speed'
From: David Miller @ 2018-11-25 1:37 UTC (permalink / raw)
To: yuehaibing; +Cc: ganeshgr, linux-kernel, netdev
In-Reply-To: <20181124103621.24280-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 24 Nov 2018 18:36:21 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:5883:6:
> warning: variable 'multitrc' set but not used [-Wunused-but-set-variable]
>
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:8585:32:
> warning: variable 'speed' set but not used [-Wunused-but-set-variable]
>
> 'multitrc' never used since introduction in
> commit 8e3d04fd7d70 ("cxgb4: Add MPS tracing support")
>
> 'speed' never used since introduction in
> commit c3168cabe1af ("cxgb4/cxgbvf: Handle 32-bit fw port capabilities")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: qualcomm: rmnet: move null check on dev before dereferecing it
From: David Miller @ 2018-11-25 1:40 UTC (permalink / raw)
To: colin.king; +Cc: subashab, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20181124150302.20339-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 24 Nov 2018 15:03:02 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently dev is dereferenced by the call dev_net(dev) before dev is null
> checked. Fix this by null checking dev before the potential null
> pointer dereference.
>
> Detected by CoverityScan, CID#1462955 ("Dereference before null check")
>
> Fixes: 23790ef12082 ("net: qualcomm: rmnet: Allow to configure flags for existing devices")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next.
^ permalink raw reply
* Re: WARNING in csum_and_copy_to_iter
From: Al Viro @ 2018-11-25 1:51 UTC (permalink / raw)
To: Slavomir Kaslev
Cc: syzbot, davem, gregkh, kgraul, linux-kernel, netdev, stranche,
syzkaller-bugs
In-Reply-To: <20181124214436.GD2217@ZenIV.linux.org.uk>
On Sat, Nov 24, 2018 at 09:44:36PM +0000, Al Viro wrote:
> No point, IMO - the fix isn't hard and bisect hazard created by the whole thing
> is both mild (spurious WARN() in case that used to fail anyway) _and_ won't
> disappear from reverting, obviously. I'll post a fix later tonight...
FWIW, I think the following ought to work; it's obviously a pair of commits
(introduction of convenience helper/switch to its use + csum_and_copy_to_iter()
for ITER_PIPE), as well as commit message, etc., but I would really appreciate
if folks gave it a look _and_ a beating.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 7ebccb5c1637..621984743268 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -560,6 +560,44 @@ static size_t copy_pipe_to_iter(const void *addr, size_t bytes,
return bytes;
}
+static __wsum csum_and_memcpy(void *to, const void *from, size_t len,
+ __wsum sum, size_t off)
+{
+ __wsum next = csum_partial_copy_nocheck(from, to, len, 0);
+ return csum_block_add(sum, next, off);
+}
+
+static size_t csum_and_copy_to_pipe_iter(const void *addr, size_t bytes,
+ __wsum *csum, struct iov_iter *i)
+{
+ struct pipe_inode_info *pipe = i->pipe;
+ size_t n, r;
+ size_t off = 0;
+ __wsum sum = *csum;
+ int idx;
+
+ if (!sanity(i))
+ return 0;
+
+ bytes = n = push_pipe(i, bytes, &idx, &r);
+ if (unlikely(!n))
+ return 0;
+ for ( ; n; idx = next_idx(idx, pipe), r = 0) {
+ size_t chunk = min_t(size_t, n, PAGE_SIZE - r);
+ char *p = kmap_atomic(pipe->bufs[idx].page);
+ sum = csum_and_memcpy(p + r, addr, chunk, sum, off);
+ kunmap_atomic(p);
+ i->idx = idx;
+ i->iov_offset = r + chunk;
+ n -= chunk;
+ off += chunk;
+ addr += chunk;
+ }
+ i->count -= bytes;
+ *csum = sum;
+ return bytes;
+}
+
size_t _copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i)
{
const char *from = addr;
@@ -1368,17 +1406,15 @@ size_t csum_and_copy_from_iter(void *addr, size_t bytes, __wsum *csum,
err ? v.iov_len : 0;
}), ({
char *p = kmap_atomic(v.bv_page);
- next = csum_partial_copy_nocheck(p + v.bv_offset,
- (to += v.bv_len) - v.bv_len,
- v.bv_len, 0);
+ sum = csum_and_memcpy((to += v.bv_len) - v.bv_len,
+ p + v.bv_offset, v.bv_len,
+ sum, off);
kunmap_atomic(p);
- sum = csum_block_add(sum, next, off);
off += v.bv_len;
}),({
- next = csum_partial_copy_nocheck(v.iov_base,
- (to += v.iov_len) - v.iov_len,
- v.iov_len, 0);
- sum = csum_block_add(sum, next, off);
+ sum = csum_and_memcpy((to += v.iov_len) - v.iov_len,
+ v.iov_base, v.iov_len,
+ sum, off);
off += v.iov_len;
})
)
@@ -1412,17 +1448,15 @@ bool csum_and_copy_from_iter_full(void *addr, size_t bytes, __wsum *csum,
0;
}), ({
char *p = kmap_atomic(v.bv_page);
- next = csum_partial_copy_nocheck(p + v.bv_offset,
- (to += v.bv_len) - v.bv_len,
- v.bv_len, 0);
+ sum = csum_and_memcpy((to += v.bv_len) - v.bv_len,
+ p + v.bv_offset, v.bv_len,
+ sum, off);
kunmap_atomic(p);
- sum = csum_block_add(sum, next, off);
off += v.bv_len;
}),({
- next = csum_partial_copy_nocheck(v.iov_base,
- (to += v.iov_len) - v.iov_len,
- v.iov_len, 0);
- sum = csum_block_add(sum, next, off);
+ sum = csum_and_memcpy((to += v.iov_len) - v.iov_len,
+ v.iov_base, v.iov_len,
+ sum, off);
off += v.iov_len;
})
)
@@ -1438,8 +1472,12 @@ size_t csum_and_copy_to_iter(const void *addr, size_t bytes, __wsum *csum,
const char *from = addr;
__wsum sum, next;
size_t off = 0;
+
+ if (unlikely(iov_iter_is_pipe(i)))
+ return csum_and_copy_to_pipe_iter(addr, bytes, csum, i);
+
sum = *csum;
- if (unlikely(iov_iter_is_pipe(i) || iov_iter_is_discard(i))) {
+ if (unlikely(iov_iter_is_discard(i))) {
WARN_ON(1); /* for now */
return 0;
}
@@ -1455,17 +1493,15 @@ size_t csum_and_copy_to_iter(const void *addr, size_t bytes, __wsum *csum,
err ? v.iov_len : 0;
}), ({
char *p = kmap_atomic(v.bv_page);
- next = csum_partial_copy_nocheck((from += v.bv_len) - v.bv_len,
- p + v.bv_offset,
- v.bv_len, 0);
+ sum = csum_and_memcpy(p + v.bv_offset,
+ (from += v.bv_len) - v.bv_len,
+ v.bv_len, sum, off);
kunmap_atomic(p);
- sum = csum_block_add(sum, next, off);
off += v.bv_len;
}),({
- next = csum_partial_copy_nocheck((from += v.iov_len) - v.iov_len,
- v.iov_base,
- v.iov_len, 0);
- sum = csum_block_add(sum, next, off);
+ sum = csum_and_memcpy(v.iov_base,
+ (from += v.iov_len) - v.iov_len,
+ v.iov_len, sum, off);
off += v.iov_len;
})
)
^ permalink raw reply related
* Re: [PATCH] net: bridge: check for a null p->dev before dereferencing it
From: David Miller @ 2018-11-25 2:04 UTC (permalink / raw)
To: nikolay; +Cc: colin.king, roopa, bridge, netdev, kernel-janitors, linux-kernel
In-Reply-To: <85963d6a-3411-9461-67aa-42e1fd02e663@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Sat, 24 Nov 2018 14:21:07 +0200
> I was contacted recently about this privately and this was my reply:
> "Checking new_nbp() and del_nbp() it should not be possible to reach that code
> with p->dev or p->br as NULL. The cap check code has always been there, I just
> shuffled the rest of the function to obtain rtnl lock and kept it as close to
> the original as possible, thus the checks remained.
> In order to avoid future reports like this I'll send a cleanup once net-next
> opens up.
>
> My reasoning of why it shouldn't be possible:
> - On port add new_nbp() sets both p->dev and p->br before creating kobj/sysfs
>
> - On port del (trickier) del_nbp() calls kobject_del() before call_rcu() to destroy
> the port which in turn calls sysfs_remove_dir() which uses kernfs_remove() which
> deactivates (shouldn't be able to open new files) and calls kernfs_drain() to drain
> current open/mmaped files in the respective dir before continuing, thus making it
> impossible to open a bridge port sysfs file with p->dev and p->br equal to NULL.
> "
>
> So I think it's safe to remove those checks altogether. It'd be nice to get a second
> look over my reasoning as I might be missing something in sysfs/kernfs call path.
I did a once over your analysis and I agree, the checks should be safe to remove.
^ permalink raw reply
* Re: [PATCH 6/8] socket: Add struct sock_timeval
From: David Miller @ 2018-11-25 2:09 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: deepa.kernel, linux-kernel, netdev, viro, arnd, y2038
In-Reply-To: <CAF=yD-+1BJHuajcW=2bpeAp5XOAX2fObyvhOdH-YsiGY3-_J4Q@mail.gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sat, 24 Nov 2018 14:37:42 -0500
> On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>> diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
>> index 04d5587f30d3..106f9398c285 100644
>> --- a/include/uapi/linux/time.h
>> +++ b/include/uapi/linux/time.h
>> @@ -70,6 +70,11 @@ struct __kernel_old_timeval {
>> };
>> #endif
>>
>> +struct sock_timeval {
>> + long long tv_sec;
>> + long long tv_usec;
>
> should these use fixed-width type __u64?
>
> even if all data models define long long as 64-bit, that might be more
> descriptive.
Agreed.
^ permalink raw reply
* Re: [PATCH iproute2-next 0/8] tc: gred: JSON-ify and support per-vq config
From: David Ahern @ 2018-11-24 15:26 UTC (permalink / raw)
To: Jakub Kicinski, stephen; +Cc: oss-drivers, netdev
In-Reply-To: <20181119230335.11771-1-jakub.kicinski@netronome.com>
On 11/19/18 4:03 PM, Jakub Kicinski wrote:
> Hi!
>
> This set brings GRED support up to date with recent kernel changes.
> In particular the new netlink attributes for more fine-grained stats
> and per-virtual queue flags.
>
> To make GRED usable in modern deployments the patch set starts with
> adding JSON output.
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [PATCH iproute2-next] tc: fq: support ce_threshold attribute
From: David Ahern @ 2018-11-24 15:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Eric Dumazet
In-Reply-To: <20181124063724.169456-1-edumazet@google.com>
On 11/23/18 11:37 PM, Eric Dumazet wrote:
> Kernel commit 48872c11b772 ("net_sched: sch_fq: add dctcp-like marking")
> added support for TCA_FQ_CE_THRESHOLD attribute.
>
> This patch adds iproute2 support for it.
>
> It also makes sure fq_print_xstats() can deal with smaller tc_fq_qd_stats
> structures given by older kernels.
>
> Usage :
>
> FQATTRS="ce_threshold 4ms"
> TXQS=8
>
> for ETH in eth0
> do
> tc qd del dev $ETH root 2>/dev/null
> tc qd add dev $ETH root handle 1: mq
> for i in `seq 1 $TXQS`
> do
> tc qd add dev $ETH parent 1:$i fq $FQATTRS
> done
> done
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> tc/q_fq.c | 32 ++++++++++++++++++++++++++++----
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
applied to iproute2-next. Thanks
Eric: the fq man page is out of date. Can you update it as well - not
just this argument but other missing ones? Thanks
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] netns: enable to dump full nsid translation table
From: David Ahern @ 2018-11-24 15:47 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <20181122222215.23554-6-nicolas.dichtel@6wind.com>
On 11/22/18 3:22 PM, Nicolas Dichtel wrote:
> Like the previous patch, the goal is to ease to convert nsids from one
> netns to another netns.
> A new attribute (NETNSA_CURRENT_NSID) is added to the kernel answer when
> NETNSA_TARGET_NSID is provided, thus the user can easily convert nsids.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> include/uapi/linux/net_namespace.h | 1 +
> net/core/net_namespace.c | 31 ++++++++++++++++++++++++------
> 2 files changed, 26 insertions(+), 6 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: bridge: export supported boolopts
From: Andrew Lunn @ 2018-11-24 16:16 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <20181124023422.13908-4-nikolay@cumulusnetworks.com>
On Sat, Nov 24, 2018 at 04:34:22AM +0200, Nikolay Aleksandrov wrote:
> Now that we have at least one bool option, we can export all of the
> supported bool options via optmask when dumping them.
>
Hi Nik
That answers my question then...
I'm assuming this means there is no easy way to generate a bitmask of
0? So you waited until there was at least one bit.
(1 << 2) - 1 = 3
(1 << 1) - 1 = 1
(1 << 0) - 1 = 0
So does
GENMASK((BR_BOOLOPT_MAX - 1), 0);
really not do the right thing when BR_BOOLOPT_MAX = 1?
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: bridge: add support for user-controlled bool options
From: nikolay @ 2018-11-24 16:18 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <20181124161041.GA24681@lunn.ch>
On 24 November 2018 18:10:41 EET, Andrew Lunn <andrew@lunn.ch> wrote:
>> +int br_boolopt_toggle(struct net_bridge *br, enum br_boolopt_id opt,
>bool on,
>> + struct netlink_ext_ack *extack)
>> +{
>> + switch (opt) {
>> + default:
>> + /* shouldn't be called with unsupported options */
>> + WARN_ON(1);
>> + break;
>
>So you return 0 here, meaning the br_debug() lower down will not
>happen. Maybe return -EOPNOTSUPP?
>
No, the idea here is that some option in the future might return an error.
This function cannot be called with unsupported option thus the warn.
>> + }
>> +
>> + return 0;
>> +}
>> +
>
>> +int br_boolopt_multi_toggle(struct net_bridge *br,
>> + struct br_boolopt_multi *bm,
>> + struct netlink_ext_ack *extack)
>> +{
>> + unsigned long bitmap = bm->optmask;
>> + int err = 0;
>> + int opt_id;
>> +
>> + for_each_set_bit(opt_id, &bitmap, BR_BOOLOPT_MAX) {
>> + bool on = !!(bm->optval & BIT(opt_id));
>> +
>> + err = br_boolopt_toggle(br, opt_id, on, extack);
>> + if (err) {
>> + br_debug(br, "boolopt multi-toggle error: option: %d current: %d
>new: %d error: %d\n",
>> + opt_id, br_boolopt_get(br, opt_id), on, err);
>> + break;
>> + }
>> + }
>
>Does the semantics of extack allow you to return something even when
>there is no error? If there are bits > BR_BOOLOPT_MAX you could return
>0, but also add a warning in extack that some bits where not supported
>by this kernel.
If we return 0 there's no reason to check extack.
>> +void br_boolopt_multi_get(const struct net_bridge *br,
>> + struct br_boolopt_multi *bm)
>> +{
>> + u32 optval = 0;
>> + int opt_id;
>> +
>> + for (opt_id = 0; opt_id < BR_BOOLOPT_MAX; opt_id++)
>> + optval |= (br_boolopt_get(br, opt_id) << opt_id);
>> +
>> + bm->optval = optval;
>> + bm->optmask = 0;
>
>You liked the idea of setting optmask to indicate which bits this
>kernel supports. Did you change your mind?
>
Please see patch 03.
> Andrew
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: bridge: export supported boolopts
From: nikolay @ 2018-11-24 16:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <20181124161647.GB24681@lunn.ch>
On 24 November 2018 18:16:47 EET, Andrew Lunn <andrew@lunn.ch> wrote:
>On Sat, Nov 24, 2018 at 04:34:22AM +0200, Nikolay Aleksandrov wrote:
>> Now that we have at least one bool option, we can export all of the
>> supported bool options via optmask when dumping them.
>>
>Hi Nik
>
>That answers my question then...
>
>I'm assuming this means there is no easy way to generate a bitmask of
>0? So you waited until there was at least one bit.
>
>(1 << 2) - 1 = 3
>(1 << 1) - 1 = 1
>(1 << 0) - 1 = 0
>
>So does
>
>GENMASK((BR_BOOLOPT_MAX - 1), 0);
>
>really not do the right thing when BR_BOOLOPT_MAX = 1?
>
GENMASK(0, 0) = 1
the minus is done before the shift.
Think of it of setting all bits from 0 to MAX - 1 inclusive.
> Andrew
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: bridge: add support for user-controlled bool options
From: Andrew Lunn @ 2018-11-24 16:25 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <66D818AF-A45E-41B3-AC9C-90A7E607FD2D@cumulusnetworks.com>
On Sat, Nov 24, 2018 at 06:18:33PM +0200, nikolay@cumulusnetworks.com wrote:
> On 24 November 2018 18:10:41 EET, Andrew Lunn <andrew@lunn.ch> wrote:
> >> +int br_boolopt_toggle(struct net_bridge *br, enum br_boolopt_id opt,
> >bool on,
> >> + struct netlink_ext_ack *extack)
> >> +{
> >> + switch (opt) {
> >> + default:
> >> + /* shouldn't be called with unsupported options */
> >> + WARN_ON(1);
> >> + break;
> >
> >So you return 0 here, meaning the br_debug() lower down will not
> >happen. Maybe return -EOPNOTSUPP?
> >
>
> No, the idea here is that some option in the future might return an error.
> This function cannot be called with unsupported option thus the warn.
O.K, i was trying to make it easier to see which option caused it to
happen.
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >
> >> +int br_boolopt_multi_toggle(struct net_bridge *br,
> >> + struct br_boolopt_multi *bm,
> >> + struct netlink_ext_ack *extack)
> >> +{
> >> + unsigned long bitmap = bm->optmask;
> >> + int err = 0;
> >> + int opt_id;
> >> +
> >> + for_each_set_bit(opt_id, &bitmap, BR_BOOLOPT_MAX) {
> >> + bool on = !!(bm->optval & BIT(opt_id));
> >> +
> >> + err = br_boolopt_toggle(br, opt_id, on, extack);
> >> + if (err) {
> >> + br_debug(br, "boolopt multi-toggle error: option: %d current: %d
> >new: %d error: %d\n",
> >> + opt_id, br_boolopt_get(br, opt_id), on, err);
> >> + break;
> >> + }
> >> + }
> >
> >Does the semantics of extack allow you to return something even when
> >there is no error? If there are bits > BR_BOOLOPT_MAX you could return
> >0, but also add a warning in extack that some bits where not supported
> >by this kernel.
>
> If we return 0 there's no reason to check extack.
Well, the caller can check to see if extack is present, even on
success. This is extack, not extnack after all...
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: bridge: export supported boolopts
From: Andrew Lunn @ 2018-11-24 16:26 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <20181124023422.13908-4-nikolay@cumulusnetworks.com>
On Sat, Nov 24, 2018 at 04:34:22AM +0200, Nikolay Aleksandrov wrote:
> Now that we have at least one bool option, we can export all of the
> supported bool options via optmask when dumping them.
>
> v2: new patch
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: bridge: add no_linklocal_learn bool option
From: Andrew Lunn @ 2018-11-24 16:27 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <20181124023422.13908-3-nikolay@cumulusnetworks.com>
On Sat, Nov 24, 2018 at 04:34:21AM +0200, Nikolay Aleksandrov wrote:
> Use the new boolopt API to add an option which disables learning from
> link-local packets. The default is kept as before and learning is
> enabled. This is a simple map from a boolopt bit to a bridge private
> flag that is tested before learning.
>
> v2: pass NULL for extack via sysfs
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 3/8] socket: Disentangle SOCK_RCVTSTAMPNS from SOCK_RCVTSTAMP
From: Willem de Bruijn @ 2018-11-25 3:59 UTC (permalink / raw)
To: Deepa Dinamani
Cc: David Miller, LKML, Network Development, Al Viro, Arnd Bergmann,
y2038 Mailman List
In-Reply-To: <20181124022035.17519-4-deepa.kernel@gmail.com>
On Sat, Nov 24, 2018 at 3:59 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> SOCK_RCVTSTAMPNS is never set alone. SOCK_RCVTSTAMP
> is always set along with SOCK_RCVTSTAMPNS. This leads to
> checking for two flag states whenever we need to check for
> SOCK_RCVTSTAMPS.
>
> Also SOCK_RCVTSTAMPS was the only flag that needed to be
> checked in order to verify if either of the two flags are
> set. But, the two features are not actually dependent on
> each other. This artificial dependency creates more
> confusion.
This is done so that the hot path only has to check one flag
in the common case where no timestamp is requested.
^ 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