Skip to content
Snippets Groups Projects
  1. Aug 25, 2023
  2. Aug 21, 2023
  3. Jun 26, 2023
  4. Jun 23, 2023
    • Damien Le Moal's avatar
      PCI: endpoint: Automatically create a function specific attributes group · 70b3740f
      Damien Le Moal authored
      A PCI endpoint function driver can define function specific attributes
      under its function configfs directory using the add_cfs() endpoint driver
      operation. This is done by tying up the mkdir operation for the function
      configfs directory to a call to the add_cfs() operation.  However, there
      are no checks preventing the user from repeatedly creating function
      specific attribute directories with different names, resulting in the same
      endpoint specific attributes group being added multiple times, which also
      result in an invalid reference counting for the attribute groups. E.g.,
      using the pci-epf-ntb function driver as an example, the user creates the
      function as follows:
      
        $ modprobe pci-epf-ntb
        $ cd /sys/kernel/config/pci_ep/functions/pci_epf_ntb
        $ mkdir func0
        $ tree func0
        func0/
        |-- baseclass_code
        |-- cache_line_size
        |-- ...
        `-- vendorid
      
        $ mkdir func0/attrs
        $ tree func0
        func0/
        |-- attrs
        |   |-- db_count
        |   |-- mw1
        |   |-- mw2
        |   |-- mw3
        |   |-- mw4
        |   |-- num_mws
        |   `-- spad_count
        |-- baseclass_code
        |-- cache_line_size
        |-- ...
        `-- vendorid
      
      At this point, the function can be started by linking the EP controller.
      However, if the user mistakenly creates again a directory:
      
        $ mkdir func0/attrs2
        $ tree func0
        func0/
        |-- attrs
        |   |-- db_count
        |   |-- mw1
        |   |-- mw2
        |   |-- mw3
        |   |-- mw4
        |   |-- num_mws
        |   `-- spad_count
        |-- attrs2
        |   |-- db_count
        |   |-- mw1
        |   |-- mw2
        |   |-- mw3
        |   |-- mw4
        |   |-- num_mws
        |   `-- spad_count
        |-- baseclass_code
        |-- cache_line_size
        |-- ...
        `-- vendorid
      
      The endpoint function specific attributes are duplicated and cause a crash
      when the endpoint function device is torn down:
      
        refcount_t: addition on 0; use-after-free.
        WARNING: CPU: 2 PID: 834 at lib/refcount.c:25 refcount_warn_saturate+0xc8/0x144
        CPU: 2 PID: 834 Comm: rmdir Not tainted 6.3.0-rc1 #1
        Hardware name: Pine64 RockPro64 v2.1 (DT)
        pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        ...
        Call trace:
        refcount_warn_saturate+0xc8/0x144
        config_item_get+0x7c/0x80
        configfs_rmdir+0x17c/0x30c
        vfs_rmdir+0x8c/0x204
        do_rmdir+0x158/0x184
        __arm64_sys_unlinkat+0x64/0x80
        invoke_syscall+0x48/0x114
        ...
      
      Fix this by modifying pci_epf_cfs_work() to execute the new function
      pci_ep_cfs_add_type_group() which itself calls pci_epf_type_add_cfs() to
      obtain the function specific attribute group and the group name (directory
      name) from the endpoint function driver. If the function driver defines an
      attribute group, pci_ep_cfs_add_type_group() then proceeds to register this
      group using configfs_register_group(), thus automatically exposing the
      function type specific configfs attributes to the user. E.g.:
      
        $ modprobe pci-epf-ntb
        $ cd /sys/kernel/config/pci_ep/functions/pci_epf_ntb
        $ mkdir func0
        $ tree func0
        func0/
        |-- baseclass_code
        |-- cache_line_size
        |-- ...
        |-- pci_epf_ntb.0
        |   |-- db_count
        |   |-- mw1
        |   |-- mw2
        |   |-- mw3
        |   |-- mw4
        |   |-- num_mws
        |   `-- spad_count
        |-- primary
        |-- ...
        `-- vendorid
      
      With this change, there is no need for the user to create or delete
      directories in the endpoint function attributes directory. The
      pci_epf_type_group_ops group operations are thus removed.
      
      Also update the documentation for the pci-epf-ntb and pci-epf-vntb function
      drivers to reflect this change, removing the explanations showing the need
      to manually create the sub-directory for the function specific attributes.
      
      Link: https://lore.kernel.org/r/20230415023542.77601-2-dlemoal@kernel.org
      
      
      Signed-off-by: default avatarDamien Le Moal <dlemoal@kernel.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lpieralisi@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarManivannan Sadhasivam <mani@kernel.org>
      70b3740f
  5. Jun 12, 2023
  6. Mar 19, 2023
  7. Jan 24, 2023
  8. Dec 03, 2022
  9. Nov 17, 2022
  10. Aug 09, 2022
  11. Jul 29, 2022
    • Arnd Bergmann's avatar
      PCI: Remove pci_mmap_page_range() wrapper · 0ad722f1
      Arnd Bergmann authored
      The ARCH_GENERIC_PCI_MMAP_RESOURCE symbol came up in a recent discussion,
      and I noticed that this was left behind by an unfinished cleanup from 2017.
      
      The only architecture that still relies on providing its own
      pci_mmap_page_range() helper instead of using the generic
      pci_mmap_resource_range() is sparc. Presumably the reasons for this have
      not changed, but at least this can be simplified by converting sparc to use
      the same interface as the others.
      
      The only difference between the two is the device-specific offset that gets
      added to or subtracted from vma->vm_pgoff.
      
      Change the only caller of pci_mmap_page_range() in common code to subtract
      this offset and call the modern interface, while adding it back in the
      sparc implementation to preserve the existing behavior.
      
      This removes the complexities of the dual interfaces from the common code,
      and keeps it all specific to the sparc architecture code. According to
      David Miller, the sparc code lets user space poke into the VGA I/O port
      registers by mmapping the I/O space of the parent bridge device, which is
      something that the generic pci_mmap_resource_range() code apparently does
      not.
      
      Link: https://lore.kernel.org/lkml/1519887203.622.3.camel@infradead.org/t/
      Link: https://lore.kernel.org/lkml/20220714214657.2402250-3-shorne@gmail.com/
      Link: https://lore.kernel.org/r/20220715153617.3393420-1-arnd@kernel.org
      
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Stafford Horne <shorne@gmail.com>
      0ad722f1
  12. Jul 11, 2022
  13. Apr 21, 2022
  14. Mar 30, 2022
  15. Aug 26, 2021
  16. Aug 19, 2021
  17. Jun 17, 2021
  18. Jun 01, 2021
  19. Feb 23, 2021
  20. Oct 09, 2020
  21. Jul 07, 2020
  22. Jul 05, 2020
  23. Jun 30, 2020
  24. Jun 26, 2020
  25. Jun 19, 2020
  26. May 11, 2020
  27. Apr 20, 2020
Loading