* Re: WARNING in rds_cmsg_rdma_args
From: Santosh Shilimkar @ 2018-01-03 18:43 UTC (permalink / raw)
To: syzbot, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
syzkaller-bugs-/JYPxA39Uh5TLH3MbocFFw, Mohamed Ghannam
In-Reply-To: <001a1144d1c8a6b0cd0561db6999-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On 1/3/2018 12:58 AM, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> ad036b63ee57df9ab802a4eb20cbbbec66aa4520
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See
>
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ef175b5825285531eabf-Pl5Pbv+GP7P466ipTTIvnc23WoclnBCfAL8bYrjMMd8@public.gmane.org
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1514947982.760:7): avc: denied { map } for
> pid=3468 comm="syzkaller284818" path="/root/syzkaller284818499"
> dev="sda1" ino=16481
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> WARNING: CPU: 1 PID: 3468 at net/rds/rdma.c:617
> rds_cmsg_rdma_args+0xe96/0x1360 net/rds/rdma.c:617
> Kernel panic - not syncing: panic_on_warn set ...
>
+Mohamed Ghannam, who was discussing similar issue and was going
to post fix for it. Checking args->nr_local against 0 upfront would
address this issue as well.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3] 3c59x: fix missing dma_mapping_error check and bad ring refill logic
From: David Miller @ 2018-01-03 18:44 UTC (permalink / raw)
To: nhorman; +Cc: netdev, tedheadster, nhorman, klassert
In-Reply-To: <20180103180923.24868-1-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 3 Jan 2018 13:09:23 -0500
> A few spots in 3c59x missed calls to dma_mapping_error checks, casuing
> WARN_ONS to trigger. Clean those up. While we're at it, refactor the
> refill code a bit so that if skb allocation or dma mapping fails, we
> recycle the existing buffer. This prevents holes in the rx ring, and
> makes for much simpler logic
>
> Note: This is compile only tested. Ted, if you could run this and
> confirm that it continues to work properly, I would appreciate it, as I
> currently don't have access to this hardware
>
> Signed-off-by: Neil Horman <nhorman@redhat.com>
> CC: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
> CC: "David S. Miller" <davem@davemloft.net>
> Reported-by: tedheadster@gmail.com
>
> ---
> Change notes:
>
> v2)
> * Fixed tx path to free skb on mapping error
> * Refactored rx path to recycle skbs on allocation/mapping error
> * Used refactoring to remove oom timer and dirty_rx index
>
> v3)
> * Removed unused variable that was causing a warning
Applied.
^ permalink raw reply
* Re: [RFC PATCH net-next 03/19] ipv6: Clear nexthop flags upon netdev up
From: David Ahern @ 2018-01-03 18:47 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Ido Schimmel, netdev, davem, roopa, nicolas.dichtel, mlxsw
In-Reply-To: <20180103174025.GA6584@splinter>
On 1/3/18 10:40 AM, Ido Schimmel wrote:
> David, can we please get back to the issue at hand? What's the problem
> with the location of the call to rt6_sync_up()?
My original comment was asking why do it on NETDEV_CHANGE when it should
only be needed on NETDEV_UP.
^ permalink raw reply
* Re: [net 0/4][pull request] Intel Wired LAN Driver Updates 2018-01-03
From: David Miller @ 2018-01-03 18:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180103173317.72430-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 3 Jan 2018 09:33:13 -0800
> This series contains fixes for i40e and i40evf.
...
> The following are changes since commit c095508770aebf1b9218e77026e48345d719b17c:
> RDS: Heap OOB write in rds_message_alloc_sgs()
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 40GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock
From: Cong Wang @ 2018-01-03 18:52 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Alexey Kuznetsov, LKML,
Linux Kernel Network Developers, syzkaller-bugs,
Hideaki YOSHIFUJI, avejwatson, ilyal, aviadye
In-Reply-To: <001a113ed0fc75c8770561d3de8c@google.com>
On Tue, Jan 2, 2018 at 3:58 PM, syzbot
<syzbot+6dc95bddc6976b800b0b@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzkaller hit the following crash on
> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6dc95bddc6976b800b0b@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
> cookies. Check SNMP counters.
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
> net/ipv6/tcp_ipv6.c:1144
> Write of size 160 at addr ffff8801cbdd7460 by task syzkaller545407/3196
>
> CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x25b/0x340 mm/kasan/report.c:409
> check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
> memcpy+0x37/0x50 mm/kasan/kasan.c:303
> memcpy include/linux/string.h:344 [inline]
> tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144
tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads
to this bug. I guess IPv6 is not supported for TLS? If so, need
a check on proto in tls_init()...
> tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
> cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
> tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
> tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
> tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
> ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
> NF_HOOK include/linux/netfilter.h:250 [inline]
> ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
> dst_input include/net/dst.h:466 [inline]
> ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
> NF_HOOK include/linux/netfilter.h:250 [inline]
> ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
> __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
> process_backlog+0x203/0x740 net/core/dev.c:5205
> napi_poll net/core/dev.c:5603 [inline]
> net_rx_action+0x792/0x1910 net/core/dev.c:5669
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
> </IRQ>
> do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
> do_softirq kernel/softirq.c:177 [inline]
> __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
> local_bh_enable include/linux/bottom_half.h:32 [inline]
> rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
> ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
> ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
> NF_HOOK_COND include/linux/netfilter.h:239 [inline]
> ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
> dst_output include/net/dst.h:460 [inline]
> NF_HOOK include/linux/netfilter.h:250 [inline]
> ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
> inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
> tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
> tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
> __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
> tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
> tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
> inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
> sock_release+0x8d/0x1e0 net/socket.c:600
> sock_close+0x16/0x20 net/socket.c:1129
> __fput+0x327/0x7e0 fs/file_table.c:210
> ____fput+0x15/0x20 fs/file_table.c:244
> task_work_run+0x199/0x270 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x9bb/0x1ad0 kernel/exit.c:865
> do_group_exit+0x149/0x400 kernel/exit.c:968
> get_signal+0x73f/0x16c0 kernel/signal.c:2335
> do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:809
> exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
> prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
> syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
> entry_SYSCALL_64_fastpath+0x94/0x96
> RIP: 0033:0x4456e9
> RSP: 002b:00007fb4de631da8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
> RAX: fffffffffffffe00 RBX: 00000000006dac3c RCX: 00000000004456e9
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000006dac3c
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac38
> R13: 0100000000000000 R14: 00007fb4de6329c0 R15: 0000000000000009
>
> Allocated by task 3196:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
> sk_prot_alloc+0x65/0x2a0 net/core/sock.c:1463
> sk_clone_lock+0x152/0x1570 net/core/sock.c:1649
> inet_csk_clone_lock+0x92/0x4f0 net/ipv4/inet_connection_sock.c:781
> tcp_create_openreq_child+0x9b/0x1b70 net/ipv4/tcp_minisocks.c:449
> tcp_v6_syn_recv_sock+0x22d/0x23a0 net/ipv6/tcp_ipv6.c:1123
> tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
> cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
> tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
> tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
> tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
> ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
> NF_HOOK include/linux/netfilter.h:250 [inline]
> ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
> dst_input include/net/dst.h:466 [inline]
> ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
> NF_HOOK include/linux/netfilter.h:250 [inline]
> ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
> __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
> process_backlog+0x203/0x740 net/core/dev.c:5205
> napi_poll net/core/dev.c:5603 [inline]
> net_rx_action+0x792/0x1910 net/core/dev.c:5669
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>
> Freed by task 0:
> (stack is not available)
>
> The buggy address belongs to the object at ffff8801cbdd6a80
> which belongs to the cache TCP of size 2528
> The buggy address is located 0 bytes to the right of
> 2528-byte region [ffff8801cbdd6a80, ffff8801cbdd7460)
> The buggy address belongs to the page:
> page:000000006145927c count:1 mapcount:0 mapping:00000000d41dd7c1
> index:0xffff8801cbdd7ffd compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffff8801cbdd6000 ffff8801cbdd7ffd 0000000100000003
> raw: ffffea00074ef120 ffff8801d82b7248 ffff8801d798b640 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801cbdd7300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801cbdd7380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>
>> ffff8801cbdd7400: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
>
> ^
> ffff8801cbdd7480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801cbdd7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to 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
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: general protection fault in fib6_add (2)
From: Wei Wang @ 2018-01-03 18:53 UTC (permalink / raw)
To: David Ahern
Cc: syzbot, David S . Miller, Alexey Kuznetsov, lkml,
Linux Kernel Network Developers, syzkaller-bugs,
Hideaki YOSHIFUJI
In-Reply-To: <f54f53e7-593e-853d-9b52-fd296898c49c@gmail.com>
On Wed, Jan 3, 2018 at 8:16 AM, David Ahern <dsahern@gmail.com> wrote:
> [ +weiwan@google.com ]
>
> On 1/2/18 3:58 PM, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+0693adff3f83403dc5da@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1514594846.496:7): avc: denied { map } for
>> pid=3201 comm="syzkaller001778" path="/root/syzkaller001778299"
>> dev="sda1" ino=16481
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
>> IPv6: Can't replace route, no match found
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] SMP KASAN
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 3201 Comm: syzkaller001778 Not tainted 4.15.0-rc5+ #151
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244
pn could be NULL if fib6_add_1() failed. Will submit a fix for this.
>> RSP: 0018:ffff8801c7626a70 EFLAGS: 00010202
>> RAX: dffffc0000000000 RBX: 0000000000000020 RCX: ffffffff84794465
>> RDX: 0000000000000004 RSI: ffff8801d38935f0 RDI: 0000000000000282
>> RBP: ffff8801c7626da0 R08: 1ffff10038ec4c35 R09: 0000000000000000
>> R10: ffff8801c7626c68 R11: 0000000000000000 R12: 00000000fffffffe
>> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000009
>> FS: 0000000000000000(0000) GS:ffff8801db200000(0063)
>> knlGS:0000000009b70840
>> CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
>> CR2: 0000000020be1000 CR3: 00000001d585a006 CR4: 00000000001606f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>> __ip6_ins_rt+0x6c/0x90 net/ipv6/route.c:1006
>> ip6_route_multipath_add+0xd14/0x16c0 net/ipv6/route.c:3833
>> inet6_rtm_newroute+0xdc/0x160 net/ipv6/route.c:3957
>> rtnetlink_rcv_msg+0x733/0x1020 net/core/rtnetlink.c:4411
>> netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
>> rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4423
>> netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
>> netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
>> netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
>> sock_sendmsg_nosec net/socket.c:636 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:646
>> sock_write_iter+0x31a/0x5d0 net/socket.c:915
>> call_write_iter include/linux/fs.h:1772 [inline]
>> do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
>> do_iter_write+0x154/0x540 fs/read_write.c:932
>> compat_writev+0x225/0x420 fs/read_write.c:1246
>> do_compat_writev+0x115/0x220 fs/read_write.c:1267
>> C_SYSC_writev fs/read_write.c:1278 [inline]
>> compat_SyS_writev+0x26/0x30 fs/read_write.c:1274
>> do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>> do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>> entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:125
>> RIP: 0023:0xf7f1fc79
>> RSP: 002b:00000000ffb61bfc EFLAGS: 00000203 ORIG_RAX: 0000000000000092
>> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000204aaff0
>> RDX: 0000000000000001 RSI: 0000000000000167 RDI: 0000000000000010
>> RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>> Code: f1 a9 f6 fc e8 2c f2 e2 fc 85 c0 0f 85 d5 03 00 00 49 8d 5e 20 e8
>> db a9 f6 fc 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c
>> 02 00 0f 85 5a 0c 00 00 4d 39 ee 4d 8b 7e 20 0f 95 c0 4c
>> RIP: fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244 RSP: ffff8801c7626a70
>> ---[ end trace 956c65133fcfff88 ]---
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to 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
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>
^ permalink raw reply
* Re: WARNING in rds_cmsg_rdma_args
From: Santosh Shilimkar @ 2018-01-03 18:55 UTC (permalink / raw)
To: Mohamed Ghannam
Cc: syzbot, David Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
syzkaller-bugs-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <CAP8jf_ApOkxWXDsh6SZtSryqCRiN84bpEMqXUVCFuzYjtZMakQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 1/3/2018 10:51 AM, Mohamed Ghannam wrote:
> The fix : https://patchwork.ozlabs.org/patch/854723/
Cool. Thanks Mohamed for following it up.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 26/39] nds32: Device tree support
From: Rob Herring @ 2018-01-03 19:14 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime-MUIXKm3Oiri1Z/+hSey0Gg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Arnd Bergmann, linux-arch-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner,
Jason Cooper, Marc Zyngier, netdev,
deanbo422-Re5JQEeQqe8AvxtiuMwx3w,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Linus Walleij, Mark Rutland, Greg KH,
ren_guo-Y+KPrCd2zL4AvxtiuMwx3w, Randy
In-Reply-To: <7fe1190a9cf8e30f1b8af52dd382ba1176997786.1514874857.git.green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jan 2, 2018 at 2:24 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>
> This patch adds support for device tree.
>
> Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
> ---
> arch/nds32/boot/dts/Makefile | 8 +++++
> arch/nds32/boot/dts/ae3xx.dts | 73 +++++++++++++++++++++++++++++++++++++++++
> arch/nds32/kernel/devtree.c | 19 +++++++++++
> 3 files changed, 100 insertions(+)
> create mode 100644 arch/nds32/boot/dts/Makefile
> create mode 100644 arch/nds32/boot/dts/ae3xx.dts
> create mode 100644 arch/nds32/kernel/devtree.c
>
> diff --git a/arch/nds32/boot/dts/Makefile b/arch/nds32/boot/dts/Makefile
> new file mode 100644
> index 0000000..d31faa8
> --- /dev/null
> +++ b/arch/nds32/boot/dts/Makefile
> @@ -0,0 +1,8 @@
> +ifneq '$(CONFIG_NDS32_BUILTIN_DTB)' '""'
> +BUILTIN_DTB := $(patsubst "%",%,$(CONFIG_NDS32_BUILTIN_DTB)).dtb.o
> +else
> +BUILTIN_DTB :=
> +endif
> +obj-$(CONFIG_OF) += $(BUILTIN_DTB)
> +
> +clean-files := *.dtb *.dtb.S
> diff --git a/arch/nds32/boot/dts/ae3xx.dts b/arch/nds32/boot/dts/ae3xx.dts
> new file mode 100644
> index 0000000..6b23d60
> --- /dev/null
> +++ b/arch/nds32/boot/dts/ae3xx.dts
> @@ -0,0 +1,73 @@
> +/dts-v1/;
> +/ {
> + compatible = "andestech,ae3xx";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&intc>;
> +
> + chosen {
> + stdout-path = &serial0;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x00000000 0x40000000>;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "andestech,n13", "andestech,nds32v3";
> + reg = <0>;
> + clock-frequency = <60000000>;
> + next-level-cache = <&L2>;
> + };
> + };
> +
> + L2: l2-cache@e0500000 {
> + compatible = "andestech,atl2c";
> + reg = <0xe0500000 0x1000>;
> + cache-unified;
> + cache-level = <2>;
> + };
> +
> + apb: clk@0 {
unit address without reg is not valid. Drop the "@0".
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <30000000>;
> + };
> +
> +
> + intc: interrupt-controller {
> + compatible = "andestech,ativic32";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> +
> + serial0: serial@f0300000 {
All the memory mapped peripherals should be under at least one simple-bus node.
> + compatible = "andestech,uart16550", "ns16550a";
> + reg = <0xf0300000 0x1000>;
> + interrupts = <8>;
> + clock-frequency = <14745600>;
> + reg-shift = <2>;
> + reg-offset = <32>;
> + no-loopback-test = <1>;
> + };
> +
> + timer0: timer@f0400000 {
> + compatible = "andestech,atcpit100";
> + reg = <0xf0400000 0x1000>;
> + interrupts = <2>;
> + clocks = <&apb>;
> + clock-names = "PCLK";
> + };
> +
> + mac0: mac@e0100000 {
ethernet@...
> + compatible = "andestech,atmac100";
> + reg = <0xe0100000 0x1000>;
> + interrupts = <18>;
> + };
> +
> +};
> diff --git a/arch/nds32/kernel/devtree.c b/arch/nds32/kernel/devtree.c
> new file mode 100644
> index 0000000..bdce0fe
> --- /dev/null
> +++ b/arch/nds32/kernel/devtree.c
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2005-2017 Andes Technology Corporation
> +
> +#include <linux/bug.h>
> +#include <linux/printk.h>
> +#include <linux/of_fdt.h>
> +
> +void __init early_init_devtree(void *params)
> +{
> + if (!params || !early_init_dt_scan(params)) {
> + pr_crit("\n"
> + "Error: invalid device tree blob at (virtual address 0x%p)\n"
> + "\nPlease check your bootloader.", params);
> +
> + BUG_ON(1);
> + }
> +
> + dump_stack_set_arch_desc("%s (DT)", of_flat_dt_get_machine_name());
> +}
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-01-03 19:28 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-netdev, Andy Gospodarek, Jay Vosburgh, Veaceslav Falico,
LKML, kernel-janitors
In-Reply-To: <f93750d3-700f-897d-c4ef-2cf5b5a3374e@users.sourceforge.net>
On Wed, Jan 3, 2018 at 12:45 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
>>> Omit an extra message for a memory allocation failure in this function.
>>>
>>> This issue was detected by using the Coccinelle software.
>>>
>> What is the issue with this message?
>
> * Is it redundant?
>
> * Would a Linux allocation failure report be already sufficient here?
>
If you see 8 out of 9 call sites in this file ignore the return value.
This message in the log could give a clue when debugging. Unless it's
spamming it's not harmful, or is it?
> Regards,
> Markus
^ permalink raw reply
* Re: Linux ECN Handling
From: Neal Cardwell @ 2018-01-03 19:39 UTC (permalink / raw)
To: Steve Ibanez
Cc: Eric Dumazet, Yuchung Cheng, Daniel Borkmann, Netdev,
Florian Westphal, Mohammad Alizadeh, Lawrence Brakmo
In-Reply-To: <CACJspmK89b2sMzeBhK1Xs-hkN3aZyr4f24FwN8qSh9i=59faYQ@mail.gmail.com>
On Tue, Jan 2, 2018 at 6:57 PM, Steve Ibanez <sibanez@stanford.edu> wrote:
> Hi Neal,
>
> Sorry, my last email was incorrect. It turns out the default tcp
> congestion control alg that was being used on my client machines was
> cubic instead of dctcp. That is why tp->processing_cwr field was never
> set in the tcp_rcv_established function. I've changed the default back
> to dctcp on all of my machines.
>
> I am now logging the value of tp->rcv_nxt at the top of the
> tcp_transmit_skb() function for all CWR segments. I see that during
> normal operation, the value of tp->rcv_nxt is equal to the SeqNo in
> the CWR segment + length of the CWR segment.
OK, thanks. That makes sense.
This part I didn't understand:
> However, for the unACKed
> CWR segment, the value of tp->rcv_nxt is just equal to the SeqNo in
> the CWR segment (i.e. not incremented by the length). And I see that
> by the time the tcp_ack_snd_check() function is executed, tp->rcv_nxt
> has been incremented by the length of the unACKed CWR segment.
I would have thought that for the processing of the skb that has the
CWR, the sequence would be:
(1) "...the tcp_ack_snd_check() function is executed, tp->rcv_nxt has
been incremented by the length of the unACKed CWR segment"
(2) then we send the ACK, and the instrumentation at the top of the
tcp_transmit_skb() function logs that rcv_nxt value (which "has been
incremented by the length of the unACKed CWR segment").
But you are saying "for the unACKed CWR segment, the value of
tp->rcv_nxt is just equal to the SeqNo in the CWR segment (i.e. not
incremented by the length)", which does not seem to match my
prediction in (2). Apparently I am mis-understanding the sequence.
Perhaps you can help clear it up for me? :-)
Is it possible that the case where you see "tp->rcv_nxt is just equal
to the SeqNo in the CWR segment" is a log line that was logged while
processing the skb that precedes the skb with the CWR?
> The tcp_transmit_skb() function sets the outgoing segment's ack_seq to
> be tp->rcv_next:
>
> th->ack_seq = htonl(tp->rcv_nxt);
>
> So I think the rcv_nxt field is supposed to be incremented before
> reaching tcp_transmit_skb(). Can you see any reason as to why this
> field would not be incremented for CWR segments sometimes?
No, so far I haven't been able to think of a reason why rcv_nxt would
not be incremented for in-order CWR-marked segments...
cheers,
neal
^ permalink raw reply
* MY DEAR
From: Duncan vargas @ 2018-01-03 19:42 UTC (permalink / raw)
HI
^ permalink raw reply
* [wireless-testsing2:master 1/4] drivers/net/netdevsim/bpf.c:130:14: sparse: incompatible types for 'case' statement
From: kbuild test robot @ 2018-01-03 19:53 UTC (permalink / raw)
To: David S. Miller; +Cc: kbuild-all, netdev, Bob Copeland
[-- Attachment #1: Type: text/plain, Size: 5187 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git master
head: 6b3b30d0c31ddb2f4d8208c90bc2b4adef47204d
commit: af2cae39f6ab9dc596616d6a28c7772e1dd55e91 [1/4] Merge remote-tracking branch 'wireless-drivers-next/master'
reproduce:
# apt-get install sparse
git checkout af2cae39f6ab9dc596616d6a28c7772e1dd55e91
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
All errors (new ones prefixed by >>):
drivers/net/netdevsim/bpf.c:130:14: sparse: undefined identifier 'TC_CLSBPF_REPLACE'
drivers/net/netdevsim/bpf.c:132:14: sparse: undefined identifier 'TC_CLSBPF_ADD'
drivers/net/netdevsim/bpf.c:134:14: sparse: undefined identifier 'TC_CLSBPF_DESTROY'
drivers/net/netdevsim/bpf.c:130:14: sparse: incompatible types for 'case' statement
drivers/net/netdevsim/bpf.c:132:14: sparse: incompatible types for 'case' statement
drivers/net/netdevsim/bpf.c:134:14: sparse: incompatible types for 'case' statement
drivers/net/netdevsim/bpf.c:130:14: sparse: Expected constant expression in case statement
drivers/net/netdevsim/bpf.c:132:14: sparse: Expected constant expression in case statement
drivers/net/netdevsim/bpf.c:134:14: sparse: Expected constant expression in case statement
drivers/net/netdevsim/bpf.c: In function 'nsim_bpf_setup_tc_block_cb':
>> drivers/net/netdevsim/bpf.c:130:7: error: 'TC_CLSBPF_REPLACE' undeclared (first use in this function); did you mean 'TC_RED_REPLACE'?
case TC_CLSBPF_REPLACE:
^~~~~~~~~~~~~~~~~
TC_RED_REPLACE
drivers/net/netdevsim/bpf.c:130:7: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/net/netdevsim/bpf.c:132:7: error: 'TC_CLSBPF_ADD' undeclared (first use in this function); did you mean 'TC_CLSBPF_STATS'?
case TC_CLSBPF_ADD:
^~~~~~~~~~~~~
TC_CLSBPF_STATS
>> drivers/net/netdevsim/bpf.c:134:7: error: 'TC_CLSBPF_DESTROY' undeclared (first use in this function); did you mean 'TC_CLSBPF_STATS'?
case TC_CLSBPF_DESTROY:
^~~~~~~~~~~~~~~~~
TC_CLSBPF_STATS
sparse warnings: (new ones prefixed by >>)
vim +/case +130 drivers/net/netdevsim/bpf.c
31d3ad83 Jakub Kicinski 2017-12-01 103
31d3ad83 Jakub Kicinski 2017-12-01 104 int nsim_bpf_setup_tc_block_cb(enum tc_setup_type type,
31d3ad83 Jakub Kicinski 2017-12-01 105 void *type_data, void *cb_priv)
31d3ad83 Jakub Kicinski 2017-12-01 106 {
31d3ad83 Jakub Kicinski 2017-12-01 107 struct tc_cls_bpf_offload *cls_bpf = type_data;
31d3ad83 Jakub Kicinski 2017-12-01 108 struct bpf_prog *prog = cls_bpf->prog;
31d3ad83 Jakub Kicinski 2017-12-01 109 struct netdevsim *ns = cb_priv;
31d3ad83 Jakub Kicinski 2017-12-01 110 bool skip_sw;
31d3ad83 Jakub Kicinski 2017-12-01 111
31d3ad83 Jakub Kicinski 2017-12-01 112 if (type != TC_SETUP_CLSBPF ||
31d3ad83 Jakub Kicinski 2017-12-01 113 !tc_can_offload(ns->netdev) ||
31d3ad83 Jakub Kicinski 2017-12-01 114 cls_bpf->common.protocol != htons(ETH_P_ALL) ||
31d3ad83 Jakub Kicinski 2017-12-01 115 cls_bpf->common.chain_index)
31d3ad83 Jakub Kicinski 2017-12-01 116 return -EOPNOTSUPP;
31d3ad83 Jakub Kicinski 2017-12-01 117
31d3ad83 Jakub Kicinski 2017-12-01 118 skip_sw = cls_bpf->gen_flags & TCA_CLS_FLAGS_SKIP_SW;
31d3ad83 Jakub Kicinski 2017-12-01 119
31d3ad83 Jakub Kicinski 2017-12-01 120 if (nsim_xdp_offload_active(ns))
31d3ad83 Jakub Kicinski 2017-12-01 121 return -EBUSY;
31d3ad83 Jakub Kicinski 2017-12-01 122
31d3ad83 Jakub Kicinski 2017-12-01 123 if (!ns->bpf_tc_accept)
31d3ad83 Jakub Kicinski 2017-12-01 124 return -EOPNOTSUPP;
31d3ad83 Jakub Kicinski 2017-12-01 125 /* Note: progs without skip_sw will probably not be dev bound */
31d3ad83 Jakub Kicinski 2017-12-01 126 if (prog && !prog->aux->offload && !ns->bpf_tc_non_bound_accept)
31d3ad83 Jakub Kicinski 2017-12-01 127 return -EOPNOTSUPP;
31d3ad83 Jakub Kicinski 2017-12-01 128
31d3ad83 Jakub Kicinski 2017-12-01 129 switch (cls_bpf->command) {
31d3ad83 Jakub Kicinski 2017-12-01 @130 case TC_CLSBPF_REPLACE:
31d3ad83 Jakub Kicinski 2017-12-01 131 return nsim_bpf_offload(ns, prog, true);
31d3ad83 Jakub Kicinski 2017-12-01 @132 case TC_CLSBPF_ADD:
31d3ad83 Jakub Kicinski 2017-12-01 133 return nsim_bpf_offload(ns, prog, false);
31d3ad83 Jakub Kicinski 2017-12-01 @134 case TC_CLSBPF_DESTROY:
31d3ad83 Jakub Kicinski 2017-12-01 135 return nsim_bpf_offload(ns, NULL, true);
31d3ad83 Jakub Kicinski 2017-12-01 136 default:
31d3ad83 Jakub Kicinski 2017-12-01 137 return -EOPNOTSUPP;
31d3ad83 Jakub Kicinski 2017-12-01 138 }
31d3ad83 Jakub Kicinski 2017-12-01 139 }
31d3ad83 Jakub Kicinski 2017-12-01 140
:::::: The code at line 130 was first introduced by commit
:::::: 31d3ad832948c75139b0e5b653912f7898a1d5d5 netdevsim: add bpf offload support
:::::: TO: Jakub Kicinski <jakub.kicinski@netronome.com>
:::::: CC: Daniel Borkmann <daniel@iogearbox.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 62408 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net,stable 1/2] net: fec: restore dev_id in the cases of probe error
From: Troy Kisky @ 2018-01-03 20:03 UTC (permalink / raw)
To: Fugang Duan, festevam, davem; +Cc: netdev, andrew
In-Reply-To: <1514947170-8887-2-git-send-email-fugang.duan@nxp.com>
On 1/2/2018 6:39 PM, Fugang Duan wrote:
> The static variable dev_id always plus one before netdev registerred.
> It should restore the dev_id value in the cases of probe error.
>
> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index e17d10b..dae89bc 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -3576,6 +3576,7 @@ static int fec_enet_get_irq_cnt(struct platform_device *pdev)
> of_node_put(phy_node);
> failed_ioremap:
> free_netdev(ndev);
> + dev_id--;
This should be before failed_ioremap.
>
> return ret;
> }
>
^ permalink raw reply
* [PATCH 0/2] Ether fixes for the SolutionEngine771x boards
From: Sergei Shtylyov @ 2018-01-03 20:08 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, linux-sh; +Cc: netdev
Hello!
Here's the series of 2 patches against Linus' repo. This series should
(hoplefully) fix the Ether support on the SolutionEngine771x boards...
[1/2] SolutionEngine771x: fix Ether platform data
[2/2] SolutionEngine771x: add Ether TSU resource
MBR, Sergei
^ permalink raw reply
* [PATCH 2/2] SolutionEngine771x: add Ether TSU resource
From: Sergei Shtylyov @ 2018-01-03 20:08 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, linux-sh; +Cc: netdev, Sergei Shtylyov
[-- Attachment #1: SolutionEngine771x-add-Ether-TSU-resource.patch --]
[-- Type: text/plain, Size: 2154 bytes --]
After the Ether platform data is fixed, the driver probe() method would
still fail since the 'struct sh_eth_cpu_data' corresponding to SH771x
indicates the presence of TSU but the memory resource for it is absent.
Add the missing TSU resource to both Ether devices and fix the harmless
off-by-one error in the main memory resources, while at it...
Fixes: 4986b996882d ("net: sh_eth: remove the SH_TSU_ADDR")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/sh/boards/mach-se/770x/setup.c | 14 ++++++++++++--
arch/sh/include/mach-se/mach/se.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
Index: linux/arch/sh/boards/mach-se/770x/setup.c
===================================================================
--- linux.orig/arch/sh/boards/mach-se/770x/setup.c
+++ linux/arch/sh/boards/mach-se/770x/setup.c
@@ -123,10 +123,15 @@ static struct sh_eth_plat_data sh_eth_pl
static struct resource sh_eth0_resources[] = {
[0] = {
.start = SH_ETH0_BASE,
- .end = SH_ETH0_BASE + 0x1B8,
+ .end = SH_ETH0_BASE + 0x1B8 - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
+ .start = SH_TSU_BASE,
+ .end = SH_TSU_BASE + 0xA00 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [2] = {
.start = SH_ETH0_IRQ,
.end = SH_ETH0_IRQ,
.flags = IORESOURCE_IRQ,
@@ -146,10 +151,15 @@ static struct platform_device sh_eth0_de
static struct resource sh_eth1_resources[] = {
[0] = {
.start = SH_ETH1_BASE,
- .end = SH_ETH1_BASE + 0x1B8,
+ .end = SH_ETH1_BASE + 0x1B8 - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
+ .start = SH_TSU_BASE,
+ .end = SH_TSU_BASE + 0xA00 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [2] = {
.start = SH_ETH1_IRQ,
.end = SH_ETH1_IRQ,
.flags = IORESOURCE_IRQ,
Index: linux/arch/sh/include/mach-se/mach/se.h
===================================================================
--- linux.orig/arch/sh/include/mach-se/mach/se.h
+++ linux/arch/sh/include/mach-se/mach/se.h
@@ -100,6 +100,7 @@
/* Base address */
#define SH_ETH0_BASE 0xA7000000
#define SH_ETH1_BASE 0xA7000400
+#define SH_TSU_BASE 0xA7000800
/* PHY ID */
#if defined(CONFIG_CPU_SUBTYPE_SH7710)
# define PHY_ID 0x00
^ permalink raw reply
* [PATCH 0/2] wireless: libertas_tf: Adjustments for three function implementations
From: SF Markus Elfring @ 2018-01-03 20:10 UTC (permalink / raw)
To: linux-wireless, netdev, Arvind Yadav, Kalle Valo, Kees Cook
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 3 Jan 2018 21:06:54 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
in __if_usb_submit_rx_urb()
Improve a size determination in two functions
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] SolutionEngine771x: fix Ether platform data
From: Sergei Shtylyov @ 2018-01-03 20:08 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, linux-sh; +Cc: netdev, Sergei Shtylyov
[-- Attachment #1: SolutionEngine771x-fix-Ether-platform-data.patch --]
[-- Type: text/plain, Size: 1734 bytes --]
The 'sh_eth' driver's probe() method would fail on the SolutionEngine7710
board and crash on SolutionEngine7712 board as the platform code is
hopelessly behind the driver's platform data -- it passes the PHY address
instead of 'struct sh_eth_plat_data *'; pass the latter to the driver in
order to fix the bug...
Fixes: 71557a37adb5 ("[netdrvr] sh_eth: Add SH7619 support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against Paul Mundt's 'linux-sh.git' repo, 'sh-latest' branch.
arch/sh/boards/mach-se/770x/setup.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux/arch/sh/boards/mach-se/770x/setup.c
===================================================================
--- linux.orig/arch/sh/boards/mach-se/770x/setup.c
+++ linux/arch/sh/boards/mach-se/770x/setup.c
@@ -115,6 +115,11 @@ static struct platform_device heartbeat_
#if defined(CONFIG_CPU_SUBTYPE_SH7710) ||\
defined(CONFIG_CPU_SUBTYPE_SH7712)
/* SH771X Ethernet driver */
+static struct sh_eth_plat_data sh_eth_plat = {
+ .phy = PHY_ID,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
static struct resource sh_eth0_resources[] = {
[0] = {
.start = SH_ETH0_BASE,
@@ -132,7 +137,7 @@ static struct platform_device sh_eth0_de
.name = "sh771x-ether",
.id = 0,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth0_resources),
.resource = sh_eth0_resources,
@@ -155,7 +160,7 @@ static struct platform_device sh_eth1_de
.name = "sh771x-ether",
.id = 1,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth1_resources),
.resource = sh_eth1_resources,
^ permalink raw reply
* [PATCH 1/2] wireless: libertas_tf: Delete an error message for a failed memory allocation in __if_usb_submit_rx_urb()
From: SF Markus Elfring @ 2018-01-03 20:11 UTC (permalink / raw)
To: linux-wireless, netdev, Arvind Yadav, Kalle Valo, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <e8b93aae-8dea-7089-43fe-9222054f0749@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 3 Jan 2018 20:55:10 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index 5153922e7ce1..9eebc84cd15a 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -420,7 +420,6 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
skb = dev_alloc_skb(MRVDRV_ETH_RX_PACKET_BUFFER_SIZE);
if (!skb) {
- pr_err("No free skb\n");
lbtf_deb_leave(LBTF_DEB_USB);
return -1;
}
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] wireless: libertas_tf: Improve a size determination in two functions
From: SF Markus Elfring @ 2018-01-03 20:13 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Arvind Yadav, Kalle Valo,
Kees Cook
Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e8b93aae-8dea-7089-43fe-9222054f0749-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Date: Wed, 3 Jan 2018 21:02:17 +0100
Replace the specification of data structures by variable references
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
---
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index 9eebc84cd15a..98e81a6f2338 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -152,7 +152,7 @@ static int if_usb_probe(struct usb_interface *intf,
lbtf_deb_enter(LBTF_DEB_USB);
udev = interface_to_usbdev(intf);
- cardp = kzalloc(sizeof(struct if_usb_card), GFP_KERNEL);
+ cardp = kzalloc(sizeof(*cardp), GFP_KERNEL);
if (!cardp)
goto error;
@@ -536,8 +536,7 @@ static void if_usb_receive_fwload(struct urb *urb)
return;
}
- syncfwheader = kmemdup(skb->data, sizeof(struct fwsyncheader),
- GFP_ATOMIC);
+ syncfwheader = kmemdup(skb->data, sizeof(*syncfwheader), GFP_ATOMIC);
if (!syncfwheader) {
lbtf_deb_usbd(&cardp->udev->dev,
"Failure to allocate syncfwheader\n");
--
2.15.1
^ permalink raw reply related
* Re: [PATCHv5 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec
From: Rob Herring @ 2018-01-03 20:48 UTC (permalink / raw)
To: jassisinghbrar
Cc: netdev, devicetree, davem, arnd.bergmann, andrew, ard.biesheuvel,
mark.rutland, masami.hiramatsu, Jassi Brar
In-Reply-To: <1514783660-4290-1-git-send-email-jassisinghbrar@gmail.com>
On Mon, Jan 01, 2018 at 10:44:20AM +0530, jassisinghbrar@gmail.com wrote:
> From: Jassi Brar <jassisinghbrar@gmail.com>
>
> This patch adds documentation for Device-Tree bindings for the
> Socionext NetSec Controller driver.
>
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> .../devicetree/bindings/net/socionext-netsec.txt | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH net-next 03/19] ipv6: Clear nexthop flags upon netdev up
From: Ido Schimmel @ 2018-01-03 20:53 UTC (permalink / raw)
To: David Ahern; +Cc: Ido Schimmel, netdev, davem, roopa, nicolas.dichtel, mlxsw
In-Reply-To: <f692a886-82eb-6dc1-a8b9-d1c68466f29c@gmail.com>
On Wed, Jan 03, 2018 at 11:47:16AM -0700, David Ahern wrote:
> On 1/3/18 10:40 AM, Ido Schimmel wrote:
> > David, can we please get back to the issue at hand? What's the problem
> > with the location of the call to rt6_sync_up()?
>
> My original comment was asking why do it on NETDEV_CHANGE when it should
> only be needed on NETDEV_UP.
I can condition the call to rt6_sync_up() on the event being NETDEV_UP,
but the location needs to stay the same. Before that the interface still
doesn't have an IP address.
Reason for this requirement is that rt6_sync_up() is going to generate
FIB_EVENT_NH_ADD events that instruct switch drivers to populate their
adjacency tables with the notified nexthop. For this to happen, the
nexthop device needs to have L3 configuration (e.g., RIF in mlxsw) which
is dependent on the presence of an IP address.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock
From: Ozgur @ 2018-01-03 20:55 UTC (permalink / raw)
To: Cong Wang, syzbot
Cc: David Miller, Alexey Kuznetsov, LKML,
Linux Kernel Network Developers, syzkaller-bugs@googlegroups.com,
Hideaki YOSHIFUJI, avejwatson@fb.com, ilyal@mellanox.com,
aviadye@mellanox.com
In-Reply-To: <CAM_iQpVaHVJviJPPxTvNkEFSPoN7rFjTcyh9W91RrYUpsUOepQ@mail.gmail.com>
03.01.2018, 21:57, "Cong Wang" <xiyou.wangcong@gmail.com>:
> On Tue, Jan 2, 2018 at 3:58 PM, syzbot
> <syzbot+6dc95bddc6976b800b0b@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+6dc95bddc6976b800b0b@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
>> cookies. Check SNMP counters.
>> ==================================================================
>> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
>> BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
>> net/ipv6/tcp_ipv6.c:1144
>> Write of size 160 at addr ffff8801cbdd7460 by task syzkaller545407/3196
>>
>> CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> <IRQ>
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x194/0x257 lib/dump_stack.c:53
>> print_address_description+0x73/0x250 mm/kasan/report.c:252
>> kasan_report_error mm/kasan/report.c:351 [inline]
>> kasan_report+0x25b/0x340 mm/kasan/report.c:409
>> check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>> check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>> memcpy+0x37/0x50 mm/kasan/kasan.c:303
>> memcpy include/linux/string.h:344 [inline]
>> tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144
>
> tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads
> to this bug. I guess IPv6 is not supported for TLS? If so, need
> a check on proto in tls_init()...
Hello,
I think IPv6 supports with TLS.
There was a previously posted commit by Mellanox:
https://patchwork.ozlabs.org/patch/801530/
Ozgur
>> tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>> cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>> tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>> tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>> tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>> ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>> NF_HOOK include/linux/netfilter.h:250 [inline]
>> ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>> dst_input include/net/dst.h:466 [inline]
>> ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>> NF_HOOK include/linux/netfilter.h:250 [inline]
>> ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>> __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>> process_backlog+0x203/0x740 net/core/dev.c:5205
>> napi_poll net/core/dev.c:5603 [inline]
>> net_rx_action+0x792/0x1910 net/core/dev.c:5669
>> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
>> </IRQ>
>> do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
>> do_softirq kernel/softirq.c:177 [inline]
>> __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>> local_bh_enable include/linux/bottom_half.h:32 [inline]
>> rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>> ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
>> ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>> NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>> ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
>> dst_output include/net/dst.h:460 [inline]
>> NF_HOOK include/linux/netfilter.h:250 [inline]
>> ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
>> inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>> tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>> tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>> __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>> tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
>> tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
>> inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426
>> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
>> sock_release+0x8d/0x1e0 net/socket.c:600
>> sock_close+0x16/0x20 net/socket.c:1129
>> __fput+0x327/0x7e0 fs/file_table.c:210
>> ____fput+0x15/0x20 fs/file_table.c:244
>> task_work_run+0x199/0x270 kernel/task_work.c:113
>> exit_task_work include/linux/task_work.h:22 [inline]
>> do_exit+0x9bb/0x1ad0 kernel/exit.c:865
>> do_group_exit+0x149/0x400 kernel/exit.c:968
>> get_signal+0x73f/0x16c0 kernel/signal.c:2335
>> do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:809
>> exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
>> prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>> syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>> entry_SYSCALL_64_fastpath+0x94/0x96
>> RIP: 0033:0x4456e9
>> RSP: 002b:00007fb4de631da8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
>> RAX: fffffffffffffe00 RBX: 00000000006dac3c RCX: 00000000004456e9
>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000006dac3c
>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac38
>> R13: 0100000000000000 R14: 00007fb4de6329c0 R15: 0000000000000009
>>
>> Allocated by task 3196:
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>> set_track mm/kasan/kasan.c:459 [inline]
>> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
>> sk_prot_alloc+0x65/0x2a0 net/core/sock.c:1463
>> sk_clone_lock+0x152/0x1570 net/core/sock.c:1649
>> inet_csk_clone_lock+0x92/0x4f0 net/ipv4/inet_connection_sock.c:781
>> tcp_create_openreq_child+0x9b/0x1b70 net/ipv4/tcp_minisocks.c:449
>> tcp_v6_syn_recv_sock+0x22d/0x23a0 net/ipv6/tcp_ipv6.c:1123
>> tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>> cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>> tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>> tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>> tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>> ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>> NF_HOOK include/linux/netfilter.h:250 [inline]
>> ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>> dst_input include/net/dst.h:466 [inline]
>> ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>> NF_HOOK include/linux/netfilter.h:250 [inline]
>> ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>> __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>> process_backlog+0x203/0x740 net/core/dev.c:5205
>> napi_poll net/core/dev.c:5603 [inline]
>> net_rx_action+0x792/0x1910 net/core/dev.c:5669
>> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>
>> Freed by task 0:
>> (stack is not available)
>>
>> The buggy address belongs to the object at ffff8801cbdd6a80
>> which belongs to the cache TCP of size 2528
>> The buggy address is located 0 bytes to the right of
>> 2528-byte region [ffff8801cbdd6a80, ffff8801cbdd7460)
>> The buggy address belongs to the page:
>> page:000000006145927c count:1 mapcount:0 mapping:00000000d41dd7c1
>> index:0xffff8801cbdd7ffd compound_mapcount: 0
>> flags: 0x2fffc0000008100(slab|head)
>> raw: 02fffc0000008100 ffff8801cbdd6000 ffff8801cbdd7ffd 0000000100000003
>> raw: ffffea00074ef120 ffff8801d82b7248 ffff8801d798b640 0000000000000000
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>> ffff8801cbdd7300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ffff8801cbdd7380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> ffff8801cbdd7400: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
>>
>> ^
>> ffff8801cbdd7480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8801cbdd7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ==================================================================
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to 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
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH 0/2] Ether fixes for the SolutionEngine771x boards
From: Sergei Shtylyov @ 2018-01-03 20:57 UTC (permalink / raw)
To: Yoshinori Sato, Rich Felker, linux-sh; +Cc: netdev
In-Reply-To: <20180103200813.162806401@cogentembedded.com>
Hello!
On 01/03/2018 11:08 PM, Sergei Shtylyov wrote:
> Here's the series of 2 patches against Linus' repo. This series should
> (hoplefully) fix the Ether support on the SolutionEngine771x boards...
>
> [1/2] SolutionEngine771x: fix Ether platform data
> [2/2] SolutionEngine771x: add Ether TSU resource
Forgot to mention that the patches haven't been tested (even not
compile-tested)...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8723de: Add firmware for new driver/device
From: Josh Boyer @ 2018-01-03 20:58 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-firmware, linux-wireless, netdev, Ping-Ke Shih
In-Reply-To: <20180103004442.947-1-Larry.Finger@lwfinger.net>
On Tue, Jan 2, 2018 at 7:44 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> A driver for the RTL8723DE is nearing submission to staging. This commit supplies
> the firmware for it.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> ---
> WHENCE | 9 +++++++++
> rtlwifi/rtl8723defw.bin | Bin 0 -> 27726 bytes
> 2 files changed, 9 insertions(+)
> create mode 100644 rtlwifi/rtl8723defw.bin
Applied and pushed out. Thanks.
josh
^ permalink raw reply
* [PATCH] RDS: null pointer dereference in rds_atomic_free_op
From: simo.ghannam @ 2018-01-03 21:06 UTC (permalink / raw)
To: netdev, linux-rdma, santosh.shilimkar, davem, rds-devel; +Cc: Mohamed Ghannam
From: Mohamed Ghannam <simo.ghannam@gmail.com>
set rm->atomic.op_active to 0 when rds_pin_pages() fails
or the user supplied address is invalid,
this prevents a NULL pointer usage in rds_atomic_free_op()
Signed-off-by: Mohamed Ghannam <simo.ghannam@gmail.com>
---
net/rds/rdma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index bc2f1e0977d6..398932fbaf27 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -874,6 +874,7 @@ int rds_cmsg_atomic(struct rds_sock *rs, struct rds_message *rm,
err:
if (page)
put_page(page);
+ rm->atomic.op_active = 0;
kfree(rm->atomic.op_notifier);
return ret;
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox