On Tue, Feb 02, 2021 at 06:55:18PM +, Christoph Hellwig wrote:
> On Tue, Feb 02, 2021 at 02:50:17PM -0400, Jason Gunthorpe wrote:
> > For uAPI compatability vfio_pci.ko would need some
> > request_module()/symbol_get() trick to pass control over to the device
> > spec
On Tue, Feb 02, 2021 at 12:37:23PM -0700, Alex Williamson wrote:
> For the most part, this explicit bind interface is redundant to
> driver_override, which already avoids the duplicate ID issue.
No, the point here is to have the ID tables in the PCI drivers because
they fundamentally only work
On Tue, Feb 02, 2021 at 02:30:13PM -0700, Alex Williamson wrote:
> The first set of users already fail this specification though, we can't
> base it strictly on device and vendor IDs, we need wildcards, class
> codes, revision IDs, etc., just like any other PCI drvier. We're not
> going to mainta
On Tue, Feb 02, 2021 at 04:59:23PM -0700, Alex Williamson wrote:
> On Tue, 2 Feb 2021 19:06:04 -0400
> Jason Gunthorpe wrote:
>
> > On Tue, Feb 02, 2021 at 02:30:13PM -0700, Alex Williamson wrote:
> >
> > > The first set of users already fail this specification
On Wed, Feb 03, 2021 at 02:43:58PM +0200, Gal Pressman wrote:
> > On Tue, Feb 02, 2021 at 12:05:36PM -0500, Peter Xu wrote:
> >
> >> > Gal, you could also MADV_DONTFORK this range if you are explicitly
> >> > allocating them via special mmap.
> >>
> >> Yeah I wanted to mention this one too but I
On Wed, Feb 03, 2021 at 01:22:18PM +, Joao Martins wrote:
> With this, longterm gup will 'regress' for hugetlbfs e.g. from ~6k -> 32k
> usecs when
> pinning a 16G hugetlb file.
Yes, but correctness demands it.
The solution is to track these pages as we discover them so we know if
a PMD/PUD
On Wed, Feb 03, 2021 at 04:13:21PM +, Joao Martins wrote:
> If check_and_migrate_movable_pages() is meant to migrate unpinned
> pages, then rather than pinning+unpinning+moving, perhaps it would
> be called in __get_user_pages() place where we are walking page
> tables and know if it's a PUD/P
On Sun, Jan 31, 2021 at 09:32:28PM -0700, Alex Williamson wrote:
> > I think we can leave common arch specific stuff, such as s390 (IIUC) in
> > the core driver. And only create vfio_pci drivers for
> > vendor/device/subvendor specific stuff.
>
> So on one hand you're telling us that the design
On Mon, Feb 01, 2021 at 04:28:28PM +, Max Gurtovoy wrote:
> This patch doesn't change any logic but only align to the concept of
> vfio_pci_core extensions. Extensions that are related to a platform
> and not to a specific vendor of PCI devices should be part of the
> core driver. Extensions th
On Fri, Jan 29, 2021 at 10:09:03AM +, Tian, Kevin wrote:
> > SVA is not doom to work with IO page fault only. If we have SVA+pin,
> > we would get both sharing address and stable I/O latency.
>
> Isn't it like a traditional MAP_DMA API (imply pinning) plus specifying
> cpu_va of the memory po
On Wed, Feb 03, 2021 at 12:56:44PM -0800, Megha Dey wrote:
> +bool arch_support_pci_device_ims(struct pci_dev *pdev)
> +{
Consistent language please, we are not using IMS elsewhere, this
feature is called device_msi in Linux.
Jason
On Thu, Feb 04, 2021 at 12:05:22PM +1100, Alexey Kardashevskiy wrote:
> It is system firmware (==bios) which puts stuff in the device tree. The
> stuff is:
> 1. emulated pci devices (custom pci bridges), one per nvlink, emulated by
> the firmware, the driver is "ibmnpu" and it is a part on the nvi
On Wed, Feb 03, 2021 at 04:15:53PM -0800, John Hubbard wrote:
> > diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> > index 2dde99a9ba07..ea4ebb3261d9 100644
> > +++ b/drivers/infiniband/core/umem.c
> > @@ -47,17 +47,17 @@
> > static void __ib_umem_release(struct ib_d
On Wed, Feb 03, 2021 at 03:00:01PM -0800, John Hubbard wrote:
> > +static inline void compound_next(unsigned long i, unsigned long npages,
> > +struct page **list, struct page **head,
> > +unsigned int *ntails)
> > +{
> > + if (i >= npages)
the page protections along with the PFN.
> >
> > Fixes: bd2fae8da794 ("KVM: do not assume PTE is writable after follow_pfn")
> > Cc: David Stevens
> > Cc: Jann Horn
> > Cc: Jason Gunthorpe
> > Cc: Paolo Bonzini
> > Cc: k...@vger.kernel.org
>
On Thu, Feb 04, 2021 at 09:50:32AM -0500, Peter Xu wrote:
> We've got quite a few places (pte, pmd, pud) that explicitly checked against
> whether we should break the cow right now during fork(). It's easier to
> provide a helper, especially before we work the same thing on hugetlbfs.
>
> Since w
> Signed-off-by: Paolo Bonzini
> ---
> arch/s390/pci/pci_mmio.c | 2 +-
> fs/dax.c | 5 +++--
> include/linux/mm.h | 6 --
> mm/memory.c | 35 ++-
> 4 files changed, 38 insertions(+), 10 deletions(-)
Looks good to me, thanks
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Feb 05, 2021 at 08:48:11AM -0800, James Bottomley wrote:
> > Thanks for pointing this out. I'd strongly support Jason's proposal:
> >
> > https://lore.kernel.org/linux-integrity/20201215175624.gg5...@ziepe.ca/
> >
> > It's the best long-term way to fix this.
>
> Really, no it's not. It
On Tue, Feb 02, 2021 at 01:40:33AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 1048ba83fb1c00cd24172e23e8263972f6b5d9ac
> commit: 9f85cbe50aa044a46f0a22fda323fa27b80c82da RDMA/uverbs: Expose the new
> GID query AP
On Fri, Feb 05, 2021 at 11:42:11AM +1100, Alexey Kardashevskiy wrote:
> > A real nvswitch function?
>
> What do you mean by this exactly? The cpu side of nvlink is "emulated pci
> devices", the gpu side is not in pci space at all, the nvidia driver manages
> it via the gpu's mmio or/and cfg space.
On Mon, Feb 08, 2021 at 09:14:28AM +0100, David Hildenbrand wrote:
> People are constantly struggling with the effects of long term pinnings
> under user space control, like we already have with vfio and RDMA.
>
> And here we are, adding yet another, easier way to mess with core MM in the
> same
On Fri, Feb 05, 2021 at 01:14:11PM -0500, Peter Xu wrote:
> But I do have a question on why dax as the only user needs to pass in the
> notifier to follow_pte() for initialization.
Not sure either, why does DAX opencode something very much like
page_mkclean() with dax_entry_mkclean()?
Also it lo
On Mon, Feb 08, 2021 at 08:35:31PM +, Song Bao Hua (Barry Song) wrote:
>
>
> > From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> > Sent: Tuesday, February 9, 2021 7:34 AM
> > To: David Hildenbrand
> > Cc: Wangzhou (B) ; linux-kernel@vger.kernel.org;
> > io.
On Mon, Feb 08, 2021 at 05:02:59PM -0500, Peter Xu wrote:
> On Mon, Feb 08, 2021 at 02:51:33PM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 05, 2021 at 01:14:11PM -0500, Peter Xu wrote:
> >
> > > But I do have a question on why dax as the only user needs to pass
On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote:
> On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > >
> > > Recent changes to pin_user_pages() prevent the creation of pinned pages in
> > > ZONE_MOVABLE. This series allows pinned pages to be created in
> ZONE_MOV
On Tue, Feb 09, 2021 at 12:52:17PM +0100, Lino Sanfilippo wrote:
> > @@ -640,8 +643,10 @@ void tpm_chip_unregister(struct tpm_chip *chip)
> > if (IS_ENABLED(CONFIG_HW_RANDOM_TPM))
> > hwrng_unregister(&chip->hwrng);
> > tpm_bios_log_teardown(chip);
> > - if (chip->flags & TPM_
On Tue, Feb 09, 2021 at 12:07:14PM +1100, Alistair Popple wrote:
> Device private pages are used to represent device memory that is not
> directly accessible from the CPU. Extra references to a device private
> page are only used to ensure the struct page itself remains valid whilst
> waiting for m
On Tue, Feb 09, 2021 at 02:39:51PM +0100, Daniel Vetter wrote:
> Either way ZONE_DEVICE for not vram/device memory sounds wrong. Is
> that really going on here?
My read was this was doing non-coherent atomics on CPU memory.
Atomics on GPU memory is just called migration to GPU memory, it
doesn't
On Tue, Feb 09, 2021 at 03:01:42AM +, Song Bao Hua (Barry Song) wrote:
> On the other hand, wouldn't it be the benefit of hardware accelerators
> to have a lower and more stable latency zip/encryption than CPU?
No, I don't think so.
If this is an important problem then it should apply equall
mm/memory.c| 8 +---
> 4 files changed, 24 insertions(+), 18 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
uct mm_struct *src,
> pte_t *src_pte, *dst_pte, entry, dst_entry;
> struct page *ptepage;
> unsigned long addr;
> - int cow;
> + int cow = is_cow_mapping(vma->vm_flags);
int should be bool
Otherwise looks fine to me
Reviewed-by: Jason Gunthorpe
Jason
+++
> 1 file changed, 62 insertions(+), 4 deletions(-)
Didn't check every hugetlbfs detail, but looks reasonable
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Feb 25, 2021 at 12:54:57PM -0500, Peter Xu wrote:
> I can't say I fully understand the whole rational behind 5cbf3264bc71, but
> that
> commit still sounds reasonable to me, since I don't see why VFIO cannot do
> VFIO_IOMMU_MAP_DMA upon another memory range that's neither anonymous memor
On Thu, Feb 25, 2021 at 02:06:46PM -0500, Peter Xu wrote:
> Agreed. I saw discussions around on redefining the vm_pgoff namespace, I
> can't
> say I followed that closely either, but yes it definitely makes sense to
> always
> use an unified namespace. Maybe we should even comment it somewhere
On Thu, Feb 25, 2021 at 03:21:13PM -0700, Alex Williamson wrote:
> This is where it gets tricky. The vm_pgoff we get from
> file_operations.mmap is already essentially describing an offset from
> the base of a specific resource. We could convert that from an absolute
> offset to a pfn offset, bu
apping_range() to zap all vmas associated with a device.
> >
> > Suggested-by: Jason Gunthorpe
> > Signed-off-by: Alex Williamson
>
> Adding Al:
>
> I hate how we're are growing these tiny file systems just to allocate an
> anonymous inode all over. Shouldn&#
On Thu, Feb 25, 2021 at 08:58:20PM +, Matthew Wilcox wrote:
> I'd like to hear better ideas than this.
You didn't like my suggestion to put a sleepable lock around the
freeing of page tables during flushing?
I still don't see how you convert the sleepable page walkers to use
rcu??
Jason
On Fri, Feb 26, 2021 at 04:03:54PM +, Matthew Wilcox wrote:
> On Fri, Feb 26, 2021 at 10:42:00AM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 25, 2021 at 08:58:20PM +, Matthew Wilcox wrote:
> >
> > > I'd like to hear better ideas than this.
> >
> &g
On Fri, May 29, 2020 at 11:39:18AM +0300, Dan Carpenter wrote:
> The "dmac" variable is used before it is initialized.
>
> Fixes: 494c3b312255 ("RDMA/hns: Refactor the QP context filling process
> related to WQE buffer configure")
> Signed-off-by: Dan Carpenter
> Reviewed-by: Leon Romanovsky
>
e, no
HMM_PFN_SPECIAL, and no customizable output PFN format
- Add a selftest for hmm_range_fault() and DEVICE_PRIVATE related
functionality
Jason Gunthorpe (4):
mm/hmm: make hmm_range_fault return 0 or -1
drm/amdgpu: remove
On Fri, May 15, 2020 at 06:04:24PM -0700, Ralph Campbell wrote:
> The test driver uses an xa_array to store virtual to physical address
> translations for a simulated hardware device. The MMU notifier
> invalidation callback is used to keep the table consistent with the CPU
> page table and is freq
On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> Get some consistency into your decision making as maintainer. And don't
> tell me or anyone else that this is complicated, gpu and rdma driver folks
> very much told you and Olof last year that this is what you're getting
> yourself
On Tue, May 19, 2020 at 11:36:12AM -0500, Gustavo A. R. Silva wrote:
> Remove the if-statement and return the value contained in _err_,
> unconditionally.
>
> Addresses-Coverity-ID: 1493753 ("Identical code for different branches")
> Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
>
On Tue, May 19, 2020 at 06:30:18PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GF
On Tue, May 19, 2020 at 04:30:52PM -0700, Divya Indi wrote:
> Hi Jason,
>
> I wanted to follow up to see if you got a chance to review the following
> reply?
Not yet, it still seems bad to be doing code like this.
If two threads are sharing memory they really need to use a
refcount/kref not rel
On Thu, May 14, 2020 at 10:51:58AM -0600, Alex Williamson wrote:
> @@ -1450,6 +1467,10 @@ static int vfio_pci_zap_and_vma_lock(struct
> vfio_pci_device *vdev, bool try)
>
> zap_vma_ptes(vma, vma->vm_start,
>vma->vm_end - v
On Thu, May 14, 2020 at 10:52:09AM -0600, Alex Williamson wrote:
> vfio_unregister_iommu_driver(&vfio_noiommu_ops);
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 62ba6bd8a486..8d6286d89230 100644
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -61,6 +61
On Thu, May 14, 2020 at 10:51:46AM -0600, Alex Williamson wrote:
> This is a follow-on series to "vfio-pci: Block user access to disabled
> device MMIO"[1], which extends user access blocking of disabled MMIO
> ranges to include unmapping the ranges from the IOMMU. The first patch
> adds an invali
On Thu, May 14, 2020 at 04:55:17PM -0600, Alex Williamson wrote:
> On Thu, 14 May 2020 19:24:15 -0300
> Jason Gunthorpe wrote:
>
> > On Thu, May 14, 2020 at 04:17:12PM -0600, Alex Williamson wrote:
> >
> > > that much. I think this would also address Jason's
On Thu, Jul 23, 2020 at 10:07:03AM +0300, Leon Romanovsky wrote:
> This small series simplifies some of the RDMA CM state transitions
> connected with DESTROYING states and in the process resolves a bug
> discovered by syzkaller.
>
> Thanks
>
> Jason Gunthorpe (4):
&
On Thu, Jul 30, 2020 at 07:21:10PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the hmm tree got a conflict in:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
>
> between commit:
>
> 7763d24f3ba0 ("drm/nouveau/vmm/gp100-: fix mapping 2MB sysmem pages")
>
On Thu, Jul 30, 2020 at 11:27:16AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi,
>
> First patch fixes an issue observed after auto-PID series was merged,
> but because the bug that not-initialized mutex existed before, the
> patch is sent to -rc.
>
> Other two patches are fixin
On Tue, May 19, 2020 at 07:39:30PM -0700, Michel Lespinasse wrote:
> > > I think this assertion should be deleted from this driver. It's there
> > > in case get_user_pages_fast() takes the mmap sem. It would make sense to
> > > have this assertion in get_user_pages_fast() in case we take the fast
On Wed, May 20, 2020 at 11:36:52AM -0700, Ralph Campbell wrote:
> When calling OpenCL clEnqueueSVMMigrateMem() on a region of memory that
> is backed by pte_none() or zero pages, migrate_vma_setup() will fill the
> source PFN array with an entry indicating the source page is zero.
> Use this to opt
> create/destroy commands were introduced over 'ioctl', the CQ KABI was
> extended over its existing 'ioctl' create command.
>
> As part of moving to 'ioctl' for the above objects the frame work was
> improved to abort a fully created uobject upon some
On Fri, Jul 31, 2020 at 07:33:33AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 31, 2020 at 07:33:06AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jul 31, 2020 at 07:53:01AM +0300, Leon Romanovsky wrote:
> > > On Thu, Jul 30, 2020 at 03:20:26PM -0400, Peilin Ye wrote:
> > > > rds_notify_queue_ge
On Fri, Jul 31, 2020 at 04:21:48PM +0200, Greg Kroah-Hartman wrote:
> > The spec was updated in C11 to require zero'ing padding when doing
> > partial initialization of aggregates (eg = {})
> >
> > """if it is an aggregate, every member is initialized (recursively)
> > according to these rules, a
buffer logic
- Missed mutex initialization crash in mlx5
- Two small defects with RDMA DIM
Jason Gunthorpe (2):
RDMA/cm: Add min length checks to user structure copies
RDMA/mlx5: Fix prefetch memory leak if
On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
> > Your preservation-across-exec use-case might or might not need the
> > VMA to be mapped at the same address.
>
> It does. qemu registers memory with vfio which remembers the va's in kernel
> metadata for the device.
Once the m
xactly this, the
motivation is to reduce the memory consumption if a lot of pages are
combined.
> Signed-off-by: Eric Dumazet
> Cc: Doug Ledford
> Cc: Jason Gunthorpe
> Cc: linux-r...@vger.kernel.org
> ---
> drivers/infiniband/core/umem.c | 1 +
> 1 file changed, 1 insert
On Fri, Jul 31, 2020 at 01:15:34PM -0400, Steven Sistare wrote:
> On 7/31/2020 12:56 PM, Jason Gunthorpe wrote:
> > On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
> >>> Your preservation-across-exec use-case might or might not need the
> >>> VMA
On Fri, Jul 31, 2020 at 07:19:24PM +0200, Greg Kroah-Hartman wrote:
> > I tried for a bit and didn't find a way to get even old gcc 4.4 to not
> > initialize the holes.
>
> Odd, so it is just the "= {0};" that does not zero out the holes?
Nope, it seems to work fine too. I tried a number of situ
On Tue, Jul 28, 2020 at 03:04:07PM -0700, Ralph Campbell wrote:
>
> On 7/28/20 12:19 PM, Jason Gunthorpe wrote:
> > On Thu, Jul 23, 2020 at 03:30:04PM -0700, Ralph Campbell wrote:
> > > When migrating the special zero page, migrate_vma_pages() calls
> > > mmu_n
On Sat, Aug 01, 2020 at 11:00:26AM +0300, Dan Carpenter wrote:
> > Without an actual example where this doesn't work right it is hard to
> > say anything more..
>
> Here is the example that set off the recent patches:
>
> https://lkml.org/lkml/2020/7/27/199
Oh, that is something completely diffe
On Sat, Aug 01, 2020 at 08:38:33AM +0300, Leon Romanovsky wrote:
> I'm using {} instead of {0} because of this GCC bug.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
This is why the {} extension exists..
Jason
On Fri, Jul 31, 2020 at 02:11:22PM -0700, Rustam Kovhaev wrote:
> IB roce driver receives NETDEV_UNREGISTER event, calls dev_hold() and
> schedules work item to execute, and before wq gets a chance to complete
> it, we return to ip_tunnel.c:274 and call free_netdev(), and then later
> we get UAF w
On Sun, Aug 02, 2020 at 03:23:58PM -0700, Joe Perches wrote:
> On Sun, 2020-08-02 at 19:10 -0300, Jason Gunthorpe wrote:
> > On Sat, Aug 01, 2020 at 08:38:33AM +0300, Leon Romanovsky wrote:
> >
> > > I'm using {} instead of {0} because of this GCC bug.
>
On Tue, Aug 04, 2020 at 01:00:13PM -0700, Rustam Kovhaev wrote:
> On Sun, Aug 02, 2020 at 07:22:26PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jul 31, 2020 at 02:11:22PM -0700, Rustam Kovhaev wrote:
> >
> > > IB roce driver receives NETDEV_UNREGISTER event, calls dev_ho
On Wed, Aug 05, 2020 at 07:01:52PM +, Saeed Mahameed wrote:
> On Wed, 2020-08-05 at 09:12 -0400, Michael S. Tsirkin wrote:
> > On Wed, Aug 05, 2020 at 04:01:58PM +0300, Eli Cohen wrote:
> > > On Wed, Aug 05, 2020 at 08:48:52AM -0400, Michael S. Tsirkin wrote:
> > > > > Did you merge this?:
> >
On Wed, Aug 05, 2020 at 07:18:39PM +, Dey, Megha wrote:
> Hence we will only have one create_dev_msi_domain which can be
> called by any device driver that wants to use the dev-msi IRQ domain
> to alloc/free IRQs. It would be the responsibility of the device
> driver to provide the correct dev
On Wed, Aug 05, 2020 at 10:36:23PM +, Dey, Megha wrote:
> Hi Jason,
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, August 5, 2020 3:16 PM
> > To: Dey, Megha
> > Cc: Marc Zyngier ; Jiang, Dave ;
> > vk...@kernel.org; bhelg...@google.com; raf...@kernel.or
On Thu, Aug 06, 2020 at 12:13:24AM +, Dey, Megha wrote:
> > Well, I had suggested to pass in the parent struct device, but it could
> > certainly
> > use an irq_domain instead:
> >
> > platform_msi_assign_domain(dev, device_to_iommu(p_dev)->ir_domain);
> >
> > Or
> >
> > platform_msi_as
On Thu, Aug 06, 2020 at 12:32:31AM +, Dey, Megha wrote:
> > Oops, I was thinking of platform_msi_domain_alloc_irqs() not
> > create_device_domain()
> >
> > ie call it in the device driver that wishes to consume the extra MSIs.
> >
> > Is there a harm if each device driver creates a new irq_do
On Sun, Aug 02, 2020 at 07:15:42PM +0800, Tianjia Zhang wrote:
> On an error exit path, a negative error code should be returned
> instead of a positive return value.
>
> Fixes: 7a5c938b9ed09 ("IB/core: Check for rdma_protocol_ib only after
> validating port_num")
> C
User/kernel compatibility handshake mechanism
RDMA/efa: Add EFA 0xefa1 PCI ID
Gustavo A. R. Silva (2):
IB/hfi1: Remove unnecessary fall-through markings
IB/hfi1: Use fallthrough pseudo-keyword
Jack Wang (1):
RDMA/rtrs: remove WQ_MEM_RECLAIM for rtrs_wq
Jason Gunthorpe (9):
n invalidation type")
> > Signed-off-by: Ralph Campbell
> > Reported-by: Randy Dunlap
>
> Acked-by: Randy Dunlap # build-tested
Reviewed-by: Jason Gunthorpe
I thought it spent enough time in linux-next and for 0-day to catch
things like this, but I guess I was wrong.
Linus has already merged the hmm pull request.
Andrew Morton: Can you pick this fix up to forward to Linus?
Thanks,
Jason
On Thu, Aug 06, 2020 at 10:21:11PM +0200, Thomas Gleixner wrote:
> Optionally? Please tell the hardware folks to make this mandatory. We
> have enough pain with non maskable MSI interrupts already so introducing
> yet another non maskable interrupt trainwreck is not an option.
Can you elaborate o
On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
> If you see this as an abuse of the framework, then let's identify those
> specific issues and come up with a better approach. As we've discussed
> before, things like basic PCI config space emulation are acceptable
> overhead and
On Fri, Aug 07, 2020 at 02:38:31PM +0200, gre...@linuxfoundation.org wrote:
> On Fri, Aug 07, 2020 at 09:06:50AM -0300, Jason Gunthorpe wrote:
> > On Thu, Aug 06, 2020 at 10:21:11PM +0200, Thomas Gleixner wrote:
> >
> > > Optionally? Please tell the hardware folks to
On Fri, Aug 07, 2020 at 10:54:51AM -0700, Dey, Megha wrote:
> So from the hierarchical domain standpoint, we will have:
> - For DSA device: vector->intel-IR->IDXD
> - For Jason's device: root domain-> domain A-> Jason's device's IRQ domain
> - For any other intel IMS device in the future which
>
On Tue, Aug 18, 2020 at 01:09:01AM +, Tian, Kevin wrote:
> The difference in my reply is not just about the implementation gap
> of growing a userspace DMA framework to a passthrough framework.
> My real point is about the different goals that each wants to achieve.
> Userspace DMA is purely ab
On Wed, Aug 05, 2020 at 03:14:59PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a usnic_err error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/infiniband/hw/usnic/usnic_ib_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, Aug 05, 2020 at 03:11:11PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_dbg message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied
On Tue, Aug 18, 2020 at 06:27:21PM +0200, Paolo Bonzini wrote:
> On 18/08/20 13:50, Jason Gunthorpe wrote:
> > For instance, what about suspend/resume of containers using idxd?
> > Wouldn't you want to have the same basic approach of controlling the
> > wq from userspac
On Tue, Aug 18, 2020 at 07:05:16PM +0200, Paolo Bonzini wrote:
> On 18/08/20 18:49, Jason Gunthorpe wrote:
> > On Tue, Aug 18, 2020 at 06:27:21PM +0200, Paolo Bonzini wrote:
> >> On 18/08/20 13:50, Jason Gunthorpe wrote:
> >>> For instance, what about suspend/r
On Thu, Jul 30, 2020 at 11:12:32AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Very straightforward cleanup.
>
> Thanks
>
> Leon Romanovsky (3):
> RDMA/mlx5: Simplify multiple else-if cases with switch keyword
> RDMA/mlx5: Replace open-coded offsetofend() macro
> RDMA: Remov
On Mon, Aug 10, 2020 at 08:58:24AM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a pr_warn message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/infiniband/core/device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-ne
On Sun, Jan 10, 2021 at 11:30:57AM -0800, Linus Torvalds wrote:
> Notice how this is all both conceptually fairly simple (ie I can
> explain the rules in plain English without really making any complex
> argument) and it is arguably internally fairly self-consistent (ie the
> whole notion of "oh,
On Fri, Jan 08, 2021 at 09:50:08PM -0500, Andrea Arcangeli wrote:
> For all those that aren't using mmu notifier and that rely solely on
> page pins, they still require privilege, except they do through /dev/
> permissions.
It is normal that the dev nodes are a+rw so it doesn't really require
pri
On Sat, Jan 09, 2021 at 11:49:58AM +0800, Hillf Danton wrote:
> On Fri, 8 Jan 2021 14:19:45 -0400 Jason Gunthorpe wrote:
> >
> > What I was trying to explain below, is I think we agreed that a page
> > under active FOLL_LONGTERM pin *can not* be write protected.
>
On Sat, Jan 09, 2021 at 05:58:50PM -0500, Douglas Gilbert wrote:
> On 2021-01-07 12:44 p.m., Jason Gunthorpe wrote:
> > On Mon, Dec 28, 2020 at 06:49:52PM -0500, Douglas Gilbert wrote:
> > > diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> > > index a59778
On Sat, Jan 09, 2021 at 09:51:14PM -0500, Andrea Arcangeli wrote:
> Are we spending 32bit in mm_struct atomic_t just to call atomic_set(1)
> on it? Why isn't it a MMF_HAS_PINNED that already can be set
> atomically under mmap_read_lock too? There's bit left free there, we
> didn't run out yet to j
On Sun, Jan 10, 2021 at 11:26:57PM -0800, John Hubbard wrote:
> So:
>
> FOLL_PIN: would use DMA_PIN_COUNTING_BIAS to increment page refcount.
> These are long term pins for dma.
>
> FOLL_GET: would use GUP_PIN_COUNTING_BIAS to increment page refcount.
> These are not long term pins.
Do we have
On Sat, Oct 31, 2020 at 06:46:38AM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> A semicolon is not needed after a switch statement.
>
> Signed-off-by: Tom Rix
> ---
> drivers/infiniband/hw/mlx5/qp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next
Jason
On Mon, Dec 07, 2020 at 06:32:55PM +0100, Lukas Bulwahn wrote:
> Commit 66f57b871efc ("RDMA/restrack: Support all QP types") extends
> ib_create_qp() to a named ib_create_named_qp(), which takes the caller's
> name as argument, but it did not add the new argument description to the
> function's ker
On Thu, Dec 10, 2020 at 01:57:20PM -0500, Pavel Tatashin wrote:
> Thank you. Yes, this series should be backported, but I am not sure
> what to do about Jason's patch. Perhaps, in the next version I will
> send out this series together with his patch.
You need to send out patches that can be appl
On Tue, Dec 08, 2020 at 09:35:42AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi,
>
> This is set of various and unrelated fixes that we collected over time.
>
> Thanks
>
> Avihai Horon (1):
> RDMA/uverbs: Fix incorrect variable type
>
> Jack Morgenstein (2):
> RDMA/core: C
On Tue, Dec 08, 2020 at 09:39:28PM +0200, Vladimir Oltean wrote:
> It is not clear what this lock protects. If the authors wanted to ensure
> that "dev" does not disappear, that is impossible, given the following
> code path:
>
> mlx4_ib_netdev_event (under RTNL mutex)
> -> mlx4_ib_scan_netdevs
>
On Fri, Dec 11, 2020 at 07:56:54PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> mm/gup.c
>
> between commit:
>
> 2a4a06da8a4b ("mm/gup: Provide gup_get_pte() more generic")
>
> from the tip tree and commit:
>
> 1eb
On Fri, Dec 11, 2020 at 03:21:39PM -0500, Pavel Tatashin wrote:
> @@ -1593,7 +1592,7 @@ static long check_and_migrate_cma_pages(struct
> mm_struct *mm,
> }
>
> if (!isolate_lru_page(head)) {
> - list_
701 - 800 of 3031 matches
Mail list logo
