1. 02 5月, 2019 40 次提交
    • P
      mlxsw: spectrum: Put MC TCs into DWRR mode · b08774d3
      Petr Machata 提交于
      [ Upstream commit f476b3f809fa02f47af6333ed63715058c3fc348 ]
      
      Both Spectrum-1 and Spectrum-2 chips are currently configured such that
      pairs of TC n (which is used for UC traffic) and TC n+8 (which is used
      for MC traffic) are feeding into the same subgroup. Strict
      prioritization is configured between the two TCs, and by enabling
      MC-aware mode on the switch, the lower-numbered (UC) TCs are favored
      over the higher-numbered (MC) TCs.
      
      On Spectrum-2 however, there is an issue in configuration of the
      MC-aware mode. As a result, MC traffic is prioritized over UC traffic.
      To work around the issue, configure the MC TCs with DWRR mode (while
      keeping the UC TCs in strict mode).
      
      With this patch, the multicast-unicast arbitration results in the same
      behavior on both Spectrum-1 and Spectrum-2 chips.
      
      Fixes: 7b819530 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b08774d3
    • I
      mlxsw: pci: Reincrease PCI reset timeout · 21e47998
      Ido Schimmel 提交于
      [ Upstream commit 1ab3030193d25878b3b1409060e1e0a879800c95 ]
      
      During driver initialization the driver sends a reset to the device and
      waits for the firmware to signal that it is ready to continue.
      
      Commit d2f372ba0914 ("mlxsw: pci: Increase PCI SW reset timeout")
      increased the timeout to 13 seconds due to longer PHY calibration in
      Spectrum-2 compared to Spectrum-1.
      
      Recently it became apparent that this timeout is too short and therefore
      this patch increases it again to a safer limit that will be reduced in
      the future.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Fixes: d2f372ba0914 ("mlxsw: pci: Increase PCI SW reset timeout")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21e47998
    • J
      net: hns: Fix WARNING when hns modules installed · e875a409
      Jun Xiao 提交于
      Commit dfdf26babc98 upstream
      
      this patch need merge to 4.19.y stable kernel
      
      Fix Conflict:already fixed the confilct dfdf26babc98 with Yonglong Liu
      
      stable candidate:user cannot connect to the internet via hns dev
      by default setting without this patch
      
      we have already verified this patch on kunpeng916 platform,
      and it works well.
      Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: NJun Xiao <xiaojun2@hisilicon.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e875a409
    • H
      team: fix possible recursive locking when add slaves · 7ce836e8
      Hangbin Liu 提交于
      [ Upstream commit 925b0c841e066b488cc3a60272472b2c56300704 ]
      
      If we add a bond device which is already the master of the team interface,
      we will hold the team->lock in team_add_slave() first and then request the
      lock in team_set_mac_address() again. The functions are called like:
      
      - team_add_slave()
       - team_port_add()
         - team_port_enter()
           - team_modeop_port_enter()
             - __set_port_dev_addr()
               - dev_set_mac_address()
                 - bond_set_mac_address()
                   - dev_set_mac_address()
        	       - team_set_mac_address
      
      Although team_upper_dev_link() would check the upper devices but it is
      called too late. Fix it by adding a checking before processing the slave.
      
      v2: Do not split the string in netdev_err()
      
      Fixes: 3d249d4c ("net: introduce ethernet teaming device")
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ce836e8
    • S
      stmmac: pci: Adjust IOT2000 matching · 1f78e75e
      Su Bao Cheng 提交于
      [ Upstream commit e0c1d14a1a3211dccf0540a6703ffbd5d2a75bdb ]
      
      Since there are more IOT2040 variants with identical hardware but
      different asset tags, the asset tag matching should be adjusted to
      support them.
      
      For the board name "SIMATIC IOT2000", currently there are 2 types of
      hardware, IOT2020 and IOT2040. The IOT2020 is identified by its unique
      asset tag. Match on it first. If we then match on the board name only,
      we will catch all IOT2040 variants. In the future there will be no other
      devices with the "SIMATIC IOT2000" DMI board name but different
      hardware.
      Signed-off-by: NSu Bao Cheng <baocheng.su@siemens.com>
      Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f78e75e
    • J
      net/tls: fix refcount adjustment in fallback · e97f0bc7
      Jakub Kicinski 提交于
      [ Upstream commit 9188d5ca454fd665145904267e726e9e8d122f5c ]
      
      Unlike atomic_add(), refcount_add() does not deal well
      with a negative argument.  TLS fallback code reallocates
      the skb and is very likely to shrink the truesize, leading to:
      
      [  189.513254] WARNING: CPU: 5 PID: 0 at lib/refcount.c:81 refcount_add_not_zero_checked+0x15c/0x180
       Call Trace:
        refcount_add_checked+0x6/0x40
        tls_enc_skb+0xb93/0x13e0 [tls]
      
      Once wmem_allocated count saturates the application can no longer
      send data on the socket.  This is similar to Eric's fixes for GSO,
      TCP:
      commit 7ec318fe ("tcp: gso: avoid refcount_t warning from tcp_gso_segment()")
      and UDP:
      commit 575b65bc ("udp: avoid refcount_t saturation in __udp_gso_segment()").
      
      Unlike the GSO case, for TLS fallback it's likely that the skb has
      shrunk, so the "likely" annotation is the other way around (likely
      branch being "sub").
      
      Fixes: e8f69799 ("net/tls: Add generic NIC offload infrastructure")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e97f0bc7
    • V
      net: stmmac: move stmmac_check_ether_addr() to driver probe · b02f8aa8
      Vinod Koul 提交于
      [ Upstream commit b561af36b1841088552464cdc3f6371d92f17710 ]
      
      stmmac_check_ether_addr() checks the MAC address and assigns one in
      driver open(). In many cases when we create slave netdevice, the dev
      addr is inherited from master but the master dev addr maybe NULL at
      that time, so move this call to driver probe so that address is
      always valid.
      Signed-off-by: NXiaofei Shen <xiaofeis@codeaurora.org>
      Tested-by: NXiaofei Shen <xiaofeis@codeaurora.org>
      Signed-off-by: NSneh Shah <snehshah@codeaurora.org>
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b02f8aa8
    • E
      net/rose: fix unbound loop in rose_loopback_timer() · d7b10dfe
      Eric Dumazet 提交于
      [ Upstream commit 0453c682459583910d611a96de928f4442205493 ]
      
      This patch adds a limit on the number of skbs that fuzzers can queue
      into loopback_queue. 1000 packets for rose loopback seems more than enough.
      
      Then, since we now have multiple cpus in most linux hosts,
      we also need to limit the number of skbs rose_loopback_timer()
      can dequeue at each round.
      
      rose_loopback_queue() can be drop-monitor friendly, calling
      consume_skb() or kfree_skb() appropriately.
      
      Finally, use mod_timer() instead of del_timer() + add_timer()
      
      syzbot report was :
      
      rcu: INFO: rcu_preempt self-detected stall on CPU
      rcu:    0-...!: (10499 ticks this GP) idle=536/1/0x4000000000000002 softirq=103291/103291 fqs=34
      rcu:     (t=10500 jiffies g=140321 q=323)
      rcu: rcu_preempt kthread starved for 10426 jiffies! g140321 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
      rcu: RCU grace-period kthread stack dump:
      rcu_preempt     I29168    10      2 0x80000000
      Call Trace:
       context_switch kernel/sched/core.c:2877 [inline]
       __schedule+0x813/0x1cc0 kernel/sched/core.c:3518
       schedule+0x92/0x180 kernel/sched/core.c:3562
       schedule_timeout+0x4db/0xfd0 kernel/time/timer.c:1803
       rcu_gp_fqs_loop kernel/rcu/tree.c:1971 [inline]
       rcu_gp_kthread+0x962/0x17b0 kernel/rcu/tree.c:2128
       kthread+0x357/0x430 kernel/kthread.c:253
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      NMI backtrace for cpu 0
      CPU: 0 PID: 7632 Comm: kworker/0:4 Not tainted 5.1.0-rc5+ #172
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events iterate_cleanup_work
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
       nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
       arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
       trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
       rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree.c:1223
       print_cpu_stall kernel/rcu/tree.c:1360 [inline]
       check_cpu_stall kernel/rcu/tree.c:1434 [inline]
       rcu_pending kernel/rcu/tree.c:3103 [inline]
       rcu_sched_clock_irq.cold+0x500/0xa4a kernel/rcu/tree.c:2544
       update_process_times+0x32/0x80 kernel/time/timer.c:1635
       tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:161
       tick_sched_timer+0x47/0x130 kernel/time/tick-sched.c:1271
       __run_hrtimer kernel/time/hrtimer.c:1389 [inline]
       __hrtimer_run_queues+0x33e/0xde0 kernel/time/hrtimer.c:1451
       hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
       local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1035 [inline]
       smp_apic_timer_interrupt+0x120/0x570 arch/x86/kernel/apic/apic.c:1060
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
      RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50 kernel/kcov.c:95
      Code: 89 25 b4 6e ec 08 41 bc f4 ff ff ff e8 cd 5d ea ff 48 c7 05 9e 6e ec 08 00 00 00 00 e9 a4 e9 ff ff 90 90 90 90 90 90 90 90 90 <55> 48 89 e5 48 8b 75 08 65 48 8b 04 25 00 ee 01 00 65 8b 15 c8 60
      RSP: 0018:ffff8880ae807ce0 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
      RAX: ffff88806fd40640 RBX: dffffc0000000000 RCX: ffffffff863fbc56
      RDX: 0000000000000100 RSI: ffffffff863fbc1d RDI: ffff88808cf94228
      RBP: ffff8880ae807d10 R08: ffff88806fd40640 R09: ffffed1015d00f8b
      R10: ffffed1015d00f8a R11: 0000000000000003 R12: ffff88808cf941c0
      R13: 00000000fffff034 R14: ffff8882166cd840 R15: 0000000000000000
       rose_loopback_timer+0x30d/0x3f0 net/rose/rose_loopback.c:91
       call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
       expire_timers kernel/time/timer.c:1362 [inline]
       __run_timers kernel/time/timer.c:1681 [inline]
       __run_timers kernel/time/timer.c:1649 [inline]
       run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
       __do_softirq+0x266/0x95a kernel/softirq.c:293
       do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7b10dfe
    • Z
      net: rds: exchange of 8K and 1M pool · ed1866aa
      Zhu Yanjun 提交于
      [ Upstream commit 4b9fc7146249a6e0e3175d0acc033fdcd2bfcb17 ]
      
      Before the commit 490ea596 ("RDS: IB: move FMR code to its own file"),
      when the dirty_count is greater than 9/10 of max_items of 8K pool,
      1M pool is used, Vice versa. After the commit 490ea596 ("RDS: IB: move
      FMR code to its own file"), the above is removed. When we make the
      following tests.
      
      Server:
        rds-stress -r 1.1.1.16 -D 1M
      
      Client:
        rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M
      
      The following will appear.
      "
      connecting to 1.1.1.16:4000
      negotiated options, tasks will start in 2 seconds
      Starting up..header from 1.1.1.166:4001 to id 4001 bogus
      ..
      tsks  tx/s  rx/s tx+rx K/s  mbi K/s  mbo K/s tx us/c  rtt us
      cpu %
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
      ...
      "
      So this exchange between 8K and 1M pool is added back.
      
      Fixes: commit 490ea596 ("RDS: IB: move FMR code to its own file")
      Signed-off-by: NZhu Yanjun <yanjun.zhu@oracle.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed1866aa
    • E
      net/mlx5e: ethtool, Remove unsupported SFP EEPROM high pages query · 7da11d6a
      Erez Alfasi 提交于
      [ Upstream commit ace329f4ab3ba434be2adf618073c752d083b524 ]
      
      Querying EEPROM high pages data for SFP module is currently
      not supported by our driver and yet queried, resulting in
      invalid FW queries.
      
      Set the EEPROM ethtool data length to 256 for SFP module will
      limit the reading for page 0 only and prevent invalid FW queries.
      
      Fixes: bb64143e ("net/mlx5e: Add ethtool support for dump module EEPROM")
      Signed-off-by: NErez Alfasi <ereza@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7da11d6a
    • A
      mlxsw: spectrum: Fix autoneg status in ethtool · 829fd984
      Amit Cohen 提交于
      [ Upstream commit 151f0dddbbfe4c35c9c5b64873115aafd436af9d ]
      
      If link is down and autoneg is set to on/off, the status in ethtool does
      not change.
      
      The reason is when the link is down the function returns with zero
      before changing autoneg value.
      
      Move the checking of link state (up/down) to be performed after setting
      autoneg value, in order to be sure that autoneg will change in any case.
      
      Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
      Signed-off-by: NAmit Cohen <amitc@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      829fd984
    • Z
      ipv4: set the tcp_min_rtt_wlen range from 0 to one day · 250e51f8
      ZhangXiaoxu 提交于
      [ Upstream commit 19fad20d15a6494f47f85d869f00b11343ee5c78 ]
      
      There is a UBSAN report as below:
      UBSAN: Undefined behaviour in net/ipv4/tcp_input.c:2877:56
      signed integer overflow:
      2147483647 * 1000 cannot be represented in type 'int'
      CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.1.0-rc4-00058-g582549e #1
      Call Trace:
       <IRQ>
       dump_stack+0x8c/0xba
       ubsan_epilogue+0x11/0x60
       handle_overflow+0x12d/0x170
       ? ttwu_do_wakeup+0x21/0x320
       __ubsan_handle_mul_overflow+0x12/0x20
       tcp_ack_update_rtt+0x76c/0x780
       tcp_clean_rtx_queue+0x499/0x14d0
       tcp_ack+0x69e/0x1240
       ? __wake_up_sync_key+0x2c/0x50
       ? update_group_capacity+0x50/0x680
       tcp_rcv_established+0x4e2/0xe10
       tcp_v4_do_rcv+0x22b/0x420
       tcp_v4_rcv+0xfe8/0x1190
       ip_protocol_deliver_rcu+0x36/0x180
       ip_local_deliver+0x15b/0x1a0
       ip_rcv+0xac/0xd0
       __netif_receive_skb_one_core+0x7f/0xb0
       __netif_receive_skb+0x33/0xc0
       netif_receive_skb_internal+0x84/0x1c0
       napi_gro_receive+0x2a0/0x300
       receive_buf+0x3d4/0x2350
       ? detach_buf_split+0x159/0x390
       virtnet_poll+0x198/0x840
       ? reweight_entity+0x243/0x4b0
       net_rx_action+0x25c/0x770
       __do_softirq+0x19b/0x66d
       irq_exit+0x1eb/0x230
       do_IRQ+0x7a/0x150
       common_interrupt+0xf/0xf
       </IRQ>
      
      It can be reproduced by:
        echo 2147483647 > /proc/sys/net/ipv4/tcp_min_rtt_wlen
      
      Fixes: f6722583 ("tcp: track min RTT using windowed min-filter")
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      250e51f8
    • E
      ipv4: add sanity checks in ipv4_link_failure() · 07445fea
      Eric Dumazet 提交于
      [ Upstream commit 20ff83f10f113c88d0bb74589389b05250994c16 ]
      
      Before calling __ip_options_compile(), we need to ensure the network
      header is a an IPv4 one, and that it is already pulled in skb->head.
      
      RAW sockets going through a tunnel can end up calling ipv4_link_failure()
      with total garbage in the skb, or arbitrary lengthes.
      
      syzbot report :
      
      BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:355 [inline]
      BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
      Write of size 69 at addr ffff888096abf068 by task syz-executor.4/9204
      
      CPU: 0 PID: 9204 Comm: syz-executor.4 Not tainted 5.1.0-rc5+ #77
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       check_memory_region_inline mm/kasan/generic.c:185 [inline]
       check_memory_region+0x123/0x190 mm/kasan/generic.c:191
       memcpy+0x38/0x50 mm/kasan/common.c:133
       memcpy include/linux/string.h:355 [inline]
       __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
       __icmp_send+0x725/0x1400 net/ipv4/icmp.c:695
       ipv4_link_failure+0x29f/0x550 net/ipv4/route.c:1204
       dst_link_failure include/net/dst.h:427 [inline]
       vti6_xmit net/ipv6/ip6_vti.c:514 [inline]
       vti6_tnl_xmit+0x10d4/0x1c0c net/ipv6/ip6_vti.c:553
       __netdev_start_xmit include/linux/netdevice.h:4414 [inline]
       netdev_start_xmit include/linux/netdevice.h:4423 [inline]
       xmit_one net/core/dev.c:3292 [inline]
       dev_hard_start_xmit+0x1b2/0x980 net/core/dev.c:3308
       __dev_queue_xmit+0x271d/0x3060 net/core/dev.c:3878
       dev_queue_xmit+0x18/0x20 net/core/dev.c:3911
       neigh_direct_output+0x16/0x20 net/core/neighbour.c:1527
       neigh_output include/net/neighbour.h:508 [inline]
       ip_finish_output2+0x949/0x1740 net/ipv4/ip_output.c:229
       ip_finish_output+0x73c/0xd50 net/ipv4/ip_output.c:317
       NF_HOOK_COND include/linux/netfilter.h:278 [inline]
       ip_output+0x21f/0x670 net/ipv4/ip_output.c:405
       dst_output include/net/dst.h:444 [inline]
       NF_HOOK include/linux/netfilter.h:289 [inline]
       raw_send_hdrinc net/ipv4/raw.c:432 [inline]
       raw_sendmsg+0x1d2b/0x2f20 net/ipv4/raw.c:663
       inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xdd/0x130 net/socket.c:661
       sock_write_iter+0x27c/0x3e0 net/socket.c:988
       call_write_iter include/linux/fs.h:1866 [inline]
       new_sync_write+0x4c7/0x760 fs/read_write.c:474
       __vfs_write+0xe4/0x110 fs/read_write.c:487
       vfs_write+0x20c/0x580 fs/read_write.c:549
       ksys_write+0x14f/0x2d0 fs/read_write.c:599
       __do_sys_write fs/read_write.c:611 [inline]
       __se_sys_write fs/read_write.c:608 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:608
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458c29
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f293b44bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458c29
      RDX: 0000000000000014 RSI: 00000000200002c0 RDI: 0000000000000003
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f293b44c6d4
      R13: 00000000004c8623 R14: 00000000004ded68 R15: 00000000ffffffff
      
      The buggy address belongs to the page:
      page:ffffea00025aafc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0x1fffc0000000000()
      raw: 01fffc0000000000 0000000000000000 ffffffff025a0101 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888096abef80: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 f2
       ffff888096abf000: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff888096abf080: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
                               ^
       ffff888096abf100: 00 00 00 00 f1 f1 f1 f1 00 00 f3 f3 00 00 00 00
       ffff888096abf180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
      Acked-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07445fea
    • S
      x86/fpu: Don't export __kernel_fpu_{begin,end}() · d4ff57d0
      Sebastian Andrzej Siewior 提交于
      commit 12209993e98c5fa1855c467f22a24e3d5b8be205 upstream.
      
      There is one user of __kernel_fpu_begin() and before invoking it,
      it invokes preempt_disable(). So it could invoke kernel_fpu_begin()
      right away. The 32bit version of arch_efi_call_virt_setup() and
      arch_efi_call_virt_teardown() does this already.
      
      The comment above *kernel_fpu*() claims that before invoking
      __kernel_fpu_begin() preemption should be disabled and that KVM is a
      good example of doing it. Well, KVM doesn't do that since commit
      
        f775b13e ("x86,kvm: move qemu/guest FPU switching out to vcpu_run")
      
      so it is not an example anymore.
      
      With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can
      be made static and not exported anymore.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NRik van Riel <riel@surriel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Nicolai Stange <nstange@suse.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kvm ML <kvm@vger.kernel.org>
      Cc: linux-efi <linux-efi@vger.kernel.org>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181129150210.2k4mawt37ow6c2vq@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4ff57d0
    • J
      mm: Fix warning in insert_pfn() · 423497a9
      Jan Kara 提交于
      commit f2c57d91b0d96aa13ccff4e3b178038f17b00658 upstream.
      
      In DAX mode a write pagefault can race with write(2) in the following
      way:
      
      CPU0                            CPU1
                                      write fault for mapped zero page (hole)
      dax_iomap_rw()
        iomap_apply()
          xfs_file_iomap_begin()
            - allocates blocks
          dax_iomap_actor()
            invalidate_inode_pages2_range()
              - invalidates radix tree entries in given range
                                      dax_iomap_pte_fault()
                                        grab_mapping_entry()
                                          - no entry found, creates empty
                                        ...
                                        xfs_file_iomap_begin()
                                          - finds already allocated block
                                        ...
                                        vmf_insert_mixed_mkwrite()
                                          - WARNs and does nothing because there
                                            is still zero page mapped in PTE
              unmap_mapping_pages()
      
      This race results in WARN_ON from insert_pfn() and is occasionally
      triggered by fstest generic/344. Note that the race is otherwise
      harmless as before write(2) on CPU0 is finished, we will invalidate page
      tables properly and thus user of mmap will see modified data from
      write(2) from that point on. So just restrict the warning only to the
      case when the PFN in PTE is not zero page.
      
      Link: http://lkml.kernel.org/r/20180824154542.26872-1-jack@suse.czSigned-off-by: NJan Kara <jack@suse.cz>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      423497a9
    • D
      x86/retpolines: Disable switch jump tables when retpolines are enabled · e923c6b7
      Daniel Borkmann 提交于
      commit a9d57ef15cbe327fe54416dd194ee0ea66ae53a4 upstream.
      
      Commit ce02ef06fcf7 ("x86, retpolines: Raise limit for generating indirect
      calls from switch-case") raised the limit under retpolines to 20 switch
      cases where gcc would only then start to emit jump tables, and therefore
      effectively disabling the emission of slow indirect calls in this area.
      
      After this has been brought to attention to gcc folks [0], Martin Liska
      has then fixed gcc to align with clang by avoiding to generate switch jump
      tables entirely under retpolines. This is taking effect in gcc starting
      from stable version 8.4.0. Given kernel supports compilation with older
      versions of gcc where the fix is not being available or backported anymore,
      we need to keep the extra KBUILD_CFLAGS around for some time and generally
      set the -fno-jump-tables to align with what more recent gcc is doing
      automatically today.
      
      More than 20 switch cases are not expected to be fast-path critical, but
      it would still be good to align with gcc behavior for versions < 8.4.0 in
      order to have consistency across supported gcc versions. vmlinux size is
      slightly growing by 0.27% for older gcc. This flag is only set to work
      around affected gcc, no change for clang.
      
        [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952Suggested-by: NMartin Liska <mliska@suse.cz>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Björn Töpel<bjorn.topel@intel.com>
      Cc: Magnus Karlsson <magnus.karlsson@intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: David S. Miller <davem@davemloft.net>
      Link: https://lkml.kernel.org/r/20190325135620.14882-1-daniel@iogearbox.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e923c6b7
    • D
      x86, retpolines: Raise limit for generating indirect calls from switch-case · 6cfcff3c
      Daniel Borkmann 提交于
      commit ce02ef06fcf7a399a6276adb83f37373d10cbbe1 upstream.
      
      From networking side, there are numerous attempts to get rid of indirect
      calls in fast-path wherever feasible in order to avoid the cost of
      retpolines, for example, just to name a few:
      
        * 283c16a2dfd3 ("indirect call wrappers: helpers to speed-up indirect calls of builtin")
        * aaa5d90b395a ("net: use indirect call wrappers at GRO network layer")
        * 028e0a476684 ("net: use indirect call wrappers at GRO transport layer")
        * 356da6d0cde3 ("dma-mapping: bypass indirect calls for dma-direct")
        * 09772d92 ("bpf: avoid retpoline for lookup/update/delete calls on maps")
        * 10870dd89e95 ("netfilter: nf_tables: add direct calls for all builtin expressions")
        [...]
      
      Recent work on XDP from Björn and Magnus additionally found that manually
      transforming the XDP return code switch statement with more than 5 cases
      into if-else combination would result in a considerable speedup in XDP
      layer due to avoidance of indirect calls in CONFIG_RETPOLINE enabled
      builds. On i40e driver with XDP prog attached, a 20-26% speedup has been
      observed [0]. Aside from XDP, there are many other places later in the
      networking stack's critical path with similar switch-case
      processing. Rather than fixing every XDP-enabled driver and locations in
      stack by hand, it would be good to instead raise the limit where gcc would
      emit expensive indirect calls from the switch under retpolines and stick
      with the default as-is in case of !retpoline configured kernels. This would
      also have the advantage that for archs where this is not necessary, we let
      compiler select the underlying target optimization for these constructs and
      avoid potential slow-downs by if-else hand-rewrite.
      
      In case of gcc, this setting is controlled by case-values-threshold which
      has an architecture global default that selects 4 or 5 (latter if target
      does not have a case insn that compares the bounds) where some arch back
      ends like arm64 or s390 override it with their own target hooks, for
      example, in gcc commit db7a90aa0de5 ("S/390: Disable prediction of indirect
      branches") the threshold pretty much disables jump tables by limit of 20
      under retpoline builds.  Comparing gcc's and clang's default code
      generation on x86-64 under O2 level with retpoline build results in the
      following outcome for 5 switch cases:
      
      * gcc with -mindirect-branch=thunk-inline -mindirect-branch-register:
      
        # gdb -batch -ex 'disassemble dispatch' ./c-switch
        Dump of assembler code for function dispatch:
         0x0000000000400be0 <+0>:     cmp    $0x4,%edi
         0x0000000000400be3 <+3>:     ja     0x400c35 <dispatch+85>
         0x0000000000400be5 <+5>:     lea    0x915f8(%rip),%rdx        # 0x4921e4
         0x0000000000400bec <+12>:    mov    %edi,%edi
         0x0000000000400bee <+14>:    movslq (%rdx,%rdi,4),%rax
         0x0000000000400bf2 <+18>:    add    %rdx,%rax
         0x0000000000400bf5 <+21>:    callq  0x400c01 <dispatch+33>
         0x0000000000400bfa <+26>:    pause
         0x0000000000400bfc <+28>:    lfence
         0x0000000000400bff <+31>:    jmp    0x400bfa <dispatch+26>
         0x0000000000400c01 <+33>:    mov    %rax,(%rsp)
         0x0000000000400c05 <+37>:    retq
         0x0000000000400c06 <+38>:    nopw   %cs:0x0(%rax,%rax,1)
         0x0000000000400c10 <+48>:    jmpq   0x400c90 <fn_3>
         0x0000000000400c15 <+53>:    nopl   (%rax)
         0x0000000000400c18 <+56>:    jmpq   0x400c70 <fn_2>
         0x0000000000400c1d <+61>:    nopl   (%rax)
         0x0000000000400c20 <+64>:    jmpq   0x400c50 <fn_1>
         0x0000000000400c25 <+69>:    nopl   (%rax)
         0x0000000000400c28 <+72>:    jmpq   0x400c40 <fn_0>
         0x0000000000400c2d <+77>:    nopl   (%rax)
         0x0000000000400c30 <+80>:    jmpq   0x400cb0 <fn_4>
         0x0000000000400c35 <+85>:    push   %rax
         0x0000000000400c36 <+86>:    callq  0x40dd80 <abort>
        End of assembler dump.
      
      * clang with -mretpoline emitting search tree:
      
        # gdb -batch -ex 'disassemble dispatch' ./c-switch
        Dump of assembler code for function dispatch:
         0x0000000000400b30 <+0>:     cmp    $0x1,%edi
         0x0000000000400b33 <+3>:     jle    0x400b44 <dispatch+20>
         0x0000000000400b35 <+5>:     cmp    $0x2,%edi
         0x0000000000400b38 <+8>:     je     0x400b4d <dispatch+29>
         0x0000000000400b3a <+10>:    cmp    $0x3,%edi
         0x0000000000400b3d <+13>:    jne    0x400b52 <dispatch+34>
         0x0000000000400b3f <+15>:    jmpq   0x400c50 <fn_3>
         0x0000000000400b44 <+20>:    test   %edi,%edi
         0x0000000000400b46 <+22>:    jne    0x400b5c <dispatch+44>
         0x0000000000400b48 <+24>:    jmpq   0x400c20 <fn_0>
         0x0000000000400b4d <+29>:    jmpq   0x400c40 <fn_2>
         0x0000000000400b52 <+34>:    cmp    $0x4,%edi
         0x0000000000400b55 <+37>:    jne    0x400b66 <dispatch+54>
         0x0000000000400b57 <+39>:    jmpq   0x400c60 <fn_4>
         0x0000000000400b5c <+44>:    cmp    $0x1,%edi
         0x0000000000400b5f <+47>:    jne    0x400b66 <dispatch+54>
         0x0000000000400b61 <+49>:    jmpq   0x400c30 <fn_1>
         0x0000000000400b66 <+54>:    push   %rax
         0x0000000000400b67 <+55>:    callq  0x40dd20 <abort>
        End of assembler dump.
      
        For sake of comparison, clang without -mretpoline:
      
        # gdb -batch -ex 'disassemble dispatch' ./c-switch
        Dump of assembler code for function dispatch:
         0x0000000000400b30 <+0>:	cmp    $0x4,%edi
         0x0000000000400b33 <+3>:	ja     0x400b57 <dispatch+39>
         0x0000000000400b35 <+5>:	mov    %edi,%eax
         0x0000000000400b37 <+7>:	jmpq   *0x492148(,%rax,8)
         0x0000000000400b3e <+14>:	jmpq   0x400bf0 <fn_0>
         0x0000000000400b43 <+19>:	jmpq   0x400c30 <fn_4>
         0x0000000000400b48 <+24>:	jmpq   0x400c10 <fn_2>
         0x0000000000400b4d <+29>:	jmpq   0x400c20 <fn_3>
         0x0000000000400b52 <+34>:	jmpq   0x400c00 <fn_1>
         0x0000000000400b57 <+39>:	push   %rax
         0x0000000000400b58 <+40>:	callq  0x40dcf0 <abort>
        End of assembler dump.
      
      Raising the cases to a high number (e.g. 100) will still result in similar
      code generation pattern with clang and gcc as above, in other words clang
      generally turns off jump table emission by having an extra expansion pass
      under retpoline build to turn indirectbr instructions from their IR into
      switch instructions as a built-in -mno-jump-table lowering of a switch (in
      this case, even if IR input already contained an indirect branch).
      
      For gcc, adding --param=case-values-threshold=20 as in similar fashion as
      s390 in order to raise the limit for x86 retpoline enabled builds results
      in a small vmlinux size increase of only 0.13% (before=18,027,528
      after=18,051,192). For clang this option is ignored due to i) not being
      needed as mentioned and ii) not having above cmdline
      parameter. Non-retpoline-enabled builds with gcc continue to use the
      default case-values-threshold setting, so nothing changes here.
      
      [0] https://lore.kernel.org/netdev/20190129095754.9390-1-bjorn.topel@gmail.com/
          and "The Path to DPDK Speeds for AF_XDP", LPC 2018, networking track:
        - http://vger.kernel.org/lpc_net2018_talks/lpc18_pres_af_xdp_perf-v3.pdf
        - http://vger.kernel.org/lpc_net2018_talks/lpc18_paper_af_xdp_perf-v2.pdfSigned-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Acked-by: NBjörn Töpel <bjorn.topel@intel.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: netdev@vger.kernel.org
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Magnus Karlsson <magnus.karlsson@intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Link: https://lkml.kernel.org/r/20190221221941.29358-1-daniel@iogearbox.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6cfcff3c
    • A
      Fix aio_poll() races · e9e47779
      Al Viro 提交于
      commit af5c72b1fc7a00aa484e90b0c4e0eeb582545634 upstream.
      
      aio_poll() has to cope with several unpleasant problems:
      	* requests that might stay around indefinitely need to
      be made visible for io_cancel(2); that must not be done to
      a request already completed, though.
      	* in cases when ->poll() has placed us on a waitqueue,
      wakeup might have happened (and request completed) before ->poll()
      returns.
      	* worse, in some early wakeup cases request might end
      up re-added into the queue later - we can't treat "woken up and
      currently not in the queue" as "it's not going to stick around
      indefinitely"
      	* ... moreover, ->poll() might have decided not to
      put it on any queues to start with, and that needs to be distinguished
      from the previous case
      	* ->poll() might have tried to put us on more than one queue.
      Only the first will succeed for aio poll, so we might end up missing
      wakeups.  OTOH, we might very well notice that only after the
      wakeup hits and request gets completed (all before ->poll() gets
      around to the second poll_wait()).  In that case it's too late to
      decide that we have an error.
      
      req->woken was an attempt to deal with that.  Unfortunately, it was
      broken.  What we need to keep track of is not that wakeup has happened -
      the thing might come back after that.  It's that async reference is
      already gone and won't come back, so we can't (and needn't) put the
      request on the list of cancellables.
      
      The easiest case is "request hadn't been put on any waitqueues"; we
      can tell by seeing NULL apt.head, and in that case there won't be
      anything async.  We should either complete the request ourselves
      (if vfs_poll() reports anything of interest) or return an error.
      
      In all other cases we get exclusion with wakeups by grabbing the
      queue lock.
      
      If request is currently on queue and we have something interesting
      from vfs_poll(), we can steal it and complete the request ourselves.
      
      If it's on queue and vfs_poll() has not reported anything interesting,
      we either put it on the cancellable list, or, if we know that it
      hadn't been put on all queues ->poll() wanted it on, we steal it and
      return an error.
      
      If it's _not_ on queue, it's either been already dealt with (in which
      case we do nothing), or there's aio_poll_complete_work() about to be
      executed.  In that case we either put it on the cancellable list,
      or, if we know it hadn't been put on all queues ->poll() wanted it on,
      simulate what cancel would've done.
      
      It's a lot more convoluted than I'd like it to be.  Single-consumer APIs
      suck, and unfortunately aio is not an exception...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9e47779
    • A
      aio: store event at final iocb_put() · aab66dfb
      Al Viro 提交于
      commit 2bb874c0d873d13bd9b9b9c6d7b7c4edab18c8b4 upstream.
      
      Instead of having aio_complete() set ->ki_res.{res,res2}, do that
      explicitly in its callers, drop the reference (as aio_complete()
      used to do) and delay the rest until the final iocb_put().
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aab66dfb
    • A
      aio: keep io_event in aio_kiocb · c20202c5
      Al Viro 提交于
      commit a9339b7855094ba11a97e8822ae038135e879e79 upstream.
      
      We want to separate forming the resulting io_event from putting it
      into the ring buffer.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c20202c5
    • A
      aio: fold lookup_kiocb() into its sole caller · 592ea630
      Al Viro 提交于
      commit 833f4154ed560232120bc475935ee1d6a20e159f upstream.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      592ea630
    • L
      pin iocb through aio. · c7f2525a
      Linus Torvalds 提交于
      commit b53119f13a04879c3bf502828d99d13726639ead upstream.
      
      aio_poll() is not the only case that needs file pinned; worse, while
      aio_read()/aio_write() can live without pinning iocb itself, the
      proof is rather brittle and can easily break on later changes.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7f2525a
    • L
      aio: simplify - and fix - fget/fput for io_submit() · d6b2615f
      Linus Torvalds 提交于
      commit 84c4e1f89fefe70554da0ab33be72c9be7994379 upstream.
      
      Al Viro root-caused a race where the IOCB_CMD_POLL handling of
      fget/fput() could cause us to access the file pointer after it had
      already been freed:
      
       "In more details - normally IOCB_CMD_POLL handling looks so:
      
         1) io_submit(2) allocates aio_kiocb instance and passes it to
            aio_poll()
      
         2) aio_poll() resolves the descriptor to struct file by req->file =
            fget(iocb->aio_fildes)
      
         3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
            aio_kiocb to 2 (bumps by 1, that is).
      
         4) aio_poll() calls vfs_poll(). After sanity checks (basically,
            "poll_wait() had been called and only once") it locks the queue.
            That's what the extra reference to iocb had been for - we know we
            can safely access it.
      
         5) With queue locked, we check if ->woken has already been set to
            true (by aio_poll_wake()) and, if it had been, we unlock the
            queue, drop a reference to aio_kiocb and bugger off - at that
            point it's a responsibility to aio_poll_wake() and the stuff
            called/scheduled by it. That code will drop the reference to file
            in req->file, along with the other reference to our aio_kiocb.
      
         6) otherwise, we see whether we need to wait. If we do, we unlock the
            queue, drop one reference to aio_kiocb and go away - eventual
            wakeup (or cancel) will deal with the reference to file and with
            the other reference to aio_kiocb
      
         7) otherwise we remove ourselves from waitqueue (still under the
            queue lock), so that wakeup won't get us. No async activity will
            be happening, so we can safely drop req->file and iocb ourselves.
      
        If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
        won't get freed under us, so we can do all the checks and locking
        safely. And we don't touch ->file if we detect that case.
      
        However, vfs_poll() most certainly *does* touch the file it had been
        given. So wakeup coming while we are still in ->poll() might end up
        doing fput() on that file. That case is not too rare, and usually we
        are saved by the still present reference from descriptor table - that
        fput() is not the final one.
      
        But if another thread closes that descriptor right after our fget()
        and wakeup does happen before ->poll() returns, we are in trouble -
        final fput() done while we are in the middle of a method:
      
      Al also wrote a patch to take an extra reference to the file descriptor
      to fix this, but I instead suggested we just streamline the whole file
      pointer handling by submit_io() so that the generic aio submission code
      simply keeps the file pointer around until the aio has completed.
      
      Fixes: bfe4037e ("aio: implement IOCB_CMD_POLL")
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6b2615f
    • M
      aio: initialize kiocb private in case any filesystems expect it. · 2afa01cd
      Mike Marshall 提交于
      commit ec51f8ee1e63498e9f521ec0e5a6d04622bb2c67 upstream.
      
      A recent optimization had left private uninitialized.
      
      Fixes: 2bc4ca9bb600 ("aio: don't zero entire aio_kiocb aio_get_req()")
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMike Marshall <hubcap@omnibond.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2afa01cd
    • J
      aio: abstract out io_event filler helper · a812f7b6
      Jens Axboe 提交于
      commit 875736bb3f3ded168469f6a14df7a938416a99d5 upstream.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a812f7b6
    • J
      aio: split out iocb copy from io_submit_one() · d384f8b8
      Jens Axboe 提交于
      commit 88a6f18b950e2e4dce57d31daa151105f4f3dcff upstream.
      
      In preparation of handing in iocbs in a different fashion as well. Also
      make it clear that the iocb being passed in isn't modified, by marking
      it const throughout.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d384f8b8
    • J
      aio: use iocb_put() instead of open coding it · 4d677689
      Jens Axboe 提交于
      commit 71ebc6fef0f53459f37fb39e1466792232fa52ee upstream.
      
      Replace the percpu_ref_put() + kmem_cache_free() with a call to
      iocb_put() instead.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d677689
    • J
      aio: don't zero entire aio_kiocb aio_get_req() · ef529eea
      Jens Axboe 提交于
      commit 2bc4ca9bb600cbe36941da2b2a67189fc4302a04 upstream.
      
      It's 192 bytes, fairly substantial. Most items don't need to be cleared,
      especially not upfront. Clear the ones we do need to clear, and leave
      the other ones for setup when the iocb is prepared and submitted.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef529eea
    • C
      aio: separate out ring reservation from req allocation · 730198c8
      Christoph Hellwig 提交于
      commit 432c79978c33ecef91b1b04cea6936c20810da29 upstream.
      
      This is in preparation for certain types of IO not needing a ring
      reserveration.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      730198c8
    • J
      aio: use assigned completion handler · b3373253
      Jens Axboe 提交于
      commit bc9bff61624ac33b7c95861abea1af24ee7a94fc upstream.
      
      We know this is a read/write request, but in preparation for
      having different kinds of those, ensure that we call the assigned
      handler instead of assuming it's aio_complete_rq().
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3373253
    • C
      aio: clear IOCB_HIPRI · 9101cbe7
      Christoph Hellwig 提交于
      commit 154989e45fd8de9bfb52bbd6e5ea763e437e54c5 upstream.
      
      No one is going to poll for aio (yet), so we must clear the HIPRI
      flag, as we would otherwise send it down the poll queues, where no
      one will be polling for completions.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      
      IOCB_HIPRI, not RWF_HIPRI.
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9101cbe7
    • E
      rxrpc: fix race condition in rxrpc_input_packet() · 920ecc72
      Eric Dumazet 提交于
      commit 032be5f19a94de51093851757089133dcc1e92aa upstream.
      
      After commit 5271953c ("rxrpc: Use the UDP encap_rcv hook"),
      rxrpc_input_packet() is directly called from lockless UDP receive
      path, under rcu_read_lock() protection.
      
      It must therefore use RCU rules :
      
      - udp_sk->sk_user_data can be cleared at any point in this function.
        rcu_dereference_sk_user_data() is what we need here.
      
      - Also, since sk_user_data might have been set in rxrpc_open_socket()
        we must observe a proper RCU grace period before kfree(local) in
        rxrpc_lookup_local()
      
      v4: @local can be NULL in xrpc_lookup_local() as reported by kbuild test robot <lkp@intel.com>
              and Julia Lawall <julia.lawall@lip6.fr>, thanks !
      
      v3,v2 : addressed David Howells feedback, thanks !
      
      syzbot reported :
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 19236 Comm: syz-executor703 Not tainted 5.1.0-rc6 #79
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__lock_acquire+0xbef/0x3fb0 kernel/locking/lockdep.c:3573
      Code: 00 0f 85 a5 1f 00 00 48 81 c4 10 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 21 00 00 49 81 7d 00 20 54 9c 89 0f 84 cf f4
      RSP: 0018:ffff88809d7aef58 EFLAGS: 00010002
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000026 RSI: 0000000000000000 RDI: 0000000000000001
      RBP: ffff88809d7af090 R08: 0000000000000001 R09: 0000000000000001
      R10: ffffed1015d05bc7 R11: ffff888089428600 R12: 0000000000000000
      R13: 0000000000000130 R14: 0000000000000001 R15: 0000000000000001
      FS:  00007f059044d700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004b6040 CR3: 00000000955ca000 CR4: 00000000001406f0
      Call Trace:
       lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4211
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
       skb_queue_tail+0x26/0x150 net/core/skbuff.c:2972
       rxrpc_reject_packet net/rxrpc/input.c:1126 [inline]
       rxrpc_input_packet+0x4a0/0x5536 net/rxrpc/input.c:1414
       udp_queue_rcv_one_skb+0xaf2/0x1780 net/ipv4/udp.c:2011
       udp_queue_rcv_skb+0x128/0x730 net/ipv4/udp.c:2085
       udp_unicast_rcv_skb.isra.0+0xb9/0x360 net/ipv4/udp.c:2245
       __udp4_lib_rcv+0x701/0x2ca0 net/ipv4/udp.c:2301
       udp_rcv+0x22/0x30 net/ipv4/udp.c:2482
       ip_protocol_deliver_rcu+0x60/0x8f0 net/ipv4/ip_input.c:208
       ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
       NF_HOOK include/linux/netfilter.h:289 [inline]
       NF_HOOK include/linux/netfilter.h:283 [inline]
       ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:255
       dst_input include/net/dst.h:450 [inline]
       ip_rcv_finish+0x1e1/0x300 net/ipv4/ip_input.c:413
       NF_HOOK include/linux/netfilter.h:289 [inline]
       NF_HOOK include/linux/netfilter.h:283 [inline]
       ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:523
       __netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4987
       __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5099
       netif_receive_skb_internal+0x117/0x660 net/core/dev.c:5202
       napi_frags_finish net/core/dev.c:5769 [inline]
       napi_gro_frags+0xade/0xd10 net/core/dev.c:5843
       tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027
       call_write_iter include/linux/fs.h:1866 [inline]
       do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681
       do_iter_write fs/read_write.c:957 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:938
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002
       do_writev+0x15e/0x370 fs/read_write.c:1037
       __do_sys_writev fs/read_write.c:1110 [inline]
       __se_sys_writev fs/read_write.c:1107 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 5271953c ("rxrpc: Use the UDP encap_rcv hook")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      920ecc72
    • T
      net/rds: Check address length before reading address family · 5a228d5d
      Tetsuo Handa 提交于
      commit dd3ac9a684358b8c1d5c432ca8322aaf5e4f28ee upstream.
      
      syzbot is reporting uninitialized value at rds_connect() [1] and
      rds_bind() [2]. This is because syzbot is passing ulen == 0 whereas
      these functions expect that it is safe to access sockaddr->family field
      in order to determine minimal address length for validation.
      
      [1] https://syzkaller.appspot.com/bug?id=f4e61c010416c1e6f0fa3ffe247561b60a50ad71
      [2] https://syzkaller.appspot.com/bug?id=a4bf9e41b7e055c3823fdcd83e8c58ca7270e38fReported-by: Nsyzbot <syzbot+0049bebbf3042dbd2e8f@syzkaller.appspotmail.com>
      Reported-by: Nsyzbot <syzbot+915c9f99f3dbc4bd6cd1@syzkaller.appspotmail.com>
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a228d5d
    • Y
      net: netrom: Fix error cleanup path of nr_proto_init · e30203e4
      YueHaibing 提交于
      commit d3706566ae3d92677b932dd156157fd6c72534b1 upstream.
      
      Syzkaller report this:
      
      BUG: unable to handle kernel paging request at fffffbfff830524b
      PGD 237fe8067 P4D 237fe8067 PUD 237e64067 PMD 1c9716067 PTE 0
      Oops: 0000 [#1] SMP KASAN PTI
      CPU: 1 PID: 4465 Comm: syz-executor.0 Not tainted 5.0.0+ #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:__list_add_valid+0x21/0xe0 lib/list_debug.c:23
      Code: 8b 0c 24 e9 17 fd ff ff 90 55 48 89 fd 48 8d 7a 08 53 48 89 d3 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 48 83 ec 08 <80> 3c 02 00 0f 85 8b 00 00 00 48 8b 53 08 48 39 f2 75 35 48 89 f2
      RSP: 0018:ffff8881ea2278d0 EFLAGS: 00010282
      RAX: dffffc0000000000 RBX: ffffffffc1829250 RCX: 1ffff1103d444ef4
      RDX: 1ffffffff830524b RSI: ffffffff85659300 RDI: ffffffffc1829258
      RBP: ffffffffc1879250 R08: fffffbfff0acb269 R09: fffffbfff0acb269
      R10: ffff8881ea2278f0 R11: fffffbfff0acb268 R12: ffffffffc1829250
      R13: dffffc0000000000 R14: 0000000000000008 R15: ffffffffc187c830
      FS:  00007fe0361df700(0000) GS:ffff8881f7300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: fffffbfff830524b CR3: 00000001eb39a001 CR4: 00000000007606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       __list_add include/linux/list.h:60 [inline]
       list_add include/linux/list.h:79 [inline]
       proto_register+0x444/0x8f0 net/core/sock.c:3375
       nr_proto_init+0x73/0x4b3 [netrom]
       ? 0xffffffffc1628000
       ? 0xffffffffc1628000
       do_one_initcall+0xbc/0x47d init/main.c:887
       do_init_module+0x1b5/0x547 kernel/module.c:3456
       load_module+0x6405/0x8c10 kernel/module.c:3804
       __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
       do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007fe0361dec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
      RBP: 00007fe0361dec70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe0361df6bc
      R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      Modules linked in: netrom(+) ax25 fcrypt pcbc af_alg arizona_ldo1 v4l2_common videodev media v4l2_dv_timings hdlc ide_cd_mod snd_soc_sigmadsp_regmap snd_soc_sigmadsp intel_spi_platform intel_spi mtd spi_nor snd_usbmidi_lib usbcore lcd ti_ads7950 hi6421_regulator snd_soc_kbl_rt5663_max98927 snd_soc_hdac_hdmi snd_hda_ext_core snd_hda_core snd_soc_rt5663 snd_soc_core snd_pcm_dmaengine snd_compress snd_soc_rl6231 mac80211 rtc_rc5t583 spi_slave_time leds_pwm hid_gt683r hid industrialio_triggered_buffer kfifo_buf industrialio ir_kbd_i2c rc_core led_class_flash dwc_xlgmac snd_ymfpci gameport snd_mpu401_uart snd_rawmidi snd_ac97_codec snd_pcm ac97_bus snd_opl3_lib snd_timer snd_seq_device snd_hwdep snd soundcore iptable_security iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan
       bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun joydev mousedev ppdev tpm kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ide_pci_generic piix aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ide_core psmouse input_leds i2c_piix4 serio_raw intel_agp intel_gtt ata_generic agpgart pata_acpi parport_pc rtc_cmos parport floppy sch_fq_codel ip_tables x_tables sha1_ssse3 sha1_generic ipv6 [last unloaded: rxrpc]
      Dumping ftrace buffer:
         (ftrace buffer empty)
      CR2: fffffbfff830524b
      ---[ end trace 039ab24b305c4b19 ]---
      
      If nr_proto_init failed, it may forget to call proto_unregister,
      tiggering this issue.This patch rearrange code of nr_proto_init
      to avoid such issues.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e30203e4
    • X
      tipc: check link name with right length in tipc_nl_compat_link_set · a0cb0faa
      Xin Long 提交于
      commit 8c63bf9ab4be8b83bd8c34aacfd2f1d2c8901c8a upstream.
      
      A similar issue as fixed by Patch "tipc: check bearer name with right
      length in tipc_nl_compat_bearer_enable" was also found by syzbot in
      tipc_nl_compat_link_set().
      
      The length to check with should be 'TLV_GET_DATA_LEN(msg->req) -
      offsetof(struct tipc_link_config, name)'.
      
      Reported-by: syzbot+de00a87b8644a582ae79@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0cb0faa
    • X
      tipc: check bearer name with right length in tipc_nl_compat_bearer_enable · f21fae80
      Xin Long 提交于
      commit 6f07e5f06c8712acc423485f657799fc8e11e56c upstream.
      
      Syzbot reported the following crash:
      
      BUG: KMSAN: uninit-value in memchr+0xce/0x110 lib/string.c:961
        memchr+0xce/0x110 lib/string.c:961
        string_is_valid net/tipc/netlink_compat.c:176 [inline]
        tipc_nl_compat_bearer_enable+0x2c4/0x910 net/tipc/netlink_compat.c:401
        __tipc_nl_compat_doit net/tipc/netlink_compat.c:321 [inline]
        tipc_nl_compat_doit+0x3aa/0xaf0 net/tipc/netlink_compat.c:354
        tipc_nl_compat_handle net/tipc/netlink_compat.c:1162 [inline]
        tipc_nl_compat_recv+0x1ae7/0x2750 net/tipc/netlink_compat.c:1265
        genl_family_rcv_msg net/netlink/genetlink.c:601 [inline]
        genl_rcv_msg+0x185f/0x1a60 net/netlink/genetlink.c:626
        netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2477
        genl_rcv+0x63/0x80 net/netlink/genetlink.c:637
        netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
        netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1336
        netlink_sendmsg+0x127f/0x1300 net/netlink/af_netlink.c:1917
        sock_sendmsg_nosec net/socket.c:622 [inline]
        sock_sendmsg net/socket.c:632 [inline]
      
      Uninit was created at:
        __alloc_skb+0x309/0xa20 net/core/skbuff.c:208
        alloc_skb include/linux/skbuff.h:1012 [inline]
        netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
        netlink_sendmsg+0xb82/0x1300 net/netlink/af_netlink.c:1892
        sock_sendmsg_nosec net/socket.c:622 [inline]
        sock_sendmsg net/socket.c:632 [inline]
      
      It was triggered when the bearer name size < TIPC_MAX_BEARER_NAME,
      it would check with a wrong len/TLV_GET_DATA_LEN(msg->req), which
      also includes priority and disc_domain length.
      
      This patch is to fix it by checking it with a right length:
      'TLV_GET_DATA_LEN(msg->req) - offsetof(struct tipc_bearer_config, name)'.
      
      Reported-by: syzbot+8b707430713eb46e1e45@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f21fae80
    • Y
      fm10k: Fix a potential NULL pointer dereference · 9b9b0df4
      Yue Haibing 提交于
      commit 01ca667133d019edc9f0a1f70a272447c84ec41f upstream.
      
      Syzkaller report this:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN PTI
      CPU: 0 PID: 4378 Comm: syz-executor.0 Tainted: G         C        5.0.0+ #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:__lock_acquire+0x95b/0x3200 kernel/locking/lockdep.c:3573
      Code: 00 0f 85 28 1e 00 00 48 81 c4 08 01 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 24 00 00 49 81 7d 00 e0 de 03 a6 41 bc 00 00
      RSP: 0018:ffff8881e3c07a40 EFLAGS: 00010002
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000080
      RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
      R10: ffff8881e3c07d98 R11: ffff8881c7f21f80 R12: 0000000000000001
      R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001
      FS:  00007fce2252e700(0000) GS:ffff8881f2400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fffc7eb0228 CR3: 00000001e5bea002 CR4: 00000000007606f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       lock_acquire+0xff/0x2c0 kernel/locking/lockdep.c:4211
       __mutex_lock_common kernel/locking/mutex.c:925 [inline]
       __mutex_lock+0xdf/0x1050 kernel/locking/mutex.c:1072
       drain_workqueue+0x24/0x3f0 kernel/workqueue.c:2934
       destroy_workqueue+0x23/0x630 kernel/workqueue.c:4319
       __do_sys_delete_module kernel/module.c:1018 [inline]
       __se_sys_delete_module kernel/module.c:961 [inline]
       __x64_sys_delete_module+0x30c/0x480 kernel/module.c:961
       do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007fce2252dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140
      RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fce2252e6bc
      R13: 00000000004bcca9 R14: 00000000006f6b48 R15: 00000000ffffffff
      
      If alloc_workqueue fails, it should return -ENOMEM, otherwise may
      trigger this NULL pointer dereference while unloading drivers.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: 0a38c17a ("fm10k: Remove create_workqueue")
      Signed-off-by: NYue Haibing <yuehaibing@huawei.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b9b0df4
    • F
      netfilter: ebtables: CONFIG_COMPAT: drop a bogus WARN_ON · f7dc13d6
      Florian Westphal 提交于
      commit 7caa56f006e9d712b44f27b32520c66420d5cbc6 upstream.
      
      It means userspace gave us a ruleset where there is some other
      data after the ebtables target but before the beginning of the next rule.
      
      Fixes: 81e675c2 ("netfilter: ebtables: add CONFIG_COMPAT support")
      Reported-by: syzbot+659574e7bcc7f7eb4df7@syzkaller.appspotmail.com
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7dc13d6
    • T
      NFS: Forbid setting AF_INET6 to "struct sockaddr_in"->sin_family. · 94ad68a6
      Tetsuo Handa 提交于
      commit 7c2bd9a39845bfb6d72ddb55ce737650271f6f96 upstream.
      
      syzbot is reporting uninitialized value at rpc_sockaddr2uaddr() [1]. This
      is because syzbot is setting AF_INET6 to "struct sockaddr_in"->sin_family
      (which is embedded into user-visible "struct nfs_mount_data" structure)
      despite nfs23_validate_mount_data() cannot pass sizeof(struct sockaddr_in6)
      bytes of AF_INET6 address to rpc_sockaddr2uaddr().
      
      Since "struct nfs_mount_data" structure is user-visible, we can't change
      "struct nfs_mount_data" to use "struct sockaddr_storage". Therefore,
      assuming that everybody is using AF_INET family when passing address via
      "struct nfs_mount_data"->addr, reject if its sin_family is not AF_INET.
      
      [1] https://syzkaller.appspot.com/bug?id=599993614e7cbbf66bc2656a919ab2a95fb5d75cReported-by: Nsyzbot <syzbot+047a11c361b872896a4f@syzkaller.appspotmail.com>
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94ad68a6
    • L
      sched/deadline: Correctly handle active 0-lag timers · 245a94a0
      luca abeni 提交于
      commit 1b02cd6a2d7f3e2a6a5262887d2cb2912083e42f upstream.
      
      syzbot reported the following warning:
      
         [ ] WARNING: CPU: 4 PID: 17089 at kernel/sched/deadline.c:255 task_non_contending+0xae0/0x1950
      
      line 255 of deadline.c is:
      
      	WARN_ON(hrtimer_active(&dl_se->inactive_timer));
      
      in task_non_contending().
      
      Unfortunately, in some cases (for example, a deadline task
      continuosly blocking and waking immediately) it can happen that
      a task blocks (and task_non_contending() is called) while the
      0-lag timer is still active.
      
      In this case, the safest thing to do is to immediately decrease
      the running bandwidth of the task, without trying to re-arm the 0-lag timer.
      Signed-off-by: Nluca abeni <luca.abeni@santannapisa.it>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NJuri Lelli <juri.lelli@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: chengjian (D) <cj.chengjian@huawei.com>
      Link: https://lkml.kernel.org/r/20190325131530.34706-1-luca.abeni@santannapisa.itSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      245a94a0