1. Aug 22, 2022
    • Maciej Fijalkowski's avatar
      ice: xsk: prohibit usage of non-balanced queue id · 5a42f112
      Maciej Fijalkowski authored
      Fix the following scenario:
      1. ethtool -L $IFACE rx 8 tx 96
      2. xdpsock -q 10 -t -z
      
      Above refers to a case where user would like to attach XSK socket in
      txonly mode at a queue id that does not have a corresponding Rx queue.
      At this moment ice's XSK logic is tightly bound to act on a "queue pair",
      e.g. both Tx and Rx queues at a given queue id are disabled/enabled and
      both of them will get XSK pool assigned, which is broken for the presented
      queue configuration. This results in the splat included at the bottom,
      which is basically an OOB access to Rx ring array.
      
      To fix this, allow using the ids only in scope of "combined" queues
      reported by ethtool. However, logic should be rewritten to allow such
      configurations later on, which would end up as a complete rewrite of the
      control path, so let us go with this temporary fix.
      
      [420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082
      [420160.566359] #PF: supervisor read access in kernel mode
      [420160.572657] #PF: error_code(0x0000) - not-present page
      [420160.579002] PGD 0 P4D 0
      [420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G           OE     5.19.0-rc7+ #10
      [420160.597893] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
      [420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice]
      [420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85
      [420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282
      [420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8
      [420160.655893] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000
      [420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000
      [420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a
      [420160.683833] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828
      [420160.693211] FS:  00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000
      [420160.703645] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [420160.711783] CR2: 0000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0
      [420160.721399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [420160.740707] PKRU: 55555554
      [420160.745960] Call Trace:
      [420160.750962]  <TASK>
      [420160.755597]  ? kmalloc_large_node+0x79/0x90
      [420160.762703]  ? __kmalloc_node+0x3f5/0x4b0
      [420160.769341]  xp_assign_dev+0xfd/0x210
      [420160.775661]  ? shmem_file_read_iter+0x29a/0x420
      [420160.782896]  xsk_bind+0x152/0x490
      [420160.788943]  __sys_bind+0xd0/0x100
      [420160.795097]  ? exit_to_user_mode_prepare+0x20/0x120
      [420160.802801]  __x64_sys_bind+0x16/0x20
      [420160.809298]  do_syscall_64+0x38/0x90
      [420160.815741]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
      [420160.823731] RIP: 0033:0x7fa86a0dd2fb
      [420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48
      [420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
      [420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb
      [420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003
      [420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000
      [420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0
      [420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000
      [420160.919817]  </TASK>
      [420160.925659] Modules linked in: ice(OE) af_packet binfmt_misc nls_iso8859_1 ipmi_ssif intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp mei_me coretemp ioatdma mei ipmi_si wmi ipmi_msghandler acpi_pad acpi_power_meter ip_tables x_tables autofs4 ixgbe i40e crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd ahci mdio dca libahci lpc_ich [last unloaded: ice]
      [420160.977576] CR2: 0000000000000082
      [420160.985037] ---[ end trace 0000000000000000 ]---
      [420161.097724] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice]
      [420161.107341] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85
      [420161.134741] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282
      [420161.144274] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8
      [420161.155690] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000
      [420161.168088] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000
      [420161.179295] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a
      [420161.190420] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828
      [420161.201505] FS:  00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000
      [420161.213628] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [420161.223413] CR2: 0000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0
      [420161.234653] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [420161.245893] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [420161.257052] PKRU: 55555554
      
      Fixes: 2d4238f5
      
       ("ice: Add support for AF_XDP")
      Signed-off-by: default avatarMaciej Fijalkowski <maciej.fijalkowski@intel.com>
      Tested-by: default avatarGeorge Kuruvinakunnel <george.kuruvinakunnel@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      5a42f112
    • Duoming Zhou's avatar
      nfc: pn533: Fix use-after-free bugs caused by pn532_cmd_timeout · f1e941db
      Duoming Zhou authored
      When the pn532 uart device is detaching, the pn532_uart_remove()
      is called. But there are no functions in pn532_uart_remove() that
      could delete the cmd_timeout timer, which will cause use-after-free
      bugs. The process is shown below:
      
          (thread 1)                  |        (thread 2)
                                      |  pn532_uart_send_frame
      pn532_uart_remove               |    mod_timer(&pn532->cmd_timeout,...)
        ...                           |    (wait a time)
        kfree(pn532) //FREE           |    pn532_cmd_timeout
                                      |      pn532_uart_send_frame
                                      |        pn532->... //USE
      
      This patch adds del_timer_sync() in pn532_uart_remove() in order to
      prevent the use-after-free bugs. What's more, the pn53x_unregister_nfc()
      is well synchronized, it sets nfc_dev->shutting_down to true and there
      are no syscalls could restart the cmd_timeout timer.
      
      Fixes: c656aa4c
      
       ("nfc: pn533: add UART phy driver")
      Signed-off-by: default avatarDuoming Zhou <duoming@zju.edu.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1e941db
    • David S. Miller's avatar
      Merge branch 'r8152-fixes' · 6e10001c
      David S. Miller authored
      
      
      Hayes Wang says:
      
      ====================
      r8152: fix flow control settings
      
      These patches fix the settings of RX FIFO about flow control.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e10001c
    • Hayes Wang's avatar
      r8152: fix the RX FIFO settings when suspending · b75d6120
      Hayes Wang authored
      The RX FIFO would be changed when suspending, so the related settings
      have to be modified, too. Otherwise, the flow control would work
      abnormally.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216333
      
      
      Reported-by: default avatarMark Blakeney <mark.blakeney@bullet-systems.net>
      Fixes: cdf0b86b
      
       ("r8152: fix a WOL issue")
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b75d6120
    • Hayes Wang's avatar
      r8152: fix the units of some registers for RTL8156A · 6dc4df12
      Hayes Wang authored
      The units of PLA_RX_FIFO_FULL and PLA_RX_FIFO_EMPTY are 16 bytes.
      
      Fixes: 195aae32
      
       ("r8152: support new chips")
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6dc4df12
    • Bernard Pidoux's avatar
      rose: check NULL rose_loopback_neigh->loopback · 3c53cd65
      Bernard Pidoux authored
      Commit 3b3fd068 added NULL check for
      `rose_loopback_neigh->dev` in rose_loopback_timer() but omitted to
      check rose_loopback_neigh->loopback.
      
      It thus prevents *all* rose connect.
      
      The reason is that a special rose_neigh loopback has a NULL device.
      
      /proc/net/rose_neigh illustrates it via rose_neigh_show() function :
      [...]
      seq_printf(seq, "%05d %-9s %-4s   %3d %3d  %3s     %3s %3lu %3lu",
      	   rose_neigh->number,
      	   (rose_neigh->loopback) ? "RSLOOP-0" : ax2asc(buf, &rose_neigh->callsign),
      	   rose_neigh->dev ? rose_neigh->dev->name : "???",
      	   rose_neigh->count,
      
      /proc/net/rose_neigh displays special rose_loopback_neigh->loopback as
      callsign RSLOOP-0:
      
      addr  callsign  dev  count use mode restart  t0  tf digipeaters
      00001 RSLOOP-0  ???      1   2  DCE     yes   0   0
      
      By checking rose_loopback_neigh->loopback, rose_rx_call_request() is called
      even in case rose_loopback_neigh->dev is NULL. This repairs rose connections.
      
      Verification with rose client application FPAC:
      
      FPAC-Node v 4.1.3 (built Aug  5 2022) for LINUX (help = h)
      F6BVP-4 (Commands = ?) : u
      Users - AX.25 Level 2 sessions :
      Port   Callsign     Callsign  AX.25 state  ROSE state  NetRom status
      axudp  F6BVP-5   -> F6BVP-9   Connected    Connected   ---------
      
      Fixes: 3b3fd068
      
       ("rose: Fix Null pointer dereference in rose_send_frame()")
      Signed-off-by: default avatarBernard Pidoux <f6bvp@free.fr>
      Suggested-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Thomas DL9SAU Osterried <thomas@osterried.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c53cd65
  2. Aug 20, 2022
  3. Aug 19, 2022
  4. Aug 18, 2022
    • Lorenzo Bianconi's avatar
      net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_xdp_run · a617ccc0
      Lorenzo Bianconi authored
      Fix possible NULL pointer dereference in mtk_xdp_run() if the
      ebpf program returns XDP_TX and xdp_convert_buff_to_frame routine fails
      returning NULL.
      
      Fixes: 5886d26f
      
       ("net: ethernet: mtk_eth_soc: add xmit XDP support")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Link: https://lore.kernel.org/r/627a07d759020356b64473e09f0855960e02db28.1660659112.git.lorenzo@kernel.org
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a617ccc0
    • Leon Romanovsky's avatar
      net/mlx5e: Allocate flow steering storage during uplink initialization · d515f38c
      Leon Romanovsky authored
      IPsec code relies on valid priv->fs pointer that is the case in NIC
      flow, but not correct in uplink. Before commit that mentioned in the
      Fixes line, that pointer was valid in all flows as it was allocated
      together with priv struct.
      
      In addition, the cleanup representors routine called to that
      not-initialized priv->fs pointer and its internals which caused NULL
      deference.
      
      So, move FS allocation to be as early as possible.
      
      Fixes: af8bbf73
      
       ("net/mlx5e: Convert mlx5e_flow_steering member of mlx5e_priv to pointer")
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Link: https://lore.kernel.org/r/ae46fa5bed3c67f937bfdfc0370101278f5422f1.1660639564.git.leonro@nvidia.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d515f38c
    • Jakub Kicinski's avatar
      Merge branch 'fixes-for-ocelot-driver-statistics' · 5b6a0729
      Jakub Kicinski authored
      Vladimir Oltean says:
      
      ====================
      Fixes for Ocelot driver statistics
      
      This series contains bug fixes for the ocelot drivers (both switchdev
      and DSA). Some concern the counters exposed to ethtool -S, and others to
      the counters exposed to ifconfig. I'm aware that the changes are fairly
      large, but I wanted to prioritize on a proper approach to addressing the
      issues rather than a quick hack.
      
      Some of the noticed problems:
      - bad register offsets for some counters
      - unhandled concurrency leading to corrupted counters
      - unhandled 32-bit wraparound of ifconfig counters
      
      The issues on the ocelot switchdev driver were noticed through code
      inspection, I do not have the hardware to test.
      
      This patch set necessarily converts ocelot->stats_lock from a mutex to a
      spinlock. I know this affects Colin Foster's development with the SPI
      controlled VSC7512. I have other changes prepared for net-next that
      convert this back into a mutex (along with other changes in this area).
      ====================
      
      Link: https://lore.kernel.org/r/20220816135352.1431497-1-vladimir.oltean@nxp.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5b6a0729
    • Vladimir Oltean's avatar
      net: mscc: ocelot: report ndo_get_stats64 from the wraparound-resistant ocelot->stats · e780e319
      Vladimir Oltean authored
      Rather than reading the stats64 counters directly from the 32-bit
      hardware, it's better to rely on the output produced by the periodic
      ocelot_port_update_stats().
      
      It would be even better to call ocelot_port_update_stats() right from
      ocelot_get_stats64() to make sure we report the current values rather
      than the ones from 2 seconds ago. But we need to export
      ocelot_port_update_stats() from the switch lib towards the switchdev
      driver for that, and future work will largely undo that.
      
      There are more ocelot-based drivers waiting to be introduced, an example
      of which is the SPI-controlled VSC7512. In that driver's case, it will
      be impossible to call ocelot_port_update_stats() from ndo_get_stats64
      context, since the latter is atomic, and reading the stats over SPI is
      sleepable. So the compromise taken here, which will also hold going
      forward, is to report 64-bit counters to stats64, which are not 100% up
      to date.
      
      Fixes: a556c76a
      
       ("net: mscc: Add initial Ocelot switch support")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e780e319
    • Vladimir Oltean's avatar
      net: mscc: ocelot: keep ocelot_stat_layout by reg address, not offset · d4c36765
      Vladimir Oltean authored
      
      
      With so many counter addresses recently discovered as being wrong, it is
      desirable to at least have a central database of information, rather
      than two: one through the SYS_COUNT_* registers (used for
      ndo_get_stats64), and the other through the offset field of struct
      ocelot_stat_layout elements (used for ethtool -S).
      
      The strategy will be to keep the SYS_COUNT_* definitions as the single
      source of truth, but for that we need to expand our current definitions
      to cover all registers. Then we need to convert the ocelot region
      creation logic, and stats worker, to the read semantics imposed by going
      through SYS_COUNT_* absolute register addresses, rather than offsets
      of 32-bit words relative to SYS_COUNT_RX_OCTETS (which should have been
      SYS_CNT, by the way).
      
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d4c36765
    • Vladimir Oltean's avatar
      net: mscc: ocelot: make struct ocelot_stat_layout array indexable · 91904600
      Vladimir Oltean authored
      
      
      The ocelot counters are 32-bit and require periodic reading, every 2
      seconds, by ocelot_port_update_stats(), so that wraparounds are
      detected.
      
      Currently, the counters reported by ocelot_get_stats64() come from the
      32-bit hardware counters directly, rather than from the 64-bit
      accumulated ocelot->stats, and this is a problem for their integrity.
      
      The strategy is to make ocelot_get_stats64() able to cherry-pick
      individual stats from ocelot->stats the way in which it currently reads
      them out from SYS_COUNT_* registers. But currently it can't, because
      ocelot->stats is an opaque u64 array that's used only to feed data into
      ethtool -S.
      
      To solve that problem, we need to make ocelot->stats indexable, and
      associate each element with an element of struct ocelot_stat_layout used
      by ethtool -S.
      
      This makes ocelot_stat_layout a fat (and possibly sparse) array, so we
      need to change the way in which we access it. We no longer need
      OCELOT_STAT_END as a sentinel, because we know the array's size
      (OCELOT_NUM_STATS). We just need to skip the array elements that were
      left unpopulated for the switch revision (ocelot, felix, seville).
      
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      91904600
    • Vladimir Oltean's avatar
      net: mscc: ocelot: fix race between ndo_get_stats64 and ocelot_check_stats_work · 18d8e67d
      Vladimir Oltean authored
      The 2 methods can run concurrently, and one will change the window of
      counters (SYS_STAT_CFG_STAT_VIEW) that the other sees. The fix is
      similar to what commit 7fbf6795 ("net: mscc: ocelot: fix mutex lock
      error during ethtool stats read") has done for ethtool -S.
      
      Fixes: a556c76a
      
       ("net: mscc: Add initial Ocelot switch support")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      18d8e67d
    • Vladimir Oltean's avatar
      net: mscc: ocelot: turn stats_lock into a spinlock · 22d842e3
      Vladimir Oltean authored
      
      
      ocelot_get_stats64() currently runs unlocked and therefore may collide
      with ocelot_port_update_stats() which indirectly accesses the same
      counters. However, ocelot_get_stats64() runs in atomic context, and we
      cannot simply take the sleepable ocelot->stats_lock mutex. We need to
      convert it to an atomic spinlock first. Do that as a preparatory change.
      
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      22d842e3
    • Vladimir Oltean's avatar
      net: mscc: ocelot: fix address of SYS_COUNT_TX_AGING counter · 173ca866
      Vladimir Oltean authored
      This register, used as part of stats->tx_dropped in
      ocelot_get_stats64(), has a wrong address. At the address currently
      given, there is actually the c_tx_green_prio_6 counter.
      
      Fixes: a556c76a
      
       ("net: mscc: Add initial Ocelot switch support")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      173ca866
    • Vladimir Oltean's avatar
      net: mscc: ocelot: fix incorrect ndo_get_stats64 packet counters · 5152de7b
      Vladimir Oltean authored
      Reading stats using the SYS_COUNT_* register definitions is only used by
      ocelot_get_stats64() from the ocelot switchdev driver, however,
      currently the bucket definitions are incorrect.
      
      Separately, on both RX and TX, we have the following problems:
      - a 256-1023 bucket which actually tracks the 256-511 packets
      - the 1024-1526 bucket actually tracks the 512-1023 packets
      - the 1527-max bucket actually tracks the 1024-1526 packets
      
      => nobody tracks the packets from the real 1527-max bucket
      
      Additionally, the RX_PAUSE, RX_CONTROL, RX_LONGS and RX_CLASSIFIED_DROPS
      all track the wrong thing. However this doesn't seem to have any
      consequence, since ocelot_get_stats64() doesn't use these.
      
      Even though this problem only manifests itself for the switchdev driver,
      we cannot split the fix for ocelot and for DSA, since it requires fixing
      the bucket definitions from enum ocelot_reg, which makes us necessarily
      adapt the structures from felix and seville as well.
      
      Fixes: 84705fc1 ("net: dsa: felix: introduce support for Seville VSC9953 switch")
      Fixes: 56051948 ("net: dsa: ocelot: add driver for Felix switch family")
      Fixes: a556c76a
      
       ("net: mscc: Add initial Ocelot switch support")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5152de7b
    • Vladimir Oltean's avatar
      net: dsa: felix: fix ethtool 256-511 and 512-1023 TX packet counters · 40d21c45
      Vladimir Oltean authored
      What the driver actually reports as 256-511 is in fact 512-1023, and the
      TX packets in the 256-511 bucket are not reported. Fix that.
      
      Fixes: 56051948
      
       ("net: dsa: ocelot: add driver for Felix switch family")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      40d21c45
    • Vladimir Oltean's avatar
      net: dsa: don't warn in dsa_port_set_state_now() when driver doesn't support it · 211987f3
      Vladimir Oltean authored
      ds->ops->port_stp_state_set() is, like most DSA methods, optional, and
      if absent, the port is supposed to remain in the forwarding state (as
      standalone). Such is the case with the mv88e6060 driver, which does not
      offload the bridge layer. DSA warns that the STP state can't be changed
      to FORWARDING as part of dsa_port_enable_rt(), when in fact it should not.
      
      The error message is also not up to modern standards, so take the
      opportunity to make it more descriptive.
      
      Fixes: fd364541
      
       ("net: dsa: change scope of STP state setter")
      Reported-by: default avatarSergei Antonov <saproj@gmail.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSergei Antonov <saproj@gmail.com>
      Link: https://lore.kernel.org/r/20220816201445.1809483-1-vladimir.oltean@nxp.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      211987f3
    • Rustam Subkhankulov's avatar
      net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions() · fd8e899c
      Rustam Subkhankulov authored
      
      
      If an error occurs in dsa_devlink_region_create(), then 'priv->regions'
      array will be accessed by negative index '-1'.
      
      Found by Linux Verification Center (linuxtesting.org) with SVACE.
      
      Signed-off-by: default avatarRustam Subkhankulov <subkhankulov@ispras.ru>
      Fixes: bf425b82 ("net: dsa: sja1105: expose static config as devlink region")
      Link: https://lore.kernel.org/r/20220817003845.389644-1-subkhankulov@ispras.ru
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fd8e899c
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf · bec13ba9
      Jakub Kicinski authored
      Florian Westphal says:
      
      ====================
      netfilter: conntrack and nf_tables bug fixes
      
      The following patchset contains netfilter fixes for net.
      
      Broken since 5.19:
        A few ancient connection tracking helpers assume TCP packets cannot
        exceed 64kb in size, but this isn't the case anymore with 5.19 when
        BIG TCP got merged, from myself.
      
      Regressions since 5.19:
        1. 'conntrack -E expect' won't display anything because nfnetlink failed
           to enable events for expectations, only for normal conntrack events.
      
        2. partially revert change that added resched calls to a function that can
           be in atomic context.  Both broken and fixed up by myself.
      
      Broken for several releases (up to original merge of nf_tables):
        Several fixes for nf_tables control plane, from Pablo.
        This fixes up resource leaks in error paths and adds more sanity
        checks for mutually exclusive attributes/flags.
      
      Kconfig:
        NF_CONNTRACK_PROCFS is very old and doesn't provide all info provided
        via ctnetlink, so it should not default to y. From Geert Uytterhoeven.
      
      Selftests:
        rework nft_flowtable.sh: it frequently indicated failure; the way it
        tried to detect an offload failure did not work reliably.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
        testing: selftests: nft_flowtable.sh: rework test to detect offload failure
        testing: selftests: nft_flowtable.sh: use random netns names
        netfilter: conntrack: NF_CONNTRACK_PROCFS should no longer default to y
        netfilter: nf_tables: check NFT_SET_CONCAT flag if field_count is specified
        netfilter: nf_tables: disallow NFT_SET_ELEM_CATCHALL and NFT_SET_ELEM_INTERVAL_END
        netfilter: nf_tables: NFTA_SET_ELEM_KEY_END requires concat and interval flags
        netfilter: nf_tables: validate NFTA_SET_ELEM_OBJREF based on NFT_SET_OBJECT flag
        netfilter: nf_tables: really skip inactive sets when allocating name
        netfilter: nfnetlink: re-enable conntrack expectation events
        netfilter: nf_tables: fix scheduling-while-atomic splat
        netfilter: nf_ct_irc: cap packet search space to 4k
        netfilter: nf_ct_ftp: prefer skb_linearize
        netfilter: nf_ct_h323: cap packet size at 64k
        netfilter: nf_ct_sane: remove pseudo skb linearization
        netfilter: nf_tables: possible module reference underflow in error path
        netfilter: nf_tables: disallow NFTA_SET_ELEM_KEY_END with NFT_SET_ELEM_INTERVAL_END flag
        netfilter: nf_tables: use READ_ONCE and WRITE_ONCE for shared generation id access
      ====================
      
      Link: https://lore.kernel.org/r/20220817140015.25843-1-fw@strlen.de
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bec13ba9
    • David Howells's avatar
      net: Fix suspicious RCU usage in bpf_sk_reuseport_detach() · fc4aaf9f
      David Howells authored
      bpf_sk_reuseport_detach() calls __rcu_dereference_sk_user_data_with_flags()
      to obtain the value of sk->sk_user_data, but that function is only usable
      if the RCU read lock is held, and neither that function nor any of its
      callers hold it.
      
      Fix this by adding a new helper, __locked_read_sk_user_data_with_flags()
      that checks to see if sk->sk_callback_lock() is held and use that here
      instead.
      
      Alternatively, making __rcu_dereference_sk_user_data_with_flags() use
      rcu_dereference_checked() might suffice.
      
      Without this, the following warning can be occasionally observed:
      
      =============================
      WARNING: suspicious RCU usage
      6.0.0-rc1-build2+ #563 Not tainted
      -----------------------------
      include/net/sock.h:592 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      5 locks held by locktest/29873:
       #0: ffff88812734b550 (&sb->s_type->i_mutex_key#9){+.+.}-{3:3}, at: __sock_release+0x77/0x121
       #1: ffff88812f5621b0 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_close+0x1c/0x70
       #2: ffff88810312f5c8 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_unhash+0x76/0x1c0
       #3: ffffffff83768bb8 (reuseport_lock){+...}-{2:2}, at: reuseport_detach_sock+0x18/0xdd
       #4: ffff88812f562438 (clock-AF_INET){++..}-{2:2}, at: bpf_sk_reuseport_detach+0x24/0xa4
      
      stack backtrace:
      CPU: 1 PID: 29873 Comm: locktest Not tainted 6.0.0-rc1-build2+ #563
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4c/0x5f
       bpf_sk_reuseport_detach+0x6d/0xa4
       reuseport_detach_sock+0x75/0xdd
       inet_unhash+0xa5/0x1c0
       tcp_set_state+0x169/0x20f
       ? lockdep_sock_is_held+0x3a/0x3a
       ? __lock_release.isra.0+0x13e/0x220
       ? reacquire_held_locks+0x1bb/0x1bb
       ? hlock_class+0x31/0x96
       ? mark_lock+0x9e/0x1af
       __tcp_close+0x50/0x4b6
       tcp_close+0x28/0x70
       inet_release+0x8e/0xa7
       __sock_release+0x95/0x121
       sock_close+0x14/0x17
       __fput+0x20f/0x36a
       task_work_run+0xa3/0xcc
       exit_to_user_mode_prepare+0x9c/0x14d
       syscall_exit_to_user_mode+0x18/0x44
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Fixes: cf8c1e96
      
       ("net: refactor bpf_sk_reuseport_detach()")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Hawkins Jiawei <yin31149@gmail.com>
      Link: https://lore.kernel.org/r/166064248071.3502205.10036394558814861778.stgit@warthog.procyon.org.uk
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fc4aaf9f
    • Linus Torvalds's avatar
      Merge tag 'ntfs3_for_6.0' of https://github.com/Paragon-Software-Group/linux-ntfs3 · 3b06a275
      Linus Torvalds authored
      Pull ntfs3 updates from Konstantin Komarov:
      
       - implement FALLOC_FL_INSERT_RANGE
      
       - fix some logic errors
      
       - fixed xfstests (tested on x86_64): generic/064 generic/213
         generic/300 generic/361 generic/449 generic/485
      
       - some dead code removed or refactored
      
      * tag 'ntfs3_for_6.0' of https://github.com/Paragon-Software-Group/linux-ntfs3: (39 commits)
        fs/ntfs3: uninitialized variable in ntfs_set_acl_ex()
        fs/ntfs3: Remove unused function wnd_bits
        fs/ntfs3: Make ni_ins_new_attr return error
        fs/ntfs3: Create MFT zone only if length is large enough
        fs/ntfs3: Refactoring attr_insert_range to restore after errors
        fs/ntfs3: Refactoring attr_punch_hole to restore after errors
        fs/ntfs3: Refactoring attr_set_size to restore after errors
        fs/ntfs3: New function ntfs_bad_inode
        fs/ntfs3: Make MFT zone less fragmented
        fs/ntfs3: Check possible errors in run_pack in advance
        fs/ntfs3: Added comments to frecord functions
        fs/ntfs3: Fill duplicate info in ni_add_name
        fs/ntfs3: Make static function attr_load_runs
        fs/ntfs3: Add new argument is_mft to ntfs_mark_rec_free
        fs/ntfs3: Remove unused mi_mark_free
        fs/ntfs3: Fix very fragmented case in attr_punch_hole
        fs/ntfs3: Fix work with fragmented xattr
        fs/ntfs3: Make ntfs_fallocate return -ENOSPC instead of -EFBIG
        fs/ntfs3: extend ni_insert_nonresident to return inserted ATTR_LIST_ENTRY
        fs/ntfs3: Check reserved size for maximum allowed
        ...
      3b06a275
    • Linus Torvalds's avatar
      dcache: move the DCACHE_OP_COMPARE case out of the __d_lookup_rcu loop · ae2a8236
      Linus Torvalds authored
      
      
      __d_lookup_rcu() is one of the hottest functions in the kernel on
      certain loads, and it is complicated by filesystems that might want to
      have their own name compare function.
      
      We can improve code generation by moving the test of DCACHE_OP_COMPARE
      outside the loop, which makes the loop itself much simpler, at the cost
      of some code duplication.  But both cases end up being simpler, and the
      "native" direct case-sensitive compare particularly so.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ae2a8236