|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5 |
|
| #
888bd832 |
| 26-Feb-2025 |
Niklas Schnelle <[email protected]> |
s390/pci: Introduce pdev->non_mappable_bars and replace VFIO_PCI_MMAP
The ability to map PCI resources to user-space is controlled by global defines. For vfio there is VFIO_PCI_MMAP which is only di
s390/pci: Introduce pdev->non_mappable_bars and replace VFIO_PCI_MMAP
The ability to map PCI resources to user-space is controlled by global defines. For vfio there is VFIO_PCI_MMAP which is only disabled on s390 and controls mapping of PCI resources using vfio-pci with a fallback option via the pread()/pwrite() interface.
For the PCI core there is ARCH_GENERIC_PCI_MMAP_RESOURCE which enables a generic implementation for mapping PCI resources plus the newer sysfs interface. Then there is HAVE_PCI_MMAP which can be used with custom definitions of pci_mmap_resource_range() and the historical /proc/bus/pci interface. Both mechanisms are all or nothing.
For s390 mapping PCI resources is possible and useful for testing and certain applications such as QEMU's vfio-pci based user-space NVMe driver. For certain devices, however access to PCI resources via mappings to user-space is not possible and these must be excluded from the general PCI resource mapping mechanisms.
Introduce pdev->non_mappable_bars to indicate that a PCI device's BARs can not be accessed via mappings to user-space. In the future this enables per-device restrictions of PCI resource mapping.
For now, set this flag for all PCI devices on s390 in line with the existing, general disable of PCI resource mapping. As s390 is the only user of the VFI_PCI_MMAP Kconfig options this can already be replaced with a check of this new flag. Also add similar checks in the other code protected by HAVE_PCI_MMAP respectively ARCH_GENERIC_PCI_MMAP in preparation for enabling these for supported devices.
Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
|
Revision tags: v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7 |
|
| #
0ad722f1 |
| 15-Jul-2022 |
Arnd Bergmann <[email protected]> |
PCI: Remove pci_mmap_page_range() wrapper
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 o
PCI: Remove pci_mmap_page_range() wrapper
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/[email protected]/t/ Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: David Woodhouse <[email protected]> Cc: David S. Miller <[email protected]> Cc: Stafford Horne <[email protected]>
show more ...
|
|
Revision tags: v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8 |
|
| #
c50762a8 |
| 13-Mar-2022 |
Bjorn Helgaas <[email protected]> |
PCI: Remove unused assignments
Remove variables and assignments that are never used.
Found by Krzysztof using cppcheck, e.g.,
$ cppcheck --enable=all --force uselessAssignmentPtrArg drivers/pc
PCI: Remove unused assignments
Remove variables and assignments that are never used.
Found by Krzysztof using cppcheck, e.g.,
$ cppcheck --enable=all --force uselessAssignmentPtrArg drivers/pci/proc.c:102 Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? unreadVariable drivers/pci/setup-bus.c:1528 Variable 'old_flags' is assigned a value that is never used.
Reported-by: Krzysztof Wilczyński <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
|
Revision tags: v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1 |
|
| #
cb2d0f84 |
| 06-Jul-2021 |
Krzysztof Wilczyński <[email protected]> |
PCI: Declare pci_filp_private only when HAVE_PCI_MMAP
The struct pci_filp_private has no users outside drivers/pci/proc.c and is only used when HAVE_PCI_MMAP is defined.
Wrap the struct pci_filp_pr
PCI: Declare pci_filp_private only when HAVE_PCI_MMAP
The struct pci_filp_private has no users outside drivers/pci/proc.c and is only used when HAVE_PCI_MMAP is defined.
Wrap the struct pci_filp_private definition itself in #ifdef HAVE_PCI_MMAP.
Found by cppcheck:
$ cppcheck --enable=all --force drivers/pci/proc.c drivers/pci/proc.c:192:6: style: struct member 'pci_filp_private::write_combine' is never used. [unusedStructMember]
Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
| #
359745d7 |
| 22-Jan-2022 |
Muchun Song <[email protected]> |
proc: remove PDE_DATA() completely
Remove PDE_DATA() completely and replace it with pde_data().
[[email protected]: fix naming clash in drivers/nubus/proc.c] [[email protected]: now
proc: remove PDE_DATA() completely
Remove PDE_DATA() completely and replace it with pde_data().
[[email protected]: fix naming clash in drivers/nubus/proc.c] [[email protected]: now fix it properly]
Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Muchun Song <[email protected]> Acked-by: Christian Brauner <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Alexey Gladkov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
| #
a153e5e1 |
| 15-Aug-2021 |
Krzysztof Wilczyński <[email protected]> |
PCI: Add schedule point in proc_bus_pci_read()
PCI configuration space reads from /proc/bus/pci can often take several milliseconds to complete.
Add a schedule point in proc_bus_pci_read() to reduc
PCI: Add schedule point in proc_bus_pci_read()
PCI configuration space reads from /proc/bus/pci can often take several milliseconds to complete.
Add a schedule point in proc_bus_pci_read() to reduce the maximum latency.
A similar change was made for sysfs by 2ce02a864ac1 ("PCI: Add schedule point in pci_read_config()").
Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
| #
54325d08 |
| 13-Jul-2021 |
Gustavo A. R. Silva <[email protected]> |
PCI: Fix fall-through warning for Clang
Fix the following fallthrough warning (arm64-randconfig with Clang):
drivers/pci/proc.c:234:3: warning: fallthrough annotation in unreachable code [-Wimplici
PCI: Fix fall-through warning for Clang
Fix the following fallthrough warning (arm64-randconfig with Clang):
drivers/pci/proc.c:234:3: warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]
Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/60edca25.k00ut905IFBjPyt5%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
show more ...
|
|
Revision tags: v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7 |
|
| #
636b21b5 |
| 04-Feb-2021 |
Daniel Vetter <[email protected]> |
PCI: Revoke mappings like devmem
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region") /dev/kmem zaps PTEs when the kernel requests exclusive acccess to an iomem region. A
PCI: Revoke mappings like devmem
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region") /dev/kmem zaps PTEs when the kernel requests exclusive acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is the default for all driver uses.
Except there are two more ways to access PCI BARs: sysfs and proc mmap support. Let's plug that hole.
For revoke_devmem() to work we need to link our vma into the same address_space, with consistent vma->vm_pgoff. ->pgoff is already adjusted, because that's how (io_)remap_pfn_range works, but for the mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is to adjust this at at ->open time:
- for sysfs this is easy, now that binary attributes support this. We just set bin_attr->mapping when mmap is supported - for procfs it's a bit more tricky, since procfs PCI access has only one file per device, and access to a specific resource first needs to be set up with some ioctl calls. But mmap is only supported for the same resources as sysfs exposes with mmap support, and otherwise rejected, so we can set the mapping unconditionally at open time without harm.
A special consideration is for arch_can_pci_mmap_io() - we need to make sure that the ->f_mapping doesn't alias between ioport and iomem space. There are only 2 ways in-tree to support mmap of ioports: generic PCI mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single architecture hand-rolling. Both approaches support ioport mmap through a special PFN range and not through magic PTE attributes. Aliasing is therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does not check for CAP_RAWIO. I'm not really sure whether that should be added or not.
Acked-by: Bjorn Helgaas <[email protected]> Reviewed-by: Dan Williams <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Stephen Rothwell <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Kees Cook <[email protected]> Cc: Dan Williams <[email protected]> Cc: Andrew Morton <[email protected]> Cc: John Hubbard <[email protected]> Cc: Jérôme Glisse <[email protected]> Cc: Jan Kara <[email protected]> Cc: Dan Williams <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Bjorn Helgaas <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
show more ...
|
|
Revision tags: v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6 |
|
| #
dc217d2c |
| 27-Nov-2020 |
Daniel Vetter <[email protected]> |
PCI: Obey iomem restrictions for procfs mmap
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs files, and the old proc interface. Two check against iomem_is_exclusive, proc never
PCI: Obey iomem restrictions for procfs mmap
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs files, and the old proc interface. Two check against iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM, this starts to matter, since we don't want random userspace having access to PCI BARs while a driver is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have on the sysfs side in pci_mmap_resource().
Acked-by: Bjorn Helgaas <[email protected]> References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") Signed-off-by: Daniel Vetter <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Kees Cook <[email protected]> Cc: Dan Williams <[email protected]> Cc: Andrew Morton <[email protected]> Cc: John Hubbard <[email protected]> Cc: Jérôme Glisse <[email protected]> Cc: Jan Kara <[email protected]> Cc: Dan Williams <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Bjorn Helgaas <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
show more ...
|
|
Revision tags: v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3 |
|
| #
df561f66 |
| 23-Aug-2020 |
Gustavo A. R. Silva <[email protected]> |
treewide: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through mar
treewide: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case.
[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <[email protected]>
show more ...
|
|
Revision tags: v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1 |
|
| #
97a32539 |
| 04-Feb-2020 |
Alexey Dobriyan <[email protected]> |
proc: convert everything to "struct proc_ops"
The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in seq_file.h.
Conversion rule is:
llseek => proc_lseek unlocked_ioctl => proc_ioctl
proc: convert everything to "struct proc_ops"
The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in seq_file.h.
Conversion rule is:
llseek => proc_lseek unlocked_ioctl => proc_ioctl
xxx => proc_xxx
delete ".owner = THIS_MODULE" line
[[email protected]: fix drivers/isdn/capi/kcapi_proc.c] [[email protected]: fix kernel/sched/psi.c] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1 |
|
| #
c9c13ba4 |
| 27-Sep-2019 |
Denis Efremov <[email protected]> |
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RE
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS".
Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors.
Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Sebastian Ott <[email protected]> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <[email protected]> # video/fbdev/ Acked-by: Gustavo Pimentel <[email protected]> # pci/controller/dwc/ Acked-by: Jack Wang <[email protected]> # scsi/pm8001/ Acked-by: Martin K. Petersen <[email protected]> # scsi/pm8001/ Acked-by: Ulf Hansson <[email protected]> # memstick/
show more ...
|
|
Revision tags: v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6 |
|
| #
eb627e17 |
| 20-Aug-2019 |
Matthew Garrett <[email protected]> |
PCI: Lock down BAR access when the kernel is locked down
Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel cod
PCI: Lock down BAR access when the kernel is locked down
Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel code, allowing them to circumvent disabled module loading or module signing. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices.
Signed-off-by: David Howells <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kees Cook <[email protected]> cc: [email protected] Signed-off-by: James Morris <[email protected]>
show more ...
|
|
Revision tags: v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2 |
|
| #
590a18e1 |
| 02-Jul-2019 |
Markus Elfring <[email protected]> |
PCI: Use seq_puts() instead of seq_printf() in show_device()
The driver name in /proc/bus/pci/devices can be printed without a printf format specification, so use seq_puts() instead of seq_printf().
PCI: Use seq_puts() instead of seq_printf() in show_device()
The driver name in /proc/bus/pci/devices can be printed without a printf format specification, so use seq_puts() instead of seq_printf().
This issue was detected by using the Coccinelle software.
Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Markus Elfring <[email protected]> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3, v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2 |
|
| #
296bd5ae |
| 20-Mar-2019 |
Gustavo A. R. Silva <[email protected]> |
PCI: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through.
This patch fixes the following warnings:
driv
PCI: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/pci/proc.c: In function ‘proc_bus_pci_ioctl’: drivers/pci/proc.c:216:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (arch_can_pci_mmap_wc()) { ^ drivers/pci/proc.c:225:2: note: here default: ^~~~~~~
drivers/pci/xen-pcifront.c: In function ‘pcifront_backend_changed’: drivers/pci/xen-pcifront.c:1105:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (xdev->state == XenbusStateClosed) ^ drivers/pci/xen-pcifront.c:1108:2: note: here case XenbusStateClosing: ^~~~
Notice that, in this particular case, the /* fall through */ comment is placed at the very bottom of the case statement, which is what GCC is expecting to find.
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
|
Revision tags: v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1 |
|
| #
96d4f267 |
| 04-Jan-2019 |
Linus Torvalds <[email protected]> |
Remove 'type' argument from access_ok() function
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old
Remove 'type' argument from access_ok() function
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand.
It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact.
A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all.
This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
There were a couple of notable cases:
- csky still had the old "verify_area()" name as an alias.
- the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it)
- microblaze used the type argument for a debug printout
but other than those oddities this should be a total no-op patch.
I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though.
Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1, v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1, v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4, v4.17-rc3, v4.17-rc2, v4.17-rc1 |
|
| #
fddda2b7 |
| 13-Apr-2018 |
Christoph Hellwig <[email protected]> |
proc: introduce proc_create_seq{,_data}
Variants of proc_create{,_data} that directly take a struct seq_operations argument and drastically reduces the boilerplate code in the callers.
All trivial
proc: introduce proc_create_seq{,_data}
Variants of proc_create{,_data} that directly take a struct seq_operations argument and drastically reduces the boilerplate code in the callers.
All trivial callers converted over.
Signed-off-by: Christoph Hellwig <[email protected]>
show more ...
|
|
Revision tags: v4.16, v4.16-rc7, v4.16-rc6, v4.16-rc5 |
|
| #
df62ab5e |
| 09-Mar-2018 |
Bjorn Helgaas <[email protected]> |
PCI: Tidy comments
Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended.
Signed-off-by: Bjorn Helg
PCI: Tidy comments
Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended.
Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
|
Revision tags: v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2, v4.15-rc1, v4.14, v4.14-rc8 |
|
| #
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <[email protected]> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license identifiers to apply.
- when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary:
SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became the concluded license(s).
- when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.
In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related.
Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches.
Reviewed-by: Kate Stewart <[email protected]> Reviewed-by: Philippe Ombredanne <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v4.14-rc7, v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13, v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7 |
|
| #
f66e2258 |
| 12-Apr-2017 |
David Woodhouse <[email protected]> |
PCI: Add BAR index argument to pci_mmap_page_range()
In all cases we know which BAR it is. Passing it in means that arch code (or generic code; watch this space) won't have to go looking for it aga
PCI: Add BAR index argument to pci_mmap_page_range()
In all cases we know which BAR it is. Passing it in means that arch code (or generic code; watch this space) won't have to go looking for it again.
Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
| #
e854d8b2 |
| 12-Apr-2017 |
David Woodhouse <[email protected]> |
PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space
This is relatively esoteric, and knowing that we don't have it makes life easier in some cases rather than just an eventua
PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space
This is relatively esoteric, and knowing that we don't have it makes life easier in some cases rather than just an eventual -EINVAL from pci_mmap_page_range().
Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
| #
ae749c7a |
| 12-Apr-2017 |
David Woodhouse <[email protected]> |
PCI: Add arch_can_pci_mmap_wc() macro
Most of the almost-identical versions of pci_mmap_page_range() silently ignore the 'write_combine' argument and give uncached mappings.
Yet we allow the PCIIOC
PCI: Add arch_can_pci_mmap_wc() macro
Most of the almost-identical versions of pci_mmap_page_range() silently ignore the 'write_combine' argument and give uncached mappings.
Yet we allow the PCIIOC_WRITE_COMBINE ioctl in /proc/bus/pci, expose the 'resourceX_wc' file in sysfs, and allow an attempted mapping to apparently succeed.
To fix this, introduce a macro arch_can_pci_mmap_wc() which indicates whether the platform can do a write-combining mapping. On x86 this ends up being pat_enabled(), while the few other platforms that support it can just set it to a literal '1'.
Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
show more ...
|
| #
cef4d023 |
| 12-Apr-2017 |
David Woodhouse <[email protected]> |
PCI: Only allow WC mmap on prefetchable resources
The /proc/bus/pci mmap interface allows the user to specify whether they want WC or not. Don't let them do so on non-prefetchable BARs.
Signed-off
PCI: Only allow WC mmap on prefetchable resources
The /proc/bus/pci mmap interface allows the user to specify whether they want WC or not. Don't let them do so on non-prefetchable BARs.
Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected]
show more ...
|
| #
17caf567 |
| 12-Apr-2017 |
David Woodhouse <[email protected]> |
PCI: Fix another sanity check bug in /proc/pci mmap
Don't match MMIO maps with I/O BARs and vice versa.
Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Bjorn Helgaas <bhelgaas@goo
PCI: Fix another sanity check bug in /proc/pci mmap
Don't match MMIO maps with I/O BARs and vice versa.
Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected]
show more ...
|
|
Revision tags: v4.11-rc6, v4.11-rc5, v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8, v4.10-rc7, v4.10-rc6, v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1 |
|
| #
7c0f6ba6 |
| 24-Dec-2016 |
Linus Torvalds <[email protected]> |
Replace <asm/uaccess.h> with <linux/uaccess.h> globally
This was entirely automated, using the script by Al:
PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PA
Replace <asm/uaccess.h> with <linux/uaccess.h> globally
This was entirely automated, using the script by Al:
PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)
to do the replacement at the end of the merge window.
Requested-by: Al Viro <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|