1. 01 Mar, 2020 4 commits
  2. 29 Feb, 2020 4 commits
    • Dan Carpenter's avatar
      ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() · 37b0b6b8
      Dan Carpenter authored
      If sbi->s_flex_groups_allocated is zero and the first allocation fails
      then this code will crash.  The problem is that "i--" will set "i" to
      -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1
      is type promoted to unsigned and becomes UINT_MAX.  Since UINT_MAX
      is more than zero, the condition is true so we call kvfree(new_groups[-1]).
      The loop will carry on freeing invalid memory until it crashes.
      
      Fixes: 7c990728 ("ext4: fix potential race between s_flex_groups online resizing and access")
      Reviewed-by: default avatarSuraj Jitindar Singh <surajjs@amazon.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountainSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      37b0b6b8
    • Wolfram Sang's avatar
      macintosh: therm_windtunnel: fix regression when instantiating devices · 38b17afb
      Wolfram Sang authored
      Removing attach_adapter from this driver caused a regression for at
      least some machines. Those machines had the sensors described in their
      DT, too, so they didn't need manual creation of the sensor devices. The
      old code worked, though, because manual creation came first. Creation of
      DT devices then failed later and caused error logs, but the sensors
      worked nonetheless because of the manually created devices.
      
      When removing attach_adaper, manual creation now comes later and loses
      the race. The sensor devices were already registered via DT, yet with
      another binding, so the driver could not be bound to it.
      
      This fix refactors the code to remove the race and only manually creates
      devices if there are no DT nodes present. Also, the DT binding is updated
      to match both, the DT and manually created devices. Because we don't
      know which device creation will be used at runtime, the code to start
      the kthread is moved to do_probe() which will be called by both methods.
      
      Fixes: 3e7bed52 ("macintosh: therm_windtunnel: drop using attach_adapter")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723Reported-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Tested-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org # v4.19+
      38b17afb
    • Qian Cai's avatar
      jbd2: fix data races at struct journal_head · 6c5d9112
      Qian Cai authored
      journal_head::b_transaction and journal_head::b_next_transaction could
      be accessed concurrently as noticed by KCSAN,
      
       LTP: starting fsync04
       /dev/zero: Can't open blockdev
       EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
       EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
       ==================================================================
       BUG: KCSAN: data-race in __jbd2_journal_refile_buffer [jbd2] / jbd2_write_access_granted [jbd2]
      
       write to 0xffff99f9b1bd0e30 of 8 bytes by task 25721 on cpu 70:
        __jbd2_journal_refile_buffer+0xdd/0x210 [jbd2]
        __jbd2_journal_refile_buffer at fs/jbd2/transaction.c:2569
        jbd2_journal_commit_transaction+0x2d15/0x3f20 [jbd2]
        (inlined by) jbd2_journal_commit_transaction at fs/jbd2/commit.c:1034
        kjournald2+0x13b/0x450 [jbd2]
        kthread+0x1cd/0x1f0
        ret_from_fork+0x27/0x50
      
       read to 0xffff99f9b1bd0e30 of 8 bytes by task 25724 on cpu 68:
        jbd2_write_access_granted+0x1b2/0x250 [jbd2]
        jbd2_write_access_granted at fs/jbd2/transaction.c:1155
        jbd2_journal_get_write_access+0x2c/0x60 [jbd2]
        __ext4_journal_get_write_access+0x50/0x90 [ext4]
        ext4_mb_mark_diskspace_used+0x158/0x620 [ext4]
        ext4_mb_new_blocks+0x54f/0xca0 [ext4]
        ext4_ind_map_blocks+0xc79/0x1b40 [ext4]
        ext4_map_blocks+0x3b4/0x950 [ext4]
        _ext4_get_block+0xfc/0x270 [ext4]
        ext4_get_block+0x3b/0x50 [ext4]
        __block_write_begin_int+0x22e/0xae0
        __block_write_begin+0x39/0x50
        ext4_write_begin+0x388/0xb50 [ext4]
        generic_perform_write+0x15d/0x290
        ext4_buffered_write_iter+0x11f/0x210 [ext4]
        ext4_file_write_iter+0xce/0x9e0 [ext4]
        new_sync_write+0x29c/0x3b0
        __vfs_write+0x92/0xa0
        vfs_write+0x103/0x260
        ksys_write+0x9d/0x130
        __x64_sys_write+0x4c/0x60
        do_syscall_64+0x91/0xb05
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       5 locks held by fsync04/25724:
        #0: ffff99f9911093f8 (sb_writers#13){.+.+}, at: vfs_write+0x21c/0x260
        #1: ffff99f9db4c0348 (&sb->s_type->i_mutex_key#15){+.+.}, at: ext4_buffered_write_iter+0x65/0x210 [ext4]
        #2: ffff99f5e7dfcf58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
        #3: ffff99f9db4c0168 (&ei->i_data_sem){++++}, at: ext4_map_blocks+0x176/0x950 [ext4]
        #4: ffffffff99086b40 (rcu_read_lock){....}, at: jbd2_write_access_granted+0x4e/0x250 [jbd2]
       irq event stamp: 1407125
       hardirqs last  enabled at (1407125): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
       hardirqs last disabled at (1407124): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
       softirqs last  enabled at (1405528): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
       softirqs last disabled at (1405521): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0
      
       Reported by Kernel Concurrency Sanitizer on:
       CPU: 68 PID: 25724 Comm: fsync04 Tainted: G L 5.6.0-rc2-next-20200221+ #7
       Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
      
      The plain reads are outside of jh->b_state_lock critical section which result
      in data races. Fix them by adding pairs of READ|WRITE_ONCE().
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Link: https://lore.kernel.org/r/20200222043111.2227-1-cai@lca.pwSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      6c5d9112
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 7557c1b3
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Four small fixes.
      
        Three are in drivers for fairly obvious bugs. The fourth is a set of
        regressions introduced by the compat_ioctl changes because some of the
        compat updates wrongly replaced .ioctl instead of .compat_ioctl"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: compat_ioctl: cdrom: Replace .ioctl with .compat_ioctl in four appropriate places
        scsi: zfcp: fix wrong data and display format of SFP+ temperature
        scsi: sd_sbc: Fix sd_zbc_report_zones()
        scsi: libfc: free response frame from GPN_ID
      7557c1b3
  3. 28 Feb, 2020 21 commits
  4. 27 Feb, 2020 11 commits
    • Lukas Bulwahn's avatar
      MAINTAINERS: Correct Cadence PCI driver path · 5901b51f
      Lukas Bulwahn authored
      de80f95c ("PCI: cadence: Move all files to per-device cadence
      directory") moved files of the PCI cadence drivers, but did not update the
      MAINTAINERS entry.
      
      Since then, ./scripts/get_maintainer.pl --self-test complains:
      
        warning: no file matches F: drivers/pci/controller/pcie-cadence*
      
      Repair the MAINTAINERS entry.
      
      Link: https://lore.kernel.org/r/20200221185402.4703-1-lukas.bulwahn@gmail.comSigned-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      5901b51f
    • Jens Axboe's avatar
      io_uring: fix 32-bit compatability with sendmsg/recvmsg · d8768362
      Jens Axboe authored
      We must set MSG_CMSG_COMPAT if we're in compatability mode, otherwise
      the iovec import for these commands will not do the right thing and fail
      the command with -EINVAL.
      
      Found by running the test suite compiled as 32-bit.
      
      Cc: stable@vger.kernel.org
      Fixes: aa1fa28f ("io_uring: add support for recvmsg()")
      Fixes: 0fa03c62 ("io_uring: add support for sendmsg()")
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      d8768362
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Fix masking of egress port · 3ee339eb
      Andrew Lunn authored
      Add missing ~ to the usage of the mask.
      Reported-by: default avatarKevin Benson <Kevin.Benson@zii.aero>
      Reported-by: default avatarChris Healy <Chris.Healy@zii.aero>
      Fixes: 5c74c54c ("net: dsa: mv88e6xxx: Split monitor port configuration")
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ee339eb
    • Amit Cohen's avatar
      mlxsw: pci: Wait longer before accessing the device after reset · ac004e84
      Amit Cohen authored
      During initialization the driver issues a reset to the device and waits
      for 100ms before checking if the firmware is ready. The waiting is
      necessary because before that the device is irresponsive and the first
      read can result in a completion timeout.
      
      While 100ms is sufficient for Spectrum-1 and Spectrum-2, it is
      insufficient for Spectrum-3.
      
      Fix this by increasing the timeout to 200ms.
      
      Fixes: da382875 ("mlxsw: spectrum: Extend to support Spectrum-3 ASIC")
      Signed-off-by: default avatarAmit Cohen <amitc@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac004e84
    • Alex Maftei (amaftei)'s avatar
      sfc: fix timestamp reconstruction at 16-bit rollover points · 23797b98
      Alex Maftei (amaftei) authored
      We can't just use the top bits of the last sync event as they could be
      off-by-one every 65,536 seconds, giving an error in reconstruction of
      65,536 seconds.
      
      This patch uses the difference in the bottom 16 bits (mod 2^16) to
      calculate an offset that needs to be applied to the last sync event to
      get to the current time.
      Signed-off-by: default avatarAlexandru-Mihai Maftei <amaftei@solarflare.com>
      Acked-by: default avatarMartin Habets <mhabets@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23797b98
    • Stefano Garzarella's avatar
      vsock: fix potential deadlock in transport->release() · 3f74957f
      Stefano Garzarella authored
      Some transports (hyperv, virtio) acquire the sock lock during the
      .release() callback.
      
      In the vsock_stream_connect() we call vsock_assign_transport(); if
      the socket was previously assigned to another transport, the
      vsk->transport->release() is called, but the sock lock is already
      held in the vsock_stream_connect(), causing a deadlock reported by
      syzbot:
      
          INFO: task syz-executor280:9768 blocked for more than 143 seconds.
            Not tainted 5.6.0-rc1-syzkaller #0
          "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
          syz-executor280 D27912  9768   9766 0x00000000
          Call Trace:
           context_switch kernel/sched/core.c:3386 [inline]
           __schedule+0x934/0x1f90 kernel/sched/core.c:4082
           schedule+0xdc/0x2b0 kernel/sched/core.c:4156
           __lock_sock+0x165/0x290 net/core/sock.c:2413
           lock_sock_nested+0xfe/0x120 net/core/sock.c:2938
           virtio_transport_release+0xc4/0xd60 net/vmw_vsock/virtio_transport_common.c:832
           vsock_assign_transport+0xf3/0x3b0 net/vmw_vsock/af_vsock.c:454
           vsock_stream_connect+0x2b3/0xc70 net/vmw_vsock/af_vsock.c:1288
           __sys_connect_file+0x161/0x1c0 net/socket.c:1857
           __sys_connect+0x174/0x1b0 net/socket.c:1874
           __do_sys_connect net/socket.c:1885 [inline]
           __se_sys_connect net/socket.c:1882 [inline]
           __x64_sys_connect+0x73/0xb0 net/socket.c:1882
           do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
           entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      To avoid this issue, this patch remove the lock acquiring in the
      .release() callback of hyperv and virtio transports, and it holds
      the lock when we call vsk->transport->release() in the vsock core.
      
      Reported-by: syzbot+731710996d79d0d58fbc@syzkaller.appspotmail.com
      Fixes: 408624af ("vsock: use local transport when it is loaded")
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f74957f
    • David S. Miller's avatar
      unix: It's CONFIG_PROC_FS not CONFIG_PROCFS · 5c05a164
      David S. Miller authored
      Fixes: 3a12500e ("unix: define and set show_fdinfo only if procfs is enabled")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c05a164
    • David S. Miller's avatar
      Merge branch 'net-rmnet-fix-several-bugs' · 795c03a5
      David S. Miller authored
      Taehee Yoo says:
      
      ====================
      net: rmnet: fix several bugs
      
      This patchset is to fix several bugs in RMNET module.
      
      1. The first patch fixes NULL-ptr-deref in rmnet_newlink().
      When rmnet interface is being created, it uses IFLA_LINK
      without checking NULL.
      So, if userspace doesn't set IFLA_LINK, panic will occur.
      In this patch, checking NULL pointer code is added.
      
      2. The second patch fixes NULL-ptr-deref in rmnet_changelink().
      To get real device in rmnet_changelink(), it uses IFLA_LINK.
      But, IFLA_LINK should not be used in rmnet_changelink().
      
      3. The third patch fixes suspicious RCU usage in rmnet_get_port().
      rmnet_get_port() uses rcu_dereference_rtnl().
      But, rmnet_get_port() is used by datapath.
      So, rcu_dereference_bh() should be used instead of rcu_dereference_rtnl().
      
      4. The fourth patch fixes suspicious RCU usage in
      rmnet_force_unassociate_device().
      RCU critical section should not be scheduled.
      But, unregister_netdevice_queue() in the rmnet_force_unassociate_device()
      would be scheduled.
      So, the RCU warning occurs.
      In this patch, the rcu_read_lock() in the rmnet_force_unassociate_device()
      is removed because it's unnecessary.
      
      5. The fifth patch fixes duplicate MUX ID case.
      RMNET MUX ID is unique.
      So, rmnet interface isn't allowed to be created, which have
      a duplicate MUX ID.
      But, only rmnet_newlink() checks this condition, rmnet_changelink()
      doesn't check this.
      So, duplicate MUX ID case would happen.
      
      6. The sixth patch fixes upper/lower interface relationship problems.
      When IFLA_LINK is used, the upper/lower infrastructure should be used.
      Because it checks the maximum depth of upper/lower interfaces and it also
      checks circular interface relationship, etc.
      In this patch, netdev_upper_dev_link() is used.
      
      7. The seventh patch fixes bridge related problems.
      a) ->ndo_del_slave() doesn't work.
      b) It couldn't detect circular upper/lower interface relationship.
      c) It couldn't prevent stack overflow because of too deep depth
      of upper/lower interface
      d) It doesn't check the number of lower interfaces.
      e) Panics because of several reasons.
      These problems are actually the same problem.
      So, this patch fixes these problems.
      
      8. The eighth patch fixes packet forwarding issue in bridge mode
      Packet forwarding is not working in rmnet bridge mode.
      Because when a packet is forwarded, skb_push() for an ethernet header
      is needed. But it doesn't call skb_push().
      So, the ethernet header will be lost.
      
      Change log:
       - update commit logs.
       - drop two patches in this patchset because of wrong target branch.
         - ("net: rmnet: add missing module alias")
         - ("net: rmnet: print error message when command fails")
       - remove unneessary rcu_read_lock() in the third patch.
       - use rcu_dereference_bh() instead of rcu_dereference in third patch.
       - do not allow to add a bridge device if rmnet interface is already
         bridge mode in the seventh patch.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      795c03a5
    • Taehee Yoo's avatar
      net: rmnet: fix packet forwarding in rmnet bridge mode · ad3cc31b
      Taehee Yoo authored
      Packet forwarding is not working in rmnet bridge mode.
      Because when a packet is forwarded, skb_push() for an ethernet header
      is needed. But it doesn't call skb_push().
      So, the ethernet header will be lost.
      
      Test commands:
          modprobe rmnet
          ip netns add nst
          ip netns add nst2
          ip link add veth0 type veth peer name veth1
          ip link add veth2 type veth peer name veth3
          ip link set veth1 netns nst
          ip link set veth3 netns nst2
      
          ip link add rmnet0 link veth0 type rmnet mux_id 1
          ip link set veth2 master rmnet0
          ip link set veth0 up
          ip link set veth2 up
          ip link set rmnet0 up
          ip a a 192.168.100.1/24 dev rmnet0
      
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip a a 192.168.100.2/24 dev veth1
          ip netns exec nst2 ip link set veth3 up
          ip netns exec nst2 ip a a 192.168.100.3/24 dev veth3
          ip netns exec nst2 ping 192.168.100.2
      
      Fixes: 60d58f97 ("net: qualcomm: rmnet: Implement bridge mode")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad3cc31b
    • Taehee Yoo's avatar
      net: rmnet: fix bridge mode bugs · d939b6d3
      Taehee Yoo authored
      In order to attach a bridge interface to the rmnet interface,
      "master" operation is used.
      (e.g. ip link set dummy1 master rmnet0)
      But, in the rmnet_add_bridge(), which is a callback of ->ndo_add_slave()
      doesn't register lower interface.
      So, ->ndo_del_slave() doesn't work.
      There are other problems too.
      1. It couldn't detect circular upper/lower interface relationship.
      2. It couldn't prevent stack overflow because of too deep depth
      of upper/lower interface
      3. It doesn't check the number of lower interfaces.
      4. Panics because of several reasons.
      
      The root problem of these issues is actually the same.
      So, in this patch, these all problems will be fixed.
      
      Test commands:
          modprobe rmnet
          ip link add dummy0 type dummy
          ip link add rmnet0 link dummy0 type rmnet mux_id 1
          ip link add dummy1 master rmnet0 type dummy
          ip link add dummy2 master rmnet0 type dummy
          ip link del rmnet0
          ip link del dummy2
          ip link del dummy1
      
      Splat looks like:
      [   41.867595][ T1164] general protection fault, probably for non-canonical address 0xdffffc0000000101I
      [   41.869993][ T1164] KASAN: null-ptr-deref in range [0x0000000000000808-0x000000000000080f]
      [   41.872950][ T1164] CPU: 0 PID: 1164 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   41.873915][ T1164] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   41.875161][ T1164] RIP: 0010:rmnet_unregister_bridge.isra.6+0x71/0xf0 [rmnet]
      [   41.876178][ T1164] Code: 48 89 ef 48 89 c6 5b 5d e9 fc fe ff ff e8 f7 f3 ff ff 48 8d b8 08 08 00 00 48 ba 00 7
      [   41.878925][ T1164] RSP: 0018:ffff8880c4d0f188 EFLAGS: 00010202
      [   41.879774][ T1164] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000101
      [   41.887689][ T1164] RDX: dffffc0000000000 RSI: ffffffffb8cf64f0 RDI: 0000000000000808
      [   41.888727][ T1164] RBP: ffff8880c40e4000 R08: ffffed101b3c0e3c R09: 0000000000000001
      [   41.889749][ T1164] R10: 0000000000000001 R11: ffffed101b3c0e3b R12: 1ffff110189a1e3c
      [   41.890783][ T1164] R13: ffff8880c4d0f200 R14: ffffffffb8d56160 R15: ffff8880ccc2c000
      [   41.891794][ T1164] FS:  00007f4300edc0c0(0000) GS:ffff8880d9c00000(0000) knlGS:0000000000000000
      [   41.892953][ T1164] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   41.893800][ T1164] CR2: 00007f43003bc8c0 CR3: 00000000ca53e001 CR4: 00000000000606f0
      [   41.894824][ T1164] Call Trace:
      [   41.895274][ T1164]  ? rcu_is_watching+0x2c/0x80
      [   41.895895][ T1164]  rmnet_config_notify_cb+0x1f7/0x590 [rmnet]
      [   41.896687][ T1164]  ? rmnet_unregister_bridge.isra.6+0xf0/0xf0 [rmnet]
      [   41.897611][ T1164]  ? rmnet_unregister_bridge.isra.6+0xf0/0xf0 [rmnet]
      [   41.898508][ T1164]  ? __module_text_address+0x13/0x140
      [   41.899162][ T1164]  notifier_call_chain+0x90/0x160
      [   41.899814][ T1164]  rollback_registered_many+0x660/0xcf0
      [   41.900544][ T1164]  ? netif_set_real_num_tx_queues+0x780/0x780
      [   41.901316][ T1164]  ? __lock_acquire+0xdfe/0x3de0
      [   41.901958][ T1164]  ? memset+0x1f/0x40
      [   41.902468][ T1164]  ? __nla_validate_parse+0x98/0x1ab0
      [   41.903166][ T1164]  unregister_netdevice_many.part.133+0x13/0x1b0
      [   41.903988][ T1164]  rtnl_delete_link+0xbc/0x100
      [ ... ]
      
      Fixes: 60d58f97 ("net: qualcomm: rmnet: Implement bridge mode")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d939b6d3
    • Taehee Yoo's avatar
      net: rmnet: use upper/lower device infrastructure · 037f9cdf
      Taehee Yoo authored
      netdev_upper_dev_link() is useful to manage lower/upper interfaces.
      And this function internally validates looping, maximum depth.
      All or most virtual interfaces that could have a real interface
      (e.g. macsec, macvlan, ipvlan etc.) use lower/upper infrastructure.
      
      Test commands:
          modprobe rmnet
          ip link add dummy0 type dummy
          ip link add rmnet1 link dummy0 type rmnet mux_id 1
          for i in {2..100}
          do
              let A=$i-1
              ip link add rmnet$i link rmnet$A type rmnet mux_id $i
          done
          ip link del dummy0
      
      The purpose of the test commands is to make stack overflow.
      
      Splat looks like:
      [   52.411438][ T1395] BUG: KASAN: slab-out-of-bounds in find_busiest_group+0x27e/0x2c00
      [   52.413218][ T1395] Write of size 64 at addr ffff8880c774bde0 by task ip/1395
      [   52.414841][ T1395]
      [   52.430720][ T1395] CPU: 1 PID: 1395 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   52.496511][ T1395] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   52.513597][ T1395] Call Trace:
      [   52.546516][ T1395]
      [   52.558773][ T1395] Allocated by task 3171537984:
      [   52.588290][ T1395] BUG: unable to handle page fault for address: ffffffffb999e260
      [   52.589311][ T1395] #PF: supervisor read access in kernel mode
      [   52.590529][ T1395] #PF: error_code(0x0000) - not-present page
      [   52.591374][ T1395] PGD d6818067 P4D d6818067 PUD d6819063 PMD 0
      [   52.592288][ T1395] Thread overran stack, or stack corrupted
      [   52.604980][ T1395] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [   52.605856][ T1395] CPU: 1 PID: 1395 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   52.611764][ T1395] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   52.621520][ T1395] RIP: 0010:stack_depot_fetch+0x10/0x30
      [   52.622296][ T1395] Code: ff e9 f9 fe ff ff 48 89 df e8 9c 1d 91 ff e9 ca fe ff ff cc cc cc cc cc cc cc 89 f8 0
      [   52.627887][ T1395] RSP: 0018:ffff8880c774bb60 EFLAGS: 00010006
      [   52.628735][ T1395] RAX: 00000000001f8880 RBX: ffff8880c774d140 RCX: 0000000000000000
      [   52.631773][ T1395] RDX: 000000000000001d RSI: ffff8880c774bb68 RDI: 0000000000003ff0
      [   52.649584][ T1395] RBP: ffffea00031dd200 R08: ffffed101b43e403 R09: ffffed101b43e403
      [   52.674857][ T1395] R10: 0000000000000001 R11: ffffed101b43e402 R12: ffff8880d900e5c0
      [   52.678257][ T1395] R13: ffff8880c774c000 R14: 0000000000000000 R15: dffffc0000000000
      [   52.694541][ T1395] FS:  00007fe867f6e0c0(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000
      [   52.764039][ T1395] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   52.815008][ T1395] CR2: ffffffffb999e260 CR3: 00000000c26aa005 CR4: 00000000000606e0
      [   52.862312][ T1395] Call Trace:
      [   52.887133][ T1395] Modules linked in: dummy rmnet veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_dex
      [   52.936749][ T1395] CR2: ffffffffb999e260
      [   52.965695][ T1395] ---[ end trace 7e32ca99482dbb31 ]---
      [   52.966556][ T1395] RIP: 0010:stack_depot_fetch+0x10/0x30
      [   52.971083][ T1395] Code: ff e9 f9 fe ff ff 48 89 df e8 9c 1d 91 ff e9 ca fe ff ff cc cc cc cc cc cc cc 89 f8 0
      [   53.003650][ T1395] RSP: 0018:ffff8880c774bb60 EFLAGS: 00010006
      [   53.043183][ T1395] RAX: 00000000001f8880 RBX: ffff8880c774d140 RCX: 0000000000000000
      [   53.076480][ T1395] RDX: 000000000000001d RSI: ffff8880c774bb68 RDI: 0000000000003ff0
      [   53.093858][ T1395] RBP: ffffea00031dd200 R08: ffffed101b43e403 R09: ffffed101b43e403
      [   53.112795][ T1395] R10: 0000000000000001 R11: ffffed101b43e402 R12: ffff8880d900e5c0
      [   53.139837][ T1395] R13: ffff8880c774c000 R14: 0000000000000000 R15: dffffc0000000000
      [   53.141500][ T1395] FS:  00007fe867f6e0c0(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000
      [   53.143343][ T1395] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   53.152007][ T1395] CR2: ffffffffb999e260 CR3: 00000000c26aa005 CR4: 00000000000606e0
      [   53.156459][ T1395] Kernel panic - not syncing: Fatal exception
      [   54.213570][ T1395] Shutting down cpus with NMI
      [   54.354112][ T1395] Kernel Offset: 0x33000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0x)
      [   54.355687][ T1395] Rebooting in 5 seconds..
      
      Fixes: b37f78f2 ("net: qualcomm: rmnet: Fix crash on real dev unregistration")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      037f9cdf