* Re: general protection fault in kfree (2)
From: syzbot @ 2018-07-13 9:02 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <000000000000483ec605708a998d@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 3ee15ba60e6b Add linux-next specific files for 20180712
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11d3652c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=fe1c3df2c7c0c81
dashboard link: https://syzkaller.appspot.com/bug?extid=1ff9d2e170913c4ef264
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10d9d1a4400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10657794400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1ff9d2e170913c4ef264@syzkaller.appspotmail.com
FS-Cache: O-cookie c=00000000bfe1c402 [p=00000000445b4196 fl=222 nc=0 na=1]
FS-Cache: O-cookie d=00000000a5eb7aa3 n=000000005d36a973
kasan: CONFIG_KASAN_INLINE enabled
FS-Cache: O-key=[10] '
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4474 Comm: syz-executor242 Not tainted
4.18.0-rc4-next-20180712+ #6
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
34
RIP: 0010:virt_to_head_page include/linux/mm.h:638 [inline]
RIP: 0010:virt_to_cache mm/slab.c:399 [inline]
RIP: 0010:kfree+0xa0/0x260 mm/slab.c:3809
Code:
32
82 cb 01 00
39
00 48 ba 00 00
34
00 80 ff 77
36
00 00 48 01
39
c2 48 89 df
35
48 b8 00 00 00
31
00 00 ea ff
35
ff 48 c1 ea
35
0c 48 c1 e2
'
06 48 01 c2 <48>
FS-Cache: N-cookie c=00000000525aeed3 [p=00000000445b4196 fl=2 nc=0 na=1]
8b 42 08 a8 01
FS-Cache: N-cookie d=00000000a5eb7aa3 n=000000003a05f34d
48 8d 48 ff 48
FS-Cache: N-key=[10] '
0f 45 d1 4c 8b
34
6a 18 49 63 75
32
74
RSP: 0018:ffff8801b105f5d0 EFLAGS: 00010003
39
RAX: ffffea0000000000 RBX: f780d0382154ac00 RCX: 1ffff1003620bed8
RDX: 03ddef20e0855280 RSI: ffffffff87700e50 RDI: f780d0382154ac00
RBP: ffff8801b105f5f0 R08: ffff8801ade02380 R09: ffffed003620bdf8
34
R10: ffffed0039d876c0 R11: 0000000000000001 R12: 0000000000000282
R13: ffffffff87700e8a R14: ffff8801b105f740 R15: ffff8801ce4c0540
FS: 00007feab2d14700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
36
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f32b40b0000 CR3: 00000001c4338000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
39
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
35
p9_client_version net/9p/client.c:1010 [inline]
p9_client_create+0xfea/0x1770 net/9p/client.c:1070
31
35
35
'
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
legacy_get_tree+0x118/0x440 fs/fs_context.c:659
vfs_get_tree+0x1cb/0x5c0 fs/super.c:1743
do_new_mount fs/namespace.c:2567 [inline]
do_mount+0x6c1/0x1fb0 fs/namespace.c:2889
ksys_mount+0x12d/0x140 fs/namespace.c:3105
__do_sys_mount fs/namespace.c:3119 [inline]
__se_sys_mount fs/namespace.c:3116 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3116
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445b59
Code: e8 bc e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 2b 0e fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007feab2d13da8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 0000000000445b59
RDX: 0000000020000180 RSI: 0000000020000140 RDI: 0000000000000000
RBP: 00000000006dac38 R08: 0000000020000300 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0031656c69662f2e
R13: 6f6c3d6568636163 R14: 64663d736e617274 R15: 0000000000000001
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace bacf24c1f955b911 ]---
general protection fault: 0000 [#2] SMP KASAN
CPU: 1 PID: 4472 Comm: syz-executor242 Tainted: G D
4.18.0-rc4-next-20180712+ #6
RIP: 0010:virt_to_head_page include/linux/mm.h:638 [inline]
RIP: 0010:virt_to_cache mm/slab.c:399 [inline]
RIP: 0010:kfree+0xa0/0x260 mm/slab.c:3809
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Code:
RIP: 0010:virt_to_head_page include/linux/mm.h:638 [inline]
RIP: 0010:virt_to_cache mm/slab.c:399 [inline]
RIP: 0010:kfree+0xa0/0x260 mm/slab.c:3809
82
Code:
cb
82
01
cb
00
01
00
00
48
00
ba
48
00 00
ba
00
00
80
00
ff
00
77
80
00
ff
00
77
48
00 00
01
48
c2
01
48
c2
89
48
df
89
48
df
b8
48
00
b8
00
00
00
00
00
00
00
00
ea
00
ff
ea
ff
ff
48
ff
c1
48
ea
c1
0c
ea
48
0c
c1
48
e2
c1
06
e2
48
06
01
48
c2
01
<48>
c2
8b
<48>
42
8b
08
42
a8
08
01
a8
48
01
8d
48
48
8d
ff
48
48
ff
0f
48
45
0f
d1
45
4c
d1
8b
4c
6a
8b
18
6a
49
18
63
49
75
63
74
75
74
RSP: 0018:ffff8801b105f5d0 EFLAGS: 00010003
RSP: 0018:ffff8801b3db75d0 EFLAGS: 00010003
RAX: ffffea0000000000 RBX: f780d0382154ac00 RCX: 1ffff1003620bed8
RDX: 03ddef20e0855280 RSI: ffffffff87700e50 RDI: f780d0382154ac00
RAX: ffffea0000000000 RBX: afd91d4db7636200 RCX: 1ffff100367b6ed8
RBP: ffff8801b105f5f0 R08: ffff8801ade02380 R09: ffffed003620bdf8
RDX: 02bf505536dd8d80 RSI: ffffffff87700e50 RDI: afd91d4db7636200
R10: ffffed0039d876c0 R11: 0000000000000001 R12: 0000000000000282
RBP: ffff8801b3db75f0 R08: ffff8801ad62a300 R09: ffffed00367b6df8
R13: ffffffff87700e8a R14: ffff8801b105f740 R15: ffff8801ce4c0540
R10: ffffed0039d876e0 R11: 0000000000000001 R12: 0000000000000282
FS: 00007feab2d14700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
R13: ffffffff87700e8a R14: ffff8801b3db7740 R15: ffff8801aa0a03c0
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
FS: 00007feab2d14700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CR2: 00007f32b40b0000 CR3: 00000001c4338000 CR4: 00000000001406f0
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
CR2: 00007f32b40b0000 CR3: 00000001c0acc000 CR4: 00000000001406e0
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
^ permalink raw reply
* Re: [PATCH][net-next] bridge: clean up mtu_set_by_user setting to false and comments
From: Nikolay Aleksandrov @ 2018-07-13 8:00 UTC (permalink / raw)
To: Li RongQing, netdev
In-Reply-To: <1531464444-26517-1-git-send-email-lirongqing@baidu.com>
On 13/07/18 09:47, Li RongQing wrote:
> Once mtu_set_by_user is set to true, br_mtu_auto_adjust will
> not run, and no chance to clear mtu_set_by_user.
>
^^
This was by design, there is no error here and no "cleanup" is needed.
If you read the ndo_change_mtu() call you'll see the comment:
/* this flag will be cleared if the MTU was automatically adjusted */
It is the only way we can know that the MTU was automatically adjusted or set
by the user manually in which case we need to _stop_ automatically adjusting
MTU. This was done to be backwards compatible as much as possible but still
give the option to have user-configured MTU which doesn't disappear (and is
not overwritten).
So please next time read the original commit.
>From the original commit 804b854d374e ("net: bridge: disable bridge MTU auto tuning if it was set manually"):
" ...
Let's improve on that situation and allow for the user to
set any MTU within ETH_MIN/MAX limits, but once manually configured it
is the user's responsibility to keep it correct afterwards.
In case the MTU isn't manually set - the behaviour reverts to the
previous and the bridge follows the minimum MTU.
...
"
> and br_mtu_auto_adjust will run only if mtu_set_by_user is
> false, so not need to set it to false again
>
> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> net/bridge/br_device.c | 1 -
> net/bridge/br_if.c | 4 ----
> 2 files changed, 5 deletions(-)
>
> diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> index e682a668ce57..c636bc2749c2 100644
> --- a/net/bridge/br_device.c
> +++ b/net/bridge/br_device.c
> @@ -227,7 +227,6 @@ static int br_change_mtu(struct net_device *dev, int new_mtu)
>
> dev->mtu = new_mtu;
>
> - /* this flag will be cleared if the MTU was automatically adjusted */
> br->mtu_set_by_user = true;
> #if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
> /* remember the MTU in the rtable for PMTU */
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index 05e42d86882d..47c65da4b1be 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -450,11 +450,7 @@ void br_mtu_auto_adjust(struct net_bridge *br)
> if (br->mtu_set_by_user)
> return;
>
> - /* change to the minimum MTU and clear the flag which was set by
> - * the bridge ndo_change_mtu callback
> - */
> dev_set_mtu(br->dev, br_mtu_min(br));
> - br->mtu_set_by_user = false;
> }
>
> static void br_set_gso_limits(struct net_bridge *br)
>
Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH 11/18] wireless/ti: change strncpy+truncation to strlcpy
From: Dominique Martinet @ 2018-07-13 8:13 UTC (permalink / raw)
To: Arend van Spriel
Cc: Greg Kroah-Hartman, Kalle Valo, David S. Miller, Thomas Gleixner,
Kate Stewart, Philippe Ombredanne, Joe Perches, linux-wireless,
netdev, linux-kernel
In-Reply-To: <5B485917.7090102@broadcom.com>
Arend van Spriel wrote on Fri, Jul 13, 2018:
> The patch adding that script contains a good motivation, but I would want to
> see that in commit message of every patch or at least the gist of
> it.
In retrospect, I definitely agree - I was happy I got coccinelle to work
and a bit too tired to make rationale decisions when I sent the serie as
it's not a kind of thing I'm used to.
For the patch you ack'd, in particular, there would be no gcc warning in
the first place because the source string's size is not known at compile
time and for some reason gcc does not mind silent truncation in that
case, so the usefulnes of the patch is fairly limited in the first
place (it's possibly simpler/good to aim for consistency but that's
about it). I however didn't take the time to make that analysis for all
the patches.
> especially as that script is not in the kernel tree yet.
I did think about that, but wasn't sure what was appropriate in this
case.
I now think it would have been better to save everyone a dozen of mails
and wait for the coccinelle patch to land first; but it's a bit late for
regret :)
I'll only catter after the coccinelle script until it lands, so if
anyone is inclined to take one of the rest as they are, great, but
otherwise feel free to ignore them for now.
(In particular, this very patch should not remove the first comment
here, as pointed out by Himanshu Jha in reply to the first patch)
Thanks for taking the time to give feedback,
--
Dominique Martinet
^ permalink raw reply
* kernel BUG at net/ipv4/ip_output.c:LINE!
From: syzbot @ 2018-07-13 8:00 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: c25c74b7476e Merge tag 'trace-v4.18-rc3-2' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1708b92c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
dashboard link: https://syzkaller.appspot.com/bug?extid=90d5ec0c05e708f3b66d
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+90d5ec0c05e708f3b66d@syzkaller.appspotmail.com
------------[ cut here ]------------
kernel BUG at net/ipv4/ip_output.c:773!
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 15085 Comm: syz-executor7 Not tainted 4.18.0-rc4+ #143
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:ip_do_fragment+0x2468/0x2ae0 net/ipv4/ip_output.c:773
Code: 8b 8d 70 fe ff ff e9 67 e8 ff ff 4c 89 ef e8 df 7a 57 fb e9 49 e9 ff
ff 4c 89 f7 e8 d2 7a 57 fb e9 c1 e5 ff ff e8 b8 a0 19 fb <0f> 0b 4c 89 e7
e8 be 7a 57 fb e9 85 e8 ff ff 4c 89 f7 89 8d 70 fe
RSP: 0018:ffff880195016880 EFLAGS: 00010246
RAX: 0000000000040000 RBX: ffff8801ce7be940 RCX: ffffc90002a12000
RDX: 0000000000040000 RSI: ffffffff86626ae8 RDI: 0000000000000005
RBP: ffff880195016a58 R08: ffff8801c66e8180 R09: ffffed00323180ba
R10: ffffed00323180bc R11: ffff8801918c05e3 R12: ffff8801ce7bea04
R13: 00000000fffffff2 R14: ffff8801ce7bea10 R15: dffffc0000000000
FS: 00007effc88a9700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdeada9000 CR3: 00000001b3b5d000 CR4: 00000000001406f0
DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
ip_fragment.constprop.49+0x179/0x240 net/ipv4/ip_output.c:546
ip_finish_output+0x6e4/0xfa0 net/ipv4/ip_output.c:315
NF_HOOK_COND include/linux/netfilter.h:276 [inline]
ip_output+0x223/0x880 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
iptunnel_xmit+0x567/0x850 net/ipv4/ip_tunnel_core.c:91
ip_tunnel_xmit+0x1598/0x3af1 net/ipv4/ip_tunnel.c:778
__gre_xmit+0x5e1/0x980 net/ipv4/ip_gre.c:449
ipgre_xmit+0x3e8/0xb50 net/ipv4/ip_gre.c:701
__netdev_start_xmit include/linux/netdevice.h:4148 [inline]
netdev_start_xmit include/linux/netdevice.h:4157 [inline]
xmit_one net/core/dev.c:3034 [inline]
dev_hard_start_xmit+0x26c/0xc30 net/core/dev.c:3050
__dev_queue_xmit+0x29ef/0x3910 net/core/dev.c:3569
dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
__bpf_tx_skb net/core/filter.c:1952 [inline]
__bpf_redirect_common net/core/filter.c:1990 [inline]
__bpf_redirect+0x5b7/0xae0 net/core/filter.c:1997
____bpf_clone_redirect net/core/filter.c:2030 [inline]
bpf_clone_redirect+0x2f6/0x490 net/core/filter.c:2002
bpf_prog_bebbfe2050753572+0x12c/0x1000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 2c302777c0a564f9 ]---
RIP: 0010:ip_do_fragment+0x2468/0x2ae0 net/ipv4/ip_output.c:773
Code: 8b 8d 70 fe ff ff e9 67 e8 ff ff 4c 89 ef e8 df 7a 57 fb e9 49 e9 ff
ff 4c 89 f7 e8 d2 7a 57 fb e9 c1 e5 ff ff e8 b8 a0 19 fb <0f> 0b 4c 89 e7
e8 be 7a 57 fb e9 85 e8 ff ff 4c 89 f7 89 8d 70 fe
RSP: 0018:ffff880195016880 EFLAGS: 00010246
RAX: 0000000000040000 RBX: ffff8801ce7be940 RCX: ffffc90002a12000
RDX: 0000000000040000 RSI: ffffffff86626ae8 RDI: 0000000000000005
RBP: ffff880195016a58 R08: ffff8801c66e8180 R09: ffffed00323180ba
R10: ffffed00323180bc R11: ffff8801918c05e3 R12: ffff8801ce7bea04
R13: 00000000fffffff2 R14: ffff8801ce7bea10 R15: dffffc0000000000
FS: 00007effc88a9700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdeada9000 CR3: 00000001b3b5d000 CR4: 00000000001406f0
DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH 11/18] wireless/ti: change strncpy+truncation to strlcpy
From: Arend van Spriel @ 2018-07-13 7:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Dominique Martinet
Cc: Kalle Valo, David S. Miller, Thomas Gleixner, Kate Stewart,
Philippe Ombredanne, Joe Perches, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20180713073810.GA31984@kroah.com>
On 7/13/2018 9:38 AM, Greg Kroah-Hartman wrote:
> On Fri, Jul 13, 2018 at 03:25:49AM +0200, Dominique Martinet wrote:
>> Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
>>
>> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
>
> I don't know about other maintainers, but I know I wouldn't take such a
> horrid changelog description as this :)
>
> good luck!
especially as that script is not in the kernel tree yet. The patch
adding that script contains a good motivation, but I would want to see
that in commit message of every patch or at least the gist of it.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 11/18] wireless/ti: change strncpy+truncation to strlcpy
From: Greg Kroah-Hartman @ 2018-07-13 7:38 UTC (permalink / raw)
To: Dominique Martinet
Cc: Kalle Valo, David S. Miller, Thomas Gleixner, Kate Stewart,
Philippe Ombredanne, Joe Perches, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1531445149-19607-1-git-send-email-asmadeus@codewreck.org>
On Fri, Jul 13, 2018 at 03:25:49AM +0200, Dominique Martinet wrote:
> Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
>
> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
I don't know about other maintainers, but I know I wouldn't take such a
horrid changelog description as this :)
good luck!
greg k-h
^ permalink raw reply
* Re: [PATCH 10/18] brcmsmac: change strncpy+truncation to strlcpy
From: Arend van Spriel @ 2018-07-13 7:19 UTC (permalink / raw)
To: Dominique Martinet
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <1531445147-19566-1-git-send-email-asmadeus@codewreck.org>
On 7/13/2018 3:25 AM, Dominique Martinet wrote:
> Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
> ---
>
> Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
> first patch of the serie) for the motivation behind this patch
I would prefer to have the motivation in the commit message of this patch.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] hostap: hide unused procfs helpers
From: Arend van Spriel @ 2018-07-13 7:26 UTC (permalink / raw)
To: YueHaibing, j, kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Randy Dunlap
In-Reply-To: <20180713070317.6724-1-yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
+ Randy
On 7/13/2018 9:03 AM, YueHaibing wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/net/wireless/intersil/hostap/hostap_hw.c:2901:12: warning: ‘prism2_registers_proc_show’ defined but not used [-Wunused-function]
> static int prism2_registers_proc_show(struct seq_file *m, void *v)
>
> drivers/net/wireless/intersil/hostap/hostap_proc.c:16:12: warning: ‘prism2_debug_proc_show’ defined but not used [-Wunused-function]
> static int prism2_debug_proc_show(struct seq_file *m, void *v)
> ^
> drivers/net/wireless/intersil/hostap/hostap_proc.c:49:12: warning: ‘prism2_stats_proc_show’ defined but not used [-Wunused-function]
> static int prism2_stats_proc_show(struct seq_file *m, void *v)
> ^
> drivers/net/wireless/intersil/hostap/hostap_proc.c:177:12: warning: ‘prism2_crypt_proc_show’ defined but not used [-Wunused-function]
> static int prism2_crypt_proc_show(struct seq_file *m, void *v)
> ^
>
> fix this by adding #ifdef around them.
> hfa384x_read_reg is only used by prism2_registers_proc_show,so move it
> into #ifdef.
There was already a fix for this posted by Randy Dunlap taking a
different approach, ie. use __maybe_unused classifier. To be honest I
prefer the ifdef approach as it is more explicit and does not feel like
a cheat.
Actually some of the functions are between a flag already
PRISM2_NO_PROCFS_DEBUG which is in a private header file
hostap_config.h. Seems like this would be better placed in Kconfig and
depend on CONFIG_PROCFS. Anyway, this driver is old cruft. Maybe some
people are still running it, but it is probably not worth the effort so
fine with either fix.
Regards,
Arend
^ permalink raw reply
* [PATCH] hostap: hide unused procfs helpers
From: YueHaibing @ 2018-07-13 7:03 UTC (permalink / raw)
To: j, kvalo; +Cc: linux-kernel, netdev, linux-wireless, davem, YueHaibing
When CONFIG_PROC_FS isn't set, gcc warning this:
drivers/net/wireless/intersil/hostap/hostap_hw.c:2901:12: warning: ‘prism2_registers_proc_show’ defined but not used [-Wunused-function]
static int prism2_registers_proc_show(struct seq_file *m, void *v)
drivers/net/wireless/intersil/hostap/hostap_proc.c:16:12: warning: ‘prism2_debug_proc_show’ defined but not used [-Wunused-function]
static int prism2_debug_proc_show(struct seq_file *m, void *v)
^
drivers/net/wireless/intersil/hostap/hostap_proc.c:49:12: warning: ‘prism2_stats_proc_show’ defined but not used [-Wunused-function]
static int prism2_stats_proc_show(struct seq_file *m, void *v)
^
drivers/net/wireless/intersil/hostap/hostap_proc.c:177:12: warning: ‘prism2_crypt_proc_show’ defined but not used [-Wunused-function]
static int prism2_crypt_proc_show(struct seq_file *m, void *v)
^
fix this by adding #ifdef around them.
hfa384x_read_reg is only used by prism2_registers_proc_show,so move it
into #ifdef.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/intersil/hostap/hostap_ap.c | 8 ++++----
drivers/net/wireless/intersil/hostap/hostap_hw.c | 17 +++++++----------
drivers/net/wireless/intersil/hostap/hostap_proc.c | 10 ++++++----
3 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/intersil/hostap/hostap_ap.c b/drivers/net/wireless/intersil/hostap/hostap_ap.c
index d1884b8..0094b1d 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ap.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ap.c
@@ -66,7 +66,7 @@ static void prism2_send_mgmt(struct net_device *dev,
#endif /* PRISM2_NO_KERNEL_IEEE80211_MGMT */
-#ifndef PRISM2_NO_PROCFS_DEBUG
+#if !defined(PRISM2_NO_PROCFS_DEBUG) && defined(CONFIG_PROC_FS)
static int ap_debug_proc_show(struct seq_file *m, void *v)
{
struct ap_data *ap = PDE_DATA(file_inode(m->file));
@@ -81,8 +81,7 @@ static int ap_debug_proc_show(struct seq_file *m, void *v)
seq_printf(m, "tx_drop_nonassoc=%u\n", ap->tx_drop_nonassoc);
return 0;
}
-#endif /* PRISM2_NO_PROCFS_DEBUG */
-
+#endif
static void ap_sta_hash_add(struct ap_data *ap, struct sta_info *sta)
{
@@ -990,7 +989,7 @@ static void prism2_send_mgmt(struct net_device *dev,
}
#endif /* PRISM2_NO_KERNEL_IEEE80211_MGMT */
-
+#ifdef CONFIG_PROC_FS
static int prism2_sta_proc_show(struct seq_file *m, void *v)
{
struct sta_info *sta = m->private;
@@ -1059,6 +1058,7 @@ static int prism2_sta_proc_show(struct seq_file *m, void *v)
return 0;
}
+#endif
static void handle_add_proc_queue(struct work_struct *work)
{
diff --git a/drivers/net/wireless/intersil/hostap/hostap_hw.c b/drivers/net/wireless/intersil/hostap/hostap_hw.c
index 2720aa3..ad1aa65 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_hw.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_hw.c
@@ -151,13 +151,6 @@ static int prism2_get_ram_size(local_info_t *local);
#define HFA384X_MAGIC 0x8A32
#endif
-
-static u16 hfa384x_read_reg(struct net_device *dev, u16 reg)
-{
- return HFA384X_INW(reg);
-}
-
-
static void hfa384x_read_regs(struct net_device *dev,
struct hfa384x_regs *regs)
{
@@ -2897,7 +2890,12 @@ static void hostap_tick_timer(struct timer_list *t)
}
-#ifndef PRISM2_NO_PROCFS_DEBUG
+#if !defined(PRISM2_NO_PROCFS_DEBUG) && defined(CONFIG_PROC_FS)
+static u16 hfa384x_read_reg(struct net_device *dev, u16 reg)
+{
+ return HFA384X_INW(reg);
+}
+
static int prism2_registers_proc_show(struct seq_file *m, void *v)
{
local_info_t *local = m->private;
@@ -2951,8 +2949,7 @@ static int prism2_registers_proc_show(struct seq_file *m, void *v)
return 0;
}
-#endif /* PRISM2_NO_PROCFS_DEBUG */
-
+#endif
struct set_tim_data {
struct list_head list;
diff --git a/drivers/net/wireless/intersil/hostap/hostap_proc.c b/drivers/net/wireless/intersil/hostap/hostap_proc.c
index 5b33cca..703d74c 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_proc.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_proc.c
@@ -11,8 +11,7 @@
#define PROC_LIMIT (PAGE_SIZE - 80)
-
-#ifndef PRISM2_NO_PROCFS_DEBUG
+#if !defined(PRISM2_NO_PROCFS_DEBUG) && defined(CONFIG_PROC_FS)
static int prism2_debug_proc_show(struct seq_file *m, void *v)
{
local_info_t *local = m->private;
@@ -43,9 +42,9 @@ static int prism2_debug_proc_show(struct seq_file *m, void *v)
return 0;
}
-#endif /* PRISM2_NO_PROCFS_DEBUG */
-
+#endif
+#ifdef CONFIG_PROC_FS
static int prism2_stats_proc_show(struct seq_file *m, void *v)
{
local_info_t *local = m->private;
@@ -82,6 +81,7 @@ static int prism2_stats_proc_show(struct seq_file *m, void *v)
return 0;
}
+#endif
static int prism2_wds_proc_show(struct seq_file *m, void *v)
{
@@ -174,6 +174,7 @@ static const struct seq_operations prism2_bss_list_proc_seqops = {
.show = prism2_bss_list_proc_show,
};
+#ifdef CONFIG_PROC_FS
static int prism2_crypt_proc_show(struct seq_file *m, void *v)
{
local_info_t *local = m->private;
@@ -190,6 +191,7 @@ static int prism2_crypt_proc_show(struct seq_file *m, void *v)
}
return 0;
}
+#endif
static ssize_t prism2_pda_proc_read(struct file *file, char __user *buf,
size_t count, loff_t *_pos)
--
2.7.0
^ permalink raw reply related
* [PATCH][net-next][v2] net: convert gro_count to bitmask
From: Li RongQing @ 2018-07-13 6:41 UTC (permalink / raw)
To: netdev; +Cc: edumazet, sbrivio
gro_hash size is 192 bytes, and uses 3 cache lines, if there is few
flows, gro_hash may be not fully used, so it is unnecessary to iterate
all gro_hash in napi_gro_flush(), to occupy unnecessary cacheline.
convert gro_count to a bitmask, and rename it as gro_bitmask, each bit
represents a element of gro_hash, only flush a gro_hash element if the
related bit is set, to speed up napi_gro_flush().
and update gro_bitmask only if it will be changed, to reduce cache
update
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Cc: Stefano Brivio <sbrivio@redhat.com>
---
netperf shows no difference, maybe because my testing machine has large
cache
include/linux/netdevice.h | 9 +++++++--
net/core/dev.c | 36 ++++++++++++++++++++++++------------
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 2daf2fa6554f..8837a998de3f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -308,9 +308,14 @@ struct gro_list {
};
/*
- * Structure for NAPI scheduling similar to tasklet but with weighting
+ * size of gro hash buckets, must less than bit number of
+ * napi_struct::gro_bitmask
*/
#define GRO_HASH_BUCKETS 8
+
+/*
+ * Structure for NAPI scheduling similar to tasklet but with weighting
+ */
struct napi_struct {
/* The poll_list must only be managed by the entity which
* changes the state of the NAPI_STATE_SCHED bit. This means
@@ -322,7 +327,7 @@ struct napi_struct {
unsigned long state;
int weight;
- unsigned int gro_count;
+ unsigned long gro_bitmask;
int (*poll)(struct napi_struct *, int);
#ifdef CONFIG_NETPOLL
int poll_owner;
diff --git a/net/core/dev.c b/net/core/dev.c
index 14a748ee8cc9..e39fef62e285 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5283,9 +5283,11 @@ static void __napi_gro_flush_chain(struct napi_struct *napi, u32 index,
list_del(&skb->list);
skb->next = NULL;
napi_gro_complete(skb);
- napi->gro_count--;
napi->gro_hash[index].count--;
}
+
+ if (!napi->gro_hash[index].count)
+ __clear_bit(index, &napi->gro_bitmask);
}
/* napi->gro_hash[].list contains packets ordered by age.
@@ -5296,8 +5298,10 @@ void napi_gro_flush(struct napi_struct *napi, bool flush_old)
{
u32 i;
- for (i = 0; i < GRO_HASH_BUCKETS; i++)
- __napi_gro_flush_chain(napi, i, flush_old);
+ for (i = 0; i < GRO_HASH_BUCKETS; i++) {
+ if (test_bit(i, &napi->gro_bitmask))
+ __napi_gro_flush_chain(napi, i, flush_old);
+ }
}
EXPORT_SYMBOL(napi_gro_flush);
@@ -5389,8 +5393,8 @@ static void gro_flush_oldest(struct list_head *head)
if (WARN_ON_ONCE(!oldest))
return;
- /* Do not adjust napi->gro_count, caller is adding a new SKB to
- * the chain.
+ /* Do not adjust napi->gro_hash[].count, caller is adding a new
+ * SKB to the chain.
*/
list_del(&oldest->list);
napi_gro_complete(oldest);
@@ -5465,7 +5469,6 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
list_del(&pp->list);
pp->next = NULL;
napi_gro_complete(pp);
- napi->gro_count--;
napi->gro_hash[hash].count--;
}
@@ -5478,7 +5481,6 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
if (unlikely(napi->gro_hash[hash].count >= MAX_GRO_SKBS)) {
gro_flush_oldest(gro_head);
} else {
- napi->gro_count++;
napi->gro_hash[hash].count++;
}
NAPI_GRO_CB(skb)->count = 1;
@@ -5493,6 +5495,13 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
if (grow > 0)
gro_pull_from_frag0(skb, grow);
ok:
+ if (napi->gro_hash[hash].count) {
+ if (!test_bit(hash, &napi->gro_bitmask))
+ __set_bit(hash, &napi->gro_bitmask);
+ } else if (test_bit(hash, &napi->gro_bitmask)) {
+ __clear_bit(hash, &napi->gro_bitmask);
+ }
+
return ret;
normal:
@@ -5891,7 +5900,7 @@ bool napi_complete_done(struct napi_struct *n, int work_done)
NAPIF_STATE_IN_BUSY_POLL)))
return false;
- if (n->gro_count) {
+ if (n->gro_bitmask) {
unsigned long timeout = 0;
if (work_done)
@@ -6100,7 +6109,7 @@ static enum hrtimer_restart napi_watchdog(struct hrtimer *timer)
/* Note : we use a relaxed variant of napi_schedule_prep() not setting
* NAPI_STATE_MISSED, since we do not react to a device IRQ.
*/
- if (napi->gro_count && !napi_disable_pending(napi) &&
+ if (napi->gro_bitmask && !napi_disable_pending(napi) &&
!test_and_set_bit(NAPI_STATE_SCHED, &napi->state))
__napi_schedule_irqoff(napi);
@@ -6115,7 +6124,7 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
INIT_LIST_HEAD(&napi->poll_list);
hrtimer_init(&napi->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED);
napi->timer.function = napi_watchdog;
- napi->gro_count = 0;
+ napi->gro_bitmask = 0;
for (i = 0; i < GRO_HASH_BUCKETS; i++) {
INIT_LIST_HEAD(&napi->gro_hash[i].list);
napi->gro_hash[i].count = 0;
@@ -6175,7 +6184,7 @@ void netif_napi_del(struct napi_struct *napi)
napi_free_frags(napi);
flush_gro_hash(napi);
- napi->gro_count = 0;
+ napi->gro_bitmask = 0;
}
EXPORT_SYMBOL(netif_napi_del);
@@ -6217,7 +6226,7 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
goto out_unlock;
}
- if (n->gro_count) {
+ if (n->gro_bitmask) {
/* flush too old packets
* If HZ < 1000, flush all packets.
*/
@@ -9264,6 +9273,9 @@ static struct hlist_head * __net_init netdev_create_hash(void)
/* Initialize per network namespace state */
static int __net_init netdev_init(struct net *net)
{
+ BUILD_BUG_ON(GRO_HASH_BUCKETS >
+ FIELD_SIZEOF(struct napi_struct, gro_bitmask));
+
if (net != &init_net)
INIT_LIST_HEAD(&net->dev_base_head);
--
2.16.2
^ permalink raw reply related
* [PATCH] connector: hide unused procfs helpers
From: YueHaibing @ 2018-07-13 7:11 UTC (permalink / raw)
To: zbr; +Cc: linux-kernel, netdev, YueHaibing
When CONFIG_PROC_FS isn't set, gcc warning this:
drivers/connector/connector.c:242:12: warning: ‘cn_proc_show’ defined but not used [-Wunused-function]
static int cn_proc_show(struct seq_file *m, void *v)
^
fix this by adding #ifdef around it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/connector/connector.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index e718b8c..e2636d4 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -239,6 +239,7 @@ void cn_del_callback(struct cb_id *id)
}
EXPORT_SYMBOL_GPL(cn_del_callback);
+#ifdef CONFIG_PROC_FS
static int cn_proc_show(struct seq_file *m, void *v)
{
struct cn_queue_dev *dev = cdev.cbdev;
@@ -259,6 +260,7 @@ static int cn_proc_show(struct seq_file *m, void *v)
return 0;
}
+#endif
static struct cn_dev cdev = {
.input = cn_rx_skb,
--
2.7.0
^ permalink raw reply related
* [PATCH][net-next] bridge: clean up mtu_set_by_user setting to false and comments
From: Li RongQing @ 2018-07-13 6:47 UTC (permalink / raw)
To: netdev; +Cc: nikolay
Once mtu_set_by_user is set to true, br_mtu_auto_adjust will
not run, and no chance to clear mtu_set_by_user.
and br_mtu_auto_adjust will run only if mtu_set_by_user is
false, so not need to set it to false again
Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/bridge/br_device.c | 1 -
net/bridge/br_if.c | 4 ----
2 files changed, 5 deletions(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index e682a668ce57..c636bc2749c2 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -227,7 +227,6 @@ static int br_change_mtu(struct net_device *dev, int new_mtu)
dev->mtu = new_mtu;
- /* this flag will be cleared if the MTU was automatically adjusted */
br->mtu_set_by_user = true;
#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
/* remember the MTU in the rtable for PMTU */
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 05e42d86882d..47c65da4b1be 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -450,11 +450,7 @@ void br_mtu_auto_adjust(struct net_bridge *br)
if (br->mtu_set_by_user)
return;
- /* change to the minimum MTU and clear the flag which was set by
- * the bridge ndo_change_mtu callback
- */
dev_set_mtu(br->dev, br_mtu_min(br));
- br->mtu_set_by_user = false;
}
static void br_set_gso_limits(struct net_bridge *br)
--
2.16.2
^ permalink raw reply related
* [PATCH 03/10] atmel: hide unused procfs helpers
From: YueHaibing @ 2018-07-13 6:46 UTC (permalink / raw)
To: simon, kvalo; +Cc: linux-kernel, netdev, linux-wireless, davem, YueHaibing
When CONFIG_PROC_FS isn't set, gcc warning this:
drivers/net/wireless/atmel/atmel.c:1402:12: warning: ‘atmel_proc_show’ defined but not used [-Wunused-function]
static int atmel_proc_show(struct seq_file *m, void *v)
^
fix this by adding #ifdef around it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/atmel/atmel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/atmel/atmel.c b/drivers/net/wireless/atmel/atmel.c
index b01dc34..3940876 100644
--- a/drivers/net/wireless/atmel/atmel.c
+++ b/drivers/net/wireless/atmel/atmel.c
@@ -1399,6 +1399,7 @@ static int atmel_validate_channel(struct atmel_private *priv, int channel)
return 0;
}
+#ifdef CONFIG_PROC_FS
static int atmel_proc_show(struct seq_file *m, void *v)
{
struct atmel_private *priv = m->private;
@@ -1481,6 +1482,7 @@ static int atmel_proc_show(struct seq_file *m, void *v)
seq_printf(m, "Current state:\t\t%s\n", s);
return 0;
}
+#endif
static const struct net_device_ops atmel_netdev_ops = {
.ndo_open = atmel_open,
--
2.7.0
^ permalink raw reply related
* Attractive interest rate @ (2.75%) for project funding/Loan/finance from Coutts & Co U.K !!
From: COUTTS & CO @ 2018-07-13 5:03 UTC (permalink / raw)
To: Recipients
Coutts & Co Ltd
440 Strand, London, WC2R 0QS
Website: https://www.coutts.com
Telephone:+4420 3389 7785 & +4420 7753 1000
Fax:+44 872 110 3479
OUR REF: Coutts/UK/2018/LOANAPP
YOUR REF:LOANAPPT/Coutts/JULY/2018
TO WHOM IT MAY CONCERN
We give out both Local/International Loan starting from 2.75%* rate of interest annually.We offer non-collateral loans to both firms and individuals.
Funds available For Most Projects Covering Real Estate, Industry And Other Forms Of Creativity In Some Major Countries.
You Might Be Interested In Submitting Your Business Proposal And Study For Evaluation.
We Do Not Promise Success Of Funding But We Shall Do Our Best To Help And Assist.
No Upfront Fees Or Payments.We Can Also Provide Bank Guarantees And SBLC's For Your Projects Including Monetization.
Please Contact Us For An Application And For More Instruction Please Email Us with the following information-FULL NAMES/COMPANY NAME,TELEPHONE NUMBER,PURPOSE OF LOAN/FINANCE AND PRESENT LOCATION At Email address:couttsfinance@mail.uk
Quick approvals | Disbursal in 72 hours* | FUND DIRECTLY DEPOSITED
© Copyright Coutts & Co 2018
^ permalink raw reply
* Re: [PATCH v3 net-next] net/sched: add skbprio scheduler
From: Cong Wang @ 2018-07-13 6:05 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Michel Machado, Nishanth Devarajan, Jamal Hadi Salim, Jiri Pirko,
David Miller, Linux Kernel Network Developers, Cody Doucette
In-Reply-To: <20180711193336.GF8880@localhost.localdomain>
On Wed, Jul 11, 2018 at 12:33 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Tue, Jul 10, 2018 at 07:25:53PM -0700, Cong Wang wrote:
> > On Mon, Jul 9, 2018 at 2:40 PM Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> > >
> > > On Mon, Jul 09, 2018 at 05:03:31PM -0400, Michel Machado wrote:
> > > > Changing TC_PRIO_MAX from 15 to 63 risks breaking backward compatibility
> > > > with applications.
> > >
> > > If done, it needs to be done carefully, indeed. I don't know if it's
> > > doable, neither I know how hard is your requirement for 64 different
> > > priorities.
> >
> > struct tc_prio_qopt {
> > int bands; /* Number of bands */
> > __u8 priomap[TC_PRIO_MAX+1]; /* Map: logical priority -> PRIO band */
> > };
> >
> > How would you do it carefully?
>
> quick shot, multiplex v1 and v2 formats based on bands and sizeof():
>
> #define TCQ_PRIO_BANDS_V1 16
> #define TCQ_PRIO_BANDS_V2 64
> #define TC_PRIO_MAX_V2 64
>
> struct tc_prio_qopt_v2 {
> int bands; /* Number of bands */
> __u8 priomap[TC_PRIO_MAX_V2+1]; /* Map: logical priority -> PRIO band */
> };
>
Good try, but:
1. You don't take padding into account, although the difference
between 16 and 64 is big here. If it were 16 and 20, almost certainly
wouldn't work.
2. What if I compile a new iproute2 on an old kernel? The iproute2
will use V2, while old kernel has no knowledge of V2, so it only
copies a part of V2 in the end....
^ permalink raw reply
* Re: [PATCH net] tun: Fix use-after-free on XDP_TX
From: Jesper Dangaard Brouer @ 2018-07-13 5:57 UTC (permalink / raw)
To: Jason Wang; +Cc: Toshiaki Makita, David S . Miller, netdev, brouer
In-Reply-To: <d18b205d-1d9d-b435-3043-1872145c60b9@redhat.com>
On Fri, 13 Jul 2018 13:05:04 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2018年07月13日 12:24, Toshiaki Makita wrote:
> > On XDP_TX we need to free up the frame only when tun_xdp_tx() returns a
> > negative value. A positive value indicates that the packet is
> > successfully enqueued to the ptr_ring, so freeing the page causes
> > use-after-free.
> >
> > Fixes: 735fc4054b3a ("xdp: change ndo_xdp_xmit API to support bulking")
> > Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> > ---
> > drivers/net/tun.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index a192a01..f5727ba 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -1688,7 +1688,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
> > case XDP_TX:
> > get_page(alloc_frag->page);
> > alloc_frag->offset += buflen;
> > - if (tun_xdp_tx(tun->dev, &xdp))
> > + if (tun_xdp_tx(tun->dev, &xdp) < 0)
> > goto err_redirect;
> > rcu_read_unlock();
> > local_bh_enable();
>
> Acked-by: Jason Wang <jasowang@redhat.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Thanks for catching and fixing this!
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH net-next] net: ip6_gre: get ipv6hdr after skb_cow_head()
From: Prashant Bhole @ 2018-07-13 5:40 UTC (permalink / raw)
To: David S . Miller
Cc: Prashant Bhole, Alexey Kuznetsov, Hideaki YOSHIFUJI, William Tu,
netdev
A KASAN:use-after-free bug was found related to ip6-erspan
while running selftests/net/ip6_gre_headroom.sh
It happens because of following sequence:
- ipv6hdr pointer is obtained from skb
- skb_cow_head() is called, skb->head memory is reallocated
- old data is accessed using ipv6hdr pointer
skb_cow_head() call was added in e41c7c68ea77 ("ip6erspan: make sure
enough headroom at xmit."), but looking at the history there was a
chance of similar bug because gre_handle_offloads() and pskb_trim()
can also reallocate skb->head memory. Fixes tag points to commit
which introduced possibility of this bug.
This patch moves ipv6hdr pointer assignment after skb_cow_head() call.
Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
net/ipv6/ip6_gre.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 367177786e34..fc7dd3a04360 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -927,7 +927,6 @@ static netdev_tx_t ip6gre_tunnel_xmit(struct sk_buff *skb,
static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,
struct net_device *dev)
{
- struct ipv6hdr *ipv6h = ipv6_hdr(skb);
struct ip6_tnl *t = netdev_priv(dev);
struct dst_entry *dst = skb_dst(skb);
struct net_device_stats *stats;
@@ -1012,6 +1011,8 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,
goto tx_err;
}
} else {
+ struct ipv6hdr *ipv6h = ipv6_hdr(skb);
+
switch (skb->protocol) {
case htons(ETH_P_IP):
memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
--
2.17.1
^ permalink raw reply related
* Attractive interest rate @ (2.75%) for project funding/Loan/finance from Coutts & Co U.K !!
From: COUTTS & CO @ 2018-07-13 4:38 UTC (permalink / raw)
To: netdev
Coutts & Co Ltd
440 Strand, London, WC2R 0QS
Website: https://www.coutts.com
Telephone:+4420 3389 7785 & +4420 7753 1000
Fax:+44 872 110 3479
OUR REF: Coutts/UK/2018/LOANAPP
YOUR REF:LOANAPPT/Coutts/JULY/2018
TO WHOM IT MAY CONCERN
We give out both Local/International Loan starting from 2.75%* rate of interest annually.We offer non-collateral loans to both firms and individuals.
Funds available For Most Projects Covering Real Estate, Industry And Other Forms Of Creativity In Some Major Countries.
You Might Be Interested In Submitting Your Business Proposal And Study For Evaluation.
We Do Not Promise Success Of Funding But We Shall Do Our Best To Help And Assist.
No Upfront Fees Or Payments.We Can Also Provide Bank Guarantees And SBLC's For Your Projects Including Monetization.
Please Contact Us For An Application And For More Instruction Please Email Us with the following information-FULL NAMES/COMPANY NAME,TELEPHONE NUMBER,PURPOSE OF LOAN/FINANCE AND PRESENT LOCATION At Email address:couttsfinance@mail.uk
Quick approvals | Disbursal in 72 hours* | FUND DIRECTLY DEPOSITED
© Copyright Coutts & Co 2018
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: remove redundant debug register dma mem allocation
From: Michael Chan @ 2018-07-13 5:42 UTC (permalink / raw)
To: YueHaibing; +Cc: open list, Netdev, David Miller
In-Reply-To: <20180713030204.884-1-yuehaibing@huawei.com>
On Thu, Jul 12, 2018 at 8:02 PM, YueHaibing <yuehaibing@huawei.com> wrote:
> hwrm_dbg_resp_addr and hwrm_dbg_resp_dma_addr are never used
> and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Thanks.
Acked-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* How are you doing today? Please read my email and reply me!!
From: Billy Wilfred @ 2018-07-13 0:31 UTC (permalink / raw)
Dear Sir/Madam,
How are you doing today? My name is Billy Wilfred. I am California, United States of America. I am a broker of Project Financing Firm who has cutting edge and group capital fund, they can finance any lucrative project and help you to enhance your business plan. Are you in need of a Loan to Finance and Fund your Project or Company? Are you an Investor, Real Estate developer, Construction Company, etc? or Do you need a loan to keep your investment or business going on in order to have a different look? Have you been trying to obtain a Loan from Banks or Loan Companies and got Ripped off and they have refused to grant you the Loan because of bad credit? do not close your company and stop your project because of bankruptcy, we are here for you for real, please be happy, rejoice and celebrate
because your solution have come, we will end your financial worries now. Therefore come to us, we will grant you the loan you need without delay. We offer all types of non-recourse Loan and Funding
at a low Interest Rate of
The categories of Loan Financial Funding we offered include but not limited to: Business Loan, Personal Loan, Company Loan, Mortgage Loan, Debt Consolidation and Financial Funding for both Turnkey and mega projects etc from a minimum of Euro / US$1Million to Euro / US$5 Billion Max. Most importantly, Note that the loan company DO NOT charge any upfront fee or advance fee. This message is not scam for what so ever. This is 100% real, legal and legitimate loan company office in Turkey. Kindly get in touch for further details and procedures. Thanks for your cooperation with us. I will be waiting for your response. Further more details and directives contact me on my private email: bwilalessandro@gmail.com
Thank you & best regards,
Billy Wilfred.
Contact me on my private email: bwilalessandro@gmail.com
^ permalink raw reply
* Re: [PATCH v3 net-next] net/sched: add skbprio scheduler
From: Cong Wang @ 2018-07-13 5:07 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Michel Machado, Nishanth Devarajan, Jamal Hadi Salim, Jiri Pirko,
David Miller, Linux Kernel Network Developers, Cody Doucette
In-Reply-To: <20180711183755.GE8880@localhost.localdomain>
On Wed, Jul 11, 2018 at 11:37 AM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Tue, Jul 10, 2018 at 07:32:43PM -0700, Cong Wang wrote:
> > On Mon, Jul 9, 2018 at 12:53 PM Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> > >
> > > On Mon, Jul 09, 2018 at 02:18:33PM -0400, Michel Machado wrote:
> > > >
> > > > 2. sch_prio.c does not have a global limit on the number of packets on
> > > > all its queues, only a limit per queue.
> > >
> > > It can be useful to sch_prio.c as well, why not?
> > > prio_enqueue()
> > > {
> > > ...
> > > + if (count > sch->global_limit)
> > > + prio_tail_drop(sch); /* to be implemented */
> > > ret = qdisc_enqueue(skb, qdisc, to_free);
> > >
> >
> > Isn't the whole point of sch_prio offloading the queueing to
> > each class? If you need a limit, there is one for each child
> > qdisc if you use for example pfifo or bfifo (depending on you
> > want to limit bytes or packets).
>
> Yes, but Michel wants to drop from other lower priorities if needed,
> and that's not possible if you handle the limit already in a child
> qdisc as they don't know about their siblings. The idea in the example
> above is to discard it from whatever lower priority is needed, then
> queue it. (ok, the example missed to check the priority level)
So it disproves your point of adding a flag to sch_prio, right?
Also, you have to re-introduce qdisc->ops->drop() if you really want
to go this direction.
>
> As for the different units, sch_prio holds a count of how many packets
> are queued on its children, and that's what would be used for the limit.
>
> >
> > Also, what's your plan for backward compatibility here?
>
> say:
> if (sch->global_limit && count > sch->global_limit)
> as in, only do the limit check/enforcing if needed.
Obviously doesn't work, users could pass 0 to effectively
disable the qdisc from enqueue'ing any packet.
^ permalink raw reply
* Re: [PATCH net] tun: Fix use-after-free on XDP_TX
From: Jason Wang @ 2018-07-13 5:05 UTC (permalink / raw)
To: Toshiaki Makita, David S . Miller; +Cc: netdev, Jesper Dangaard Brouer
In-Reply-To: <1531455878-2552-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On 2018年07月13日 12:24, Toshiaki Makita wrote:
> On XDP_TX we need to free up the frame only when tun_xdp_tx() returns a
> negative value. A positive value indicates that the packet is
> successfully enqueued to the ptr_ring, so freeing the page causes
> use-after-free.
>
> Fixes: 735fc4054b3a ("xdp: change ndo_xdp_xmit API to support bulking")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
> drivers/net/tun.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index a192a01..f5727ba 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1688,7 +1688,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
> case XDP_TX:
> get_page(alloc_frag->page);
> alloc_frag->offset += buflen;
> - if (tun_xdp_tx(tun->dev, &xdp))
> + if (tun_xdp_tx(tun->dev, &xdp) < 0)
> goto err_redirect;
> rcu_read_unlock();
> local_bh_enable();
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* [PATCH net] tun: Fix use-after-free on XDP_TX
From: Toshiaki Makita @ 2018-07-13 4:24 UTC (permalink / raw)
To: David S . Miller; +Cc: Toshiaki Makita, netdev, Jesper Dangaard Brouer
On XDP_TX we need to free up the frame only when tun_xdp_tx() returns a
negative value. A positive value indicates that the packet is
successfully enqueued to the ptr_ring, so freeing the page causes
use-after-free.
Fixes: 735fc4054b3a ("xdp: change ndo_xdp_xmit API to support bulking")
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/tun.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a192a01..f5727ba 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1688,7 +1688,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
case XDP_TX:
get_page(alloc_frag->page);
alloc_frag->offset += buflen;
- if (tun_xdp_tx(tun->dev, &xdp))
+ if (tun_xdp_tx(tun->dev, &xdp) < 0)
goto err_redirect;
rcu_read_unlock();
local_bh_enable();
--
1.8.3.1
^ permalink raw reply related
* [PATCH] isdn/capi: hide unused procfs helpers
From: YueHaibing @ 2018-07-13 4:11 UTC (permalink / raw)
To: isdn; +Cc: linux-kernel, netdev, keescook, viro, YueHaibing
When CONFIG_PROC_FS isn't set, gcc warning this:
drivers/isdn/capi/capi.c:1324:12: warning: ‘capi20_proc_show’ defined but not used [-Wunused-function]
static int capi20_proc_show(struct seq_file *m, void *v)
^
drivers/isdn/capi/capi.c:1347:12: warning: ‘capi20ncci_proc_show’ defined but not used [-Wunused-function]
static int capi20ncci_proc_show(struct seq_file *m, void *v)
^
drivers/isdn/capi/capidrv.c:2454:12: warning: ‘capidrv_proc_show’ defined but not used [-Wunused-function]
static int capidrv_proc_show(struct seq_file *m, void *v)
^
We can fix the warning by adding the same #ifdef around them.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/isdn/capi/capi.c | 2 ++
drivers/isdn/capi/capidrv.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index 6e0c281..594f767 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -1317,6 +1317,7 @@ static inline void capinc_tty_exit(void) { }
/* -------- /proc functions ----------------------------------------- */
+#ifdef CONFIG_PROC_FS
/*
* /proc/capi/capi20:
* minor applid nrecvctlpkt nrecvdatapkt nsendctlpkt nsenddatapkt
@@ -1359,6 +1360,7 @@ static int capi20ncci_proc_show(struct seq_file *m, void *v)
mutex_unlock(&capidev_list_lock);
return 0;
}
+#endif
static void __init proc_init(void)
{
diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index ee510f9..c6f45d7 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -2447,6 +2447,7 @@ lower_callback(struct notifier_block *nb, unsigned long val, void *v)
return NOTIFY_OK;
}
+#ifdef CONFIG_PROC_FS
/*
* /proc/capi/capidrv:
* nrecvctlpkt nrecvdatapkt nsendctlpkt nsenddatapkt
@@ -2460,6 +2461,7 @@ static int capidrv_proc_show(struct seq_file *m, void *v)
global.ap.nsentdatapkt);
return 0;
}
+#endif
static void __init proc_init(void)
{
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next v6 00/11] Modify action API for implementing lockless actions
From: Cong Wang @ 2018-07-13 3:54 UTC (permalink / raw)
To: David Miller
Cc: Vlad Buslov, Linux Kernel Network Developers, Jamal Hadi Salim,
Jiri Pirko, Alexei Starovoitov, Daniel Borkmann,
Yevgeny Kliteynik
In-Reply-To: <20180708.124325.344679298289898945.davem@davemloft.net>
On Sat, Jul 7, 2018 at 8:43 PM David Miller <davem@davemloft.net> wrote:
>
> From: Vlad Buslov <vladbu@mellanox.com>
> Date: Thu, 5 Jul 2018 17:24:22 +0300
>
> > Currently, all netlink protocol handlers for updating rules, actions and
> > qdiscs are protected with single global rtnl lock which removes any
> > possibility for parallelism. This patch set is a first step to remove
> > rtnl lock dependency from TC rules update path.
> ...
>
> I'll apply this for now, I reviewed it a few more times and I see
> where you are going with this.
Dear David,
I don't understand why you even believe the claim of lockless
updaters here, it at least should raise a red flag when you see any
kinda of this claim.
I know you don't trust me, how about thinking it in this way:
Why does RCU still require a lock for RCU writers? (Or at least
RCU recommends a lock, if anyone really wants to point out some
lockless algorithm here.)
or:
If writers could really go lockless as easily as Vlad claims, how could
even Paul E. McKenney never bring it into RCU?
Maybe Vlad is much cleverer than any of us here, and maybe he really
discovers a very brilliant algorithm to allow TC actions to be updated
locklessly, why not wait until he shows a proof (either code or a paper)?
Is there a rush? I don't see it.
In fact, I discussed this with Vlad a little bit at netdev TC workshop.
I never see any brilliant algorithm from him from his slides, and I was
told by him he used "copy and replace" to archive parallel updaters, I
told him that is basically how RCU works and RCU writers have to be
sync'ed with a lock (or at least recommended).
Also, to confirm my judgement, I checked this with Paul privately too.
Paul said you have to be extremely careful to go lockless, it is very hard
to be bug free for lockless, although he _never_ says it is impossible.
My _personal_ bet is that, lockless updates for TC filters or actions
are impossible unless there are more things hiding behind "copy and
replace", for example, some brilliant lockless algorithm. If lockless is
really impossible in this circumstance, then many of your efforts in
this patchset are vain, by the way.
I _do_ believe you can break RTNL down to per device, per filter or per
action, but no matter how small the locking scope is, there is still a lock.
With a lock, there is no need to make things friendly to lockless, like
making an integer increment inside an action to be atomic (your patch
02/11).
Please _do_ prove my personal judgement is wrong, by showing your
final code or a formal paper/article. I am very *happy* to be proved
to be wrong here, I am very open to change my mind here.
Vlad, we need your proof. Please prove I am wrong, seriously!!! :)
Thanks to anyone for proving me I am wrong just in case!!! :)
^ 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