* Re: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Dmitry Vyukov @ 2018-05-09 5:23 UTC (permalink / raw)
To: Eric Biggers
Cc: dccp, Gerrit Renker, syzbot, David Miller, Gustavo A . R . Silva,
LKML, netdev, syzkaller-bugs
In-Reply-To: <20180509050509.GE711@sol.localdomain>
On Wed, May 9, 2018 at 7:05 AM, Eric Biggers <ebiggers3@gmail.com> wrote:
> On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de47800000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
>> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde7800000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141b4be7800000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+99858724c0ba555a12ea@syzkaller.appspotmail.com
>>
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at
>> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
>> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> <IRQ>
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
>> net/dccp/ccids/lib/packet_history.c:422
>> ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
>> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
>> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
>> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
>> sk_backlog_rcv include/net/sock.h:909 [inline]
>> __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
>> dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
>> ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
>> NF_HOOK include/linux/netfilter.h:288 [inline]
>> ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
>> dst_input include/net/dst.h:450 [inline]
>> ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
>> NF_HOOK include/linux/netfilter.h:288 [inline]
>> ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
>> __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
>> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
>> process_backlog+0x219/0x760 net/core/dev.c:5337
>> napi_poll net/core/dev.c:5735 [inline]
>> net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
>> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
>> </IRQ>
>> do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
>> do_softirq arch/x86/include/asm/preempt.h:23 [inline]
>> __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
>> local_bh_enable include/linux/bottom_half.h:32 [inline]
>> rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
>> ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
>> ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
>> NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>> ip_output+0x21b/0x850 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
>> ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
>> dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
>> dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
>> dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
>> dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
>> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
>> sock_sendmsg_nosec net/socket.c:629 [inline]
>> sock_sendmsg+0xd5/0x120 net/socket.c:639
>> ___sys_sendmsg+0x525/0x940 net/socket.c:2117
>> __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
>> __do_sys_sendmmsg net/socket.c:2241 [inline]
>> __se_sys_sendmmsg net/socket.c:2238 [inline]
>> __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
>> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x445d09
>> RSP: 002b:00007f3c7eff5d88 EFLAGS: 00000293 ORIG_RAX: 0000000000000133
>> RAX: ffffffffffffffda RBX: 00000000006dac40 RCX: 0000000000445d09
>> RDX: 0000000000000001 RSI: 000000
>>
>>
>> ---
>> This bug is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>
> There's already a bug report with this title, this one just had a few characters
> truncated from the end. Dmitry, is that intentional? The other one is
> https://groups.google.com/forum/#!msg/syzkaller-bugs/u5nq3PdPkIc/bBFjKHXPAgAJ:
>
> #syz dup: BUG: please report to dc...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
I think this happened when we started truncating kernel crash titles
to 120 columns, so it's intentional.
However, the dup command did not pass. It's hard to understand who
received what today, but this suggests that somebody altered email in
the command to dc...@vger.kernel.org:
https://groups.google.com/forum/message/raw?msg=syzkaller-bugs/GMndq4-h7BI/VIz4aBEOAwAJ
We can also mark the old one as invalid.
> Anyway, this is apparently a DCCP bug, and as I posted on the other thread it's
> easily reproducible with the following program. Gerrit, are you still the DCCP
> maintainer, or is the MAINTAINERS file outdated?
>
> #include <linux/dccp.h>
> #include <linux/in.h>
> #include <sys/socket.h>
> #include <sys/wait.h>
> #include <unistd.h>
>
> int main()
> {
> struct sockaddr_in addr = { .sin_family = AF_INET };
> socklen_t addrlen = sizeof(addr);
> int fd;
>
> while (fork())
> wait(NULL);
> fd = socket(AF_INET, SOCK_DCCP, 0);
> bind(fd, (void *)&addr, addrlen);
> getsockname(fd, (void *)&addr, &addrlen);
> listen(fd, 100);
> if (fork()) {
> fd = socket(AF_INET, SOCK_DCCP, 0);
> setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_CCID, "\x03", 1);
> connect(fd, (void *)&addr, sizeof(addr));
> } else {
> fd = accept(fd, NULL, 0);
> }
> for (int i = 0; i < 1000; i++)
> write(fd, "X", 1);
> }
>
> - Eric
^ permalink raw reply
* Re: [PATCH] isdn: eicon: fix a missing-check bug
From: Wenwen Wang @ 2018-05-09 5:30 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Armin Schindler, Karsten Keil,
open list:ISDN SUBSYSTEM, open list
In-Reply-To: <1525548766-13017-1-git-send-email-wang6495@umn.edu>
Hello
Could you please review this patch? We need a confirmation because we
are working on an approaching deadline.
Thanks!
Wenwen
On Sat, May 5, 2018 at 2:32 PM, Wenwen Wang <wang6495@umn.edu> wrote:
> In divasmain.c, the function divas_write() firstly invokes the function
> diva_xdi_open_adapter() to open the adapter that matches with the adapter
> number provided by the user, and then invokes the function diva_xdi_write()
> to perform the write operation using the matched adapter. The two functions
> diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.
>
> In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
> from the userspace pointer 'src' through the function pointer 'cp_fn',
> which eventually calls copy_from_user() to do the copy. Then, the adapter
> number 'msg.adapter' is used to find out a matched adapter from the
> 'adapter_queue'. A matched adapter will be returned if it is found.
> Otherwise, NULL is returned to indicate the failure of the verification on
> the adapter number.
>
> As mentioned above, if a matched adapter is returned, the function
> diva_xdi_write() is invoked to perform the write operation. In this
> function, the user command is copied once again from the userspace pointer
> 'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
> both of them are from the 'buf' pointer in divas_write(). Similarly, the
> copy is achieved through the function pointer 'cp_fn', which finally calls
> copy_from_user(). After the successful copy, the corresponding command
> processing handler of the matched adapter is invoked to perform the write
> operation.
>
> It is obvious that there are two copies here from userspace, one is in
> diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
> these two copies share the same source userspace pointer, i.e., the 'buf'
> pointer in divas_write(). Given that a malicious userspace process can race
> to change the content pointed by the 'buf' pointer, this can pose potential
> security issues. For example, in the first copy, the user provides a valid
> adapter number to pass the verification process and a valid adapter can be
> found. Then the user can modify the adapter number to an invalid number.
> This way, the user can bypass the verification process of the adapter
> number and inject inconsistent data.
>
> To avoid such issues, this patch adds a check after the second copy in the
> function diva_xdi_write(). If the adapter number is not equal to the one
> obtained in the first copy, (-4) will be returned to divas_write(), which
> will then return an error code -EINVAL.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
> drivers/isdn/hardware/eicon/diva.c | 6 +++++-
> drivers/isdn/hardware/eicon/divasmain.c | 3 +++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/isdn/hardware/eicon/diva.c b/drivers/isdn/hardware/eicon/diva.c
> index 944a7f3..46cbf76 100644
> --- a/drivers/isdn/hardware/eicon/diva.c
> +++ b/drivers/isdn/hardware/eicon/diva.c
> @@ -440,6 +440,7 @@ diva_xdi_write(void *adapter, void *os_handle, const void __user *src,
> int length, divas_xdi_copy_from_user_fn_t cp_fn)
> {
> diva_os_xdi_adapter_t *a = (diva_os_xdi_adapter_t *) adapter;
> + diva_xdi_um_cfg_cmd_t *p;
> void *data;
>
> if (a->xdi_mbox.status & DIVA_XDI_MBOX_BUSY) {
> @@ -461,7 +462,10 @@ diva_xdi_write(void *adapter, void *os_handle, const void __user *src,
>
> length = (*cp_fn) (os_handle, data, src, length);
> if (length > 0) {
> - if ((*(a->interface.cmd_proc))
> + p = (diva_xdi_um_cfg_cmd_t *) data;
> + if (a->controller != (int)p->adapter) {
> + length = -4;
> + } else if ((*(a->interface.cmd_proc))
> (a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
> length = -3;
> }
> diff --git a/drivers/isdn/hardware/eicon/divasmain.c b/drivers/isdn/hardware/eicon/divasmain.c
> index b9980e8..a03c658 100644
> --- a/drivers/isdn/hardware/eicon/divasmain.c
> +++ b/drivers/isdn/hardware/eicon/divasmain.c
> @@ -614,6 +614,9 @@ static ssize_t divas_write(struct file *file, const char __user *buf,
> case -3:
> ret = -ENXIO;
> break;
> + case -4:
> + ret = -EINVAL;
> + break;
> }
> DBG_TRC(("write: ret %d", ret));
> return (ret);
> --
> 2.7.4
>
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Eric Biggers @ 2018-05-09 5:40 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: dccp, Gerrit Renker, syzbot, David Miller, Gustavo A . R . Silva,
LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+b7A89ZbBUktiDjBRAtedQHMO2pZqcB4QJSM8vG8NgkGw@mail.gmail.com>
On Wed, May 09, 2018 at 07:23:41AM +0200, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> On Wed, May 9, 2018 at 7:05 AM, Eric Biggers <ebiggers3@gmail.com> wrote:
> > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
> >> git tree: upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de47800000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde7800000
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141b4be7800000
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+99858724c0ba555a12ea@syzkaller.appspotmail.com
> >>
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at
> >> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> >> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> <IRQ>
> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> >> net/dccp/ccids/lib/packet_history.c:422
> >> ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
> >> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> >> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> >> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> >> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
> >> sk_backlog_rcv include/net/sock.h:909 [inline]
> >> __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
> >> dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
> >> ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
> >> NF_HOOK include/linux/netfilter.h:288 [inline]
> >> ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
> >> dst_input include/net/dst.h:450 [inline]
> >> ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
> >> NF_HOOK include/linux/netfilter.h:288 [inline]
> >> ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
> >> __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> >> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> >> process_backlog+0x219/0x760 net/core/dev.c:5337
> >> napi_poll net/core/dev.c:5735 [inline]
> >> net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> >> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> >> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
> >> </IRQ>
> >> do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
> >> do_softirq arch/x86/include/asm/preempt.h:23 [inline]
> >> __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
> >> local_bh_enable include/linux/bottom_half.h:32 [inline]
> >> rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
> >> ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
> >> ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
> >> NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> >> ip_output+0x21b/0x850 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
> >> ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
> >> dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
> >> dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
> >> dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
> >> dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
> >> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> >> sock_sendmsg_nosec net/socket.c:629 [inline]
> >> sock_sendmsg+0xd5/0x120 net/socket.c:639
> >> ___sys_sendmsg+0x525/0x940 net/socket.c:2117
> >> __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
> >> __do_sys_sendmmsg net/socket.c:2241 [inline]
> >> __se_sys_sendmmsg net/socket.c:2238 [inline]
> >> __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
> >> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> >> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >> RIP: 0033:0x445d09
> >> RSP: 002b:00007f3c7eff5d88 EFLAGS: 00000293 ORIG_RAX: 0000000000000133
> >> RAX: ffffffffffffffda RBX: 00000000006dac40 RCX: 0000000000445d09
> >> RDX: 0000000000000001 RSI: 000000
> >>
> >>
> >> ---
> >> This bug is generated by a bot. It may contain errors.
> >> See https://goo.gl/tpsmEJ for more information about syzbot.
> >> syzbot engineers can be reached at syzkaller@googlegroups.com.
> >>
> >> syzbot will keep track of this bug report.
> >> If you forgot to add the Reported-by tag, once the fix for this bug is
> >> merged
> >> into any tree, please reply to this email with:
> >> #syz fix: exact-commit-title
> >> If you want to test a patch for this bug, please reply with:
> >> #syz test: git://repo/address.git branch
> >> and provide the patch inline or as an attachment.
> >> To mark this as a duplicate of another syzbot report, please reply with:
> >> #syz dup: exact-subject-of-another-report
> >
> > There's already a bug report with this title, this one just had a few characters
> > truncated from the end. Dmitry, is that intentional? The other one is
> > https://groups.google.com/forum/#!msg/syzkaller-bugs/u5nq3PdPkIc/bBFjKHXPAgAJ:
> >
> > #syz dup: BUG: please report to dc...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
>
> I think this happened when we started truncating kernel crash titles
> to 120 columns, so it's intentional.
> However, the dup command did not pass. It's hard to understand who
> received what today, but this suggests that somebody altered email in
> the command to dc...@vger.kernel.org:
> https://groups.google.com/forum/message/raw?msg=syzkaller-bugs/GMndq4-h7BI/VIz4aBEOAwAJ
> We can also mark the old one as invalid.
>
Ah, that was my fault -- I must have copied the bug title from the
syzkaller-bugs Google Groups page, which had mangled the email address in the
bug title. The actual title was:
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
^ permalink raw reply
* Re: linux-next: manual merge of the bpf-next tree with the s390 tree
From: Daniel Borkmann @ 2018-05-09 6:31 UTC (permalink / raw)
To: Stephen Rothwell, Networking, Martin Schwidefsky, Heiko Carstens,
David Miller
Cc: Alexei Starovoitov, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <20180509142154.73ff5772@canb.auug.org.au>
On 05/09/2018 06:21 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 8 May 2018 10:26:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the bpf-next tree got a conflict in:
>>
>> arch/s390/net/bpf_jit.S
>>
>> between commit:
>>
>> de5cb6eb514e ("s390: use expoline thunks in the BPF JIT")
>>
>> from the s390 tree and commit:
>>
>> e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")
>>
>> from the bpf-next tree.
>>
>> I fixed it up (I just removed the file as the latter does) and can
>> carry the fix as necessary. This is now fixed as far as linux-next is
>> concerned, but any non trivial conflicts should be mentioned to your
>> upstream maintainer when your tree is submitted for merging. You may
>> also want to consider cooperating with the maintainer of the conflicting
>> tree to minimise any particularly complex conflicts.
>
> This is now a conflict between the net-next and s390 trees.
Right, bpf-next merged as usual into net-next two days ago; so same
resolution applies.
^ permalink raw reply
* Re: [PATCH] isdn: eicon: fix a missing-check bug
From: Tobin C. Harding @ 2018-05-09 6:48 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Armin Schindler, Karsten Keil,
open list:ISDN SUBSYSTEM, open list
In-Reply-To: <CAAa=b7dm5zLsDHB69sNPvFkWwOjF6UV-pekEFmgrtKNod-XYSg@mail.gmail.com>
On Wed, May 09, 2018 at 12:30:18AM -0500, Wenwen Wang wrote:
> Hello
>
> Could you please review this patch? We need a confirmation because we
> are working on an approaching deadline.
I didn't know 'we' had deadlines :)
Tobin
^ permalink raw reply
* [PATCH net] tun: fix use after free for ptr_ring
From: Jason Wang @ 2018-05-09 6:59 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Jason Wang, Eric Dumazet, Cong Wang, Michael S . Tsirkin
We used to initialize ptr_ring during TUNSETIFF, this is because its
size depends on the tx_queue_len of netdevice. And we try to clean it
up when socket were detached from netdevice. A race were spotted when
trying to do uninit during a read which will lead a use after free for
pointer ring. Solving this by always initialize a zero size ptr_ring
in open() and do resizing during TUNSETIFF, and then we can safely do
cleanup during close(). With this, there's no need for the workaround
that was introduced by commit 4df0bfc79904 ("tun: fix a memory leak
for tfile->tx_array").
Reported-by: syzbot+e8b902c3c3fadf0a9dba@syzkaller.appspotmail.com
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ef33950..298cb96 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -681,15 +681,6 @@ static void tun_queue_purge(struct tun_file *tfile)
skb_queue_purge(&tfile->sk.sk_error_queue);
}
-static void tun_cleanup_tx_ring(struct tun_file *tfile)
-{
- if (tfile->tx_ring.queue) {
- ptr_ring_cleanup(&tfile->tx_ring, tun_ptr_free);
- xdp_rxq_info_unreg(&tfile->xdp_rxq);
- memset(&tfile->tx_ring, 0, sizeof(tfile->tx_ring));
- }
-}
-
static void __tun_detach(struct tun_file *tfile, bool clean)
{
struct tun_file *ntfile;
@@ -736,7 +727,8 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
tun->dev->reg_state == NETREG_REGISTERED)
unregister_netdevice(tun->dev);
}
- tun_cleanup_tx_ring(tfile);
+ if (tun)
+ xdp_rxq_info_unreg(&tfile->xdp_rxq);
sock_put(&tfile->sk);
}
}
@@ -783,14 +775,14 @@ static void tun_detach_all(struct net_device *dev)
tun_napi_del(tun, tfile);
/* Drop read queue */
tun_queue_purge(tfile);
+ xdp_rxq_info_unreg(&tfile->xdp_rxq);
sock_put(&tfile->sk);
- tun_cleanup_tx_ring(tfile);
}
list_for_each_entry_safe(tfile, tmp, &tun->disabled, next) {
tun_enable_queue(tfile);
tun_queue_purge(tfile);
+ xdp_rxq_info_unreg(&tfile->xdp_rxq);
sock_put(&tfile->sk);
- tun_cleanup_tx_ring(tfile);
}
BUG_ON(tun->numdisabled != 0);
@@ -834,7 +826,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file,
}
if (!tfile->detached &&
- ptr_ring_init(&tfile->tx_ring, dev->tx_queue_len, GFP_KERNEL)) {
+ ptr_ring_resize(&tfile->tx_ring, dev->tx_queue_len,
+ GFP_KERNEL, __skb_array_destroy_skb)) {
err = -ENOMEM;
goto out;
}
@@ -3219,6 +3212,11 @@ static int tun_chr_open(struct inode *inode, struct file * file)
&tun_proto, 0);
if (!tfile)
return -ENOMEM;
+ if (ptr_ring_init(&tfile->tx_ring, 0, GFP_KERNEL)) {
+ sk_free(&tfile->sk);
+ return -ENOMEM;
+ }
+
RCU_INIT_POINTER(tfile->tun, NULL);
tfile->flags = 0;
tfile->ifindex = 0;
@@ -3239,8 +3237,6 @@ static int tun_chr_open(struct inode *inode, struct file * file)
sock_set_flag(&tfile->sk, SOCK_ZEROCOPY);
- memset(&tfile->tx_ring, 0, sizeof(tfile->tx_ring));
-
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: Failed to clone net-next.git
From: Michal Kubecek @ 2018-05-09 7:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, songliubraving, ast, konstantin
In-Reply-To: <20180508.200442.76151477268117595.davem@davemloft.net>
On Tue, May 08, 2018 at 08:04:42PM -0400, David Miller wrote:
> From: Song Liu <songliubraving@fb.com>
> Date: Tue, 8 May 2018 17:46:23 +0000
>
> > We are seeing the following error on multiple different systems while
> > cloning net-next tree.
> >
> > $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> > Cloning into 'net-next'...
>
> Regardless of the failure, it is so _insanely_ wasteful to clone my
> trees like this.
>
> Just simply always have Linus's tree always checked out somewhere:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> Let's say you have it under src/GIT/linux as I do.
>
> Then go to src/GIT and say:
>
> git clone --reference linux/.git https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>
> This way it only downloads the objects that are unique to the net-next
> tree. Similarly for 'net':
>
> git clone --reference linux/.git https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>
> Or any other subsystem tree.
>
> Periodically "git pull --ff-only" your Linus's tree, and you'll be
> much happier in GIT land :-)
>
> As subsystem changes make their way into Linus's GIT tree, git will
> notice over time and garbage collect the dups that are in your
> subsystem GIT trees.
With reasonably recent git (>= 2.5), another option worth considering is
using worktrees:
cd /src/GIT/linux
git remote add --no-tags net-next git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
git branch --track net-next net-next/master
git worktree add ../net-next net-next
It works well for me, the only limitation to keep in mind is that you
cannot have the same branch checked out in two different worktrees at
the same time.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH net-next] tun: Do SIOCGSKNS out of rtnl_lock()
From: Jason Wang @ 2018-05-09 7:18 UTC (permalink / raw)
To: Kirill Tkhai, davem, edumazet, mst, brouer, peterpenkov96, sd,
netdev
In-Reply-To: <152579647246.21100.10461408116587658568.stgit@localhost.localdomain>
On 2018年05月09日 00:21, Kirill Tkhai wrote:
> Since net ns of tun device is assigned on the device creation,
> and it never changes, we do not need to use any lock to get it
> from alive tun.
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
> ---
> drivers/net/tun.c | 18 +++++++-----------
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index d3c04ab9752a..44d4f3d25350 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -2850,10 +2850,10 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg, int ifreq_len)
> {
> struct tun_file *tfile = file->private_data;
> + struct net *net = sock_net(&tfile->sk);
> struct tun_struct *tun;
> void __user* argp = (void __user*)arg;
> struct ifreq ifr;
> - struct net *net;
> kuid_t owner;
> kgid_t group;
> int sndbuf;
> @@ -2877,14 +2877,18 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
> */
> return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
> (unsigned int __user*)argp);
> - } else if (cmd == TUNSETQUEUE)
> + } else if (cmd == TUNSETQUEUE) {
> return tun_set_queue(file, &ifr);
> + } else if (cmd == SIOCGSKNS) {
Not for this patch, reusing socket ioctl cmd is probably not good though
they were probably not intersected (see ioctl-number.txt). We probably
need to introduce TUN specific ioctls for SIOCGSKNS and SIOCGIFHWADDR
and warn for socket ones.
Thanks
> + if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> + return -EPERM;
> + return open_related_ns(&net->ns, get_net_ns);
> + }
>
> ret = 0;
> rtnl_lock();
>
> tun = tun_get(tfile);
> - net = sock_net(&tfile->sk);
> if (cmd == TUNSETIFF) {
> ret = -EEXIST;
> if (tun)
> @@ -2914,14 +2918,6 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
> tfile->ifindex = ifindex;
> goto unlock;
> }
> - if (cmd == SIOCGSKNS) {
> - ret = -EPERM;
> - if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> - goto unlock;
> -
> - ret = open_related_ns(&net->ns, get_net_ns);
> - goto unlock;
> - }
>
> ret = -EBADFD;
> if (!tun)
>
^ permalink raw reply
* [PATCH net] nfp: flower: remove headroom from max MTU calculation
From: Jakub Kicinski @ 2018-05-09 7:18 UTC (permalink / raw)
To: davem; +Cc: oss-drivers, netdev, Pieter Jansen van Vuuren
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Since commit 29a5dcae2790 ("nfp: flower: offload phys port MTU change") we
take encapsulation headroom into account when calculating the max allowed
MTU. This is unnecessary as the max MTU advertised by firmware should have
already accounted for encap headroom.
Subtracting headroom twice brings the max MTU below what's necessary for
some deployments.
Fixes: 29a5dcae2790 ("nfp: flower: offload phys port MTU change")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
.../net/ethernet/netronome/nfp/flower/main.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c
index a997e34bcec2..84e3b9f5abb1 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.c
@@ -52,8 +52,6 @@
#define NFP_FLOWER_ALLOWED_VER 0x0001000000010000UL
-#define NFP_FLOWER_FRAME_HEADROOM 158
-
static const char *nfp_flower_extra_cap(struct nfp_app *app, struct nfp_net *nn)
{
return "FLOWER";
@@ -559,22 +557,6 @@ static void nfp_flower_clean(struct nfp_app *app)
app->priv = NULL;
}
-static int
-nfp_flower_check_mtu(struct nfp_app *app, struct net_device *netdev,
- int new_mtu)
-{
- /* The flower fw reserves NFP_FLOWER_FRAME_HEADROOM bytes of the
- * supported max MTU to allow for appending tunnel headers. To prevent
- * unexpected behaviour this needs to be accounted for.
- */
- if (new_mtu > netdev->max_mtu - NFP_FLOWER_FRAME_HEADROOM) {
- nfp_err(app->cpp, "New MTU (%d) is not valid\n", new_mtu);
- return -EINVAL;
- }
-
- return 0;
-}
-
static bool nfp_flower_check_ack(struct nfp_flower_priv *app_priv)
{
bool ret;
@@ -656,7 +638,6 @@ const struct nfp_app_type app_flower = {
.init = nfp_flower_init,
.clean = nfp_flower_clean,
- .check_mtu = nfp_flower_check_mtu,
.repr_change_mtu = nfp_flower_repr_change_mtu,
.vnic_alloc = nfp_flower_vnic_alloc,
--
2.17.0
^ permalink raw reply related
* Re: pull-request: ieee802154 2018-05-08
From: Stefan Schmidt @ 2018-05-09 7:31 UTC (permalink / raw)
To: David Miller; +Cc: s.schmidt, linux-wpan, alex.aring, netdev
In-Reply-To: <20180508.200638.1908252284342544792.davem@davemloft.net>
Hello.
On 05/09/2018 02:06 AM, David Miller wrote:
> From: Stefan Schmidt <stefan@osg.samsung.com>
> Date: Tue, 8 May 2018 21:55:37 +0200
>
>> On 05/08/2018 04:18 PM, David Miller wrote:
>>> Please submit the -stable fix directly, you can feel free to CC: me.
>> Will do when the patch hits Linus git tree.
>>
>> I have a quick question on the process here. From the netdev-faq document
>> I was under the impression all stable patches under net/ and drivers/net
>> should be brought up to you and would be handled by you.
>>
>> Does this apply to the core part of net (I fully understand that ieee802154
>> is rather a niche) or is there some other reason for this exception?
>>
>> Both processes (the normal stable one as well as the slightly different one
>> for net/) would be fine to go with for me. Just need to know which one I
>> should use for future stable patches. :-)
>>
>> regards
>> Stefan Schmidt
> Generally wireless and ipsec have been submitting them directly,
> sometimes the Intel ethernet guys do too.
>
> Sometimes this makes things easier for me, and I'll ask you to submit
> things directly when that is the case like right now.
Thanks for taking the time to explain it. I will go ahead and handle
the stable patches for ieee802154 directly from now on. If you want
to have this changed again just let me know.
regards
Stefan Schmidt
^ permalink raw reply
* Re: KASAN: use-after-free Read in __dev_queue_xmit
From: Eric Biggers @ 2018-05-09 7:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, syzbot, alexander.deucher, Andrey Konovalov,
Anoob Soman, chris, David Miller, elena.reshetova,
Greg Kroah-Hartman, Kees Cook, LKML, Mike Maloney, mchehab,
netdev, rami.rosen, Sowmini Varadhan, syzkaller-bugs,
Willem de Bruijn
In-Reply-To: <1515048794.131759.4.camel@gmail.com>
On Wed, Jan 03, 2018 at 10:53:14PM -0800, Eric Dumazet wrote:
> On Wed, 2018-01-03 at 21:13 -0800, Eric Dumazet wrote:
> > Note: all commands must start from beginning of the line in the email body.
> >
> > I guess skb_probe_transport_header() should be hardened to reject malicious
> > packets given by user space, instead of being gentle.
>
> Although bug triggered for this particular repro is in flow dissector
> :/
>
> I will test :
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 15ce300637650e17fcab7e378b20fe7972686d46..544bddf08e13c7f6e47aadc737244c9ba5af56b2 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -976,8 +976,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> out_good:
> ret = true;
>
> - key_control->thoff = (u16)nhoff;
> out:
> + key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> key_basic->n_proto = proto;
> key_basic->ip_proto = ip_proto;
>
> @@ -985,7 +985,6 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>
> out_bad:
> ret = false;
> - key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> goto out;
> }
> EXPORT_SYMBOL(__skb_flow_dissect);
Fix for this was commit d0c081b49137cd:
#syz fix: flow_dissector: properly cap thoff field
But a crash with the same signature is still occurring, so it should eventually
get reported again. C reproducer is here, it works on Linus' tree (commit
036db8bd963): https://syzkaller.appspot.com/text?tag=ReproC&x=105b1ae7800000
- Eric
^ permalink raw reply
* Re: [bpf-next v2 8/9] bpf: Provide helper to do forwarding lookups in kernel FIB table
From: Daniel Borkmann @ 2018-05-09 8:15 UTC (permalink / raw)
To: David Ahern, netdev, borkmann, ast
Cc: davem, shm, roopa, brouer, toke, john.fastabend
In-Reply-To: <20180504025432.23451-9-dsahern@gmail.com>
On 05/04/2018 04:54 AM, David Ahern wrote:
> Provide a helper for doing a FIB and neighbor lookup in the kernel
> tables from an XDP program. The helper provides a fastpath for forwarding
> packets. If the packet is a local delivery or for any reason is not a
> simple lookup and forward, the packet continues up the stack.
>
> If it is to be forwarded, the forwarding can be done directly if the
> neighbor is already known. If the neighbor does not exist, the first
> few packets go up the stack for neighbor resolution. Once resolved, the
> xdp program provides the fast path.
>
> On successful lookup the nexthop dmac, current device smac and egress
> device index are returned.
>
> The API supports IPv4, IPv6 and MPLS protocols, but only IPv4 and IPv6
> are implemented in this patch. The API includes layer 4 parameters if
> the XDP program chooses to do deep packet inspection to allow compare
> against ACLs implemented as FIB rules.
>
> Header rewrite is left to the XDP program.
>
> The lookup takes 2 flags:
> - BPF_FIB_LOOKUP_DIRECT to do a lookup that bypasses FIB rules and goes
> straight to the table associated with the device (expert setting for
> those looking to maximize throughput)
>
> - BPF_FIB_LOOKUP_OUTPUT to do a lookup from the egress perspective.
> Default is an ingress lookup.
>
> Initial performance numbers collected by Jesper, forwarded packets/sec:
>
> Full stack XDP FIB lookup XDP Direct lookup
> IPv4 1,947,969 7,074,156 7,415,333
> IPv6 1,728,000 6,165,504 7,262,720
>
> These number are single CPU core forwarding on a Broadwell
> E5-1650 v4 @ 3.60GHz.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Ohh well, this is causing allmodconfig build warnings (e.g. on x86) as reported today:
In file included from include/linux/dma-mapping.h:5:0,
from include/linux/skbuff.h:34,
from include/linux/if_ether.h:23,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/perf_event.h:57,
from include/linux/trace_events.h:10,
from include/trace/trace_events.h:20,
from include/trace/define_trace.h:96,
from drivers/android/binder_trace.h:387,
from drivers/android/binder.c:5702:
include/linux/sizes.h:24:0: warning: "SZ_1K" redefined
#define SZ_1K 0x00000400
drivers/android/binder.c:116:0: note: this is the location of the previous definition
#define SZ_1K 0x400
In file included from include/linux/dma-mapping.h:5:0,
from include/linux/skbuff.h:34,
from include/linux/if_ether.h:23,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/perf_event.h:57,
from include/linux/trace_events.h:10,
from include/trace/trace_events.h:20,
from include/trace/define_trace.h:96,
from drivers/android/binder_trace.h:387,
from drivers/android/binder.c:5702:
include/linux/sizes.h:37:0: warning: "SZ_4M" redefined
#define SZ_4M 0x00400000
drivers/android/binder.c:120:0: note: this is the location of the previous definition
#define SZ_4M 0x400000
fs/ecryptfs/miscdev.c:206:0: warning: "PKT_TYPE_OFFSET" redefined
#define PKT_TYPE_OFFSET 0
In file included from include/linux/if_ether.h:23:0,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/writeback.h:183,
from include/linux/backing-dev.h:16,
from fs/ecryptfs/ecryptfs_kernel.h:41,
from fs/ecryptfs/miscdev.c:30:
include/linux/skbuff.h:753:0: note: this is the location of the previous definition
#define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)
Lets get a clean, proper version of the whole series into bpf-next. I've dropped it
from there right now and waiting for your v3 respin to apply with the above fixed.
Thank you.
^ permalink raw reply
* [PATCH v2] hv_netvsc: Fix net device attach on older Windows hosts
From: Mohammed Gamal @ 2018-05-09 8:17 UTC (permalink / raw)
To: netdev, sthemmin; +Cc: Mohammed Gamal, haiyangz, linux-kernel, devel, vkuznets
On older windows hosts the net_device instance is returned to
the caller of rndis_filter_device_add() without having the presence
bit set first. This would cause any subsequent calls to network device
operations (e.g. MTU change, channel change) to fail after the device
is detached once, returning -ENODEV.
Instead of returning the device instabce, we take the exit path where
we call netif_device_attach()
Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/rndis_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 6b127be..e7ca5b5 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1288,7 +1288,7 @@ struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
rndis_device->link_state ? "down" : "up");
if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
- return net_device;
+ goto out;
rndis_filter_query_link_speed(rndis_device, net_device);
--
1.8.3.1
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Anders Roxell @ 2018-05-09 8:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <20180509141908.7b07df43@canb.auug.org.au>
On 9 May 2018 at 06:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> tools/testing/selftests/net/Makefile
>
> between commit:
>
> 1751eb42ddb5 ("selftests: net: use TEST_PROGS_EXTENDED")
>
> from the net tree and commits:
>
> a7b15ab887e5 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc tools/testing/selftests/net/Makefile
> index 3ff81a478dbe,73af45773938..000000000000
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@@ -5,10 -5,13 +5,13 @@@ CFLAGS = -Wall -Wl,--no-as-needed -O2
> CFLAGS += -I../../../../usr/include/
>
> TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
> - TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
> + TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
in_netns.sh shouldn't be in the above list, its already in the
TEST_PROGS_EXTENDED below.
Cheers,
Anders
> + TEST_PROGS += udpgso_bench.sh
> -TEST_GEN_PROGS_EXTENDED := in_netns.sh
> +TEST_PROGS_EXTENDED := in_netns.sh
> TEST_GEN_FILES = socket
> TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
> + TEST_GEN_FILES += tcp_mmap tcp_inq
> + TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx
> TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
> TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
>
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: fix added_by_user switchdev notification
From: Petr Machata @ 2018-05-09 8:54 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, jiri, idosch, ivecera, davem,
stephen, andrew, f.fainelli, nikolay, bridge
In-Reply-To: <20180509030312.29548-1-vivien.didelot@savoirfairelinux.com>
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> @petr I expect the same issue with Rocker, but I haven't tested it.
Yeah, pretty sure. Such an obvious bug, sorry about that :-/
I'll send a rocker patch later today.
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH net-next] tun: Do SIOCGSKNS out of rtnl_lock()
From: Kirill Tkhai @ 2018-05-09 9:00 UTC (permalink / raw)
To: Jason Wang, davem, edumazet, mst, brouer, peterpenkov96, sd,
netdev
In-Reply-To: <06a89506-2d3c-a0dd-3ac2-2c517683517e@redhat.com>
Hi, Jason,
On 09.05.2018 10:18, Jason Wang wrote:
>
>
> On 2018年05月09日 00:21, Kirill Tkhai wrote:
>> Since net ns of tun device is assigned on the device creation,
>> and it never changes, we do not need to use any lock to get it
>> from alive tun.
>>
>> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
>> ---
>> drivers/net/tun.c | 18 +++++++-----------
>> 1 file changed, 7 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index d3c04ab9752a..44d4f3d25350 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -2850,10 +2850,10 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>> unsigned long arg, int ifreq_len)
>> {
>> struct tun_file *tfile = file->private_data;
>> + struct net *net = sock_net(&tfile->sk);
>> struct tun_struct *tun;
>> void __user* argp = (void __user*)arg;
>> struct ifreq ifr;
>> - struct net *net;
>> kuid_t owner;
>> kgid_t group;
>> int sndbuf;
>> @@ -2877,14 +2877,18 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>> */
>> return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
>> (unsigned int __user*)argp);
>> - } else if (cmd == TUNSETQUEUE)
>> + } else if (cmd == TUNSETQUEUE) {
>> return tun_set_queue(file, &ifr);
>> + } else if (cmd == SIOCGSKNS) {
>
> Not for this patch, reusing socket ioctl cmd is probably not good though they were probably not intersected (see ioctl-number.txt). We probably need to introduce TUN specific ioctls for SIOCGSKNS and SIOCGIFHWADDR and warn for socket ones.
The most of socket ioctl cmds use 0x8900 type:
#define SOCK_IOC_TYPE 0x89
while tun cmd is 5400 ('T'). They should not intersect.
The only exceptions are
#define SIOCINQ FIONREAD
#define SIOCOUTQ TIOCOUTQ
#define TIOCOUTQ 0x5411
#define FIONREAD 0x541B
But they can't intersect even with exceptions, since tun nr starts from 200:
#define TUNSETNOCSUM _IOW('T', 200, int)
and 200 > 0x1b (==27).
I implemented SIOCGSKNS cmd in the same style as older socket cmds were used.
I'm not sure, we can remove existing SIOCGIFHWADDR, since they are already used.
If we add a warn, which time will we able to remove them? Some old software may
use it, and in case of the program isn't developed any more, nobody can fix this
warnings, even if he/she sees them..
Kirill
>
>> + if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
>> + return -EPERM;
>> + return open_related_ns(&net->ns, get_net_ns);
>> + }
>> ret = 0;
>> rtnl_lock();
>> tun = tun_get(tfile);
>> - net = sock_net(&tfile->sk);
>> if (cmd == TUNSETIFF) {
>> ret = -EEXIST;
>> if (tun)
>> @@ -2914,14 +2918,6 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>> tfile->ifindex = ifindex;
>> goto unlock;
>> }
>> - if (cmd == SIOCGSKNS) {
>> - ret = -EPERM;
>> - if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
>> - goto unlock;
>> -
>> - ret = open_related_ns(&net->ns, get_net_ns);
>> - goto unlock;
>> - }
>> ret = -EBADFD;
>> if (!tun)
>>
>
^ permalink raw reply
* [PATCH] net/9p: fix spelling mistake: "suspsend" -> "suspend"
From: Colin King @ 2018-05-09 9:48 UTC (permalink / raw)
To: Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David S . Miller, v9fs-developer, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in dev_warn message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/9p/trans_xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 086a4abdfa7c..0f19960390a6 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -485,7 +485,7 @@ static int xen_9pfs_front_probe(struct xenbus_device *dev,
static int xen_9pfs_front_resume(struct xenbus_device *dev)
{
- dev_warn(&dev->dev, "suspsend/resume unsupported\n");
+ dev_warn(&dev->dev, "suspend/resume unsupported\n");
return 0;
}
--
2.17.0
^ permalink raw reply related
* [PATCH net] ipv4: reset fnhe_mtu_locked after cache route flushed
From: Hangbin Liu @ 2018-05-09 10:06 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Stefano Brivio, Hangbin Liu
After route cache is flushed via ipv4_sysctl_rtcache_flush(), we forget
to reset fnhe_mtu_locked in rt_bind_exception(). When pmtu is updated
in __ip_rt_update_pmtu(), it will return directly since the pmtu is
still locked. e.g.
+ ip netns exec client ping 10.10.1.1 -c 1 -s 1400 -M do
PING 10.10.1.1 (10.10.1.1) 1400(1428) bytes of data.
>From 10.10.0.254 icmp_seq=1 Frag needed and DF set (mtu = 0)
--- 10.10.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
+ ip netns exec client ip route get 10.10.1.1
10.10.1.1 via 10.10.0.254 dev veth0_c src 10.10.0.1 uid 0
cache expires 599sec mtu lock 552
+ ip netns exec client ip route flush cache
+ ip netns exec client ip route get 10.10.1.1
10.10.1.1 via 10.10.0.254 dev veth0_c src 10.10.0.1 uid 0
cache
+ ip netns exec client ping 10.10.1.1 -c 1 -s 1400 -M do
PING 10.10.1.1 (10.10.1.1) 1400(1428) bytes of data.
ping: local error: Message too long, mtu=576
--- 10.10.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
+ ip netns exec client ip route get 10.10.1.1
10.10.1.1 via 10.10.0.254 dev veth0_c src 10.10.0.1 uid 0
cache
Fixes: d52e5a7e7ca49 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu")
Reported-by: Jianlin Shi <jishi@redhat.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv4/route.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 1412a7b..29268ef 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1375,6 +1375,7 @@ static bool rt_bind_exception(struct rtable *rt, struct fib_nh_exception *fnhe,
fnhe->fnhe_gw = 0;
fnhe->fnhe_pmtu = 0;
fnhe->fnhe_expires = 0;
+ fnhe->fnhe_mtu_locked = false;
fnhe_flush_routes(fnhe);
orig = NULL;
}
--
2.5.5
^ permalink raw reply related
* Re: mwifiex: delete unneeded include
From: Kalle Valo @ 2018-05-09 10:25 UTC (permalink / raw)
To: Julia Lawall
Cc: Amitkumar Karwar, kernel-janitors, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <1525593233-10968-1-git-send-email-Julia.Lawall@lip6.fr>
Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> Nothing that is defined in 11ac.h is referenced in cmdevt.c.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Patch applied to wireless-drivers-next.git, thanks.
4793e5a954fa mwifiex: delete unneeded include
--
https://patchwork.kernel.org/patch/10382667/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Tariq Toukan @ 2018-05-09 10:31 UTC (permalink / raw)
To: Christophe JAILLET, davem, tariqt
Cc: netdev, linux-rdma, linux-kernel, kernel-janitors
In-Reply-To: <20180508093426.11550-1-christophe.jaillet@wanadoo.fr>
On 08/05/2018 12:34 PM, Christophe JAILLET wrote:
> If the 2nd memory allocation of the loop fails, we must undo the
> memory allocation done so far.
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index e0adac4a9a19..bf078244e467 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -3331,7 +3331,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> if (!priv->tx_cq[t]) {
> kfree(priv->tx_ring[t]);
> err = -ENOMEM;
> - goto out;
> + goto err_free_tx;
> }
> }
> priv->rx_ring_num = prof->rx_ring_num;
>
Hi Christophe,
Thanks for re-sending this.
In your previous mail you referred to the call mlx4_en_destroy_netdev here:
https://elixir.bootlin.com/linux/v4.16-rc5/source/drivers/net/ethernet/mellanox/mlx4/en_main.c#L232
While I was referring to the one below, which is always called on failures:
https://elixir.bootlin.com/linux/v4.16-rc5/source/drivers/net/ethernet/mellanox/mlx4/en_netdev.c#L3587
I still believe that the err_free_tx label and its while loop is redundant.
Regards,
Tariq
^ permalink raw reply
* [PATCH net] udp: fix SO_BINDTODEVICE
From: Paolo Abeni @ 2018-05-09 10:42 UTC (permalink / raw)
To: netdev; +Cc: Damir Mansurov, David Ahern, David Miller
Damir reported a breakage of SO_BINDTODEVICE for UDP sockets.
In absence of VRF devices, after commit fb74c27735f0 ("net:
ipv4: add second dif to udp socket lookups") the dif mismatch
isn't fatal anymore for UDP socket lookup with non null
sk_bound_dev_if, breaking SO_BINDTODEVICE semantics.
This changeset addresses the issue making the dif match mandatory
again in the above scenario.
Reported-by: Damir Mansurov <dnman@oktetlabs.ru>
Fixes: fb74c27735f0 ("net: ipv4: add second dif to udp socket lookups")
Fixes: 1801b570dd2a ("net: ipv6: add second dif to udp socket lookups")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv4/udp.c | 4 ++--
net/ipv6/udp.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 24b5c59b1c53..c2a292dfd137 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -401,9 +401,9 @@ static int compute_score(struct sock *sk, struct net *net,
bool dev_match = (sk->sk_bound_dev_if == dif ||
sk->sk_bound_dev_if == sdif);
- if (exact_dif && !dev_match)
+ if (!dev_match)
return -1;
- if (sk->sk_bound_dev_if && dev_match)
+ if (sk->sk_bound_dev_if)
score += 4;
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 4ec76a87aeb8..ea0730028e5d 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -148,9 +148,9 @@ static int compute_score(struct sock *sk, struct net *net,
bool dev_match = (sk->sk_bound_dev_if == dif ||
sk->sk_bound_dev_if == sdif);
- if (exact_dif && !dev_match)
+ if (!dev_match)
return -1;
- if (sk->sk_bound_dev_if && dev_match)
+ if (sk->sk_bound_dev_if)
score++;
}
--
2.14.3
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2018-05-09 10:44 UTC (permalink / raw)
To: Anders Roxell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CADYN=9JYJVVKyrPexNKNkbNjNBr1B3Xeuf6-wpdpE9+Px1UF9g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi Anders,
On Wed, 9 May 2018 10:24:49 +0200 Anders Roxell <anders.roxell@linaro.org> wrote:
>
> On 9 May 2018 at 06:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
> > - TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
> > + TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
>
> in_netns.sh shouldn't be in the above list, its already in the
> TEST_PROGS_EXTENDED below.
Thanks for that, I have fixed up my merge resolution for tomorrow.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] drivers: net: davinci_mdio: prevent sprious timeout
From: Sekhar Nori @ 2018-05-09 10:44 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Grygorii Strashko, David S . Miller, linux-omap, netdev
In-Reply-To: <20180508124856.GA2888@lunn.ch>
On Tuesday 08 May 2018 06:18 PM, Andrew Lunn wrote:
> On Tue, May 08, 2018 at 01:56:38PM +0530, Sekhar Nori wrote:
>> A well timed kernel preemption in the time_after() loop
>> in wait_for_idle() can result in a spurious timeout
>> error to be returned.
>>
>> Fix it by checking for status of hardware before returning
>> timeout error.
>>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>
> I've seen this with other drivers as well.
>
> I suggest you make use of readx_poll_timeout(), or one of its
> cousins. They get this right.
Thanks for pointing me to these. I somehow thought these helpers are
only available with regmap.
Sending a version using readl_poll_timeout(). I know __raw_readl() is
used elsewhere in the driver, but I think that should be cleaned up
sometime to use readl_relaxed() at least. So not sure if there is
benefit in persisting with existing accessor.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 net-next] drivers: net: davinci_mdio: prevent spurious timeout
From: Sekhar Nori @ 2018-05-09 11:00 UTC (permalink / raw)
To: David S . Miller
Cc: Grygorii Strashko, linux-omap, netdev, Andrew Lunn, Sekhar Nori
A well timed kernel preemption in the time_after() loop
in wait_for_idle() can result in a spurious timeout
error to be returned.
Fix it by using readl_poll_timeout() which takes care of
this issue.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
v2: use readl_poll_timeout() per suggestion from Andrew.
The issue has not been personally observed by me, but has
been reported by users. Sending for next-next given the
non-critical nature. There is seems to be no easy way to
reproduce this.
drivers/net/ethernet/ti/davinci_mdio.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 3c33f4504d8e..d073432a5dbe 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -34,6 +34,7 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/pm_runtime.h>
#include <linux/davinci_emac.h>
#include <linux/of.h>
@@ -227,14 +228,16 @@ static inline int wait_for_user_access(struct davinci_mdio_data *data)
static inline int wait_for_idle(struct davinci_mdio_data *data)
{
struct davinci_mdio_regs __iomem *regs = data->regs;
- unsigned long timeout = jiffies + msecs_to_jiffies(MDIO_TIMEOUT);
+ u32 val, ret;
- while (time_after(timeout, jiffies)) {
- if (__raw_readl(®s->control) & CONTROL_IDLE)
- return 0;
+ ret = readl_poll_timeout(®s->control, val, val & CONTROL_IDLE,
+ 0, MDIO_TIMEOUT * 1000);
+ if (ret) {
+ dev_err(data->dev, "timed out waiting for idle\n");
+ return ret;
}
- dev_err(data->dev, "timed out waiting for idle\n");
- return -ETIMEDOUT;
+
+ return 0;
}
static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
--
2.16.2
^ permalink raw reply related
* Re: [PATCH] sctp: fix spelling mistake: "max_retans" -> "max_retrans"
From: Neil Horman @ 2018-05-09 11:16 UTC (permalink / raw)
To: Colin King
Cc: Vlad Yasevich, Marcelo Ricardo Leitner, David S . Miller,
linux-sctp, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180508222428.24874-1-colin.king@canonical.com>
On Tue, May 08, 2018 at 11:24:28PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in error string
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/sctp/sm_make_chunk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index 4d7b3ccea078..4a4fd1971255 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -1131,7 +1131,7 @@ struct sctp_chunk *sctp_make_violation_max_retrans(
> const struct sctp_association *asoc,
> const struct sctp_chunk *chunk)
> {
> - static const char error[] = "Association exceeded its max_retans count";
> + static const char error[] = "Association exceeded its max_retrans count";
> size_t payload_len = sizeof(error) + sizeof(struct sctp_errhdr);
> struct sctp_chunk *retval;
>
> --
> 2.17.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ 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