1. 17 Feb, 2020 36 commits
    • Marek Vasut's avatar
      net: ks8851-ml: Fix 16-bit IO operation · 58292104
      Marek Vasut authored
      The Micrel KSZ8851-16MLLI datasheet DS00002357B page 12 states that
      BE[3:0] signals are active high. This contradicts the measurements
      of the behavior of the actual chip, where these signals behave as
      active low. For example, to read the CIDER register, the bus must
      expose 0xc0c0 during the address phase, which means BE[3:0]=4'b1100.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Petr Stetiar <ynezz@true.cz>
      Cc: YueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58292104
    • Marek Vasut's avatar
      net: ks8851-ml: Fix 16-bit data access · edacb098
      Marek Vasut authored
      The packet data written to and read from Micrel KSZ8851-16MLLI must be
      byte-swapped in 16-bit mode, add this byte-swapping.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Petr Stetiar <ynezz@true.cz>
      Cc: YueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      edacb098
    • Marek Vasut's avatar
      net: ks8851-ml: Remove 8-bit bus accessors · 69233bba
      Marek Vasut authored
      This driver is mixing 8-bit and 16-bit bus accessors for reasons unknown,
      however the speculation is that this was some sort of attempt to support
      the 8-bit bus mode.
      
      As per the KS8851-16MLL documentation, all two registers accessed via the
      8-bit accessors are internally 16-bit registers, so reading them using
      16-bit accessors is fine. The KS_CCR read can be converted to 16-bit read
      outright, as it is already a concatenation of two 8-bit reads of that
      register. The KS_RXQCR accesses are 8-bit only, however writing the top
      8 bits of the register is OK as well, since the driver caches the entire
      16-bit register value anyway.
      
      Finally, the driver is not used by any hardware in the kernel right now.
      The only hardware available to me is one with 16-bit bus, so I have no
      way to test the 8-bit bus mode, however it is unlikely this ever really
      worked anyway. If the 8-bit bus mode is ever required, it can be easily
      added by adjusting the 16-bit accessors to do 2 consecutive accesses,
      which is how this should have been done from the beginning.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Petr Stetiar <ynezz@true.cz>
      Cc: YueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69233bba
    • Matthieu Baerts's avatar
      mptcp: select CRYPTO · 357b41ca
      Matthieu Baerts authored
      Without this modification and if CRYPTO is not selected, we have this
      warning:
      
        WARNING: unmet direct dependencies detected for CRYPTO_LIB_SHA256
          Depends on [n]: CRYPTO [=n]
          Selected by [y]:
          - MPTCP [=y] && NET [=y] && INET [=y]
      
      MPTCP selects CRYPTO_LIB_SHA256 which seems to depend on CRYPTO. CRYPTO
      is now selected to avoid this issue.
      
      Even though the config system prints that warning, it looks like
      sha256.c is compiled and linked even without CONFIG_CRYPTO. Since MPTCP
      will end up needing CONFIG_CRYPTO anyway in future commits -- currently
      in preparation for net-next -- we propose to add it now to fix the
      warning.
      
      The dependency in the config system comes from the fact that
      CRYPTO_LIB_SHA256 is defined in "lib/crypto/Kconfig" which is sourced
      from "crypto/Kconfig" only if CRYPTO is selected.
      
      Fixes: 65492c5a (mptcp: move from sha1 (v0) to sha256 (v1))
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      357b41ca
    • David S. Miller's avatar
      Merge branch 'bonding-fix-bonding-interface-bugs' · c230978f
      David S. Miller authored
      Taehee Yoo says:
      
      ====================
      bonding: fix bonding interface bugs
      
      This patchset fixes lockdep problem in bonding interface
      
      1. The first patch is to add missing netdev_update_lockdep_key().
      After bond_release(), netdev_update_lockdep_key() should be called.
      But both ioctl path and attribute path don't call
      netdev_update_lockdep_key().
      This patch adds missing netdev_update_lockdep_key().
      
      2. The second patch is to export netdev_next_lower_dev_rcu symbol.
      netdev_next_lower_dev_rcu() is useful to implement the function,
      which is to walk their all lower interfaces.
      This patch is actually a preparing patch for the third patch.
      
      3. The last patch is to fix lockdep waring in bond_get_stats().
      The stats_lock uses a dynamic lockdep key.
      So, after "nomaster" operation, updating the dynamic lockdep key
      routine is needed. but it doesn't
      So, lockdep warning occurs.
      
      Change log:
      v1 -> v2:
       - Update headline from "fix bonding interface bugs"
         to "bonding: fix bonding interface bugs"
       - Drop a patch("bonding: do not collect slave's stats")
       - Add new patches
         - ("net: export netdev_next_lower_dev_rcu()")
         - ("bonding: fix lockdep warning in bond_get_stats()")
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c230978f
    • Taehee Yoo's avatar
      bonding: fix lockdep warning in bond_get_stats() · b3e80d44
      Taehee Yoo authored
      In the "struct bonding", there is stats_lock.
      This lock protects "bond_stats" in the "struct bonding".
      bond_stats is updated in the bond_get_stats() and this function would be
      executed concurrently. So, the lock is needed.
      
      Bonding interfaces would be nested.
      So, either stats_lock should use dynamic lockdep class key or stats_lock
      should be used by spin_lock_nested(). In the current code, stats_lock is
      using a dynamic lockdep class key.
      But there is no updating stats_lock_key routine So, lockdep warning
      will occur.
      
      Test commands:
          ip link add bond0 type bond
          ip link add bond1 type bond
          ip link set bond0 master bond1
          ip link set bond0 nomaster
          ip link set bond1 master bond0
      
      Splat looks like:
      [   38.420603][  T957] 5.5.0+ #394 Not tainted
      [   38.421074][  T957] ------------------------------------------------------
      [   38.421837][  T957] ip/957 is trying to acquire lock:
      [   38.422399][  T957] ffff888063262cd8 (&bond->stats_lock_key#2){+.+.}, at: bond_get_stats+0x90/0x4d0 [bonding]
      [   38.423528][  T957]
      [   38.423528][  T957] but task is already holding lock:
      [   38.424526][  T957] ffff888065fd2cd8 (&bond->stats_lock_key){+.+.}, at: bond_get_stats+0x90/0x4d0 [bonding]
      [   38.426075][  T957]
      [   38.426075][  T957] which lock already depends on the new lock.
      [   38.426075][  T957]
      [   38.428536][  T957]
      [   38.428536][  T957] the existing dependency chain (in reverse order) is:
      [   38.429475][  T957]
      [   38.429475][  T957] -> #1 (&bond->stats_lock_key){+.+.}:
      [   38.430273][  T957]        _raw_spin_lock+0x30/0x70
      [   38.430812][  T957]        bond_get_stats+0x90/0x4d0 [bonding]
      [   38.431451][  T957]        dev_get_stats+0x1ec/0x270
      [   38.432088][  T957]        bond_get_stats+0x1a5/0x4d0 [bonding]
      [   38.432767][  T957]        dev_get_stats+0x1ec/0x270
      [   38.433322][  T957]        rtnl_fill_stats+0x44/0xbe0
      [   38.433866][  T957]        rtnl_fill_ifinfo+0xeb2/0x3720
      [   38.434474][  T957]        rtmsg_ifinfo_build_skb+0xca/0x170
      [   38.435081][  T957]        rtmsg_ifinfo_event.part.33+0x1b/0xb0
      [   38.436848][  T957]        rtnetlink_event+0xcd/0x120
      [   38.437455][  T957]        notifier_call_chain+0x90/0x160
      [   38.438067][  T957]        netdev_change_features+0x74/0xa0
      [   38.438708][  T957]        bond_compute_features.isra.45+0x4e6/0x6f0 [bonding]
      [   38.439522][  T957]        bond_enslave+0x3639/0x47b0 [bonding]
      [   38.440225][  T957]        do_setlink+0xaab/0x2ef0
      [   38.440786][  T957]        __rtnl_newlink+0x9c5/0x1270
      [   38.441463][  T957]        rtnl_newlink+0x65/0x90
      [   38.442075][  T957]        rtnetlink_rcv_msg+0x4a8/0x890
      [   38.442774][  T957]        netlink_rcv_skb+0x121/0x350
      [   38.443451][  T957]        netlink_unicast+0x42e/0x610
      [   38.444282][  T957]        netlink_sendmsg+0x65a/0xb90
      [   38.444992][  T957]        ____sys_sendmsg+0x5ce/0x7a0
      [   38.445679][  T957]        ___sys_sendmsg+0x10f/0x1b0
      [   38.446365][  T957]        __sys_sendmsg+0xc6/0x150
      [   38.447007][  T957]        do_syscall_64+0x99/0x4f0
      [   38.447668][  T957]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   38.448538][  T957]
      [   38.448538][  T957] -> #0 (&bond->stats_lock_key#2){+.+.}:
      [   38.449554][  T957]        __lock_acquire+0x2d8d/0x3de0
      [   38.450148][  T957]        lock_acquire+0x164/0x3b0
      [   38.450711][  T957]        _raw_spin_lock+0x30/0x70
      [   38.451292][  T957]        bond_get_stats+0x90/0x4d0 [bonding]
      [   38.451950][  T957]        dev_get_stats+0x1ec/0x270
      [   38.452425][  T957]        bond_get_stats+0x1a5/0x4d0 [bonding]
      [   38.453362][  T957]        dev_get_stats+0x1ec/0x270
      [   38.453825][  T957]        rtnl_fill_stats+0x44/0xbe0
      [   38.454390][  T957]        rtnl_fill_ifinfo+0xeb2/0x3720
      [   38.456257][  T957]        rtmsg_ifinfo_build_skb+0xca/0x170
      [   38.456998][  T957]        rtmsg_ifinfo_event.part.33+0x1b/0xb0
      [   38.459351][  T957]        rtnetlink_event+0xcd/0x120
      [   38.460086][  T957]        notifier_call_chain+0x90/0x160
      [   38.460829][  T957]        netdev_change_features+0x74/0xa0
      [   38.461752][  T957]        bond_compute_features.isra.45+0x4e6/0x6f0 [bonding]
      [   38.462705][  T957]        bond_enslave+0x3639/0x47b0 [bonding]
      [   38.463476][  T957]        do_setlink+0xaab/0x2ef0
      [   38.464141][  T957]        __rtnl_newlink+0x9c5/0x1270
      [   38.464897][  T957]        rtnl_newlink+0x65/0x90
      [   38.465522][  T957]        rtnetlink_rcv_msg+0x4a8/0x890
      [   38.466215][  T957]        netlink_rcv_skb+0x121/0x350
      [   38.466895][  T957]        netlink_unicast+0x42e/0x610
      [   38.467583][  T957]        netlink_sendmsg+0x65a/0xb90
      [   38.468285][  T957]        ____sys_sendmsg+0x5ce/0x7a0
      [   38.469202][  T957]        ___sys_sendmsg+0x10f/0x1b0
      [   38.469884][  T957]        __sys_sendmsg+0xc6/0x150
      [   38.470587][  T957]        do_syscall_64+0x99/0x4f0
      [   38.471245][  T957]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   38.472093][  T957]
      [   38.472093][  T957] other info that might help us debug this:
      [   38.472093][  T957]
      [   38.473438][  T957]  Possible unsafe locking scenario:
      [   38.473438][  T957]
      [   38.474898][  T957]        CPU0                    CPU1
      [   38.476234][  T957]        ----                    ----
      [   38.480171][  T957]   lock(&bond->stats_lock_key);
      [   38.480808][  T957]                                lock(&bond->stats_lock_key#2);
      [   38.481791][  T957]                                lock(&bond->stats_lock_key);
      [   38.482754][  T957]   lock(&bond->stats_lock_key#2);
      [   38.483416][  T957]
      [   38.483416][  T957]  *** DEADLOCK ***
      [   38.483416][  T957]
      [   38.484505][  T957] 3 locks held by ip/957:
      [   38.485048][  T957]  #0: ffffffffbccf6230 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x457/0x890
      [   38.486198][  T957]  #1: ffff888065fd2cd8 (&bond->stats_lock_key){+.+.}, at: bond_get_stats+0x90/0x4d0 [bonding]
      [   38.487625][  T957]  #2: ffffffffbc9254c0 (rcu_read_lock){....}, at: bond_get_stats+0x5/0x4d0 [bonding]
      [   38.488897][  T957]
      [   38.488897][  T957] stack backtrace:
      [   38.489646][  T957] CPU: 1 PID: 957 Comm: ip Not tainted 5.5.0+ #394
      [   38.490497][  T957] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   38.492810][  T957] Call Trace:
      [   38.493219][  T957]  dump_stack+0x96/0xdb
      [   38.493709][  T957]  check_noncircular+0x371/0x450
      [   38.494344][  T957]  ? lookup_address+0x60/0x60
      [   38.494923][  T957]  ? print_circular_bug.isra.35+0x310/0x310
      [   38.495699][  T957]  ? hlock_class+0x130/0x130
      [   38.496334][  T957]  ? __lock_acquire+0x2d8d/0x3de0
      [   38.496979][  T957]  __lock_acquire+0x2d8d/0x3de0
      [   38.497607][  T957]  ? register_lock_class+0x14d0/0x14d0
      [   38.498333][  T957]  ? check_chain_key+0x236/0x5d0
      [   38.499003][  T957]  lock_acquire+0x164/0x3b0
      [   38.499800][  T957]  ? bond_get_stats+0x90/0x4d0 [bonding]
      [   38.500706][  T957]  _raw_spin_lock+0x30/0x70
      [   38.501435][  T957]  ? bond_get_stats+0x90/0x4d0 [bonding]
      [   38.502311][  T957]  bond_get_stats+0x90/0x4d0 [bonding]
      [ ... ]
      
      But, there is another problem.
      The dynamic lockdep class key is protected by RTNL, but bond_get_stats()
      would be called outside of RTNL.
      So, it would use an invalid dynamic lockdep class key.
      
      In order to fix this issue, stats_lock uses spin_lock_nested() instead of
      a dynamic lockdep key.
      The bond_get_stats() calls bond_get_lowest_level_rcu() to get the correct
      nest level value, which will be used by spin_lock_nested().
      The "dev->lower_level" indicates lower nest level value, but this value
      is invalid outside of RTNL.
      So, bond_get_lowest_level_rcu() returns valid lower nest level value in
      the RCU critical section.
      bond_get_lowest_level_rcu() will be work only when LOCKDEP is enabled.
      
      Fixes: 089bca2c ("bonding: use dynamic lockdep key instead of subclass")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3e80d44
    • Taehee Yoo's avatar
      net: export netdev_next_lower_dev_rcu() · 7151affe
      Taehee Yoo authored
      netdev_next_lower_dev_rcu() will be used to implement a function,
      which is to walk all lower interfaces.
      There are already functions that they walk their lower interface.
      (netdev_walk_all_lower_dev_rcu, netdev_walk_all_lower_dev()).
      But, there would be cases that couldn't be covered by given
      netdev_walk_all_lower_dev_{rcu}() function.
      So, some modules would want to implement own function,
      which is to walk all lower interfaces.
      
      In the next patch, netdev_next_lower_dev_rcu() will be used.
      In addition, this patch removes two unused prototypes in netdevice.h.
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7151affe
    • Taehee Yoo's avatar
      bonding: add missing netdev_update_lockdep_key() · 064ff66e
      Taehee Yoo authored
      After bond_release(), netdev_update_lockdep_key() should be called.
      But both ioctl path and attribute path don't call
      netdev_update_lockdep_key().
      This patch adds missing netdev_update_lockdep_key().
      
      Test commands:
          ip link add bond0 type bond
          ip link add bond1 type bond
          ifenslave bond0 bond1
          ifenslave -d bond0 bond1
          ifenslave bond1 bond0
      
      Splat looks like:
      [   29.501182][ T1046] WARNING: possible circular locking dependency detected
      [   29.501945][ T1039] hardirqs last disabled at (1962): [<ffffffffac6c807f>] handle_mm_fault+0x13f/0x700
      [   29.503442][ T1046] 5.5.0+ #322 Not tainted
      [   29.503447][ T1046] ------------------------------------------------------
      [   29.504277][ T1039] softirqs last  enabled at (1180): [<ffffffffade00678>] __do_softirq+0x678/0x981
      [   29.505443][ T1046] ifenslave/1046 is trying to acquire lock:
      [   29.505886][ T1039] softirqs last disabled at (1169): [<ffffffffac19c18a>] irq_exit+0x17a/0x1a0
      [   29.509997][ T1046] ffff88805d5da280 (&dev->addr_list_lock_key#3){+...}, at: dev_mc_sync_multiple+0x95/0x120
      [   29.511243][ T1046]
      [   29.511243][ T1046] but task is already holding lock:
      [   29.512192][ T1046] ffff8880460f2280 (&dev->addr_list_lock_key#4){+...}, at: bond_enslave+0x4482/0x47b0 [bonding]
      [   29.514124][ T1046]
      [   29.514124][ T1046] which lock already depends on the new lock.
      [   29.514124][ T1046]
      [   29.517297][ T1046]
      [   29.517297][ T1046] the existing dependency chain (in reverse order) is:
      [   29.518231][ T1046]
      [   29.518231][ T1046] -> #1 (&dev->addr_list_lock_key#4){+...}:
      [   29.519076][ T1046]        _raw_spin_lock+0x30/0x70
      [   29.519588][ T1046]        dev_mc_sync_multiple+0x95/0x120
      [   29.520208][ T1046]        bond_enslave+0x448d/0x47b0 [bonding]
      [   29.520862][ T1046]        bond_option_slaves_set+0x1a3/0x370 [bonding]
      [   29.521640][ T1046]        __bond_opt_set+0x1ff/0xbb0 [bonding]
      [   29.522438][ T1046]        __bond_opt_set_notify+0x2b/0xf0 [bonding]
      [   29.523251][ T1046]        bond_opt_tryset_rtnl+0x92/0xf0 [bonding]
      [   29.524082][ T1046]        bonding_sysfs_store_option+0x8a/0xf0 [bonding]
      [   29.524959][ T1046]        kernfs_fop_write+0x276/0x410
      [   29.525620][ T1046]        vfs_write+0x197/0x4a0
      [   29.526218][ T1046]        ksys_write+0x141/0x1d0
      [   29.526818][ T1046]        do_syscall_64+0x99/0x4f0
      [   29.527430][ T1046]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   29.528265][ T1046]
      [   29.528265][ T1046] -> #0 (&dev->addr_list_lock_key#3){+...}:
      [   29.529272][ T1046]        __lock_acquire+0x2d8d/0x3de0
      [   29.529935][ T1046]        lock_acquire+0x164/0x3b0
      [   29.530638][ T1046]        _raw_spin_lock+0x30/0x70
      [   29.531187][ T1046]        dev_mc_sync_multiple+0x95/0x120
      [   29.531790][ T1046]        bond_enslave+0x448d/0x47b0 [bonding]
      [   29.532451][ T1046]        bond_option_slaves_set+0x1a3/0x370 [bonding]
      [   29.533163][ T1046]        __bond_opt_set+0x1ff/0xbb0 [bonding]
      [   29.533789][ T1046]        __bond_opt_set_notify+0x2b/0xf0 [bonding]
      [   29.534595][ T1046]        bond_opt_tryset_rtnl+0x92/0xf0 [bonding]
      [   29.535500][ T1046]        bonding_sysfs_store_option+0x8a/0xf0 [bonding]
      [   29.536379][ T1046]        kernfs_fop_write+0x276/0x410
      [   29.537057][ T1046]        vfs_write+0x197/0x4a0
      [   29.537640][ T1046]        ksys_write+0x141/0x1d0
      [   29.538251][ T1046]        do_syscall_64+0x99/0x4f0
      [   29.538870][ T1046]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   29.539659][ T1046]
      [   29.539659][ T1046] other info that might help us debug this:
      [   29.539659][ T1046]
      [   29.540953][ T1046]  Possible unsafe locking scenario:
      [   29.540953][ T1046]
      [   29.541883][ T1046]        CPU0                    CPU1
      [   29.542540][ T1046]        ----                    ----
      [   29.543209][ T1046]   lock(&dev->addr_list_lock_key#4);
      [   29.543880][ T1046]                                lock(&dev->addr_list_lock_key#3);
      [   29.544873][ T1046]                                lock(&dev->addr_list_lock_key#4);
      [   29.545863][ T1046]   lock(&dev->addr_list_lock_key#3);
      [   29.546525][ T1046]
      [   29.546525][ T1046]  *** DEADLOCK ***
      [   29.546525][ T1046]
      [   29.547542][ T1046] 5 locks held by ifenslave/1046:
      [   29.548196][ T1046]  #0: ffff88806044c478 (sb_writers#5){.+.+}, at: vfs_write+0x3bb/0x4a0
      [   29.549248][ T1046]  #1: ffff88805af00890 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cf/0x410
      [   29.550343][ T1046]  #2: ffff88805b8b54b0 (kn->count#157){.+.+}, at: kernfs_fop_write+0x1f2/0x410
      [   29.551575][ T1046]  #3: ffffffffaecf4cf0 (rtnl_mutex){+.+.}, at: bond_opt_tryset_rtnl+0x5f/0xf0 [bonding]
      [   29.552819][ T1046]  #4: ffff8880460f2280 (&dev->addr_list_lock_key#4){+...}, at: bond_enslave+0x4482/0x47b0 [bonding]
      [   29.554175][ T1046]
      [   29.554175][ T1046] stack backtrace:
      [   29.554907][ T1046] CPU: 0 PID: 1046 Comm: ifenslave Not tainted 5.5.0+ #322
      [   29.555854][ T1046] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   29.557064][ T1046] Call Trace:
      [   29.557504][ T1046]  dump_stack+0x96/0xdb
      [   29.558054][ T1046]  check_noncircular+0x371/0x450
      [   29.558723][ T1046]  ? print_circular_bug.isra.35+0x310/0x310
      [   29.559486][ T1046]  ? hlock_class+0x130/0x130
      [   29.560100][ T1046]  ? __lock_acquire+0x2d8d/0x3de0
      [   29.560761][ T1046]  __lock_acquire+0x2d8d/0x3de0
      [   29.561366][ T1046]  ? register_lock_class+0x14d0/0x14d0
      [   29.562045][ T1046]  ? find_held_lock+0x39/0x1d0
      [   29.562641][ T1046]  lock_acquire+0x164/0x3b0
      [   29.563199][ T1046]  ? dev_mc_sync_multiple+0x95/0x120
      [   29.563872][ T1046]  _raw_spin_lock+0x30/0x70
      [   29.564464][ T1046]  ? dev_mc_sync_multiple+0x95/0x120
      [   29.565146][ T1046]  dev_mc_sync_multiple+0x95/0x120
      [   29.565793][ T1046]  bond_enslave+0x448d/0x47b0 [bonding]
      [   29.566487][ T1046]  ? bond_update_slave_arr+0x940/0x940 [bonding]
      [   29.567279][ T1046]  ? bstr_printf+0xc20/0xc20
      [   29.567857][ T1046]  ? stack_trace_consume_entry+0x160/0x160
      [   29.568614][ T1046]  ? deactivate_slab.isra.77+0x2c5/0x800
      [   29.569320][ T1046]  ? check_chain_key+0x236/0x5d0
      [   29.569939][ T1046]  ? sscanf+0x93/0xc0
      [   29.570442][ T1046]  ? vsscanf+0x1e20/0x1e20
      [   29.571003][ T1046]  bond_option_slaves_set+0x1a3/0x370 [bonding]
      [ ... ]
      
      Fixes: ab92d68f ("net: core: add generic lockdep keys")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      064ff66e
    • Christophe JAILLET's avatar
      NFC: pn544: Fix a typo in a debug message · c4c10784
      Christophe JAILLET authored
      The ending character of the string shoulb be \n, not \b.
      
      Fixes: 17936b43 ("NFC: Standardize logging style")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4c10784
    • Michal Kubecek's avatar
      ethtool: fix application of verbose no_mask bitset · 66991703
      Michal Kubecek authored
      A bitset without mask in a _SET request means we want exactly the bits in
      the bitset to be set. This works correctly for compact format but when
      verbose format is parsed, ethnl_update_bitset32_verbose() only sets the
      bits present in the request bitset but does not clear the rest. This can
      cause incorrect results like
      
        lion:~ # ethtool eth0 | grep Wake
                Supports Wake-on: pumbg
                Wake-on: g
        lion:~ # ethtool -s eth0 wol u
        lion:~ # ethtool eth0 | grep Wake
                Supports Wake-on: pumbg
                Wake-on: ug
      
      when the second ethtool command issues request
      
      ETHTOOL_MSG_WOL_SET
          ETHTOOL_A_WOL_HEADER
              ETHTOOL_A_HEADER_DEV_NAME = "eth0"
          ETHTOOL_A_WOL_MODES
              ETHTOOL_A_BITSET_NOMASK
              ETHTOOL_A_BITSET_BITS
                  ETHTOOL_A_BITSET_BITS_BIT
                      ETHTOOL_BITSET_BIT_INDEX = 1
      
      Fix the logic by clearing the whole target bitmap before we start iterating
      through the request bits.
      
      Fixes: 10b518d4 ("ethtool: netlink bitset handling")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66991703
    • Florian Fainelli's avatar
      net: dsa: b53: Ensure the default VID is untagged · d965a543
      Florian Fainelli authored
      We need to ensure that the default VID is untagged otherwise the switch
      will be sending tagged frames and the results can be problematic. This
      is especially true with b53 switches that use VID 0 as their default
      VLAN since VID 0 has a special meaning.
      
      Fixes: fea83353 ("net: dsa: b53: Fix default VLAN ID")
      Fixes: 061f6a50 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d965a543
    • David S. Miller's avatar
      Merge branch 'wireguard-fixes' · 82d81bb0
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      wireguard fixes for 5.6-rc2
      
      Here are four fixes for wireguard collected since rc1:
      
      1) Some small cleanups to the test suite to help massively parallel
         builds.
      
      2) A change in how we reset our load calculation to avoid a more
         expensive comparison, suggested by Matt Dunwoodie.
      
      3) I've been loading more and more of wireguard's surface into
         syzkaller, trying to get our coverage as complete as possible,
         leading in this case to a fix for mtu=0 devices.
      
      4) A removal of superfluous code, pointed out by Eric Dumazet.
      
      v2 fixes a logical problem in the patch for (3) pointed out by Eric Dumazet. v3
      replaces some non-obvious bitmath in (3) with a more obvious expression, and
      adds patch (4).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82d81bb0
    • Jason A. Donenfeld's avatar
      wireguard: socket: remove extra call to synchronize_net · 1fbc33b0
      Jason A. Donenfeld authored
      synchronize_net() is a wrapper around synchronize_rcu(), so there's no
      point in having synchronize_net and synchronize_rcu back to back,
      despite the documentation comment suggesting maybe it's somewhat useful,
      "Wait for packets currently being received to be done." This commit
      removes the extra call.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1fbc33b0
    • Jason A. Donenfeld's avatar
      wireguard: send: account for mtu=0 devices · 175f1ca9
      Jason A. Donenfeld authored
      It turns out there's an easy way to get packets queued up while still
      having an MTU of zero, and that's via persistent keep alive. This commit
      makes sure that in whatever condition, we don't wind up dividing by
      zero. Note that an MTU of zero for a wireguard interface is something
      quasi-valid, so I don't think the correct fix is to limit it via
      min_mtu. This can be reproduced easily with:
      
      ip link add wg0 type wireguard
      ip link add wg1 type wireguard
      ip link set wg0 up mtu 0
      ip link set wg1 up
      wg set wg0 private-key <(wg genkey)
      wg set wg1 listen-port 1 private-key <(wg genkey) peer $(wg show wg0 public-key)
      wg set wg0 peer $(wg show wg1 public-key) persistent-keepalive 1 endpoint 127.0.0.1:1
      
      However, while min_mtu=0 seems fine, it makes sense to restrict the
      max_mtu. This commit also restricts the maximum MTU to the greatest
      number for which rounding up to the padding multiple won't overflow a
      signed integer. Packets this large were always rejected anyway
      eventually, due to checks deeper in, but it seems more sound not to even
      let the administrator configure something that won't work anyway.
      
      We use this opportunity to clean up this function a bit so that it's
      clear which paths we're expecting.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      175f1ca9
    • Jason A. Donenfeld's avatar
      wireguard: receive: reset last_under_load to zero · 2a8a4df3
      Jason A. Donenfeld authored
      This is a small optimization that prevents more expensive comparisons
      from happening when they are no longer necessary, by clearing the
      last_under_load variable whenever we wind up in a state where we were
      under load but we no longer are.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Suggested-by: default avatarMatt Dunwoodie <ncon@noconroy.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a8a4df3
    • Jason A. Donenfeld's avatar
      wireguard: selftests: reduce complexity and fix make races · 04ddf120
      Jason A. Donenfeld authored
      This gives us fewer dependencies and shortens build time, fixes up some
      hash checking race conditions, and also fixes missing directory creation
      that caused issues on massively parallel builds.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04ddf120
    • Mat Martineau's avatar
      mptcp: Protect subflow socket options before connection completes · b6e4a1ae
      Mat Martineau authored
      Userspace should not be able to directly manipulate subflow socket
      options before a connection is established since it is not yet known if
      it will be an MPTCP subflow or a TCP fallback subflow. TCP fallback
      subflows can be more directly controlled by userspace because they are
      regular TCP connections, while MPTCP subflow sockets need to be
      configured for the specific needs of MPTCP. Use the same logic as
      sendmsg/recvmsg to ensure that socket option calls are only passed
      through to known TCP fallback subflows.
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6e4a1ae
    • Arun Parameswaran's avatar
      net: phy: restore mdio regs in the iproc mdio driver · 6f08e98d
      Arun Parameswaran authored
      The mii management register in iproc mdio block
      does not have a retention register so it is lost on suspend.
      Save and restore value of register while resuming from suspend.
      
      Fixes: bb1a6197 ("net: phy: Initialize mdio clock at probe function")
      Signed-off-by: default avatarArun Parameswaran <arun.parameswaran@broadcom.com>
      Signed-off-by: default avatarScott Branden <scott.branden@broadcom.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f08e98d
    • Eric Dumazet's avatar
      net: add strict checks in netdev_name_node_alt_destroy() · e08ad805
      Eric Dumazet authored
      netdev_name_node_alt_destroy() does a lookup over all
      device names of a namespace.
      
      We need to make sure the name belongs to the device
      of interest, and that we do not destroy its primary
      name, since we rely on it being not deleted :
      dev->name_node would indeed point to freed memory.
      
      syzbot report was the following :
      
      BUG: KASAN: use-after-free in dev_net include/linux/netdevice.h:2206 [inline]
      BUG: KASAN: use-after-free in mld_force_mld_version net/ipv6/mcast.c:1172 [inline]
      BUG: KASAN: use-after-free in mld_in_v2_mode_only net/ipv6/mcast.c:1180 [inline]
      BUG: KASAN: use-after-free in mld_in_v1_mode+0x203/0x230 net/ipv6/mcast.c:1190
      Read of size 8 at addr ffff88809886c588 by task swapper/1/0
      
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc1-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x197/0x210 lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
       __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506
       kasan_report+0x12/0x20 mm/kasan/common.c:641
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
       dev_net include/linux/netdevice.h:2206 [inline]
       mld_force_mld_version net/ipv6/mcast.c:1172 [inline]
       mld_in_v2_mode_only net/ipv6/mcast.c:1180 [inline]
       mld_in_v1_mode+0x203/0x230 net/ipv6/mcast.c:1190
       mld_send_initial_cr net/ipv6/mcast.c:2083 [inline]
       mld_dad_timer_expire+0x24/0x230 net/ipv6/mcast.c:2118
       call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1404
       expire_timers kernel/time/timer.c:1449 [inline]
       __run_timers kernel/time/timer.c:1773 [inline]
       __run_timers kernel/time/timer.c:1740 [inline]
       run_timer_softirq+0x6c3/0x1790 kernel/time/timer.c:1786
       __do_softirq+0x262/0x98c kernel/softirq.c:292
       invoke_softirq kernel/softirq.c:373 [inline]
       irq_exit+0x19b/0x1e0 kernel/softirq.c:413
       exiting_irq arch/x86/include/asm/apic.h:546 [inline]
       smp_apic_timer_interrupt+0x1a3/0x610 arch/x86/kernel/apic/apic.c:1146
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
       </IRQ>
      RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61
      Code: 68 73 c5 f9 eb 8a cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 94 be 59 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d 84 be 59 00 fb f4 <c3> cc 55 48 89 e5 41 57 41 56 41 55 41 54 53 e8 de 2a 74 f9 e8 09
      RSP: 0018:ffffc90000d3fd68 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
      RAX: 1ffffffff136761a RBX: ffff8880a99fc340 RCX: 0000000000000000
      RDX: dffffc0000000000 RSI: 0000000000000006 RDI: ffff8880a99fcbd4
      RBP: ffffc90000d3fd98 R08: ffff8880a99fc340 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
      R13: ffffffff8aa5a1c0 R14: 0000000000000000 R15: 0000000000000001
       arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:686
       default_idle_call+0x84/0xb0 kernel/sched/idle.c:94
       cpuidle_idle_call kernel/sched/idle.c:154 [inline]
       do_idle+0x3c8/0x6e0 kernel/sched/idle.c:269
       cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:361
       start_secondary+0x2f4/0x410 arch/x86/kernel/smpboot.c:264
       secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:242
      
      Allocated by task 10229:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       __kasan_kmalloc mm/kasan/common.c:515 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:488
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529
       __do_kmalloc_node mm/slab.c:3616 [inline]
       __kmalloc_node+0x4e/0x70 mm/slab.c:3623
       kmalloc_node include/linux/slab.h:578 [inline]
       kvmalloc_node+0x68/0x100 mm/util.c:574
       kvmalloc include/linux/mm.h:645 [inline]
       kvzalloc include/linux/mm.h:653 [inline]
       alloc_netdev_mqs+0x98/0xe40 net/core/dev.c:9797
       rtnl_create_link+0x22d/0xaf0 net/core/rtnetlink.c:3047
       __rtnl_newlink+0xf9f/0x1790 net/core/rtnetlink.c:3309
       rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3377
       rtnetlink_rcv_msg+0x45e/0xaf0 net/core/rtnetlink.c:5438
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5456
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:672
       __sys_sendto+0x262/0x380 net/socket.c:1998
       __do_compat_sys_socketcall net/compat.c:771 [inline]
       __se_compat_sys_socketcall net/compat.c:719 [inline]
       __ia32_compat_sys_socketcall+0x530/0x710 net/compat.c:719
       do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline]
       do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408
       entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
      
      Freed by task 10229:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       kasan_set_free_info mm/kasan/common.c:337 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:476
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:485
       __cache_free mm/slab.c:3426 [inline]
       kfree+0x10a/0x2c0 mm/slab.c:3757
       __netdev_name_node_alt_destroy+0x1ff/0x2a0 net/core/dev.c:322
       netdev_name_node_alt_destroy+0x57/0x80 net/core/dev.c:334
       rtnl_alt_ifname net/core/rtnetlink.c:3518 [inline]
       rtnl_linkprop.isra.0+0x575/0x6f0 net/core/rtnetlink.c:3567
       rtnl_dellinkprop+0x46/0x60 net/core/rtnetlink.c:3588
       rtnetlink_rcv_msg+0x45e/0xaf0 net/core/rtnetlink.c:5438
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5456
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:672
       ____sys_sendmsg+0x753/0x880 net/socket.c:2343
       ___sys_sendmsg+0x100/0x170 net/socket.c:2397
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2430
       __compat_sys_sendmsg net/compat.c:642 [inline]
       __do_compat_sys_sendmsg net/compat.c:649 [inline]
       __se_compat_sys_sendmsg net/compat.c:646 [inline]
       __ia32_compat_sys_sendmsg+0x7a/0xb0 net/compat.c:646
       do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline]
       do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408
       entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
      
      The buggy address belongs to the object at ffff88809886c000
       which belongs to the cache kmalloc-4k of size 4096
      The buggy address is located 1416 bytes inside of
       4096-byte region [ffff88809886c000, ffff88809886d000)
      The buggy address belongs to the page:
      page:ffffea0002621b00 refcount:1 mapcount:0 mapping:ffff8880aa402000 index:0x0 compound_mapcount: 0
      flags: 0xfffe0000010200(slab|head)
      raw: 00fffe0000010200 ffffea0002610d08 ffffea0002607608 ffff8880aa402000
      raw: 0000000000000000 ffff88809886c000 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88809886c480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88809886c500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff88809886c580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
       ffff88809886c600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88809886c680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 36fbf1e5 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e08ad805
    • David S. Miller's avatar
      Merge branch 'atlantic-fixes' · 0b634c0e
      David S. Miller authored
      Igor Russkikh says:
      
      ====================
      Marvell atlantic 2020/02 updates
      
      Hi David, here is another set of bugfixes on AQC family found on
      last integration phase.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b634c0e
    • Dmitry Bogdanov's avatar
      net: atlantic: fix out of range usage of active_vlans array · 5a292c89
      Dmitry Bogdanov authored
      fix static checker warning:
       drivers/net/ethernet/aquantia/atlantic/aq_filters.c:166 aq_check_approve_fvlan()
       error: passing untrusted data to 'test_bit()'
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 7975d2af: ("net: aquantia: add support of rx-vlan-filter offload")
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a292c89
    • Pavel Belous's avatar
      net: atlantic: possible fault in transition to hibernation · 52a22f4d
      Pavel Belous authored
      during hibernation freeze, aq_nic_stop could be invoked
      on a stopped device. That may cause panic on access to
      not yet allocated vector/ring structures.
      
      Add a check to stop device if it is not yet stopped.
      
      Similiarly after freeze in hibernation thaw, aq_nic_start
      could be invoked on a not initialized net device.
      Result will be the same.
      
      Add a check to start device if it is initialized.
      In our case, this is the same as started.
      
      Fixes: 8aaa112a ("net: atlantic: refactoring pm logic")
      Signed-off-by: default avatarPavel Belous <pbelous@marvell.com>
      Signed-off-by: default avatarNikita Danilov <ndanilov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52a22f4d
    • Pavel Belous's avatar
      net: atlantic: fix potential error handling · 380ec5b9
      Pavel Belous authored
      Code inspection found that in case of mapping error we do return current
      'ret' value. But beside error, it is used to count number of descriptors
      allocated for the packet. In that case map_skb function could return '1'.
      
      Changing it to return zero (number of mapped descriptors for skb)
      
      Fixes: 018423e9 ("net: ethernet: aquantia: Add ring support code")
      Signed-off-by: default avatarPavel Belous <pbelous@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      380ec5b9
    • Pavel Belous's avatar
      net: atlantic: fix use after free kasan warn · a4980919
      Pavel Belous authored
      skb->len is used to calculate statistics after xmit invocation.
      
      Under a stress load it may happen that skb will be xmited,
      rx interrupt will come and skb will be freed, all before xmit function
      is even returned.
      
      Eventually, skb->len will access unallocated area.
      
      Moving stats calculation into tx_clean routine.
      
      Fixes: 018423e9 ("net: ethernet: aquantia: Add ring support code")
      Reported-by: default avatarChristophe Vu-Brugier <cvubrugier@fastmail.fm>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarPavel Belous <pbelous@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4980919
    • Nikita Danilov's avatar
      net: atlantic: better loopback mode handling · b42726fc
      Nikita Danilov authored
      Add checks to not enable multiple loopback modes simultaneously,
      It was also discovered that for dma loopback to function correctly
      promisc mode should be enabled on device.
      
      Fixes: ea4b4d7f ("net: atlantic: loopback tests via private flags")
      Signed-off-by: default avatarNikita Danilov <ndanilov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b42726fc
    • Egor Pomozov's avatar
      net: atlantic: ptp gpio adjustments · f08a464c
      Egor Pomozov authored
      Clock adjustment data should be passed to FW as well, otherwise in some
      cases a drift was observed when using GPIO features.
      Signed-off-by: default avatarEgor Pomozov <epomozov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f08a464c
    • Igor Russkikh's avatar
      net: atlantic: check rpc result and wait for rpc address · e7b5f97e
      Igor Russkikh authored
      Artificial HW reliability tests revealed a possible hangup in
      the driver. Normally, when device disappears from bus, all
      register reads returns 0xFFFFFFFF.
      
      At remote procedure invocation towards FW there is a logic
      where result is compared with -1 in a loop.
      That caused an infinite loop if hardware due to some issues
      disappears from bus.
      
      Add extra result checks to prevent this.
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7b5f97e
    • Dmitry Bezrukov's avatar
      net: atlantic: checksum compat issue · 15beab0a
      Dmitry Bezrukov authored
      Yet another checksum offload compatibility issue was found.
      
      The known issue is that AQC HW marks tcp packets with 0xFFFF checksum
      as invalid (1). This is workarounded in driver, passing all the suspicious
      packets up to the stack for further csum validation.
      
      Another HW problem (2) is that it hides invalid csum of LRO aggregated
      packets inside of the individual descriptors. That was workarounded
      by forced scan of all LRO descriptors for checksum errors.
      
      However the scan logic was joint for both LRO and multi-descriptor
      packets (jumbos). And this causes the issue.
      
      We have to drop LRO packets with the detected bad checksum
      because of (2), but we have to pass jumbo packets to stack because of (1).
      
      When using windows tcp partner with jumbo frames but with LSO disabled
      driver discards such frames as bad checksummed. But only LRO frames
      should be dropped, not jumbos.
      
      On such a configurations tcp stream have a chance of drops and stucks.
      
      (1) 76f254d4 ("net: aquantia: tcp checksum 0xffff being handled incorrectly")
      (2) d08b9a0a ("net: aquantia: do not pass lro session with invalid tcp checksum")
      
      Fixes: d08b9a0a ("net: aquantia: do not pass lro session with invalid tcp checksum")
      Signed-off-by: default avatarDmitry Bezrukov <dbezrukov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15beab0a
    • Hangbin Liu's avatar
      selftests: forwarding: vxlan_bridge_1d: fix tos value · 4e867c9a
      Hangbin Liu authored
      After commit 71130f29 ("vxlan: fix tos value before xmit") we start
      strict vxlan xmit tos value by RT_TOS(), which limits the tos value less
      than 0x1E. With current value 0x40 the test will failed with "v1: Expected
      to capture 10 packets, got 0". So let's choose a smaller tos value for
      testing.
      
      Fixes: d417ecf5 ("selftests: forwarding: vxlan_bridge_1d: Add a TOS test")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e867c9a
    • Eric Dumazet's avatar
      net: rtnetlink: fix bugs in rtnl_alt_ifname() · 44bfa9c5
      Eric Dumazet authored
      Since IFLA_ALT_IFNAME is an NLA_STRING, we have no
      guarantee it is nul terminated.
      
      We should use nla_strdup() instead of kstrdup(), since this
      helper will make sure not accessing out-of-bounds data.
      
      BUG: KMSAN: uninit-value in strlen+0x5e/0xa0 lib/string.c:535
      CPU: 1 PID: 19157 Comm: syz-executor.5 Not tainted 5.5.0-rc5-syzkaller #0
      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+0x1c9/0x220 lib/dump_stack.c:118
       kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
       __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
       strlen+0x5e/0xa0 lib/string.c:535
       kstrdup+0x7f/0x1a0 mm/util.c:59
       rtnl_alt_ifname net/core/rtnetlink.c:3495 [inline]
       rtnl_linkprop+0x85d/0xc00 net/core/rtnetlink.c:3553
       rtnl_newlinkprop+0x9d/0xb0 net/core/rtnetlink.c:3568
       rtnetlink_rcv_msg+0x1153/0x1570 net/core/rtnetlink.c:5424
       netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:639 [inline]
       sock_sendmsg net/socket.c:659 [inline]
       ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
       ___sys_sendmsg net/socket.c:2384 [inline]
       __sys_sendmsg+0x451/0x5f0 net/socket.c:2417
       __do_sys_sendmsg net/socket.c:2426 [inline]
       __se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
       do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x45b3b9
      Code: ad b6 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 b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ff1c7b1ac78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007ff1c7b1b6d4 RCX: 000000000045b3b9
      RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000003
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000000009cb R14: 00000000004cb3dd R15: 000000000075bf2c
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline]
       kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127
       kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:82
       slab_alloc_node mm/slub.c:2774 [inline]
       __kmalloc_node_track_caller+0xb40/0x1200 mm/slub.c:4382
       __kmalloc_reserve net/core/skbuff.c:141 [inline]
       __alloc_skb+0x2fd/0xac0 net/core/skbuff.c:209
       alloc_skb include/linux/skbuff.h:1049 [inline]
       netlink_alloc_large_skb net/netlink/af_netlink.c:1174 [inline]
       netlink_sendmsg+0x7d3/0x14d0 net/netlink/af_netlink.c:1892
       sock_sendmsg_nosec net/socket.c:639 [inline]
       sock_sendmsg net/socket.c:659 [inline]
       ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
       ___sys_sendmsg net/socket.c:2384 [inline]
       __sys_sendmsg+0x451/0x5f0 net/socket.c:2417
       __do_sys_sendmsg net/socket.c:2426 [inline]
       __se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
       do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 36fbf1e5 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44bfa9c5
    • Alexandre Belloni's avatar
      net: macb: ensure interface is not suspended on at91rm9200 · e6a41c23
      Alexandre Belloni authored
      Because of autosuspend, at91ether_start is called with clocks disabled.
      Ensure that pm_runtime doesn't suspend the interface as soon as it is
      opened as there is no pm_runtime support is the other relevant parts of the
      platform support for at91rm9200.
      
      Fixes: d54f89af ("net: macb: Add pm runtime support")
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Reviewed-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6a41c23
    • Jethro Beekman's avatar
      net: fib_rules: Correctly set table field when table number exceeds 8 bits · 540e585a
      Jethro Beekman authored
      In 709772e6, RT_TABLE_COMPAT was added to
      allow legacy software to deal with routing table numbers >= 256, but the
      same change to FIB rule queries was overlooked.
      Signed-off-by: default avatarJethro Beekman <jethro@fortanix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      540e585a
    • Leon Romanovsky's avatar
      net/rds: Track user mapped pages through special API · 0d4597c8
      Leon Romanovsky authored
      Convert net/rds to use the newly introduces pin_user_pages() API,
      which properly sets FOLL_PIN. Setting FOLL_PIN is now required for
      code that requires tracking of pinned pages.
      
      Note that this effectively changes the code's behavior: it now
      ultimately calls set_page_dirty_lock(), instead of set_page_dirty().
      This is probably more accurate.
      
      As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
      dealing with a file backed page where we have reference on the inode it
      hangs off." [1]
      
      [1] https://lore.kernel.org/r/20190723153640.GB720@lst.de
      
      Cc: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d4597c8
    • Benjamin Poirier's avatar
      ipv6: Fix nlmsg_flags when splitting a multipath route · afecdb37
      Benjamin Poirier authored
      When splitting an RTA_MULTIPATH request into multiple routes and adding the
      second and later components, we must not simply remove NLM_F_REPLACE but
      instead replace it by NLM_F_CREATE. Otherwise, it may look like the netlink
      message was malformed.
      
      For example,
      	ip route add 2001:db8::1/128 dev dummy0
      	ip route change 2001:db8::1/128 nexthop via fe80::30:1 dev dummy0 \
      		nexthop via fe80::30:2 dev dummy0
      results in the following warnings:
      [ 1035.057019] IPv6: RTM_NEWROUTE with no NLM_F_CREATE or NLM_F_REPLACE
      [ 1035.057517] IPv6: NLM_F_CREATE should be set when creating new route
      
      This patch makes the nlmsg sequence look equivalent for __ip6_ins_rt() to
      what it would get if the multipath route had been added in multiple netlink
      operations:
      	ip route add 2001:db8::1/128 dev dummy0
      	ip route change 2001:db8::1/128 nexthop via fe80::30:1 dev dummy0
      	ip route append 2001:db8::1/128 nexthop via fe80::30:2 dev dummy0
      
      Fixes: 27596472 ("ipv6: fix ECMP route replacement")
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@cumulusnetworks.com>
      Reviewed-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afecdb37
    • Benjamin Poirier's avatar
      ipv6: Fix route replacement with dev-only route · e404b8c7
      Benjamin Poirier authored
      After commit 27596472 ("ipv6: fix ECMP route replacement") it is no
      longer possible to replace an ECMP-able route by a non ECMP-able route.
      For example,
      	ip route add 2001:db8::1/128 via fe80::1 dev dummy0
      	ip route replace 2001:db8::1/128 dev dummy0
      does not work as expected.
      
      Tweak the replacement logic so that point 3 in the log of the above commit
      becomes:
      3. If the new route is not ECMP-able, and no matching non-ECMP-able route
      exists, replace matching ECMP-able route (if any) or add the new route.
      
      We can now summarize the entire replace semantics to:
      When doing a replace, prefer replacing a matching route of the same
      "ECMP-able-ness" as the replace argument. If there is no such candidate,
      fallback to the first route found.
      
      Fixes: 27596472 ("ipv6: fix ECMP route replacement")
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@cumulusnetworks.com>
      Reviewed-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e404b8c7
    • Hangbin Liu's avatar
      selftests: forwarding: use proto icmp for {gretap, ip6gretap}_mac testing · e8023b03
      Hangbin Liu authored
      For tc ip_proto filter, when we extract the flow via __skb_flow_dissect()
      without flag FLOW_DISSECTOR_F_STOP_AT_ENCAP, we will continue extract to
      the inner proto.
      
      So for GRE + ICMP messages, we should not track GRE proto, but inner ICMP
      proto.
      
      For test mirror_gre.sh, it may make user confused if we capture ICMP
      message on $h3(since the flow is GRE message). So I move the capture
      dev to h3-gt{4,6}, and only capture ICMP message.
      
      Before the fix:
      ]# ./mirror_gre.sh
      TEST: ingress mirror to gretap (skip_hw)                            [ OK ]
      TEST: egress mirror to gretap (skip_hw)                             [ OK ]
      TEST: ingress mirror to ip6gretap (skip_hw)                         [ OK ]
      TEST: egress mirror to ip6gretap (skip_hw)                          [ OK ]
      TEST: ingress mirror to gretap: envelope MAC (skip_hw)              [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: egress mirror to gretap: envelope MAC (skip_hw)               [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: ingress mirror to ip6gretap: envelope MAC (skip_hw)           [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: egress mirror to ip6gretap: envelope MAC (skip_hw)            [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: two simultaneously configured mirrors (skip_hw)               [ OK ]
      WARN: Could not test offloaded functionality
      
      After fix:
      ]# ./mirror_gre.sh
      TEST: ingress mirror to gretap (skip_hw)                            [ OK ]
      TEST: egress mirror to gretap (skip_hw)                             [ OK ]
      TEST: ingress mirror to ip6gretap (skip_hw)                         [ OK ]
      TEST: egress mirror to ip6gretap (skip_hw)                          [ OK ]
      TEST: ingress mirror to gretap: envelope MAC (skip_hw)              [ OK ]
      TEST: egress mirror to gretap: envelope MAC (skip_hw)               [ OK ]
      TEST: ingress mirror to ip6gretap: envelope MAC (skip_hw)           [ OK ]
      TEST: egress mirror to ip6gretap: envelope MAC (skip_hw)            [ OK ]
      TEST: two simultaneously configured mirrors (skip_hw)               [ OK ]
      WARN: Could not test offloaded functionality
      
      Fixes: ba8d3987 ("selftests: forwarding: Add test for mirror to gretap")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: default avatarPetr Machata <pmachata@gmail.com>
      Tested-by: default avatarPetr Machata <pmachata@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8023b03
  2. 14 Feb, 2020 4 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 2019fc96
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix interrupt name truncation in mv88e6xxx dsa driver, from Andrew
          Lunn.
      
       2) Process generic XDP even if SKB is cloned, from Toke Høiland-Jørgensen.
      
       3) Fix leak of kernel memory to userspace in smc, from Eric Dumazet.
      
       4) Add some missing netlink attribute validation to matchall and
          flower, from Davide Caratti.
      
       5) Send icmp responses properly when NAT has been applied to the frame
          before we get to the tunnel emitting the icmp, from Jason Donenfeld.
      
       6) Make sure there is enough SKB headroom when adding dsa tags for qca
          and ar9331. From Per Forlin.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (62 commits)
        netdevice.h: fix all kernel-doc and Sphinx warnings
        net: dsa: tag_ar9331: Make sure there is headroom for tag
        net: dsa: tag_qca: Make sure there is headroom for tag
        net, ip6_tunnel: enhance tunnel locate with link check
        net/smc: no peer ID in CLC decline for SMCD
        net/smc: transfer fasync_list in case of fallback
        net: hns3: fix a copying IPv6 address error in hclge_fd_get_flow_tuples()
        net: hns3: fix VF bandwidth does not take effect in some case
        net: hns3: add management table after IMP reset
        mac80211: fix wrong 160/80+80 MHz setting
        cfg80211: add missing policy for NL80211_ATTR_STATUS_CODE
        xfrm: interface: use icmp_ndo_send helper
        wireguard: device: use icmp_ndo_send helper
        sunvnet: use icmp_ndo_send helper
        gtp: use icmp_ndo_send helper
        icmp: introduce helper for nat'd source address in network device context
        net/sched: flower: add missing validation of TCA_FLOWER_FLAGS
        net/sched: matchall: add missing validation of TCA_MATCHALL_FLAGS
        net/flow_dissector: remove unexist field description
        page_pool: refill page when alloc.count of pool is zero
        ...
      2019fc96
    • Linus Torvalds's avatar
      Merge tag 'pm-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 4e03e4e6
      Linus Torvalds authored
      Pull power management fixes from Rafael Wysocki:
       "Fix three issues related to the handling of wakeup events signaled
        through the ACPI SCI while suspended to idle (Rafael Wysocki) and
        unexport an internal cpufreq variable (Yangtao Li)"
      
      * tag 'pm-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system
        ACPICA: Introduce acpi_any_gpe_status_set()
        ACPI: PM: s2idle: Avoid possible race related to the EC GPE
        ACPI: EC: Fix flushing of pending work
        cpufreq: Make cpufreq_global_kobject static
      4e03e4e6
    • Linus Torvalds's avatar
      Merge tag 'sound-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 81f3011c
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "The only common change is the regression fix of the previous PCM fix
        patch for managed buffers while the rest are usual suspects, USB-audio
        and HD-audio device-specific quirks.
      
        The change for UAC2 clock validation workaround became a bit big, but
        the changes are fairly straightforward"
      
      * tag 'sound-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: pcm: Fix double hw_free calls
        ALSA: usb-audio: Add clock validity quirk for Denon MC7000/MCX8000
        ALSA: hda/realtek - Fix silent output on MSI-GL73
        ALSA: hda/realtek - Add more codec supported Headset Button
        ALSA: usb-audio: Apply sample rate quirk for Audioengine D1
        ALSA: usb-audio: Fix UAC2/3 effect unit parsing
        ALSA: usb-audio: Apply 48kHz fixed rate playback for Jabra Evolve 65 headset
      81f3011c
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2020-02-14' of git://anongit.freedesktop.org/drm/drm · 3f0d3293
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "The core has a build fix for edid code on certain compilers/arches/,
        one MST fix and one vgem fix. Regular amdgpu fixes, and a couple of
        small driver fixes.
      
        The i915 fixes are bit larger than normal for this stage, but they
        were having CI issues last week, and they hadn't sent any fixes last
        week due to this.
      
        core:
         - edid build fix
      
        mst:
         - fix NULL ptr deref
      
        vgem:
         - fix close after free
      
        msm:
         - better dma-api usage
      
        sun4i:
         - disable allow_fb_modifiers
      
        amdgpu:
         - Additional OD fixes for navi
         - Misc display fixes
         - VCN 2.5 DPG fix
         - Prevent build errors on PowerPC on some configs
         - GDS EDC fix
      
        i915:
         - dsi/acpi fixes
         - gvt locking and allocation fixes
         - gem/gt fixes
         - bios timing parameters fix"
      
      * tag 'drm-fixes-2020-02-14' of git://anongit.freedesktop.org/drm/drm: (50 commits)
        drm/i915: Mark the removal of the i915_request from the sched.link
        drm/i915/execlists: Reclaim the hanging virtual request
        drm/i915/execlists: Take a reference while capturing the guilty request
        drm/i915/execlists: Offline error capture
        drm/i915/gt: Allow temporary suspension of inflight requests
        drm/i915: Keep track of request among the scheduling lists
        drm/i915/gem: Tighten checks and acquiring the mmap object
        drm/i915: Fix preallocated barrier list append
        drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
        drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release
        drm/i915: Stub out i915_gpu_coredump_put
        drm/amdgpu:/navi10: use the ODCAP enum to index the caps array
        drm/amdgpu: update smu_v11_0_pptable.h
        drm/amdgpu: correct comment to clear up the confusion
        drm/amd/display: DCN2.x Do not program DPPCLK if same value
        drm/amd/display: Don't map ATOM_ENABLE to ATOM_INIT
        drm/amdgpu/vcn2.5: fix warning
        drm/amdgpu: limit GDS clearing workaround in cold boot sequence
        drm/amdgpu: fix amdgpu pmu to use hwc->config instead of hwc->conf
        amdgpu: Prevent build errors regarding soft/hard-float FP ABI tags
        ...
      3f0d3293