On Thu, Apr 01, 2021 at 12:26:56PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 01, 2021 at 08:05:37AM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 31, 2021 at 07:47:01PM +0100, Matthew Wilcox (Oracle) wrote:
> > > - Mirror members of struct page (for pagecache / anon) into struct folio,
> > >
On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> > > On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
>
On Wed, Mar 31, 2021 at 04:46:21PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 31 Mar 2021 09:38:01 -0300, Jason Gunthorpe wrote:
>
> > > > Get rid of the ioasid set.
> > > >
> > > > Each driver has its own list of allowed ioasids.
> &
On Wed, Mar 31, 2021 at 10:01:05AM +0800, Tang Yizhou wrote:
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
>
> Reported-by: Hulk Robot
> Signed-off-by: Tang Yizhou
> ---
> drivers/infiniband/hw/cxgb4/cm.c | 3 +--
> 1 file
On Wed, Mar 31, 2021 at 11:20:30AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 31 Mar 2021 14:31:48 -0300, Jason Gunthorpe wrote:
>
> > > > We should try to avoid hidden behind the scenes kernel
> > > > interconnections between subsystems.
> >
On Thu, Mar 25, 2021 at 11:39:28AM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 23, 2021 at 09:27:38PM -0700, Aruna Ramakrishna wrote:
>
> > > Do you have benchmarks that show the performance of the high order
> > > pages is not relavent? I'm a bit surprised to hear th
On Wed, Mar 31, 2021 at 09:34:57AM -0700, Jacob Pan wrote:
> "3.3 PASID translation
> To support PASID isolation for Shared Work Queues used by VMs, the CPU must
> provide a way for the PASID to be communicated to the device in the DMWr
> transaction. On Intel CPUs, the CPU provides a PASID transl
On Wed, Mar 31, 2021 at 09:04:32AM -0700, Dan Williams wrote:
> On Wed, Mar 31, 2021 at 6:10 AM Jason Gunthorpe wrote:
> >
> > On Tue, Mar 30, 2021 at 04:36:42PM -0700, Dan Williams wrote:
> > > +static int cxl_mem_add_memdev(struct cxl_mem *cxlm)
> > > +{
>
On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> > On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> >
> > > I guess that makes sense as the split could go either way a
On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> I guess that makes sense as the split could go either way at the
> moment but I should add a check to make sure this isn't used with
> pinned pages anyway.
Is it possible to have a pinned page under one of these things? If I
pin i
hutdown any ioctl operations that
>* saw that state.
>*/
> cxl_memdev_shutdown(cxlmd);
Then this doesn't need to be a function
But it is OK as is
Reviewed-by: Jason Gunthorpe
Jason
; + * saw that state.
>*/
Wow it is really subtle that cdev_device_add has this tiny hole where
it can fail but have already allowed open() :<
Other than the lock it looks OK
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Mar 31, 2021 at 07:38:36AM +, Liu, Yi L wrote:
> The reason is /dev/ioasid FD is per-VM since the ioasid allocated to
> the VM should be able to be shared by all assigned device for the VM.
> But the SVA operations (bind/unbind page table, cache_invalidate) should
> be per-device.
It
On Wed, Mar 31, 2021 at 07:41:40AM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 9:28 PM
> >
> > On Tue, Mar 30, 2021 at 04:14:58AM +, Tian, Kevin wrote:
> >
> > > One correction. The mdev should still construct th
On Tue, Mar 30, 2021 at 05:10:41PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Tue, 30 Mar 2021 10:43:13 -0300, Jason Gunthorpe wrote:
>
> > > If two mdevs from the same PF dev are assigned to two VMs, the PASID
> > > table will be shared. IOASID set ensures
On Wed, Mar 31, 2021 at 03:15:47PM +1100, Alistair Popple wrote:
> On Wednesday, 31 March 2021 2:56:38 PM AEDT John Hubbard wrote:
> > On 3/30/21 3:56 PM, Alistair Popple wrote:
> > ...
> > >> +1 for renaming "munlock*" items to "mlock*", where applicable. good
> grief.
> > >
> > > At least the s
On Tue, Mar 30, 2021 at 08:29:12AM -0400, Ruiqi Gong wrote:
> s/caculating/calculating
>
> Reported-by: Hulk Robot
> Signed-off-by: Ruiqi Gong
> ---
> drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Applied to for-next, thanks
Jason
On Fri, Mar 26, 2021 at 07:33:46PM +0800, Wan Jiabing wrote:
> struct iscsi_iser_task has been declared at 201st line.
> Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
> ---
> drivers/infiniband/ulp/iser/iscsi_iser.h | 1 -
> 1 file changed, 1 deletion(-)
Applied to for-next, thanks
Jaso
On Wed, Mar 31, 2021 at 09:09:30AM +1100, Alistair Popple wrote:
> > > @@ -1796,8 +1821,7 @@ bool try_to_unmap(struct page *page, enum ttu_flags
> flags)
> > > void try_to_munlock(struct page *page)
> > > {
> >
> > But this is also called try_to_munlock ??
>
> As far as I can tell this has al
On Tue, Mar 30, 2021 at 02:00:43PM -0700, Dan Williams wrote:
> Ok, so another case where I agree the instability exists but does not
> matter in practice in this case because the cxl_memdev_ioctl() read
> side is prepared for the state change to leak into the down_read()
> section. There's no mea
On Tue, Mar 30, 2021 at 12:43:15PM -0700, Dan Williams wrote:
> Ok, so this is the disagreement. Strict adherence to the model where
> it does not matter in practice.
The basic problem is that it is hard to know if it does not matter in
practice because you never know what the compiler might deci
On Fri, Mar 26, 2021 at 11:08:02AM +1100, Alistair Popple wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index 3a5705cfc891..33d11527ef77 100644
> +++ b/mm/memory.c
> @@ -781,6 +781,27 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct
> mm_struct *src_mm,
> p
On Tue, Mar 30, 2021 at 12:00:23PM -0700, Dan Williams wrote:
> > > > IMHO this can't use 'dev->kobj.state_in_sysfs' as the RCU protected
> > > > data.
> > >
> > > This usage of srcu is functionally equivalent to replacing
> > > srcu_read_lock() with down_read() and the shutdown path with:
> >
>
On Fri, Mar 26, 2021 at 11:08:00AM +1100, Alistair Popple wrote:
> +static bool try_to_munlock_one(struct page *page, struct vm_area_struct *vma,
> + unsigned long address, void *arg)
> +{
Is this function name right?
> + struct page_vma_mapped_walk pvmw = {
> +
> mm/memory.c | 10 +++---
> mm/migrate.c| 6 ++--
> mm/page_vma_mapped.c| 6 ++--
> 10 files changed, 50 insertions(+), 81 deletions(-)
Looks good
Reviewed-by: Jason Gunthorpe
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 943cb2ba4442..3b2dda71d0ed
On Tue, Mar 30, 2021 at 10:31:15AM -0700, Dan Williams wrote:
> On Tue, Mar 30, 2021 at 10:03 AM Jason Gunthorpe wrote:
> >
> > On Tue, Mar 30, 2021 at 09:05:29AM -0700, Dan Williams wrote:
> >
> > > > If you can't clearly point to the *data* under RCU pro
On Tue, Mar 30, 2021 at 09:05:29AM -0700, Dan Williams wrote:
> > If you can't clearly point to the *data* under RCU protection it is
> > being used wrong.
>
> Agree.
>
> The data being protected is the value of
> dev->kobj.state_in_sysfs. The
So where is that read under:
+ idx = srcu_re
On Tue, Mar 30, 2021 at 08:37:19AM -0700, Dan Williams wrote:
> On Tue, Mar 30, 2021 at 4:16 AM Jason Gunthorpe wrote:
> >
> > On Mon, Mar 29, 2021 at 07:47:49PM -0700, Dan Williams wrote:
> >
> > > @@ -1155,21 +1175,12 @@ static void cxlmdev_unregister(void *_cxlmd)
On Mon, Mar 29, 2021 at 04:24:19PM -0700, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 7:34 AM Jason Gunthorpe wrote:
> >
> > On Thu, Mar 18, 2021 at 10:03:06AM -0700, Dan Williams wrote:
> > > Yes. I still need to answer the question of whether mapping
> > > i
On Tue, Mar 30, 2021 at 03:42:24PM +0200, Jean-Philippe Brucker wrote:
> On Tue, Mar 30, 2021 at 10:07:55AM -0300, Jason Gunthorpe wrote:
> > On Fri, Mar 26, 2021 at 09:06:42AM +0100, Jean-Philippe Brucker wrote:
> >
> > > It's not inconceivable to have a contro
On Mon, Mar 29, 2021 at 03:55:26PM -0700, Jacob Pan wrote:
> In one of the earlier discussions, I was made aware of some use cases (by
> AMD, iirc) where PASID can be used w/o IOMMU. That is why I tried to keep
> ioasid a separate subsystem. Other than that, I don't see an issue
> combining the tw
On Tue, Mar 30, 2021 at 01:37:05AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 12:32 AM
> >
> > On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
> >
> > > > IMHO a use created PASID is either bound
On Tue, Mar 30, 2021 at 04:14:58AM +, Tian, Kevin wrote:
> One correction. The mdev should still construct the list of allowed PASID's as
> you said (by listening to IOASID_BIND/UNBIND event), in addition to the
> ioasid
> set maintained per VM (updated when a PASID is allocated/freed). The
On Tue, Mar 30, 2021 at 02:24:09AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 12:32 AM
> > > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host
> > > mm,
> > > the use case is as the following
On Fri, Mar 26, 2021 at 09:06:42AM +0100, Jean-Philippe Brucker wrote:
> It's not inconceivable to have a control queue doing DMA tagged with
> PASID. The devices I know either use untagged DMA, or have a choice to use
> a PASID.
I don't think we should encourage that. A PASID and all the related
On Mon, Mar 29, 2021 at 07:47:49PM -0700, Dan Williams wrote:
> @@ -1155,21 +1175,12 @@ static void cxlmdev_unregister(void *_cxlmd)
> struct cxl_memdev *cxlmd = _cxlmd;
> struct device *dev = &cxlmd->dev;
>
> - percpu_ref_kill(&cxlmd->ops_active);
> cdev_device_del(&cxlmd-
On Mon, Mar 29, 2021 at 02:03:37PM -0700, Dan Williams wrote:
> Ugh, exactly why I was motivated to attempt to preclude this with new
> core infrastructure that attempted to fix this centrally [1]. Remove
> the possibility of "others" getting this wrong. However after my
> initial idea bounced of
On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
> > IMHO a use created PASID is either bound to a mm (current) at creation
> > time, or it will never be bound to a mm and its page table is under
> > user control via /dev/ioasid.
> >
> True for PASID used in native SVA bind. But for bin
On Mon, Mar 29, 2021 at 05:43:23PM +0300, Mika Westerberg wrote:
> The nvm is a separate (physical Linux) device that gets added under this
> one. It cannot be added before AFAICT.
Hum, yes, but then it is odd that a parent is holding sysfs attributes
that refer to a child.
> The code you refer
g the pte somehow by
> adjusting it and moving it into the kerneldoc for the new follow_pte()
> function.
>
> Cc: 3...@google.com
> Cc: Jann Horn
> Cc: Paolo Bonzini
> Cc: Jason Gunthorpe
> Cc: Cornelia Huck
> Cc: Peter Xu
> Cc: Alex Williamson
> Cc: linux...@kv
h later patches will then
> roll out to all appropriate places.
>
> Also mark up follow_pfn as EXPORT_SYMBOL_GPL. The only safe way to use
> that by drivers/modules is together with an mmu_notifier, and that's
> all _GPL stuff.
>
> Signed-off-by: Daniel Vetter
> Cc: Christop
; fundamental so review carefully etc.
It looks OK to me
Reviewed-by: Jason Gunthorpe
This also highlights the code has an ordering issue too, it calls
device_register() then goes to do tb_retimer_nvm_add() however
device_register() makes sysfs attributes visible before the rt->nvm is
initializ
On Wed, Mar 24, 2021 at 08:59:13AM +, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 7acac4b3196caee5e21fb5ea53f8bc124e6a16fc
> commit: 179209fa12709a3dfc323b37315da2683c24 vfio: IOMMU_API should be
> selected
> dat
On Sun, Mar 28, 2021 at 03:06:40AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e
> commit: 179209fa12709a3dfc323b37315da2683c24 vfio: IOMMU_API should be
> selected
> dat
On Mon, Mar 22, 2021 at 09:13:25AM -0700, Lv Yunlong wrote:
> The device is got by isert_device_get() with refcount is 1,
> and is assigned to isert_conn by isert_conn->device = device.
> When isert_create_qp() failed, device will be freed with
> isert_device_put().
>
> Later, the device is used i
On Mon, Mar 22, 2021 at 12:13:22PM +0530, Bhaskar Chowdhury wrote:
> s/struture/structure/
>
> Signed-off-by: Bhaskar Chowdhury
> Acked-by: Randy Dunlap
> ---
> include/rdma/rdma_vt.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next, thanks
Jason
On Mon, Mar 22, 2021 at 11:59:23AM +0530, Bhaskar Chowdhury wrote:
> s/struture/structure/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/infiniband/hw/hfi1/iowait.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next with Randy's note
Thanks,
Jason
On Fri, Mar 26, 2021 at 10:08:09AM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/25/21 7:24 PM, Jason Gunthorpe wrote:
> > On Thu, Mar 25, 2021 at 07:13:33PM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
> > > > On Thu,
On Thu, Mar 25, 2021 at 07:13:33PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
> > On Thu, Mar 25, 2021 at 06:51:26PM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/24/21 9:25 PM, Dave Hansen wrote:
> > > > On 3/24/21
Hi Linus,
Not much going on, just some small bug fixes
Thanks,
Jason
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
On Thu, Mar 25, 2021 at 06:51:26PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/24/21 9:25 PM, Dave Hansen wrote:
> > On 3/24/21 1:22 PM, Thomas Hellström (Intel) wrote:
> > > > We also have not been careful at *all* about how _PAGE_BIT_SOFTW* are
> > > > used. It's quite possible we can encod
On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> Hi Jean-Philippe,
>
> On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> wrote:
>
> > On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> > > Hi Jason,
> > >
> > > On
o be cleaned up by
> put_device(). Skip cdev_device_add() and proceed directly to
> put_device() if the name set failure.
>
> Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
> Reported-by: Jason Gunthorpe
> Signed-off-by: Dan Williams
> drivers/cxl/mem.c
gt;
> Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
> Reported-by: Jason Gunthorpe
> Signed-off-by: Dan Williams
> drivers/cxl/mem.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/
Reviewed-by: Ben Widawsky
> Reported-by: Jason Gunthorpe
> Signed-off-by: Dan Williams
> ---
> drivers/cxl/mem.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
On Tue, Mar 23, 2021 at 09:27:38PM -0700, Aruna Ramakrishna wrote:
> > Do you have benchmarks that show the performance of the high order
> > pages is not relavent? I'm a bit surprised to hear that
> >
>
> I guess my point was more to the effect that an order-8 alloc will
> fail more often than
device presence can be
> revalidated with locks held.
>
> Reported-by: Jason Gunthorpe
> Cc: Christoph Hellwig
> Cc: Shiyang Ruan
> Cc: Vishal Verma
> Cc: Dave Jiang
> Cc: Ira Weiny
> Cc: Matthew Wilcox
> Cc: Jan Kara
>
On Thu, Mar 18, 2021 at 10:03:06AM -0700, Dan Williams wrote:
> Yes. I still need to answer the question of whether mapping
> invalidation triggers longterm pin holders to relinquish their hold,
> but that's a problem regardless of whether gup-fast is supported or
> not.
It does not, GUP users do
On Thu, Mar 25, 2021 at 02:54:31PM +0100, Christian König wrote:
> > The goal is to optimize large page size usage in the page tables.
> >
> > There are three critera that impact this:
> > 1) The possible CPU page table sizes
> > 2) The useful contiguity the device can create in its iomemory
On Thu, Mar 25, 2021 at 02:26:50PM +0100, Christian König wrote:
> Am 25.03.21 um 14:17 schrieb Jason Gunthorpe:
> > On Thu, Mar 25, 2021 at 02:05:14PM +0100, Christian König wrote:
> > >
> > > Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
> > > > O
On Thu, Mar 25, 2021 at 02:05:14PM +0100, Christian König wrote:
>
>
> Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
> > On Thu, Mar 25, 2021 at 01:09:14PM +0100, Christian König wrote:
> > > Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
> > > > On Thu, Mar
On Thu, Mar 25, 2021 at 01:09:14PM +0100, Christian König wrote:
> Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
> > On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel) wrote:
> >
> > > Nope. The point here was that in this case, to make sure mmap uses the
On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel) wrote:
> Nope. The point here was that in this case, to make sure mmap uses the
> correct VA to give us a reasonable chance of alignement, the driver might
> need to be aware of and do trickery with the huge page-table-entry sizes
On Thu, Mar 25, 2021 at 10:51:35AM +0100, Thomas Hellström (Intel) wrote:
> > Please explain that further. Why do we need the mmap lock to insert PMDs
> > but not when insert PTEs?
>
> We don't. But once you've inserted a PMD directory you can't remove it
> unless you have the mmap lock (and prob
On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/24/21 7:31 PM, Christian König wrote:
> >
> >
> > Am 24.03.21 um 17:38 schrieb Jason Gunthorpe:
> > > On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel)
> &
On Mon, Mar 15, 2021 at 10:27:08AM -0600, Logan Gunthorpe wrote:
> In this case the WARN_ON is just to guard against misuse of the
> function. It should never happen unless a developer changes the code in
> a way that is incorrect. So I think that's the correct use of WARN_ON.
> Though I might cha
On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > Also wondering about device driver allocating auxiliary domains for their
> > private use, to do iommu_map/unmap on private PASIDs (a clean replacement
> > to super SVA, for example). Would that go through the same path as
> > /dev/ioas
On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/24/21 2:48 PM, Jason Gunthorpe wrote:
> > On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote:
> >
> > > > In an ideal world the creation/destruction of page
On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote:
> > In an ideal world the creation/destruction of page table levels would
> > by dynamic at this point, like THP.
>
> Hmm, but I'm not sure what problem we're trying to solve by changing the
> interface in this way?
We are
e somehow by
> adjusting it and moving it into the kerneldoc for the new follow_pte()
> function.
>
> Cc: 3...@google.com
> Cc: Jann Horn
> Cc: Paolo Bonzini
> Cc: Jason Gunthorpe
> Cc: Cornelia Huck
> Cc: Peter Xu
> Cc: Alex Williamson
> Cc: linux...@kv
On Wed, Mar 24, 2021 at 01:35:17PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/24/21 1:24 PM, Jason Gunthorpe wrote:
> > On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
>
On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
> >
> > On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
> > > On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas
On Tue, Mar 23, 2021 at 12:41:51PM -0700, Aruna Ramakrishna wrote:
>There is a far greater possibility of an order-8 allocation failing,
>esp. with the addition of __GFP_NORETRY , and the code would have to
>fall back to a lower order allocation more often than not (esp. on a
>long
On Mon, Mar 22, 2021 at 10:40:16AM -0600, Alex Williamson wrote:
> Of course if you start looking at features like migration support,
> that's more than likely not simply an additional region with optional
> information, it would need to interact with the actual state of the
> device. For those,
On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:
> > > @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct
> > > vm_fault *vmf,
> > > if ((pfn & (fault_page_size - 1)) != 0)
> > > goto out_fallback;
> > > + /*
> > > + * Huge en
On Tue, Mar 16, 2021 at 01:09:01PM +, Praveen Kumar Kannoju wrote:
> To update xlt (during mlx5_ib_reg_user_mr()), the driver can request up to
> 1 MB (order-8) memory, depending on the size of the MR. This costly
> allocation can sometimes take very long to return (a few seconds),
> especially
On Tue, Mar 23, 2021 at 04:46:00PM +0100, Thomas Hellström (Intel) wrote:
> > > +static inline bool is_cow_mapping(vm_flags_t flags)
> > > +{
> > > + return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
> > > +}
> > Most driver places are just banning VM_SHARED.
> >
> > I see you copied this
On Tue, Mar 23, 2021 at 12:47:24PM +0100, Daniel Vetter wrote:
> > +static inline bool is_cow_mapping(vm_flags_t flags)
>
> Bit a bikeshed, but I wonder whether the public interface shouldn't be
> vma_is_cow_mapping. Or whether this shouldn't be rejected somewhere else,
> since at least in driver
t; means there should not be a performance difference anymore, but this
> needs to be verified.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-de...@lists.freedesktop.org
On Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellström (Intel) wrote:
> diff --git a/mm/gup.c b/mm/gup.c
> index e40579624f10..1b6a127f0bdd 100644
> +++ b/mm/gup.c
> @@ -1993,6 +1993,17 @@ static void __maybe_unused undo_dev_pagemap(int *nr,
> int nr_start,
> }
>
> #ifdef CONFIG_ARCH_HAS_P
On Tue, Mar 23, 2021 at 02:17:09PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 01:44:11PM -0300, Jason Gunthorpe wrote:
> > This isn't quite the scenario that needs solving. Lets go back to
> > Max's V1 posting:
> >
> > The ml
On Thu, Mar 18, 2021 at 03:34:53PM +0530, Bhaskar Chowdhury wrote:
> s/proviee/provide/
> s/undelying/underlying/
> s/quesiton/question/
> s/drivr/driver/
>
> Signed-off-by: Bhaskar Chowdhury
> Acked-by: Randy Dunlap
> ---
> include/rdma/rdma_vt.h | 8
> 1 file changed, 4 insertions(+)
On Mon, Mar 22, 2021 at 07:57:51AM +0530, Bhaskar Chowdhury wrote:
> s/wubsytem/subsystem/
>
> Signed-off-by: Bhaskar Chowdhury
> Acked-by: Weihang Li
> ---
> .../devicetree/bindings/infiniband/hisilicon-hns-roce.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-
On Mon, Mar 22, 2021 at 04:11:25PM +0100, Christoph Hellwig wrote:
> On Fri, Mar 19, 2021 at 05:07:49PM -0300, Jason Gunthorpe wrote:
> > The way the driver core works is to first match against the already
> > loaded driver list, then trigger an event for module loading and when
On Sun, Mar 14, 2021 at 03:39:06PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Bunch of cleanup in RDMA subsystem.
>
> Leon Romanovsky (2):
> RDMA: Fix kernel-doc compilation warnings
> RDMA: Delete not-used static inline functions
Applied to for-next
How did you find the unu
On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe wrote:
>
> > On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> > > On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gu
On Fri, Mar 19, 2021 at 10:40:28PM -0600, Alex Williamson wrote:
> > Well, today we don't, but Max here adds id_table's to the special
> > devices and a MODULE_DEVICE_TABLE would come too if we do the flavours
> > thing below.
>
> I think the id_tables are the wrong approach for IGD and NVLink
>
On Fri, Mar 19, 2021 at 03:08:09PM -0600, Alex Williamson wrote:
> On Fri, 19 Mar 2021 17:07:49 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, Mar 19, 2021 at 11:36:42AM -0600, Alex Williamson wrote:
> > > On Fri, 19 Mar 2021 17:34:49 +0100
> > > Christoph Hellwi
On Fri, Mar 19, 2021 at 11:36:42AM -0600, Alex Williamson wrote:
> On Fri, 19 Mar 2021 17:34:49 +0100
> Christoph Hellwig wrote:
>
> > On Fri, Mar 19, 2021 at 01:28:48PM -0300, Jason Gunthorpe wrote:
> > > The wrinkle I don't yet have an easy answer to is ho
On Fri, Mar 19, 2021 at 05:20:33PM +0100, Christoph Hellwig wrote:
> On Fri, Mar 19, 2021 at 01:17:22PM -0300, Jason Gunthorpe wrote:
> > I think we talked about this.. We still need a better way to control
> > binding of VFIO modules - now that we have device-specific modules w
On Fri, Mar 19, 2021 at 09:23:41AM -0600, Alex Williamson wrote:
> On Wed, 10 Mar 2021 14:57:57 +0200
> Max Gurtovoy wrote:
> > On 3/10/2021 8:39 AM, Alexey Kardashevskiy wrote:
> > > On 09/03/2021 19:33, Max Gurtovoy wrote:
> > >> +static const struct pci_device_id nvlink2gpu_vfio_pci_table[] =
On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> > On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> >
> > > Although there is no use for it at the moment (onl
On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> Although there is no use for it at the moment (only two upstream users and
> it looks like amdkfd always uses current too), I quite like the
> client-server model where the privileged process does bind() and programs
> the ha
On Fri, Mar 12, 2021 at 01:58:44PM -0700, Alex Williamson wrote:
> Yeah, we can indeed use memalloc_nofs_save/restore(). It seems we're
> trying to allocate something for pfnmap tracking and that enables lots
> of lockdep specific tests. Is it valid to wrap io_remap_pfn_range()
> around clearing
On Fri, Mar 12, 2021 at 12:16:11PM -0700, Alex Williamson wrote:
> On Wed, 10 Mar 2021 14:40:11 -0400
> Jason Gunthorpe wrote:
>
> > On Wed, Mar 10, 2021 at 11:34:06AM -0700, Alex Williamson wrote:
> >
> > > > I think after the address_space changes this s
On Thu, Mar 11, 2021 at 02:55:34PM -0800, Jacob Pan wrote:
> Hi Jason,
>
> Thanks for the review.
>
> On Wed, 10 Mar 2021 15:23:01 -0400, Jason Gunthorpe wrote:
>
> > On Sat, Feb 27, 2021 at 02:01:26PM -0800, Jacob Pan wrote:
> >
> > > +/*
On Fri, Mar 12, 2021 at 10:19:30AM +0800, Wang Qing wrote:
> Fix the following coccicheck warning:
> WARNING: casting value returned by memory allocation function is useless.
This warning is wrong in this specific case.
The #define is creating a helper function that enforces strict type
safety on
On Thu, Mar 04, 2021 at 02:07:41PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi,
>
> The following patchset is a cleanup of mlx5_ib_mr dereg logic.
>
> Thanks
>
> Jason Gunthorpe (4):
> RDMA/mlx5: Zero out ODP related items in the mlx5_ib_mr
>
On Thu, Mar 11, 2021 at 04:31:41PM -0700, Logan Gunthorpe wrote:
> Convert to using dma_[un]map_sg() for PCI p2pdma pages.
>
> This should be equivalent, though support will be somewhat less
> (only dma-direct and dma-iommu are currently supported).
>
> Signed-off-by: Logan Gunthorpe
> drivers/
ranges, triggering OOM,
> and observing that KVM exits with an elevated notifier count.
>
> Fixes: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")
> Suggested-by: Jason Gunthorpe
> Cc: sta...@vger.kernel.org
> Cc: David Rientjes
> Cc: Ben Gardon
>
201 - 300 of 1431 matches
Mail list logo
