On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
> >
> > On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> >
> > > +struct address_space *iomem_get_mapping(void)
> > > +{
&g
On Fri, Oct 09, 2020 at 06:02:09AM -0700, Raj, Ashok wrote:
> On Fri, Oct 09, 2020 at 09:49:45AM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 09, 2020 at 05:43:07AM -0700, Raj, Ashok wrote:
> > > On Fri, Oct 09, 2020 at 08:57:37AM -0300, Jason Gunthorpe wrote:
> > > &
On Fri, Oct 09, 2020 at 05:43:07AM -0700, Raj, Ashok wrote:
> On Fri, Oct 09, 2020 at 08:57:37AM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 08, 2020 at 06:22:31PM -0700, Raj, Ashok wrote:
> >
> > > Not randomly put there Jason :-).. There is a good reason for it.
>
On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote:
> I'm not a mm/ expert, but, from what I understood from Daniel's patch
> description is that this is unsafe *only if* __GFP_MOVABLE is used.
No, it is unconditionally unsafe. The CMA movable mappings are
specific VMAs that
On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> +struct address_space *iomem_get_mapping(void)
> +{
> + return iomem_inode->i_mapping;
This should pair an acquire with the release below
> + /*
> + * Publish /dev/mem initialized.
> + * Pairs with
On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote:
> Hi,
>
> Em Fri, 9 Oct 2020 09:59:26 +0200
> Daniel Vetter escreveu:
>
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu
On Fri, Oct 09, 2020 at 09:39:00AM +0200, Daniel Vetter wrote:
> I just noticed this here in the patch because everyone else does not do
> this. But looking at the mmap_region() code in mmap.c we seem to indeed
> have this problem for the error path:
>
> unmap_and_free_vma:
> vma->vm_file =
On Thu, Oct 08, 2020 at 06:22:31PM -0700, Raj, Ashok wrote:
> Not randomly put there Jason :-).. There is a good reason for it.
Sure the PASID value being associated with the IRQ make sense, but
combining that register with the interrupt mask is just a compltely
random thing to do.
If this HW
On Fri, Oct 09, 2020 at 01:17:38AM +0200, Thomas Gleixner wrote:
> Dave,
>
> On Thu, Oct 08 2020 at 09:51, Dave Jiang wrote:
> > On 10/8/2020 12:39 AM, Thomas Gleixner wrote:
> >> On Wed, Oct 07 2020 at 14:54, Dave Jiang wrote:
> >>> On 9/30/2020 12:57 PM, Thomas Gleixner wrote:
> Aside of
On Wed, Oct 07, 2020 at 07:46:54PM -0700, Joe Perches wrote:
> Parvi Kaustubhi's email bounces.
>
> Signed-off-by: Joe Perches
> Acked-by: Christian Benvenuti
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
Applied to for-next, thanks
Jason
On Thu, Oct 08, 2020 at 10:52:04AM +0100, Colin King wrote:
> From: Colin Ian King
>
> An incorrect sizeof is being used, struct rvt_ibport ** is not correct,
> it should be struct rvt_ibport *. Note that since ** is the same size as
> * this is not causing any issues. Improve this fix by using
On Thu, Oct 08, 2020 at 05:24:03PM +0200, Jan Engelhardt wrote:
> In the case of the RDMA headers, even if we assume best conditions --
> a block of malloc(sizeof(struct ib_uverbs_create_cq_resp) +
> sizeof(u64)*N) and not some struct -- it smells a lot like undefined
> behavior, because
On Thu, Oct 08, 2020 at 12:49:54AM -0700, Dan Williams wrote:
> > This is what got me thinking maybe this needs to be a bit bigger
> > generic infrastructure - eg enter this scheme from fops mmap and
> > everything else is in mm/user_iomem.c
>
> It still requires every file that can map physical
On Wed, Oct 07, 2020 at 12:33:06PM -0700, Dan Williams wrote:
> On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter wrote:
> >
> > 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.
On Wed, Oct 07, 2020 at 08:01:42PM +0200, Daniel Vetter wrote:
> I think it'd fix the bug, until someone wires ->access up for
> drivers/gpu, or the next subsystem. This is also just for ptrace, so
> we really don't care when we stall the vm badly and other silly
> things. So I figured the
On Wed, Oct 07, 2020 at 08:10:34PM +0200, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 7:36 PM Jason Gunthorpe wrote:
> >
> > On Wed, Oct 07, 2020 at 06:44:24PM +0200, Daniel Vetter wrote:
> > > Way back it was a reasonable assumptions that iomem mappings never
&g
On Wed, Oct 07, 2020 at 11:04:42AM -0700, Joe Perches wrote:
> On Wed, 2020-10-07 at 09:53 -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 07, 2020 at 12:16:01AM -0700, Kees Cook wrote:
> > > On Tue, Oct 06, 2020 at 09:28:17AM -0700, Joe Perches wrote:
> > > > Conve
On Wed, Oct 07, 2020 at 08:14:06PM +0200, Daniel Vetter wrote:
> Hm, but wouldn't need that the semi-nasty vma_open trick to make sure
> that vma doesn't untimely disappear? Or is the idea to look up the
> underlying vfio object, and refcount that directly?
Ah, the patches Alex was working on
afe. This means that with
> CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
>
> Real fix is to wire up an mmu_notifier ... somehow. Probably means any
> invalidate is a fatal fault for this vfio device, but then this
> shouldn't ever happen if userspace is reasonable.
>
> Signe
s will then
> roll out to all appropriate places.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linu
On Wed, Oct 07, 2020 at 07:12:24PM +0200, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 6:53 PM Jason Gunthorpe wrote:
> >
> > On Wed, Oct 07, 2020 at 06:44:18PM +0200, Daniel Vetter wrote:
> > >
> > > - /*
> > > - * While get_vaddr_fr
for moving the
> memory from iomem to system memory, as the old comment seemed to
> suggest.
>
> References: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
> Cc: Jason Gunthorpe
> Cc: Dan Williams
> Cc: Kees Cook
> Cc: Rik van Riel
> Cc: Benja
On Wed, Oct 07, 2020 at 06:44:18PM +0200, Daniel Vetter wrote:
>
> - /*
> - * While get_vaddr_frames() could be used for transient (kernel
> - * controlled lifetime) pinning of memory pages all current
> - * users establish long term (userspace controlled lifetime)
> - *
On Wed, Oct 07, 2020 at 04:11:59PM +0200, Tomasz Figa wrote:
> We also need to bring back the vma_open() that somehow disappeared
> around 4.2, as Marek found.
No
Jason
On Wed, Oct 07, 2020 at 03:34:01PM +0200, Tomasz Figa wrote:
> I think the userptr zero-copy hack should be able to go away indeed,
> given that we now have CMA that allows having carveouts backed by
> struct pages and having the memory represented as DMA-buf normally.
This also needs to figure
On Wed, Oct 07, 2020 at 03:06:17PM +0200, Tomasz Figa wrote:
> Note that vb2_vmalloc is only used for in-kernel CPU usage, e.g. the
> contents being copied by the driver between vb2 buffers and some
> hardware FIFO or other dedicated buffers. The memory does not go to
> any hardware DMA.
That is
On Wed, Oct 07, 2020 at 02:58:33PM +0200, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 2:48 PM Tomasz Figa wrote:
> >
> > On Wed, Oct 7, 2020 at 2:44 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 07, 2020 at 02:33:56PM +0200, Marek Szyprowski wrote:
&g
On Wed, Oct 07, 2020 at 12:16:01AM -0700, Kees Cook wrote:
> On Tue, Oct 06, 2020 at 09:28:17AM -0700, Joe Perches wrote:
> > Convert the various uses of sprintf/snprintf/scnprintf to
> > format sysfs output to sysfs_emit and sysfs_emit_at to make
> > clear the output is sysfs related and to avoid
On Wed, Oct 07, 2020 at 02:33:56PM +0200, Marek Szyprowski wrote:
> Well, it was in vb2_get_vma() function, but now I see that it has been
> lost in fb639eb39154 and 6690c8c78c74 some time ago...
There is no guarentee that holding a get on the file says anthing
about the VMA. This needed to
On Wed, Oct 07, 2020 at 12:54:50AM +0200, Jann Horn wrote:
> @@ -1545,6 +1532,18 @@ void setup_new_exec(struct linux_binprm * bprm)
> me->mm->task_size = TASK_SIZE;
> mutex_unlock(>signal->exec_update_mutex);
> mutex_unlock(>signal->cred_guard_mutex);
> +
> +#ifndef CONFIG_MMU
>
On Tue, Oct 06, 2020 at 12:47:00PM +0100, Colin King wrote:
> From: Colin Ian King
>
> An incorrect sizeof is being used, u64 * is not correct, it should be
> just u64 for a table of umem_pgs number of u64 items in the pbl_tbl.
> Use the idiom sizeof(*pbl_tbl) to get the object type without the
On Tue, Oct 06, 2020 at 08:35:08PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the hmm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
>
> Caused by commit
>
> 07da1223ec93 ("lib/scatterlist: Add support in dynamic allocation of SG
> table from
On Tue, Oct 06, 2020 at 08:23:23AM +0200, Daniel Vetter wrote:
> On Tue, Oct 6, 2020 at 1:41 AM Jason Gunthorpe wrote:
> >
> > On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote:
> >
> > > > iow I think I can outright delete the frame vector stuff.
On Mon, Oct 05, 2020 at 08:36:00PM -0700, Andrew Morton wrote:
> On Mon, 5 Oct 2020 14:47:47 -0300 Jason Gunthorpe wrote:
>
> > Andrew please let me know if you need a resend
>
> Andrew is rather confused.
>
> Can we please identify the minimal patch(es) which are need
On Tue, Oct 06, 2020 at 12:41:22PM +0200, Daniel Vetter wrote:
> On Mon, Oct 05, 2020 at 08:56:50PM -0300, Jason Gunthorpe wrote:
> > On Sun, Oct 04, 2020 at 06:43:36PM +0300, Leon Romanovsky wrote:
> > > This series extends __sg_alloc_table_from_pages to allow chaining
On Sun, Oct 04, 2020 at 06:43:36PM +0300, Leon Romanovsky wrote:
> This series extends __sg_alloc_table_from_pages to allow chaining of
> new pages to already initialized SG table.
>
> This allows for the drivers to utilize the optimization of merging contiguous
> pages without a need to pre
On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote:
> > iow I think I can outright delete the frame vector stuff.
>
> Ok this doesn't work, because dma_mmap always uses a remap_pfn_range,
> which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and
> not a carveout, we can't
On Mon, Oct 05, 2020 at 08:16:33PM +0200, Daniel Vetter wrote:
> > kvm is some similar hack added for P2P DMA, see commit
> > add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by
> > notifiers..
>
> Yeah my thinking is that kvm (and I think also vfio, also seems to
> have mmu
On Mon, Oct 05, 2020 at 07:53:08PM +0200, Jan Kara wrote:
> On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> > When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> > be allowed to extract a struct page from a normal VMA. This could allow a
> > serious u
On Mon, Oct 05, 2020 at 02:38:54PM -0300, Jason Gunthorpe wrote:
> When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> be allowed to extract a struct page from a normal VMA. This could allow a
> serious use-after-free problem on any kernel memory.
>
> Restri
-free problem to only IO memory, which while
still serious, is an improvement.
Cc: sta...@vger.kernel.org
Fixes: 8025e5ddf9c1 ("[media] mm: Provide new get_vaddr_frames() helper")
Signed-off-by: Jason Gunthorpe
---
mm/frame_vector.c | 4
1 file changed, 4 insertions(+)
diff
On Sun, Oct 04, 2020 at 01:20:31PM +0200, Daniel Vetter wrote:
> Yeah I think that works. I tried understanding gup.c code a bit more,
> and it looks like FOLL_LONGTERM only works for the pup_fast variant
> right now? All others seem to have this comment that it's somehow
> incompatible with
On Sun, Oct 04, 2020 at 06:09:29PM +0200, Daniel Vetter wrote:
> On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote:
> >
> > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote:
> >
> > > > That leaves the only interes
On Mon, Oct 05, 2020 at 03:30:43AM +0200, Jann Horn wrote:
> But another place where lockdep asserts should be added is find_vma();
> there are currently several architectures that sometimes improperly
> call that with no lock held:
Yes, I've seen several cases of this mis-use in drivers too
On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote:
> > That leaves the only interesting places as vb2_dc_get_userptr() and
> > vb2_vmalloc_get_userptr() which both completely fail to follow the
> > REQUIRED behavior in the function's comment about checking PTEs. It
> > just DMA maps
On Sat, Oct 03, 2020 at 03:52:32PM -0700, John Hubbard wrote:
> On 10/3/20 2:45 AM, Daniel Vetter wrote:
> > On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
> > >
> > > On 10/2/20 10:53 AM, Daniel Vetter wrote:
> > > > For $reasons I've stumbled over this code and I'm not sure the change
> >
On Fri, Oct 02, 2020 at 03:26:47PM -0400, Peter Xu wrote:
> Both of the mm pointers are not needed after commit 7a4830c380f3 ("mm/fork:
> Pass new vma pointer into copy_page_range()").
>
> Jason Gunthorpe also reported that the ordering of copy_page_range() is odd.
> Sin
On Fri, Oct 02, 2020 at 08:16:48PM +0200, Daniel Vetter wrote:
> On Fri, Oct 2, 2020 at 8:06 PM Jason Gunthorpe wrote:
> > On Fri, Oct 02, 2020 at 07:53:03PM +0200, Daniel Vetter wrote:
> > > For $reasons I've stumbled over this code and I'm not sure the change
> > &g
On Fri, Oct 02, 2020 at 07:53:03PM +0200, Daniel Vetter wrote:
> For $reasons I've stumbled over this code and I'm not sure the change
> to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> convert get_user_pages() --> pin_user_pages()") was entirely correct.
>
> This here is used
On Fri, Oct 02, 2020 at 01:14:29PM -0400, Peter Xu wrote:
> On Fri, Oct 02, 2020 at 08:43:12AM -0300, Jason Gunthorpe wrote:
> > > -static int copy_pte_range(struct mm_struct *dst_mm, struct mm_struct
> > > *src_mm,
> > > -pmd_t *dst_pmd, pmd_t *src_p
On Fri, Oct 02, 2020 at 07:11:33PM +0300, Maor Gottlieb wrote:
>
> On 10/2/2020 6:02 PM, Jason Gunthorpe wrote:
> > On Sun, Sep 27, 2020 at 09:46:44AM +0300, Leon Romanovsky wrote:
> > > +struct scatterlist *__sg_alloc_table_from_pages(struct sg_table *sgt,
> > >
On Sun, Sep 27, 2020 at 09:46:44AM +0300, Leon Romanovsky wrote:
> +struct scatterlist *__sg_alloc_table_from_pages(struct sg_table *sgt,
> + struct page **pages, unsigned int n_pages, unsigned int offset,
> + unsigned long size, unsigned int max_segment,
> +
On Wed, Sep 30, 2020 at 04:49:50PM -0400, Peter Xu wrote:
> Both of the mm pointers are not needed after commit 7a4830c380f3 ("mm/fork:
> Pass new vma pointer into copy_page_range()").
>
> Reported-by: Kirill A. Shutemov
> Signed-off-by: Peter Xu
> ---
> include/linux/mm.h | 3 +--
>
On Fri, Oct 02, 2020 at 02:17:49AM -0700, Michel Lespinasse wrote:
> Also FYI I was going to play with these patches a bit to help answer
> these questions on my own, but wasn't able to easily apply them as
> they came lightly mangled (whitespace issues) when I saved them.
Me too
It seems OK,
On Wed, Sep 23, 2020 at 07:50:11PM +0300, Leon Romanovsky wrote:
> When an application is not using RDMA CM and if it is using multiple RDMA
> devices with one or more RoCE ports, finding the right GID table entry is
> a long process.
>
> For example, with two RoCE dual-port devices in a system,
On Sun, Sep 13, 2020 at 01:29:28PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> The various array_size functions use SIZE_MAX define, but missed limits.h
> causes to failure to compile code that needs overflow.h.
>
> In file included from
On Thu, Oct 01, 2020 at 12:40:02AM +0200, Rikard Falkeborn wrote:
> Constify a couple of static struct attribute_group that are never
> modified to allow the compiler to put them in read-only memory.
>
> Rikard Falkeborn (2):
> RDMA/core: Constify struct attribute_group
> RDMA/rtrs: Constify
On Thu, Oct 01, 2020 at 10:16:35PM +0200, Jann Horn wrote:
> > A subclass isn't right, it has to be a _nested annotation.
> >
> > nested locking is a pretty good reason to not be able to do this, this
> > is something lockdep does struggle to model.
>
> Did I get the terminology wrong? I thought
On Thu, Oct 01, 2020 at 01:51:33AM +0200, Jann Horn wrote:
> On Thu, Oct 1, 2020 at 1:26 AM Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 10:14:57PM +0200, Jann Horn wrote:
> > > On Wed, Sep 30, 2020 at 2:50 PM Jann Horn wrote:
> > > > On Wed, Sep 30, 2020 at
On Wed, Sep 30, 2020 at 10:14:57PM +0200, Jann Horn wrote:
> On Wed, Sep 30, 2020 at 2:50 PM Jann Horn wrote:
> > On Wed, Sep 30, 2020 at 2:30 PM Jason Gunthorpe wrote:
> > > On Tue, Sep 29, 2020 at 06:20:00PM -0700, Jann Horn wrote:
> > > > In preparation for addin
On Wed, Sep 30, 2020 at 02:49:41PM -0700, Raj, Ashok wrote:
> One of the parameters it has is the "supported system page-sizes" which is
> usually there in the SRIOV properties. So it needed a place holder for
> that.
No idea why this would be a PCI cap. It is certainly not something so
On Wed, Sep 30, 2020 at 08:47:00PM +0200, Thomas Gleixner wrote:
> > + pci_read_config_dword(pdev, SIOVCAP(dvsec), );
> > + if ((val32 & 0x1) && idxd->hw.gen_cap.max_ims_mult) {
> > + idxd->ims_size = idxd->hw.gen_cap.max_ims_mult * 256ULL;
> > + dev_dbg(dev, "IMS size:
On Wed, Sep 30, 2020 at 01:08:27PM +, Derrick, Jonathan wrote:
> +Megha
>
> On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> > > Hi Jason
> > >
> > > On Mon, 2020-0
On Wed, Sep 30, 2020 at 03:14:07PM +0200, Gioh Kim wrote:
> From: Gioh Kim
>
> list field is not used anywhere
>
> Signed-off-by: Gioh Kim
> Acked-by: Jack Wang
> ---
> drivers/infiniband/ulp/rtrs/rtrs-pri.h | 1 -
> 1 file changed, 1 deletion(-)
Applied to for-next, thanks
Jason
On Wed, Sep 30, 2020 at 06:05:15PM +0300, Maor Gottlieb wrote:
> This is right only for the last iteration. E.g. in the first iteration in
> case that there are more pages (left_pages), then we allocate
> SG_MAX_SINGLE_ALLOC. We don't know how many pages from the second iteration
> will be
On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> Hi Jason
>
> On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > > From: Thomas Gleixner
> > >
> > > De
nged, 2 insertions(+)
I'm happy to see this, I have observed many cases of missing locking
here.
Reviewed-by: Jason Gunthorpe
Thanks,
Jason
On Tue, Sep 29, 2020 at 06:20:00PM -0700, Jann Horn wrote:
> In preparation for adding a mmap_assert_locked() check in
> __get_user_pages(), teach the mmap_assert_*locked() helpers that it's fine
> to operate on an mm without locking in the middle of execve() as long as
> it hasn't been installed
is code is only for testing, and it's only reachable by root through
> debugfs, so this doesn't really have any impact; however, if we want to add
> lockdep asserts into the GUP path, we need to have clean locking here.
>
> Signed-off-by: Jann Horn
> ---
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Sep 30, 2020 at 02:53:58PM +0300, Maor Gottlieb wrote:
>
> On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
> > > On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> > > > O
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
> On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> > On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> > > @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct
>
On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
> On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> > On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
> >> #9 is obviously just for the folks interested in IMS
> >>
> >
> > I see that the tip tree (as of 9/29) has most of these patches
On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
> *device,
> goto umem_release;
>
> cur_base += ret * PAGE_SIZE;
> - npages -= ret;
> -
> -
On Tue, Sep 29, 2020 at 12:48:43PM -0700, John Hubbard wrote:
> On 9/29/20 12:08 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 29, 2020 at 11:59:55AM -0700, John Hubbard wrote:
> > > On 9/29/20 10:55 AM, Jason Gunthorpe wrote:
> > > > On Tue, Sep 29, 2020 at 10:44:
On Tue, Sep 29, 2020 at 11:59:55AM -0700, John Hubbard wrote:
> On 9/29/20 10:55 AM, Jason Gunthorpe wrote:
> > On Tue, Sep 29, 2020 at 10:44:31AM -0700, John Hubbard wrote:
> > > On 9/29/20 9:35 AM, Jason Gunthorpe wrote:
> > > > On Mon, Sep 28, 2020 at 01:10:
On Tue, Sep 29, 2020 at 10:44:31AM -0700, John Hubbard wrote:
> On 9/29/20 9:35 AM, Jason Gunthorpe wrote:
> > On Mon, Sep 28, 2020 at 01:10:24PM -0700, John Hubbard wrote:
> > > On 9/28/20 5:57 AM, Jason Gunthorpe wrote:
> > > > On Sun, Sep 27, 2020 at 11:21:
On Sat, Sep 26, 2020 at 01:24:40PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v1:
> * Rebased
> * Fixed commit messages.
> * Changed "fallthrough" to be "break".
> v0: https://lore.kernel.org/lkml/20200910140046.1306341-1-l...@kernel.org
>
On Mon, Sep 28, 2020 at 01:10:24PM -0700, John Hubbard wrote:
> On 9/28/20 5:57 AM, Jason Gunthorpe wrote:
> > On Sun, Sep 27, 2020 at 11:21:53PM -0700, John Hubbard wrote:
> > > diff --git a/tools/testing/selftests/vm/Makefile
> > > b/tools/testing/selftests/vm/Makefi
On Mon, Sep 28, 2020 at 12:29:55PM -0700, Linus Torvalds wrote:
> So a read pin action would basically never work for the fast-path for
> a few cases, notably a shared read-only mapping - because we could
> never mark it in the page tables as "fast pin accessible"
Agree, I was assuming we'd loose
On Mon, Sep 28, 2020 at 12:50:03PM -0700, Linus Torvalds wrote:
> But the more I look at this code, the more I go "ok, I want somebody
> to actually test this with the rdma case".
I suspect it will be OK as our immediate test suite that touches this
will be using malloc memory.
It seems some
On Mon, Sep 28, 2020 at 10:54:28AM -0700, Linus Torvalds wrote:
> On Mon, Sep 28, 2020 at 10:23 AM Peter Xu wrote:
> >
> > Yes... Actually I am also thinking about the complete solution to cover
> > read-only fast-gups too, but now I start to doubt this, at least for the
> > fork()
> > path.
On Sun, Sep 27, 2020 at 11:21:59PM -0700, John Hubbard wrote:
> @@ -76,8 +79,6 @@ TEST_FILES := test_vmalloc.sh
> KSFT_KHDR_INSTALL := 1
> include ../lib.mk
>
> -$(OUTPUT)/hmm-tests: LDLIBS += -lhugetlbfs
> -
> ifeq ($(ARCH),x86_64)
> BINARIES_32 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_32))
On Sun, Sep 27, 2020 at 11:21:53PM -0700, John Hubbard wrote:
> diff --git a/tools/testing/selftests/vm/Makefile
> b/tools/testing/selftests/vm/Makefile
> index d1ae706d9927..9cc6bc087461 100644
> +++ b/tools/testing/selftests/vm/Makefile
> @@ -130,3 +130,5 @@ endif
> $(OUTPUT)/userfaultfd:
On Sun, Sep 27, 2020 at 11:45:30AM -0700, Linus Torvalds wrote:
> On Sun, Sep 27, 2020 at 11:16 AM Linus Torvalds
> wrote:
> >
> > Btw, I'm not convinced about the whole "turn the pte read-only and
> > then back". If the fork races with another thread doing a pinning
> > fast-GUP on another CPU,
On Fri, Sep 25, 2020 at 06:25:59PM -0400, Peter Xu wrote:
> -static inline void
> +/*
> + * Copy one pte. Returns 0 if succeeded, or -EAGAIN if one preallocated page
> + * is required to copy this pte.
> + */
> +static inline int
> copy_present_pte(struct mm_struct *dst_mm, struct mm_struct
at I think everyone marks
> the bug as "old/dealt with" so it was only because I was added a new
> check for resource leaks that it was found when it was re-introduced.
>
> lib/test_hmm.c | 44 ++--
> 1 file changed, 22 insertions
On Fri, Sep 25, 2020 at 02:06:59PM -0700, Linus Torvalds wrote:
> On Fri, Sep 25, 2020 at 12:56 PM Linus Torvalds
> wrote:
> >
> > And honestly, since this is all getting fairly late in the rc, and it
> > took longer than I thought, I think we should do the GFP_ATOMIC
> > approach for now - not
using rxe:
- Tear down the CQ pool before waiting for all references to go away
Jason Gunthorpe (1):
RDMA/core: Fix ordering of CQ pool destruction
drivers/infiniband/core/device.c | 6 --
1 file changed, 4 insertions(+), 2
On Thu, Sep 17, 2020 at 04:13:54PM +0800, Liu Shixin wrote:
> sizeof() when applied to a pointer typed expression should gives the
> size of the pointed data, even if the data is a pointer.
>
> Signed-off-by: Liu Shixin
> ---
> drivers/infiniband/hw/mlx5/counters.c | 4 ++--
> 1 file changed, 2
On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> > On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> > wrote:
> > >
> > > On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > > > The TPM event log is
On Thu, Sep 10, 2020 at 05:00:36PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi,
>
> This series mainly changes mlx4, mlx5, and mthca drivers to future
> change of QP allocation scheme.
>
> The rdmavt driver will be sent separately.
>
> Thanks
>
> Leon Romanovsky (10):
>
On Thu, Sep 24, 2020 at 02:34:18PM -0400, Peter Xu wrote:
> > >// RDONLY gup
> > >pin_user_pages(buf, !WRITE);
> > >// pte of buf duplicated on both sides
> > >fork();
> > >mprotect(buf, WRITE);
> > >*buf = 1;
> > >// buf page replaced as
On Thu, Sep 24, 2020 at 01:55:31PM -0400, Peter Xu wrote:
> On Thu, Sep 24, 2020 at 01:51:52PM -0300, Jason Gunthorpe wrote:
> > > Regarding the solution here, I think we can also cover read-only fast-gup
> > > too
> > > in the future - IIUC what we need to
On Thu, Sep 24, 2020 at 10:35:17AM -0400, Peter Xu wrote:
> If so, I'd hope you won't disagree that I still move the get_page() out of the
> "if (wp)". Not only it's a shared operation no matter whether "if (wp)" or
> not, but I'm afraid it would confuse future readers on a special ordering on
>
On Thu, Sep 24, 2020 at 09:44:09AM +0200, Jan Kara wrote:
> > After the page is pinned it is prevented from being freed and
> > recycled. After GUP has the pin it must check that the PTE still
> > points at the same page, otherwise it might have pinned a page that is
> > alreay free'd - and that
On Wed, Sep 23, 2020 at 11:24:09AM -0400, Peter Xu wrote:
> On Tue, Sep 22, 2020 at 09:05:05AM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 21, 2020 at 05:20:31PM -0400, Peter Xu wrote:
> > > Pinned pages shouldn't be write-protected when fork() happens, because
> >
On Wed, Sep 23, 2020 at 04:20:03PM +0200, Jan Kara wrote:
> I'd hate to take spinlock in the GUP-fast path. Also I don't think this is
> quite correct because GUP-fast-only can be called from interrupt context
> and page table locks are not interrupt safe.
Yes, IIRC, that is a key element of
On Tue, Sep 22, 2020 at 08:27:35PM -0400, Peter Xu wrote:
> On Tue, Sep 22, 2020 at 04:11:16PM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 22, 2020 at 01:54:15PM -0400, Peter Xu wrote:
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 8f3521be80ca..6591f3f
On Sun, Sep 20, 2020 at 01:26:17PM +0200, Julia Lawall wrote:
> sg_init_table zeroes its first argument, so the allocation of that argument
> doesn't have to.
>
> the semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression x,n,flags;
> @@
>
On Tue, Sep 22, 2020 at 12:11:01PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v3:
> * Removed the mlx4 SR-IOV patch in favour of more robust fix that not needed
> in
>this series.
> * Cut the eroginal series to already reviewed and standalone patches.
> v2:
>
601 - 700 of 4366 matches
Mail list logo
