On Fri, Nov 11, 2022 at 02:54:19PM +0100, Thomas Gleixner wrote:
> PCI/Multi-MSI is MSI specific and not supported for MSI-X
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/iommu/amd/iommu.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- a/drivers/iommu/amd/iommu.c
>
On Fri, Nov 11, 2022 at 02:54:35PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> Set the bus token in the msi_domain_info structure and let the core code
> handle the update.
>
> Signed-off-by: Ahmed S. Darwish
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
>
On Fri, Nov 11, 2022 at 02:54:50PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Make pci_alloc_irq_vectors() a real function instead of wrapper and add
> proper
This is v5 of a series to prepare for threaded/atomic
printing. v4 is here [0]. This series focuses on reducing the
scope of the BKL console_lock. It achieves this by switching to
SRCU and a dedicated mutex for console list iteration and
modification, respectively. The console_lock will no longer
On Fri, Nov 11, 2022 at 02:55:03PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_msi_enabled() and add kernel-doc for the function.
>
>
On Fri, Nov 11, 2022 at 02:55:01PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_msi_enabled() and make its kernel-doc comprehensive.
>
> Signed-off-by:
On Fri, Nov 11, 2022 at 02:55:09PM +0100, Thomas Gleixner wrote:
> When hierarchical MSI interrupt domains are enabled then there is no point
> to do tons of work and detect the missing support for multi-MSI late in the
> allocation path.
>
> Just query the domain feature flags right away. The
On Fri, Nov 11, 2022 at 02:54:32PM +0100, Thomas Gleixner wrote:
> Split the bus token defines out into a seperate header file to avoid
> inclusion of irqdomain.h in msi.h.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/irqdomain.h | 22 +-
>
On Wed, Nov 16 2022 at 10:12, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:54:38PM +0100, Thomas Gleixner wrote:
>> What a zoo:
>>
>> PCI_MSI
>> select GENERIC_MSI_IRQ
>>
>> PCI_MSI_IRQ_DOMAIN
>> def_bool y
>> depends on PCI_MSI
>> select
On Wed, Nov 16, 2022, Huang, Kai wrote:
> On Tue, 2022-11-15 at 20:16 +, Sean Christopherson wrote:
> > On Thu, Nov 10, 2022, Huang, Kai wrote:
> > > On Thu, 2022-11-10 at 01:33 +, Huang, Kai wrote:
> > > Hmm.. I wasn't thinking thoroughly. I forgot CPU compatibility check also
> > >
On Fri, Nov 11, 2022 at 02:54:20PM +0100, Thomas Gleixner wrote:
> There are no associated MSI descriptors in the requested range when the MSI
> descriptor allocation fails. Use MSI_DESC_ALL as the filter which prepares
> the next step to get rid of the filter for freeing.
>
> Signed-off-by:
On Fri, Nov 11, 2022 at 02:54:22PM +0100, Thomas Gleixner wrote:
> When a range of descriptors is freed then all of them are not associated to
> a linux interrupt. Remove the filter and add a warning to the free function.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/base/platform-msi.c |
On Fri, Nov 11, 2022 at 02:54:32PM +0100, Thomas Gleixner wrote:
> Split the bus token defines out into a seperate header file to avoid
> inclusion of irqdomain.h in msi.h.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/irqdomain.h | 22 +-
>
On Fri, Nov 11, 2022 at 02:54:42PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> Follow the style of
>
> Signed-off-by: Ahmed S. Darwish
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/msi.h |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
On Fri, Nov 11, 2022 at 02:54:43PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> The upcoming support for per device MSI interrupt domains needs to share
> some of the inline helpers with the MSI implementation.
>
> Move them to the header file.
>
> Signed-off-by: Ahmed S. Darwish
If we already have a PMD/PUD mapped write-protected in a private mapping
and we want to break COW either due to FAULT_FLAG_WRITE or
FAULT_FLAG_UNSHARE, there is no need to inform the file system just like on
the PTE path.
Let's just split (->zap) + fallback in that case.
This is a preparation
FOLL_FORCE is really only for ptrace access. As we unpin the pinned pages
using unpin_user_pages_dirty_lock(true), the assumption is that all these
pages are writable.
FOLL_FORCE in this case seems to be a legacy leftover. Let's just remove
it.
Cc: Dennis Dalessandro
Cc: Jason Gunthorpe
Cc:
On Fri, Nov 11, 2022 at 02:54:42PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> Follow the style of
>
> Signed-off-by: Ahmed S. Darwish
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/msi.h |8
> 1 file changed, 4 insertions(+),
On Fri, Nov 11, 2022 at 02:54:37PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> Let the core do the freeing of descriptors and just keep it around for the
> legacy case.
>
> Signed-off-by: Ahmed S. Darwish
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
>
On Fri, Nov 11, 2022 at 02:54:51PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_alloc_irq_vectors_affinity() and let its kernel-doc reference
>
On Fri, Nov 11, 2022 at 02:55:07PM +0100, Thomas Gleixner wrote:
> There is no point in doing the same sanity checks over and over in a loop
> during MSI-X enablement. Put them in front of the loop and return early
> when they fail.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
>
On Wed, Nov 16 2022 at 10:23, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:54:51PM +0100, Thomas Gleixner wrote:
>> + * Same as pci_alloc_irq_vectors(), but with the extra @affd parameter.
>> + * Check that function docs, and irq_affinity, for more details.
>
> Is " irq_affinity" some
On Wed, Nov 16 2022 at 10:22, Bjorn Helgaas wrote:
>> + * Allocate up to @max_vecs interrupt vectors on device. MSI-X irq
>
> s/irq/IRQ/
>
>> + * vector allocation has a higher precedence over plain MSI, which has a
>> + * higher precedence over legacy INTx emulation.
>> + *
>> + * Upon a
Le 16/11/2022 à 18:01, Hari Bathini a écrit :
>>
>> I also managed to test it on QEMU. The config is based on
>> pmac32_defconfig.
>
> I had the same config but hit this problem:
>
> # echo 1 > /proc/sys/net/core/bpf_jit_enable; modprobe test_bpf
> test_bpf: #0 TAX
>
On Fri, Nov 11, 2022 at 02:54:23PM +0100, Thomas Gleixner wrote:
> W=1 complains about this.
>
> Signed-off-by: Thomas Gleixner
> ---
> kernel/irq/msi.c |1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Nov 11, 2022 at 02:54:40PM +0100, Thomas Gleixner wrote:
> Adjust to reality and remove another layer of pointless Kconfig
> indirection. CONFIG_GENERIC_MSI_IRQ is good enough to serve
> all purposes.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/base/Makefile |2 +-
>
On Fri, Nov 11, 2022 at 02:54:38PM +0100, Thomas Gleixner wrote:
> What a zoo:
>
> PCI_MSI
> select GENERIC_MSI_IRQ
>
> PCI_MSI_IRQ_DOMAIN
> def_bool y
> depends on PCI_MSI
> select GENERIC_MSI_IRQ_DOMAIN
>
> Ergo PCI_MSI enables PCI_MSI_IRQ_DOMAIN which in
On Fri, Nov 11, 2022 at 02:55:15PM +0100, Thomas Gleixner wrote:
> No more users.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/msi.h |4
> kernel/irq/msi.c| 17 +
> 2 files changed, 1 insertion(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Nov 11, 2022 at 02:54:15PM +0100, Thomas Gleixner wrote:
> PCI/MSI and PCI/MSI-X are mutually exclusive, but the MSI-X enable code
> lacks a check for already enabled MSI.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/msi.c |5 +
> 1 file changed, 5 insertions(+)
>
On Fri, Nov 11, 2022 at 02:54:38PM +0100, Thomas Gleixner wrote:
> What a zoo:
>
> PCI_MSI
> select GENERIC_MSI_IRQ
>
> PCI_MSI_IRQ_DOMAIN
> def_bool y
> depends on PCI_MSI
> select GENERIC_MSI_IRQ_DOMAIN
>
> Ergo PCI_MSI enables PCI_MSI_IRQ_DOMAIN which in
On Fri, Nov 11, 2022 at 02:54:48PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_enable_msix_range() and make its kernel-doc comprehensive.
>
>
On Fri, Nov 11, 2022 at 02:55:04PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> All exported device-driver MSI APIs are now grouped in one place at
> drivers/pci/msi/api.c with comprehensive kernel-docs added.
>
> Reference these kernel-docs in the official PCI/MSI howto.
>
>
On Fri, Nov 11, 2022 at 02:55:14PM +0100, Thomas Gleixner wrote:
> All these sanity checks are now done _before_ any allocation work
> happens. No point in doing it twice.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c | 48
>
On Wed, Nov 16 2022 at 10:26, Bjorn Helgaas wrote:
>> /**
>> + * pci_disable_msix() - Disable MSI-X interrupt mode on device
>> + * @dev: the PCI device to operate on
>> + *
>> + * Legacy device driver API to disable MSI-X interrupt mode on device,
>> + * free earlier-allocated interrupt vectors,
On Fri, Nov 11, 2022 at 02:55:04PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> All exported device-driver MSI APIs are now grouped in one place at
> drivers/pci/msi/api.c with comprehensive kernel-docs added.
>
> Reference these kernel-docs in the official PCI/MSI howto.
>
>
On Fri, Nov 11, 2022 at 02:54:15PM +0100, Thomas Gleixner wrote:
> PCI/MSI and PCI/MSI-X are mutually exclusive, but the MSI-X enable code
> lacks a check for already enabled MSI.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/msi.c |5 +
> 1 file changed, 5 insertions(+)
On 11/11/2022 15:54, Yang Yingliang wrote:
If device_register() fails in cxl_register_afu|adapter(), the device
is not added, device_unregister() can not be called in the error path,
otherwise it will cause a null-ptr-deref because of removing not added
device.
As comment of
On Wed, Nov 16, 2022, Huang, Kai wrote:
> On Wed, 2022-11-02 at 23:18 +, Sean Christopherson wrote:
> > Acquire a new mutex, vendor_module_lock, in kvm_x86_vendor_init() while
> > doing hardware setup to ensure that concurrent calls are fully serialized.
> > KVM rejects attempts to load vendor
On Fri, Nov 11, 2022 at 02:54:17PM +0100, Thomas Gleixner wrote:
> PCI/Multi-MSI is MSI specific and not supported for MSI-X.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/iommu/intel/irq_remapping.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> ---
On Fri, Nov 11, 2022 at 02:54:45PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> msi.c is a maze of randomly sorted functions which makes the code
> unreadable. As a first step split the driver visible API and the internal
> implementation which also allows proper API documentation
On Fri, Nov 11, 2022 at 02:54:54PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_free_irq_vectors() and make its kernel-doc comprehensive.
>
>
On Fri, Nov 11, 2022 at 02:54:56PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_msix_vec_count() and make its kernel-doc comprehensive.
>
> Signed-off-by:
On Fri, Nov 11, 2022 at 02:55:12PM +0100, Thomas Gleixner wrote:
> With interrupt domains the sanity check for MSI-X vector validation can be
> done _before_ any allocation happens. The sanity check only applies to the
> allocation functions which have an 'entries' array argument. The entries
>
On Wed, Nov 16 2022 at 08:02, Ashok Raj wrote:
> On Fri, Nov 11, 2022 at 02:54:19PM +0100, Thomas Gleixner wrote:
>> PCI/Multi-MSI is MSI specific and not supported for MSI-X
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> drivers/iommu/amd/iommu.c |3 +--
>> 1 file changed, 1 insertion(+),
On Fri, Nov 11, 2022 at 02:55:03PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_msi_enabled() and add kernel-doc for the function.
>
>
On Fri, Nov 11, 2022 at 02:54:28PM +0100, Thomas Gleixner wrote:
> Use the new msi_post_free() callback which is invoked after the interrupts
> have been freed to tell the hypervisor about the shutdown.
>
> This allows to remove the exposure of __msi_domain_free_irqs().
>
> Signed-off-by: Thomas
On Fri, Nov 11, 2022 at 02:55:07PM +0100, Thomas Gleixner wrote:
> There is no point in doing the same sanity checks over and over in a loop
> during MSI-X enablement. Put them in front of the loop and return early
> when they fail.
>
> Signed-off-by: Thomas Gleixner
> ---
>
On 11/11/2022 15:54, Yang Yingliang wrote:
If device_register() fails in cxl_pci_afu|adapter(), the device
is not added, device_unregister() can not be called in the error
path, otherwise it will cause a null-ptr-deref because of removing
not added device.
As comment of device_register()
On Fri, Nov 11, 2022 at 02:55:17PM +0100, Thomas Gleixner wrote:
> Now that the PCI/MSI core code does early checking for multi-MSI support
> X86_IRQ_ALLOC_CONTIGUOUS_VECTORS is not required anymore.
> Remove the flag and rely on MSI_FLAG_MULTI_PCI_MSI.
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Nov 11, 2022 at 02:54:20PM +0100, Thomas Gleixner wrote:
> There are no associated MSI descriptors in the requested range when the MSI
> descriptor allocation fails. Use MSI_DESC_ALL as the filter which prepares
> the next step to get rid of the filter for freeing.
>
> Signed-off-by:
On Fri, Nov 11, 2022 at 02:54:58PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_disable_msix() and make its kernel-doc comprehensive.
>
> Signed-off-by:
On Wed, Nov 16 2022 at 10:28, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:55:06PM +0100, Thomas Gleixner wrote:
>> From: Ahmed S. Darwish
>>
>> There is no way to navigate msi.c without banging the head against the wall
>> every now and then because MSI and MSI-X specific functions are
>>
On Wed, Nov 16, 2022 at 06:02:30PM +0100, Thomas Gleixner wrote:
> On Wed, Nov 16 2022 at 07:52, Ashok Raj wrote:
> > On Fri, Nov 11, 2022 at 02:54:17PM +0100, Thomas Gleixner wrote:
> >> PCI/Multi-MSI is MSI specific and not supported for MSI-X.
> >>
> >> Signed-off-by: Thomas Gleixner
> >> ---
On Fri, Nov 11, 2022 at 02:54:30PM +0100, Thomas Gleixner wrote:
> Now that the last user is gone, confine it to the core code.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/msi.h |4
> kernel/irq/msi.c|3 ++-
> 2 files changed, 2 insertions(+), 5 deletions(-)
On Fri, Nov 11, 2022 at 02:55:11PM +0100, Thomas Gleixner wrote:
> Similar to PCI multi-MSI reject MSI-X enablement when a irq domain is
> attached to the device which does not support MSI-X.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/msi.c |4
> 1 file changed, 4
On Fri, Nov 11, 2022 at 02:55:09PM +0100, Thomas Gleixner wrote:
> When hierarchical MSI interrupt domains are enabled then there is no point
> to do tons of work and detect the missing support for multi-MSI late in the
> allocation path.
>
> Just query the domain feature flags right away. The
On Fri, Nov 11, 2022 at 02:54:43PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> The upcoming support for per device MSI interrupt domains needs to share
> some of the inline helpers with the MSI implementation.
>
> Move them to the header file.
>
> Signed-off-by: Ahmed S. Darwish
On Fri, Nov 11, 2022 at 02:54:53PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_irq_vector() and let its kernel-doc match the rest of the file.
>
>
On Fri, Nov 11, 2022 at 02:55:11PM +0100, Thomas Gleixner wrote:
> Similar to PCI multi-MSI reject MSI-X enablement when a irq domain is
> attached to the device which does not support MSI-X.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/msi.c |4
On Wed, Nov 16 2022 at 07:52, Ashok Raj wrote:
> On Fri, Nov 11, 2022 at 02:54:17PM +0100, Thomas Gleixner wrote:
>> PCI/Multi-MSI is MSI specific and not supported for MSI-X.
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> drivers/iommu/intel/irq_remapping.c |3 +--
>> 1 file changed, 1
On 16/11/22 12:14 am, Christophe Leroy wrote:
Le 14/11/2022 à 18:27, Christophe Leroy a écrit :
Le 14/11/2022 à 15:47, Hari Bathini a écrit :
Hi Christophe,
On 11/11/22 4:55 pm, Christophe Leroy wrote:
Le 10/11/2022 à 19:43, Hari Bathini a écrit :
Most BPF programs are small, but
On Fri, Nov 11, 2022 at 02:54:27PM +0100, Thomas Gleixner wrote:
> To prepare for removing the exposure of __msi_domain_free_irqs() provide a
> post_free() callback in the MSI domain ops which can be used to solve
> the problem of the only user of __msi_domain_free_irqs() in arch/powerpc.
>
>
On Fri, Nov 11, 2022 at 02:54:25PM +0100, Thomas Gleixner wrote:
> Nothing outside of the core code requires this.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/msi.h |7 ++-
> kernel/irq/msi.c|6 --
> 2 files changed, 6 insertions(+), 7 deletions(-)
Reviewed-by:
On Fri, Nov 11, 2022 at 02:54:35PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> Set the bus token in the msi_domain_info structure and let the core code
> handle the update.
>
> Signed-off-by: Ahmed S. Darwish
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/irqdomain.c
On Fri, Nov 11, 2022 at 02:54:33PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> Add a bus token member to struct msi_domain_info and let
> msi_create_irq_domain() set the bus token.
>
> That allows to remove the bus token updates at the call sites.
>
> Suggested-by: Thomas
On Fri, Nov 11, 2022 at 02:55:14PM +0100, Thomas Gleixner wrote:
> All these sanity checks are now done _before_ any allocation work
> happens. No point in doing it twice.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/irqdomain.c | 48
>
On Fri, Nov 11, 2022 at 02:54:46PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c all exported device-driver MSI APIs are now
> to be grouped in one file, api.c.
>
> Move pci_enable_msi() and make its kernel-doc comprehensive.
>
> Signed-off-by: Ahmed
It is not reliable to check for CON_ENABLED in order to identify if a
console is registered. Use console_is_registered() instead.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
drivers/tty/hvc/hvc_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Fri, Nov 11, 2022 at 02:55:06PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> There is no way to navigate msi.c without banging the head against the wall
> every now and then because MSI and MSI-X specific functions are
> intermingled and the code flow is completely non-obvious.
On Fri, Nov 11, 2022 at 02:54:15PM +0100, Thomas Gleixner wrote:
> PCI/MSI and PCI/MSI-X are mutually exclusive, but the MSI-X enable code
> lacks a check for already enabled MSI.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/msi.c |5 +
> 1 file
On Fri, Nov 11, 2022 at 02:54:59PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>
> Move pci_irq_get_affinity() and let its kernel-doc match rest of the
> file.
>
>
On Wed, Nov 16 2022 at 10:18, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:54:46PM +0100, Thomas Gleixner wrote:
>> From: Ahmed S. Darwish
>>
>> To distangle the maze in msi.c all exported device-driver MSI APIs are now
>> to be grouped in one file, api.c.
>>
>> Move pci_enable_msi() and
On Fri, Nov 11, 2022 at 02:54:37PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish
>
> Let the core do the freeing of descriptors and just keep it around for the
> legacy case.
>
> Signed-off-by: Ahmed S. Darwish
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/irqdomain.c |
On Fri, Nov 11, 2022 at 02:55:12PM +0100, Thomas Gleixner wrote:
> With interrupt domains the sanity check for MSI-X vector validation can be
> done _before_ any allocation happens. The sanity check only applies to the
> allocation functions which have an 'entries' array argument. The entries
>
For now, FAULT_FLAG_UNSHARE only applies to anonymous pages, which
implies a COW mapping. Let's hide FAULT_FLAG_UNSHARE early if we're not
dealing with a COW mapping, such that we treat it like a read fault as
documented and don't have to worry about the flag throughout all fault
handlers.
While
GUP now supports reliable R/O long-term pinning in COW mappings, such
that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
far in one corner case (DAXFS file with holes), which can be ignored
because GUP does not support long-term pinning in fsdax (see
check_vma_flags()).
On Wed, Nov 16, 2022 at 11:26:52AM +0100, David Hildenbrand wrote:
> GUP now supports reliable R/O long-term pinning in COW mappings, such
> that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
> far in one corner case (DAXFS file with holes), which can be ignored
> because GUP
We already support reliable R/O pinning of anonymous memory. However,
assume we end up pinning (R/O long-term) a pagecache page or the shared
zeropage inside a writable private ("COW") mapping. The next write access
will trigger a write-fault and replace the pinned page by an exclusive
anonymous
On Tue, Nov 15, 2022 at 5:16 AM Michael Sammler wrote:
> > We're currently working on a feature in chromium that uses pkeys for
> > in-process isolation. Being able to use the pkey state in the seccomp
> > filter would be pretty useful for this. For example, it would allow
> > us to enforce that
On Tue, 2022-11-15 at 20:16 +, Sean Christopherson wrote:
> On Thu, Nov 10, 2022, Huang, Kai wrote:
> > On Thu, 2022-11-10 at 01:33 +, Huang, Kai wrote:
> > > > @@ -9283,7 +9283,13 @@ static int
> > > > kvm_x86_check_processor_compatibility(struct kvm_x86_init_ops *ops)
> > > > int
Extend FAULT_FLAG_UNSHARE to break COW on anything mapped into a
COW (i.e., private writable) mapping and adjust the documentation
accordingly.
FAULT_FLAG_UNSHARE will now also break COW when encountering the shared
zeropage, a pagecache page, a PFNMAP, ... inside a COW mapping, by
properly
GUP now supports reliable R/O long-term pinning in COW mappings, such
that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
far in one corner case (DAXFS file with holes), which can be ignored
because GUP does not support long-term pinning in fsdax (see
check_vma_flags()).
GUP now supports reliable R/O long-term pinning in COW mappings, such
that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
far in one corner case (DAXFS file with holes), which can be ignored
because GUP does not support long-term pinning in fsdax (see
check_vma_flags()).
Originally, the plan was to have a separate tests for testing COW of
non-anonymous (e.g., shared zeropage) pages.
Turns out, that we'd need a lot of similar functionality and that there
isn't a really good reason to separate it. So let's prepare for non-anon
tests by renaming to "cow".
Let's add basic tests for COW with non-anonymous pages in private
mappings: write access should properly trigger COW and result in the
private changes not being visible through other page mappings.
Especially, add tests for:
* Zeropage
* Huge zeropage
* Ordinary pagecache pages via memfd and
GUP now supports reliable R/O long-term pinning in COW mappings, such
that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
far in one corner case (DAXFS file with holes), which can be ignored
because GUP does not support long-term pinning in fsdax (see
check_vma_flags()).
GUP now supports reliable R/O long-term pinning in COW mappings, such
that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
far in one corner case (DAXFS file with holes), which can be ignored
because GUP does not support long-term pinning in fsdax (see
check_vma_flags()).
On Wed, Nov 16, 2022 at 11:26:53AM +0100, David Hildenbrand wrote:
> GUP now supports reliable R/O long-term pinning in COW mappings, such
> that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
> far in one corner case (DAXFS file with holes), which can be ignored
> because GUP
pci_get_device() will increase the reference count for the returned
pci_dev, and also decrease the reference count for the input parameter
*from* if it is not NULL.
In function pas_setup_mce_regs(), after we break out the loop with 'dev'
not NULL, we need to decrease the reference count of 'dev'.
FOLL_FORCE is really only for ptrace access. According to commit
707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always
writable"), get_vaddr_frames() currently pins all pages writable as a
workaround for issues with read-only buffers.
FOLL_FORCE, however, seems to be a legacy
FOLL_FORCE is really only for ptrace access. R/O pinning a page is
supposed to fail if the VMA misses proper access permissions (no VM_READ).
Let's just remove FOLL_FORCE usage here; there would have to be a pretty
good reason to allow arbitrary drivers to R/O pin pages in a PROT_NONE
VMA. Most
On Wed, Nov 16, 2022 at 11:26:56AM +0100, David Hildenbrand wrote:
> FOLL_FORCE is really only for ptrace access. As we unpin the pinned pages
> using unpin_user_pages_dirty_lock(true), the assumption is that all these
> pages are writable.
>
> FOLL_FORCE in this case seems to be a legacy
On Wed, Nov 16, 2022 at 11:26:55AM +0100, David Hildenbrand wrote:
> FOLL_FORCE is really only for ptrace access. According to commit
> 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always
> writable"), get_vaddr_frames() currently pins all pages writable as a
> workaround for
Let's test whether R/O long-term pinning is reliable for non-anonymous
memory: when R/O long-term pinning a page, the expectation is that we
break COW early before pinning, such that actual write access via the
page tables won't break COW later and end up replacing the R/O-pinned
page in the page
On Wed, Nov 16, 2022 at 11:26:48AM +0100, David Hildenbrand wrote:
> We already support reliable R/O pinning of anonymous memory. However,
> assume we end up pinning (R/O long-term) a pagecache page or the shared
> zeropage inside a writable private ("COW") mapping. The next write access
> will
FOLL_FORCE is really only for ptrace access. As we unpin the pinned pages
using unpin_user_pages_dirty_lock(true), the assumption is that all these
pages are writable.
FOLL_FORCE in this case seems to be due to copy-and-past from other
drivers. Let's just remove it.
Acked-by: Oded Gabbay
Cc:
We want to extent FAULT_FLAG_UNSHARE support to anything mapped into a
COW mapping (pagecache page, zeropage, PFN, ...), not just anonymous pages.
Let's prepare for that by handling shared mappings first such that we can
handle private mappings last.
While at it, use folio-based functions instead
Let's catch abuse of FAULT_FLAG_WRITE early, such that we don't have to
care in all other handlers and might get "surprises" if we forget to do
so.
Write faults without VM_MAYWRITE don't make any sense, and our
maybe_mkwrite() logic could have hidden such abuse for now.
Write faults without
FOLL_FORCE is really only for ptrace access. As we unpin the pinned pages
using unpin_user_pages_dirty_lock(true), the assumption is that all these
pages are writable.
FOLL_FORCE in this case seems to be a legacy leftover. Let's just remove
it.
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
On Wed, Nov 16 2022 at 13:49, Jason Gunthorpe wrote:
> On Fri, Nov 11, 2022 at 02:54:33PM +0100, Thomas Gleixner wrote:
>> From: Ahmed S. Darwish
>>
>> Add a bus token member to struct msi_domain_info and let
>> msi_create_irq_domain() set the bus token.
>>
>> That allows to remove the bus
1 - 100 of 117 matches
Mail list logo
