1. 23 Mar, 2023 4 commits
    • Zheng Wang's avatar
      Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work · 1e9ac114
      Zheng Wang authored
      In btsdio_probe, &data->work was bound with btsdio_work.In
      btsdio_send_frame, it was started by schedule_work.
      
      If we call btsdio_remove with an unfinished job, there may
      be a race condition and cause UAF bug on hdev.
      
      Fixes: ddbaf13e ("[Bluetooth] Add generic driver for Bluetooth SDIO devices")
      Signed-off-by: default avatarZheng Wang <zyytlz.wz@163.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      1e9ac114
    • Luiz Augusto von Dentz's avatar
      Bluetooth: L2CAP: Fix responding with wrong PDU type · 9aa9d947
      Luiz Augusto von Dentz authored
      L2CAP_ECRED_CONN_REQ shall be responded with L2CAP_ECRED_CONN_RSP not
      L2CAP_LE_CONN_RSP:
      
      L2CAP LE EATT Server - Reject - run
        Listening for connections
        New client connection with handle 0x002a
        Sending L2CAP Request from client
        Client received response code 0x15
        Unexpected L2CAP response code (expected 0x18)
      L2CAP LE EATT Server - Reject - test failed
      
      > ACL Data RX: Handle 42 flags 0x02 dlen 26
            LE L2CAP: Enhanced Credit Connection Request (0x17) ident 1 len 18
              PSM: 39 (0x0027)
              MTU: 64
              MPS: 64
              Credits: 5
              Source CID: 65
              Source CID: 66
              Source CID: 67
              Source CID: 68
              Source CID: 69
      < ACL Data TX: Handle 42 flags 0x00 dlen 16
            LE L2CAP: LE Connection Response (0x15) ident 1 len 8
              invalid size
              00 00 00 00 00 00 06 00
      
      L2CAP LE EATT Server - Reject - run
        Listening for connections
        New client connection with handle 0x002a
        Sending L2CAP Request from client
        Client received response code 0x18
      L2CAP LE EATT Server - Reject - test passed
      
      Fixes: 15f02b91 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      9aa9d947
    • Stephan Gerhold's avatar
      Bluetooth: btqcomsmd: Fix command timeout after setting BD address · 5d44ab9e
      Stephan Gerhold authored
      On most devices using the btqcomsmd driver (e.g. the DragonBoard 410c
      and other devices based on the Qualcomm MSM8916/MSM8909/... SoCs)
      the Bluetooth firmware seems to become unresponsive for a while after
      setting the BD address. On recent kernel versions (at least 5.17+)
      this often causes timeouts for subsequent commands, e.g. the HCI reset
      sent by the Bluetooth core during initialization:
      
          Bluetooth: hci0: Opcode 0x c03 failed: -110
      
      Unfortunately this behavior does not seem to be documented anywhere.
      Experimentation suggests that the minimum necessary delay to avoid
      the problem is ~150us. However, to be sure add a sleep for > 1ms
      in case it is a bit longer on other firmware versions.
      
      Older kernel versions are likely also affected, although perhaps with
      slightly different errors or less probability. Side effects can easily
      hide the issue in most cases, e.g. unrelated incoming interrupts that
      cause the necessary delay.
      
      Fixes: 1511cc75 ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
      Signed-off-by: default avatarStephan Gerhold <stephan.gerhold@kernkonzept.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      5d44ab9e
    • Kiran K's avatar
      Bluetooth: btinel: Check ACPI handle for NULL before accessing · 902160cd
      Kiran K authored
      Older platforms and Virtual platforms which doesn't have support for
      bluetooth device in ACPI firmware will not have valid ACPI handle.
      Check for validity of handle before accessing.
      
      dmesg log from simics environment (virtual platform):
      
      BUG: unable to handle kernel NULL pointer dereference at
      0000000000000018
      IP: acpi_ns_walk_namespace+0x5c/0x278
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      Modules linked in: bnep intel_powerclamp coretemp kvm_intel
      kvm irqbypass intel_cstate input_leds joydev serio_raw mac_hid
      btusb(OE) btintel(OE) bluetooth(OE) lpc_ich compat(OE) ecdh_generic
      i7core_edac i5500_temp shpchp binfmt_misc sch_fq_codel parport_pc ppdev
      lp parport ip_tables x_tables autofs4 hid_generic usbhid hid e1000e
      psmouse ahci pata_acpi libahci ptp pps_core floppy
      CPU: 0 PID: 35 Comm: kworker/u3:0 Tainted: G           OE
      4.15.0-140-generic #144-Ubuntu
      Hardware name: Simics Simics, BIOS Simics 01/01/2011
      Workqueue: hci0 hci_power_on [bluetooth]
      RIP: 0010:acpi_ns_walk_namespace+0x5c/0x278
      RSP: 0000:ffffaa9c0049bba8 EFLAGS: 00010246
      RAX: 0000000000000001 RBX: 0000000000001001 RCX: 0000000000000010
      RDX: ffffffff92ea7e27 RSI: ffffffff92ea7e10 RDI: 00000000000000c8
      RBP: ffffaa9c0049bbf8 R08: 0000000000000000 R09: ffffffffc05b39d0
      R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
      R13: 0000000000000000 R14: ffffffffc05b39d0 R15: ffffaa9c0049bc70
      FS:  0000000000000000(0000) GS:ffff8be73fc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000018 CR3: 0000000075f0e000 CR4: 00000000000006f0
      
      Fixes: 294d749b ("Bluetooth: btintel: Iterate only bluetooth device ACPI entries")
      Signed-off-by: default avatarKiran K <kiran.k@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      902160cd
  2. 22 Mar, 2023 16 commits
    • Brian Gix's avatar
      Bluetooth: Remove "Power-on" check from Mesh feature · 52dd5e96
      Brian Gix authored
      The Bluetooth mesh experimental feature enable was requiring the
      controller to be powered off in order for the Enable to work. Mesh is
      supposed to be enablable regardless of the controller state, and created
      an unintended requirement that the mesh daemon be started before the
      classic bluetoothd daemon.
      
      Fixes: af6bcc19 ("Bluetooth: Add experimental wrapper for MGMT based mesh")
      Signed-off-by: default avatarBrian Gix <brian.gix@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      52dd5e96
    • Min Li's avatar
      Bluetooth: Fix race condition in hci_cmd_sync_clear · 1c66bee4
      Min Li authored
      There is a potential race condition in hci_cmd_sync_work and
      hci_cmd_sync_clear, and could lead to use-after-free. For instance,
      hci_cmd_sync_work is added to the 'req_workqueue' after cancel_work_sync
      The entry of 'cmd_sync_work_list' may be freed in hci_cmd_sync_clear, and
      causing kernel panic when it is used in 'hci_cmd_sync_work'.
      
      Here's the call trace:
      
      dump_stack_lvl+0x49/0x63
      print_report.cold+0x5e/0x5d3
      ? hci_cmd_sync_work+0x282/0x320
      kasan_report+0xaa/0x120
      ? hci_cmd_sync_work+0x282/0x320
      __asan_report_load8_noabort+0x14/0x20
      hci_cmd_sync_work+0x282/0x320
      process_one_work+0x77b/0x11c0
      ? _raw_spin_lock_irq+0x8e/0xf0
      worker_thread+0x544/0x1180
      ? poll_idle+0x1e0/0x1e0
      kthread+0x285/0x320
      ? process_one_work+0x11c0/0x11c0
      ? kthread_complete_and_exit+0x30/0x30
      ret_from_fork+0x22/0x30
      </TASK>
      
      Allocated by task 266:
      kasan_save_stack+0x26/0x50
      __kasan_kmalloc+0xae/0xe0
      kmem_cache_alloc_trace+0x191/0x350
      hci_cmd_sync_queue+0x97/0x2b0
      hci_update_passive_scan+0x176/0x1d0
      le_conn_complete_evt+0x1b5/0x1a00
      hci_le_conn_complete_evt+0x234/0x340
      hci_le_meta_evt+0x231/0x4e0
      hci_event_packet+0x4c5/0xf00
      hci_rx_work+0x37d/0x880
      process_one_work+0x77b/0x11c0
      worker_thread+0x544/0x1180
      kthread+0x285/0x320
      ret_from_fork+0x22/0x30
      
      Freed by task 269:
      kasan_save_stack+0x26/0x50
      kasan_set_track+0x25/0x40
      kasan_set_free_info+0x24/0x40
      ____kasan_slab_free+0x176/0x1c0
      __kasan_slab_free+0x12/0x20
      slab_free_freelist_hook+0x95/0x1a0
      kfree+0xba/0x2f0
      hci_cmd_sync_clear+0x14c/0x210
      hci_unregister_dev+0xff/0x440
      vhci_release+0x7b/0xf0
      __fput+0x1f3/0x970
      ____fput+0xe/0x20
      task_work_run+0xd4/0x160
      do_exit+0x8b0/0x22a0
      do_group_exit+0xba/0x2a0
      get_signal+0x1e4a/0x25b0
      arch_do_signal_or_restart+0x93/0x1f80
      exit_to_user_mode_prepare+0xf5/0x1a0
      syscall_exit_to_user_mode+0x26/0x50
      ret_from_fork+0x15/0x30
      
      Fixes: 6a98e383 ("Bluetooth: Add helper for serialized HCI command execution")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMin Li <lm0963hack@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      1c66bee4
    • Kiran K's avatar
      Bluetooth: btintel: Iterate only bluetooth device ACPI entries · 294d749b
      Kiran K authored
      Current flow interates over entire ACPI table entries looking for
      Bluetooth Per Platform Antenna Gain(PPAG) entry. This patch iterates
      over ACPI entries relvant to Bluetooth device only.
      
      Fixes: c585a92b ("Bluetooth: btintel: Set Per Platform Antenna Gain(PPAG)")
      Signed-off-by: default avatarKiran K <kiran.k@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      294d749b
    • Pauli Virtanen's avatar
      Bluetooth: ISO: fix timestamped HCI ISO data packet parsing · 2f10e40a
      Pauli Virtanen authored
      Use correct HCI ISO data packet header struct when the packet has
      timestamp. The timestamp, when present, goes before the other fields
      (Core v5.3 4E 5.4.5), so the structs are not compatible.
      
      Fixes: ccf74f23 ("Bluetooth: Add BTPROTO_ISO socket type")
      Signed-off-by: default avatarPauli Virtanen <pav@iki.fi>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      2f10e40a
    • Luiz Augusto von Dentz's avatar
      Bluetooth: btusb: Remove detection of ISO packets over bulk · efe375b7
      Luiz Augusto von Dentz authored
      This removes the code introduced by
      14202eff as hci_recv_frame is now able
      to detect ACL packets that are in fact ISO packets.
      
      Fixes: 14202eff ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      efe375b7
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_core: Detect if an ACL packet is in fact an ISO packet · 876e7810
      Luiz Augusto von Dentz authored
      Because some transports don't have a dedicated type for ISO packets
      (see 14202eff) they may use ACL type
      when in fact they are ISO packets.
      
      In the past this was left for the driver to detect such thing but it
      creates a problem when using the likes of btproxy when used by a VM as
      the host would not be aware of the connection the guest is doing it
      won't be able to detect such behavior, so this make bt_recv_frame
      detect when it happens as it is the common interface to all drivers
      including guest VMs.
      
      Fixes: 14202eff ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      876e7810
    • Zhengping Jiang's avatar
      Bluetooth: hci_sync: Resume adv with no RPA when active scan · 3c44a431
      Zhengping Jiang authored
      The address resolution should be disabled during the active scan,
      so all the advertisements can reach the host. The advertising
      has to be paused before disabling the address resolution,
      because the advertising will prevent any changes to the resolving
      list and the address resolution status. Skipping this will cause
      the hci error and the discovery failure.
      
      According to the bluetooth specification:
      "7.8.44 LE Set Address Resolution Enable command
      
      This command shall not be used when:
      - Advertising (other than periodic advertising) is enabled,
      - Scanning is enabled, or
      - an HCI_LE_Create_Connection, HCI_LE_Extended_Create_Connection, or
        HCI_LE_Periodic_Advertising_Create_Sync command is outstanding."
      
      If the host is using RPA, the controller needs to generate RPA for
      the advertising, so the advertising must remain paused during the
      active scan.
      
      If the host is not using RPA, the advertising can be resumed after
      disabling the address resolution.
      
      Fixes: 9afc675e ("Bluetooth: hci_sync: allow advertise when scan without RPA")
      Signed-off-by: default avatarZhengping Jiang <jiangzp@google.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      3c44a431
    • Ido Schimmel's avatar
      mlxsw: spectrum_fid: Fix incorrect local port type · bb765a74
      Ido Schimmel authored
      Local port is a 10-bit number, but it was mistakenly stored in a u8,
      resulting in firmware errors when using a netdev corresponding to a
      local port higher than 255.
      
      Fix by storing the local port in u16, as is done in the rest of the
      code.
      
      Fixes: bf73904f ("mlxsw: Add support for 802.1Q FID family")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Link: https://lore.kernel.org/r/eace1f9d96545ab8a2775db857cb7e291a9b166b.1679398549.git.petrm@nvidia.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      bb765a74
    • Zhang Changzhong's avatar
      net/sonic: use dma_mapping_error() for error check · 4107b874
      Zhang Changzhong authored
      The DMA address returned by dma_map_single() should be checked with
      dma_mapping_error(). Fix it accordingly.
      
      Fixes: efcce839 ("[PATCH] macsonic/jazzsonic network drivers update")
      Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: default avatarFinn Thain <fthain@linux-m68k.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Link: https://lore.kernel.org/r/6645a4b5c1e364312103f48b7b36783b94e197a2.1679370343.git.fthain@linux-m68k.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4107b874
    • Jakub Kicinski's avatar
      Merge branch 'fix-trainwreck-with-ocelot-switch-statistics-counters' · 82463d9d
      Jakub Kicinski authored
      Vladimir Oltean says:
      
      ====================
      Fix trainwreck with Ocelot switch statistics counters
      
      While testing the patch set for preemptible traffic classes with some
      controlled traffic and measuring counter deltas:
      https://lore.kernel.org/netdev/20230220122343.1156614-1-vladimir.oltean@nxp.com/
      
      I noticed that in the output of "ethtool -S swp0 --groups eth-mac
      eth-phy eth-ctrl rmon -- --src emac | grep -v ': 0'", the TX counters
      were off. Quickly I realized that their values were permutated by 1
      compared to their names, and that for example
      tx-rmon-etherStatsPkts64to64Octets was incrementing when
      tx-rmon-etherStatsPkts65to127Octets should have.
      
      Initially I suspected something having to do with the bulk reading
      logic, and indeed I found a bug there (fixed as 1/3), but that was not
      the source of the problems. Instead it revealed other problems.
      
      While dumping the regions created by the driver on my switch, I figured
      out that it sees a discontinuity which shouldn't have existed between
      reg 0x278 and reg 0x280.
      
      Discontinuity between last reg 0x0 and new reg 0x0, creating new region
      Discontinuity between last reg 0x108 and new reg 0x200, creating new region
      Discontinuity between last reg 0x278 and new reg 0x280, creating new region
      Discontinuity between last reg 0x2b0 and new reg 0x400, creating new region
      region of 67 contiguous counters starting with SYS:STAT:CNT[0x000]
      region of 31 contiguous counters starting with SYS:STAT:CNT[0x080]
      region of 13 contiguous counters starting with SYS:STAT:CNT[0x0a0]
      region of 18 contiguous counters starting with SYS:STAT:CNT[0x100]
      
      That is where TX_MM_HOLD should have been, and that was the bug, since
      it was missing. After adding it, the regions look like this and the
      off-by-one issue is resolved:
      
      Discontinuity between last reg 0x000000 and new reg 0x000000, creating new region
      Discontinuity between last reg 0x000108 and new reg 0x000200, creating new region
      Discontinuity between last reg 0x0002b0 and new reg 0x000400, creating new region
      region of 67 contiguous counters starting with SYS:STAT:CNT[0x000]
      region of 45 contiguous counters starting with SYS:STAT:CNT[0x080]
      region of 18 contiguous counters starting with SYS:STAT:CNT[0x100]
      
      However, as I am thinking out loud, it should have not reported the
      other counters as off by one even when skipping TX_MM_HOLD... after all,
      on Ocelot/Seville, there are more counters which need to be skipped.
      
      Which is when I investigated and noticed the bug solved in 2/3.
      I've validated that both on native VSC9959 (which uses
      ocelot_mm_stats_layout) as well as by faking the other switches by
      making VSC9959 use the plain ocelot_stats_layout.
      
      To summarize: on all Ocelot switches, the TX counters and drop counters
      are completely broken. The RX counters are mostly fine.
      
      With this occasion, I have collected more cleanup patches in this area,
      which I'm going to submit after the net -> net-next merge.
      ====================
      
      Link: https://lore.kernel.org/r/20230321010325.897817-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      82463d9d
    • Vladimir Oltean's avatar
      net: mscc: ocelot: add TX_MM_HOLD to ocelot_mm_stats_layout · 5291099e
      Vladimir Oltean authored
      The lack of a definition for this counter is what initially prompted me
      to investigate a problem which really manifested itself as the previous
      change, "net: mscc: ocelot: fix transfer from region->buf to ocelot->stats".
      
      When TX_MM_HOLD is defined in enum ocelot_stat but not in struct
      ocelot_stat_layout ocelot_mm_stats_layout, this creates a hole, which
      due to the aforementioned bug, makes all counters following TX_MM_HOLD
      be recorded off by one compared to their correct position. So for
      example, a non-zero TX_PMAC_OCTETS would be reported as TX_MERGE_FRAGMENTS,
      TX_PMAC_UNICAST would be reported as TX_PMAC_OCTETS, TX_PMAC_64 would be
      reported as TX_PMAC_PAUSE, etc etc. This is because the size of the hole
      (1) is much smaller than the size of the region, so the phenomenon where
      the stats are off-by-one, rather than lost, prevails.
      
      However, the phenomenon where stats are lost can be seen too, for
      example with DROP_LOCAL, which is at the beginning of its own region
      (offset 0x000400 vs the previous 0x0002b0 constitutes a discontinuity).
      This is also reported as off by one and saved to TX_PMAC_1527_MAX, but
      that counter is not reported to the unstructured "ethtool -S", as
      opposed to DROP_LOCAL which is (as "drop_local").
      
      Fixes: ab3f97a9 ("net: mscc: ocelot: export ethtool MAC Merge stats for Felix VSC9959")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5291099e
    • Vladimir Oltean's avatar
      net: mscc: ocelot: fix transfer from region->buf to ocelot->stats · 17dfd210
      Vladimir Oltean authored
      To understand the problem, we need some definitions.
      
      The driver is aware of multiple counters (enum ocelot_stat), yet not all
      switches supported by the driver implement all counters. There are 2
      statistics layouts: ocelot_stats_layout and ocelot_mm_stats_layout, the
      latter having 36 counters more than the former.
      
      ocelot->stats[] is not a compact array, i.e. there are elements within
      it which are not going to be populated for ocelot_stats_layout. On the
      other hand, ocelot->stats[] is easily indexable, for example "tx_octets"
      for port 3 can be found at ocelot->stats[3 * OCELOT_NUM_STATS +
      OCELOT_STAT_TX_OCTETS], and that is why we keep it sparse.
      
      Regions, as created by ocelot_prepare_stats_regions(), are compact
      (every element from region->buf will correspond to a counter that is
      present in this switch's layout) but are not easily indexable.
      
      Let's define holes as the ranges of values of enum ocelot_stat for which
      ocelot_stats_layout doesn't have a "reg" defined. For example, there is
      a hole between OCELOT_STAT_RX_GREEN_PRIO_7 and OCELOT_STAT_TX_OCTETS
      which is of 23 elements that are only present on ocelot_mm_stats_layout,
      and as such, they are also present in enum ocelot_stat. Let's define the
      left extremity of the hole - the last enum ocelot_stat still defined -
      as A (in this case OCELOT_STAT_RX_GREEN_PRIO_7) and the right extremity -
      the first enum ocelot_stat that is defined after a series of undefined
      ones - as B (in this case OCELOT_STAT_TX_OCTETS).
      
      There is a bug in the procedure which transfers stats from region->buf[]
      to ocelot->stats[].
      
      For each hole in the ocelot_stats_layout, the logic transfers the stats
      starting with enum ocelot_stat B to ocelot->stats[] index A + 1. So all
      stats after a hole are saved to a position which is off by B - A + 1
      elements.
      
      This causes 2 kinds of issues:
      (a) counters which shouldn't increment increment
      (b) counters which should increment don't
      
      Holes in the ocelot_stat_layout automatically imply the end of a region
      and the beginning of a new one; however the reverse is not necessarily
      true. For example, for ocelot_mm_stat_layout, there could be multiple
      regions (which indicate discontinuities in register addresses) while
      there is no hole (which indicates discontinuities in enum ocelot_stat
      values).
      
      In the example above, the stats from the second region->buf[] are not
      transferred to ocelot->stats starting with index
      "port * OCELOT_NUM_STATS + OCELOT_STAT_TX_OCTETS" as they should, but
      rather, starting with element
      "port * OCELOT_NUM_STATS + OCELOT_STAT_RX_GREEN_PRIO_7 + 1".
      
      That stats[] array element is not reported to user space for switches
      that use ocelot_stat_layout, and that is how issue (b) occurs.
      
      However, if the length of the second region is larger than the hole,
      then some stats will start to be transferred to the ocelot->stats[]
      indices which *are* reported to user space, but those indices contain
      wrong values (corresponding to unexpected counters). This is how issue
      (a) occurs.
      
      The procedure, as it was introduced in commit d87b1c08 ("net: mscc:
      ocelot: use bulk reads for stats"), was not buggy, because there were no
      holes in the struct ocelot_stat_layout instances at that time. The
      problem is that when those holes were introduced, the function was not
      updated to take them into consideration.
      
      To update the procedure, we need to know, for each region, which enum
      ocelot_stat corresponds to its region->base. We have no way of deducing
      that based on the contents of struct ocelot_stats_region, so we need to
      add this information.
      
      Fixes: ab3f97a9 ("net: mscc: ocelot: export ethtool MAC Merge stats for Felix VSC9959")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      17dfd210
    • Vladimir Oltean's avatar
      net: mscc: ocelot: fix stats region batching · 6acc72a4
      Vladimir Oltean authored
      The blamed commit changed struct ocelot_stat_layout :: "u32 offset" to
      "u32 reg".
      
      However, "u32 reg" is not quite a register address, but an enum
      ocelot_reg, which in itself encodes an enum ocelot_target target in the
      upper bits, and an index into the ocelot->map[target][] array in the
      lower bits.
      
      So, whereas the previous code comparison between stats_layout[i].offset
      and last + 1 was correct (because those "offsets" at the time were
      32-bit relative addresses), the new code, comparing layout[i].reg to
      last + 4 is not correct, because the "reg" here is an enum/index, not an
      actual register address.
      
      What we want to compare are indeed register addresses, but to do that,
      we need to actually go through the same motions as
      __ocelot_bulk_read_ix() itself.
      
      With this bug, all statistics counters are deemed by
      ocelot_prepare_stats_regions() as constituting their own region.
      (Truncated) log on VSC9959 (Felix) below (prints added by me):
      
      Before:
      
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x000]
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x001]
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x002]
      ...
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x041]
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x042]
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x080]
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x081]
      ...
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x0ac]
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x100]
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x101]
      ...
      region of 1 contiguous counters starting with SYS:STAT:CNT[0x111]
      
      After:
      
      region of 67 contiguous counters starting with SYS:STAT:CNT[0x000]
      region of 45 contiguous counters starting with SYS:STAT:CNT[0x080]
      region of 18 contiguous counters starting with SYS:STAT:CNT[0x100]
      
      Since commit d87b1c08 ("net: mscc: ocelot: use bulk reads for
      stats") intended bulking as a performance improvement, and since now,
      with trivial-sized regions, performance is even worse than without
      bulking at all, this could easily qualify as a performance regression.
      
      Fixes: d4c36765 ("net: mscc: ocelot: keep ocelot_stat_layout by reg address, not offset")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Acked-by: default avatarColin Foster <colin.foster@in-advantage.com>
      Tested-by: default avatarColin Foster <colin.foster@in-advantage.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6acc72a4
    • Eric Dumazet's avatar
      erspan: do not use skb_mac_header() in ndo_start_xmit() · 8e50ed77
      Eric Dumazet authored
      Drivers should not assume skb_mac_header(skb) == skb->data in their
      ndo_start_xmit().
      
      Use skb_network_offset() and skb_transport_offset() which
      better describe what is needed in erspan_fb_xmit() and
      ip6erspan_tunnel_xmit()
      
      syzbot reported:
      WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]
      WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
      Modules linked in:
      CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb9 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
      RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]
      RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
      Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00
      RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
      RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003
      RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff
      R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00
      R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000
      FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
      <TASK>
      __netdev_start_xmit include/linux/netdevice.h:4900 [inline]
      netdev_start_xmit include/linux/netdevice.h:4914 [inline]
      __dev_direct_xmit+0x504/0x730 net/core/dev.c:4300
      dev_direct_xmit include/linux/netdevice.h:3088 [inline]
      packet_xmit+0x20a/0x390 net/packet/af_packet.c:285
      packet_snd net/packet/af_packet.c:3075 [inline]
      packet_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107
      sock_sendmsg_nosec net/socket.c:724 [inline]
      sock_sendmsg+0xde/0x190 net/socket.c:747
      __sys_sendto+0x23a/0x340 net/socket.c:2142
      __do_sys_sendto net/socket.c:2154 [inline]
      __se_sys_sendto net/socket.c:2150 [inline]
      __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      RIP: 0033:0x7f123aaa1039
      Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
      RBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0
      R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000
      
      Fixes: 1baf5ebf ("erspan: auto detect truncated packets.")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Link: https://lore.kernel.org/r/20230320163427.8096-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8e50ed77
    • Li Zetao's avatar
      atm: idt77252: fix kmemleak when rmmod idt77252 · 4fe3c885
      Li Zetao authored
      There are memory leaks reported by kmemleak:
      
        unreferenced object 0xffff888106500800 (size 128):
          comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s)
          hex dump (first 32 bytes):
            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          backtrace:
            [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380
            [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0
            [<000000000e947e2a>] idt77252_init_one+0x2847/0x3c90 [idt77252]
            [<000000006efb048e>] local_pci_probe+0xeb/0x1a0
          ...
      
        unreferenced object 0xffff888106500b00 (size 128):
          comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s)
          hex dump (first 32 bytes):
            00 20 3d 01 80 88 ff ff 00 20 3d 01 80 88 ff ff  . =...... =.....
            f0 23 3d 01 80 88 ff ff 00 20 3d 01 00 00 00 00  .#=...... =.....
          backtrace:
            [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380
            [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0
            [<00000000f451c5be>] alloc_scq.constprop.0+0x4a/0x400 [idt77252]
            [<00000000e6313849>] idt77252_init_one+0x28cf/0x3c90 [idt77252]
      
      The root cause is traced to the vc_maps which alloced in open_card_oam()
      are not freed in close_card_oam(). The vc_maps are used to record
      open connections, so when close a vc_map in close_card_oam(), the memory
      should be freed. Moreover, the ubr0 is not closed when close a idt77252
      device, leading to the memory leak of vc_map and scq_info.
      
      Fix them by adding kfree in close_card_oam() and implementing new
      close_card_ubr0() to close ubr0.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarLi Zetao <lizetao1@huawei.com>
      Reviewed-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Link: https://lore.kernel.org/r/20230320143318.2644630-1-lizetao1@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4fe3c885
    • Álvaro Fernández Rojas's avatar
      net: dsa: tag_brcm: legacy: fix daisy-chained switches · 032a9540
      Álvaro Fernández Rojas authored
      When BCM63xx internal switches are connected to switches with a 4-byte
      Broadcom tag, it does not identify the packet as VLAN tagged, so it adds one
      based on its PVID (which is likely 0).
      Right now, the packet is received by the BCM63xx internal switch and the 6-byte
      tag is properly processed. The next step would to decode the corresponding
      4-byte tag. However, the internal switch adds an invalid VLAN tag after the
      6-byte tag and the 4-byte tag handling fails.
      In order to fix this we need to remove the invalid VLAN tag after the 6-byte
      tag before passing it to the 4-byte tag decoding.
      
      Fixes: 964dbf18 ("net: dsa: tag_brcm: add support for legacy tags")
      Signed-off-by: default avatarÁlvaro Fernández Rojas <noltari@gmail.com>
      Reviewed-by: default avatarMichal Swiatkowski <michal.swiatkowski@linux.intel.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20230319095540.239064-1-noltari@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      032a9540
  3. 21 Mar, 2023 1 commit
  4. 20 Mar, 2023 7 commits
    • David S. Miller's avatar
      Merge branch 'ps3_gelic_net-fixes' · f36fa558
      David S. Miller authored
      Geoff Levand says:
      
      ====================
      net/ps3_gelic_net: DMA related fixes
      
      v9: Make rx_skb_size local to gelic_descr_prepare_rx.
      v8: Add more cpu_to_be32 calls.
      v7: Remove all cleanups, sync to spider net.
      v6: Reworked and cleaned up patches.
      v5: Some additional patch cleanups.
      v4: More patch cleanups.
      v3: Cleaned up patches as requested.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f36fa558
    • Geoff Levand's avatar
      net/ps3_gelic_net: Use dma_mapping_error · bebe933d
      Geoff Levand authored
      The current Gelic Etherenet driver was checking the return value of its
      dma_map_single call, and not using the dma_mapping_error() routine.
      
      Fixes runtime problems like these:
      
        DMA-API: ps3_gelic_driver sb_05: device driver failed to check map error
        WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:1027 .check_unmap+0x888/0x8dc
      
      Fixes: 02c18891 ("ps3: gigabit ethernet driver for PS3, take3")
      Reviewed-by: default avatarAlexander Duyck <alexanderduyck@fb.com>
      Signed-off-by: default avatarGeoff Levand <geoff@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bebe933d
    • Geoff Levand's avatar
      net/ps3_gelic_net: Fix RX sk_buff length · 19b3bb51
      Geoff Levand authored
      The Gelic Ethernet device needs to have the RX sk_buffs aligned to
      GELIC_NET_RXBUF_ALIGN, and also the length of the RX sk_buffs must
      be a multiple of GELIC_NET_RXBUF_ALIGN.
      
      The current Gelic Ethernet driver was not allocating sk_buffs large
      enough to allow for this alignment.
      
      Also, correct the maximum and minimum MTU sizes, and add a new
      preprocessor macro for the maximum frame size, GELIC_NET_MAX_FRAME.
      
      Fixes various randomly occurring runtime network errors.
      
      Fixes: 02c18891 ("ps3: gigabit ethernet driver for PS3, take3")
      Signed-off-by: default avatarGeoff Levand <geoff@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19b3bb51
    • Tom Rix's avatar
      usb: plusb: remove unused pl_clear_QuickLink_features function · 7d722c98
      Tom Rix authored
      clang with W=1 reports
      drivers/net/usb/plusb.c:65:1: error:
        unused function 'pl_clear_QuickLink_features' [-Werror,-Wunused-function]
      pl_clear_QuickLink_features(struct usbnet *dev, int val)
      ^
      This static function is not used, so remove it.
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d722c98
    • Szymon Heidrich's avatar
      net: usb: lan78xx: Limit packet length to skb->len · 7f247f5a
      Szymon Heidrich authored
      Packet length retrieved from descriptor may be larger than
      the actual socket buffer length. In such case the cloned
      skb passed up the network stack will leak kernel memory contents.
      
      Additionally prevent integer underflow when size is less than
      ETH_FCS_LEN.
      
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Signed-off-by: default avatarSzymon Heidrich <szymon.heidrich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f247f5a
    • Zheng Wang's avatar
      net: qcom/emac: Fix use after free bug in emac_remove due to race condition · 6b6bc5b8
      Zheng Wang authored
      In emac_probe, &adpt->work_thread is bound with
      emac_work_thread. Then it will be started by timeout
      handler emac_tx_timeout or a IRQ handler emac_isr.
      
      If we remove the driver which will call emac_remove
        to make cleanup, there may be a unfinished work.
      
      The possible sequence is as follows:
      
      Fix it by finishing the work before cleanup in the emac_remove
      and disable timeout response.
      
      CPU0                  CPU1
      
                          |emac_work_thread
      emac_remove         |
      free_netdev         |
      kfree(netdev);      |
                          |emac_reinit_locked
                          |emac_mac_down
                          |//use netdev
      Fixes: b9b17deb ("net: emac: emac gigabit ethernet controller driver")
      Signed-off-by: default avatarZheng Wang <zyytlz.wz@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b6bc5b8
    • Vladimir Oltean's avatar
      net: dsa: report rx_bytes unadjusted for ETH_HLEN · a8eff035
      Vladimir Oltean authored
      We collect the software statistics counters for RX bytes (reported to
      /proc/net/dev and to ethtool -S $dev | grep 'rx_bytes: ") at a time when
      skb->len has already been adjusted by the eth_type_trans() ->
      skb_pull_inline(skb, ETH_HLEN) call to exclude the L2 header.
      
      This means that when connecting 2 DSA interfaces back to back and
      sending 1 packet with length 100, the sending interface will report
      tx_bytes as incrementing by 100, and the receiving interface will report
      rx_bytes as incrementing by 86.
      
      Since accounting for that in scripts is quirky and is something that
      would be DSA-specific behavior (requiring users to know that they are
      running on a DSA interface in the first place), the proposal is that we
      treat it as a bug and fix it.
      
      This design bug has always existed in DSA, according to my analysis:
      commit 91da11f8 ("net: Distributed Switch Architecture protocol
      support") also updates skb->dev->stats.rx_bytes += skb->len after the
      eth_type_trans() call. Technically, prior to Florian's commit
      a86d8bec ("net: dsa: Factor bottom tag receive functions"), each and
      every vendor-specific tagging protocol driver open-coded the same bug,
      until the buggy code was consolidated into something resembling what can
      be seen now. So each and every driver should have its own Fixes: tag,
      because of their different histories until the convergence point.
      I'm not going to do that, for the sake of simplicity, but just blame the
      oldest appearance of buggy code.
      
      There are 2 ways to fix the problem. One is the obvious way, and the
      other is how I ended up doing it. Obvious would have been to move
      dev_sw_netstats_rx_add() one line above eth_type_trans(), and below
      skb_push(skb, ETH_HLEN). But DSA processing is not as simple as that.
      We count the bytes after removing everything DSA-related from the
      packet, to emulate what the packet's length was, on the wire, when the
      user port received it.
      
      When eth_type_trans() executes, dsa_untag_bridge_pvid() has not run yet,
      so in case the switch driver requests this behavior - commit
      412a1526 ("net: dsa: untag the bridge pvid from rx skbs") has the
      details - the obvious variant of the fix wouldn't have worked, because
      the positioning there would have also counted the not-yet-stripped VLAN
      header length, something which is absent from the packet as seen on the
      wire (there it may be untagged, whereas software will see it as
      PVID-tagged).
      
      Fixes: f613ed66 ("net: dsa: Add support for 64-bit statistics")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8eff035
  5. 19 Mar, 2023 10 commits
    • Ido Schimmel's avatar
      mlxsw: core_thermal: Fix fan speed in maximum cooling state · 6d206b1e
      Ido Schimmel authored
      The cooling levels array is supposed to prevent the system fans from
      being configured below a 20% duty cycle as otherwise some of them get
      stuck at 0 RPM.
      
      Due to an off-by-one error, the last element in the array was not
      initialized, causing it to be set to zero, which in turn lead to fans
      being configured with a 0% duty cycle in maximum cooling state.
      
      Since commit 332fdf95 ("mlxsw: thermal: Fix out-of-bounds memory
      accesses") the contents of the array are static. Therefore, instead of
      fixing the initialization of the array, simply remove it and adjust
      thermal_cooling_device_ops::set_cur_state() so that the configured duty
      cycle is never set below 20%.
      
      Before:
      
       # cat /sys/class/thermal/thermal_zone0/cdev0/type
       mlxsw_fan
       # echo 10 > /sys/class/thermal/thermal_zone0/cdev0/cur_state
       # cat /sys/class/hwmon/hwmon0/name
       mlxsw
       # cat /sys/class/hwmon/hwmon0/pwm1
       0
      
      After:
      
       # cat /sys/class/thermal/thermal_zone0/cdev0/type
       mlxsw_fan
       # echo 10 > /sys/class/thermal/thermal_zone0/cdev0/cur_state
       # cat /sys/class/hwmon/hwmon0/name
       mlxsw
       # cat /sys/class/hwmon/hwmon0/pwm1
       255
      
      This bug was uncovered when the thermal subsystem repeatedly tried to
      configure the cooling devices to their maximum state due to another
      issue [1]. This resulted in the fans being stuck at 0 RPM, which
      eventually lead to the system undergoing thermal shutdown.
      
      [1] https://lore.kernel.org/netdev/ZA3CFNhU4AbtsP4G@shredder/
      
      Fixes: a421ce08 ("mlxsw: core: Extend cooling device with cooling levels")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarVadim Pasternak <vadimp@nvidia.com>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d206b1e
    • Russell King (Oracle)'s avatar
      net: sfp: fix state loss when updating state_hw_mask · 04361b8b
      Russell King (Oracle) authored
      Andrew reports that the SFF modules on one of the ZII platforms do not
      indicate link up due to the SFP code believing that LOS indicating that
      there is no signal being received from the remote end, but in fact the
      LOS signal is showing that there is signal.
      
      What makes SFF modules different from SFPs is they typically have an
      inverted LOS, which uncovered this issue. When we read the hardware
      state, we mask it with state_hw_mask so we ignore anything we're not
      interested in. However, we don't re-read when state_hw_mask changes,
      leading to sfp->state being stale.
      
      Arrange for a software poll of the module state after we have parsed
      the EEPROM in sfp_sm_mod_probe() and updated state_*_mask. This will
      generate any necessary events for signal changes for the state
      machine as well as updating sfp->state.
      Reported-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Tested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Fixes: 8475c4b7 ("net: sfp: re-implement soft state polling setup")
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04361b8b
    • Jochen Henneberg's avatar
      net: stmmac: Fix for mismatched host/device DMA address width · 070246e4
      Jochen Henneberg authored
      Currently DMA address width is either read from a RO device register
      or force set from the platform data. This breaks DMA when the host DMA
      address width is <=32it but the device is >32bit.
      
      Right now the driver may decide to use a 2nd DMA descriptor for
      another buffer (happens in case of TSO xmit) assuming that 32bit
      addressing is used due to platform configuration but the device will
      still use both descriptor addresses as one address.
      
      This can be observed with the Intel EHL platform driver that sets
      32bit for addr64 but the MAC reports 40bit. The TX queue gets stuck in
      case of TCP with iptables NAT configuration on TSO packets.
      
      The logic should be like this: Whatever we do on the host side (memory
      allocation GFP flags) should happen with the host DMA width, whenever
      we decide how to set addresses on the device registers we must use the
      device DMA address width.
      
      This patch renames the platform address width field from addr64 (term
      used in device datasheet) to host_addr and uses this value exclusively
      for host side operations while all chip operations consider the device
      DMA width as read from the device register.
      
      Fixes: 7cfc4486 ("stmmac: intel: Configure EHL PSE0 GbE and PSE1 GbE to 32 bits DMA addressing")
      Signed-off-by: default avatarJochen Henneberg <jh@henneberg-systemdesign.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      070246e4
    • David S. Miller's avatar
      Merge branch 'mdiobus-module-owner' · 543887d7
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      ACPI/DT mdiobus module owner fixes
      
      This patch series fixes wrong mdiobus module ownership for MDIO buses
      registered from DT or ACPI.
      
      Thanks Maxime for providing the first patch and making me see that ACPI
      also had the same issue.
      
      Changes in v2:
      
      - fixed missing kdoc in the first patch
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      543887d7
    • Florian Fainelli's avatar
      net: mdio: fix owner field for mdio buses registered using ACPI · 30b605b8
      Florian Fainelli authored
      Bus ownership is wrong when using acpi_mdiobus_register() to register an
      mdio bus. That function is not inline, so when it calls
      mdiobus_register() the wrong THIS_MODULE value is captured.
      
      CC: Maxime Bizon <mbizon@freebox.fr>
      Fixes: 803ca24d ("net: mdio: Add ACPI support code for mdio")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      30b605b8
    • Maxime Bizon's avatar
      net: mdio: fix owner field for mdio buses registered using device-tree · 99669259
      Maxime Bizon authored
      Bus ownership is wrong when using of_mdiobus_register() to register an mdio
      bus. That function is not inline, so when it calls mdiobus_register() the wrong
      THIS_MODULE value is captured.
      Signed-off-by: default avatarMaxime Bizon <mbizon@freebox.fr>
      Fixes: 90eff909 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
      [florian: fix kdoc, added Fixes tag]
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99669259
    • Florian Fainelli's avatar
      net: phy: Ensure state transitions are processed from phy_stop() · 4203d840
      Florian Fainelli authored
      In the phy_disconnect() -> phy_stop() path, we will be forcibly setting
      the PHY state machine to PHY_HALTED. This invalidates the old_state !=
      phydev->state condition in phy_state_machine() such that we will neither
      display the state change for debugging, nor will we invoke the
      link_change_notify() callback.
      
      Factor the code by introducing phy_process_state_change(), and ensure
      that we process the state change from phy_stop() as well.
      
      Fixes: 5c5f626b ("net: phy: improve handling link_change_notify callback")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4203d840
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · 739cb499
      David S. Miller authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2023-03-16 (igb, igbvf, igc)
      
      This series contains updates to igb, igbvf, and igc drivers.
      
      Lin Ma removes rtnl_lock() when disabling SRIOV on remove which was
      causing deadlock on igb.
      
      Akihiko Odaki delays enabling of SRIOV on igb to prevent early messages
      that could get ignored and clears MAC address when PF returns nack on
      reset; indicating no MAC address was assigned for igbvf.
      
      Gaosheng Cui frees IRQs in error path for igbvf.
      
      Akashi Takahiro fixes logic on checking TAPRIO gate support for igc.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      739cb499
    • Zheng Wang's avatar
      xirc2ps_cs: Fix use after free bug in xirc2ps_detach · e8d20c3d
      Zheng Wang authored
      In xirc2ps_probe, the local->tx_timeout_task was bounded
      with xirc2ps_tx_timeout_task. When timeout occurs,
      it will call xirc_tx_timeout->schedule_work to start the
      work.
      
      When we call xirc2ps_detach to remove the driver, there
      may be a sequence as follows:
      
      Stop responding to timeout tasks and complete scheduled
      tasks before cleanup in xirc2ps_detach, which will fix
      the problem.
      
      CPU0                  CPU1
      
                          |xirc2ps_tx_timeout_task
      xirc2ps_detach      |
        free_netdev       |
          kfree(dev);     |
                          |
                          | do_reset
                          |   //use dev
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarZheng Wang <zyytlz.wz@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8d20c3d
    • Daniil Tatianin's avatar
      qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info · 25143b6a
      Daniil Tatianin authored
      We have to make sure that the info returned by the helper is valid
      before using it.
      
      Found by Linux Verification Center (linuxtesting.org) with the SVACE
      static analysis tool.
      
      Fixes: f990c82c ("qed*: Add support for ndo_set_vf_trust")
      Fixes: 733def6a ("qed*: IOV link control")
      Signed-off-by: default avatarDaniil Tatianin <d-tatianin@yandex-team.ru>
      Reviewed-by: default avatarMichal Swiatkowski <michal.swiatkowski@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25143b6a
  6. 18 Mar, 2023 2 commits