Re: [PATCH v2] mm/gup: fix gup_fast with dynamic page table folding

2020-09-15 Thread Jason Gunthorpe
> Cc: # 5.2+ > Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast > code") > Reviewed-by: Gerald Schaefer > Reviewed-by: Alexander Gordeev > Signed-off-by: Vasily Gorbik > --- > v2: added brackets -> &(pgd) Reviewed-by: Jason Gunthorpe Regards, Jason

Re: [PATCH] mm/gup: fix gup_fast with dynamic page table folding

2020-09-11 Thread Jason Gunthorpe
On Fri, Sep 11, 2020 at 04:40:00PM -0300, Jason Gunthorpe wrote: > These would probably be better as static inlines though, as only s390 > compiles will type check pudp like this. Never mind, it must be a macro - still need brackets though Jason

Re: [PATCH] mm/gup: fix gup_fast with dynamic page table folding

2020-09-11 Thread Jason Gunthorpe
On Fri, Sep 11, 2020 at 09:03:06PM +0200, Vasily Gorbik wrote: > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index e8cbc2e795d5..e899d3506671 100644 > +++ b/include/linux/pgtable.h > @@ -1427,6 +1427,16 @@ typedef unsigned int pgtbl_mod_mask; > #define mm_pmd_folded(mm)

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-11 Thread Jason Gunthorpe
On Fri, Sep 11, 2020 at 09:09:39AM +0200, pet...@infradead.org wrote: > On Thu, Sep 10, 2020 at 06:59:21PM -0300, Jason Gunthorpe wrote: > > So, I suggest pXX_offset_unlocked() > > Urgh, no. Elsewhere in gup _unlocked() means it will take the lock > itself (get_user_pages_unloc

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-10 Thread Jason Gunthorpe
On Thu, Sep 10, 2020 at 07:57:49PM +0200, Gerald Schaefer wrote: > On Thu, 10 Sep 2020 10:02:33 -0300 > Jason Gunthorpe wrote: > > > On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote: > > > > > As Gerald mentioned, it is very difficult to explain i

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-10 Thread Jason Gunthorpe
On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote: > Or am I way off here, and it really is possible (aside from the current > s390 situation) to observe something that "is no longer a page table"? Yes, that is the issue. Remember there is no locking for GUP fast. While a page table

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-10 Thread Jason Gunthorpe
On Thu, Sep 10, 2020 at 12:32:05PM -0700, Linus Torvalds wrote: > Yeah, I get hung up on naming sometimes. I don't tend to care much > about private local variables ("i" is a perfectly fine variable name), > but these kinds of somewhat subtle cross-architecture definitions I > feel matter. One of

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-10 Thread Jason Gunthorpe
On Thu, Sep 10, 2020 at 10:35:38AM -0700, Linus Torvalds wrote: > On Thu, Sep 10, 2020 at 2:40 AM Alexander Gordeev > wrote: > > > > It is only gup_fast case that exposes the issue. It hits because > > pointers to stack copies are passed to gup_pXd_range iterators, not > > pointers to real page

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-10 Thread Jason Gunthorpe
On Thu, Sep 10, 2020 at 07:07:57PM +0200, Gerald Schaefer wrote: > I might have lost track a bit. Are we still talking about possible > functional impacts of either our current pagetable walking with s390 > (apart from gup_fast), or the proposed generic change (for s390, or > others?)? I'm

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-10 Thread Jason Gunthorpe
On Thu, Sep 10, 2020 at 03:28:03PM +0200, Gerald Schaefer wrote: > On Thu, 10 Sep 2020 10:02:33 -0300 > Jason Gunthorpe wrote: > > > On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote: > > > > > As Gerald mentioned, it is very difficult to explain i

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-10 Thread Jason Gunthorpe
On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote: > As Gerald mentioned, it is very difficult to explain in a clear way. > Hopefully, one could make sense ot of it. I would say the page table API requires this invariant: pud = pud_offset(p4d, addr); do {

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Jason Gunthorpe
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote: > fallthrough to a separate case/default label break; isn't very readable. > > Convert pseudo-keyword fallthrough; statements to a simple break; when > the next label is case or default and the only statement in the next > label block

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-09 Thread Jason Gunthorpe
On Wed, Sep 09, 2020 at 07:25:34PM +0200, Gerald Schaefer wrote: > I actually had to draw myself a picture to get some hold of > this, or rather a walk-through with a certain pud-crossing > range in a folded 3-level scenario. Not sure if I would have > understood my explanation above w/o that, but

Re: [RFC PATCH v2 2/3] mm: make pXd_addr_end() functions page-table entry aware

2020-09-08 Thread Jason Gunthorpe
On Mon, Sep 07, 2020 at 08:00:57PM +0200, Gerald Schaefer wrote: > From: Alexander Gordeev > > Unlike all other page-table abstractions pXd_addr_end() do not take > into account a particular table entry in which context the functions > are called. On architectures with dynamic page-tables

Re: [PATCH 0/8 v2] PCI: Align return values of PCIe capability and PCI accessors

2020-06-30 Thread Jason Gunthorpe
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote: > Bolarinwa Olayemi Saheed (8): > IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors > IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors Applied to rdma for-next thanks Jason

Re: [PATCH 00/17] spelling.txt: /decriptors/descriptors/

2020-06-15 Thread Jason Gunthorpe
On Tue, Jun 09, 2020 at 01:45:53PM +0100, Kieran Bingham wrote: > I wouldn't normally go through spelling fixes, but I caught sight of > this typo twice, and then foolishly grepped the tree for it, and saw how > pervasive it was. > > so here I am ... fixing a typo globally... but with an addition

Re: [PATCH 0/8 v2] PCI: Align return values of PCIe capability and PCI accessors

2020-06-15 Thread Jason Gunthorpe
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote: > From: Bolarinwa Olayemi Saheed > > > PATCH 1/8 to 7/8: > PCIBIOS_ error codes have positive values and they are passed down the > call heirarchy from accessors. For functions which are meant to return > only a negative

Re: [PATCH 08/12] docs: fix broken references to text files

2020-03-17 Thread Jason Gunthorpe
s/Kconfig | 6 +++--- > include/linux/mm.h | 4 ++-- > include/uapi/linux/ethtool_netlink.h | 2 +- > include/uapi/rdma/rdma_user_ioctl_cmds.h | 2 +- For the rdma files Acked-by: Jason Gunthorpe Jason

Re: [PATCH v3 0/7] Allow setting caching mode in arch_add_memory() for P2PDMA

2020-02-27 Thread Jason Gunthorpe
On Thu, Feb 27, 2020 at 09:55:04AM -0800, Dan Williams wrote: > On Thu, Feb 27, 2020 at 9:43 AM Jason Gunthorpe wrote: > > > > On Thu, Feb 27, 2020 at 10:21:50AM -0700, Logan Gunthorpe wrote: > > > > > > > > > On 2020-02-27 10:17 a.m., Jason Gunthorpe wr

Re: [PATCH v3 0/7] Allow setting caching mode in arch_add_memory() for P2PDMA

2020-02-27 Thread Jason Gunthorpe
On Thu, Feb 27, 2020 at 10:21:50AM -0700, Logan Gunthorpe wrote: > > > On 2020-02-27 10:17 a.m., Jason Gunthorpe wrote: > >> Instead of this, this series proposes a change to arch_add_memory() > >> to take the pgprot required by the mapping which allows us to &g

Re: [PATCH v3 0/7] Allow setting caching mode in arch_add_memory() for P2PDMA

2020-02-27 Thread Jason Gunthorpe
On Fri, Feb 21, 2020 at 11:24:56AM -0700, Logan Gunthorpe wrote: > Hi, > > This is v3 of the patchset which cleans up a number of minor issues > from the feedback of v2 and rebases onto v5.6-rc2. Additional feedback > is welcome. > > Thanks, > > Logan > > -- > > Changes in v3: > * Rebased

Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

2019-12-23 Thread Jason Gunthorpe
On Fri, Dec 20, 2019 at 04:32:13PM -0800, Dan Williams wrote: > > > There's already a limit, it's just a much larger one. :) What does "no > > > limit" > > > really mean, numerically, to you in this case? > > > > I guess I mean 'hidden limit' - hitting the limit and failing would > > be

Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

2019-12-20 Thread Jason Gunthorpe
On Thu, Dec 19, 2019 at 01:13:54PM -0800, John Hubbard wrote: > On 12/19/19 1:07 PM, Jason Gunthorpe wrote: > > On Thu, Dec 19, 2019 at 12:30:31PM -0800, John Hubbard wrote: > > > On 12/19/19 5:26 AM, Leon Romanovsky wrote: > > > > On Mon, Dec 16, 2019 at 02:25:

Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

2019-12-19 Thread Jason Gunthorpe
On Thu, Dec 19, 2019 at 12:30:31PM -0800, John Hubbard wrote: > On 12/19/19 5:26 AM, Leon Romanovsky wrote: > > On Mon, Dec 16, 2019 at 02:25:12PM -0800, John Hubbard wrote: > > > Hi, > > > > > > This implements an API naming change (put_user_page*() --> > > > unpin_user_page*()), and also

Re: [PATCH v7 07/24] IB/umem: use get_user_pages_fast() to pin DMA pages

2019-11-24 Thread Jason Gunthorpe
return -EINVAL; While we think this WARN_ON is probably bogus, resolving this will have to wait. Signed-off-by: Jason Gunthorpe --- drivers/infiniband/core/umem.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/umem.c b/dri

Re: [PATCH v7 07/24] IB/umem: use get_user_pages_fast() to pin DMA pages

2019-11-21 Thread Jason Gunthorpe
locked(), which takes the mmap_sem as needed. > > > > Reviewed-by: Jan Kara > > Reviewed-by: Jason Gunthorpe > > Reviewed-by: Ira Weiny > > Signed-off-by: John Hubbard > > Looks fine, > > Reviewed-by: Christoph Hellwig > > Jason, can you que

Re: [PATCH v5 12/24] IB/{core,hw,umem}: set FOLL_PIN via pin_user_pages*(), fix up ODP

2019-11-15 Thread Jason Gunthorpe
| 2 +- > 8 files changed, 13 insertions(+), 14 deletions(-) Ok Reviewed-by: Jason Gunthorpe Jason

Re: [PATCH v5 09/24] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM

2019-11-15 Thread Jason Gunthorpe
ch in turn > calls check_dax_vmas(). It's lightly explained in the comments as well. > > Thanks to Jason Gunthorpe for pointing out a clean way to fix this, > and to Dan Williams for helping clarify the DAX refactoring. > > Suggested-by: Jason Gunthorpe > Cc: Dan Williams >

Re: [PATCH v4 08/23] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM

2019-11-13 Thread Jason Gunthorpe
ch in turn > calls check_dax_vmas(). It's lightly explained in the comments as well. > > Thanks to Jason Gunthorpe for pointing out a clean way to fix this, > and to Dan Williams for helping clarify the DAX refactoring. > > Suggested-by: Jason Gunthorpe > Cc: Dan Williams >

Re: [PATCH v3 08/23] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM

2019-11-12 Thread Jason Gunthorpe
On Tue, Nov 12, 2019 at 02:45:51PM -0800, Dan Williams wrote: > On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote: > > > > On 11/12/19 12:43 PM, Jason Gunthorpe wrote: > > ... > > >> -} > > >> +ret = get_user_pages_remote(NULL

Re: [PATCH v3 11/23] IB/{core,hw,umem}: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()

2019-11-12 Thread Jason Gunthorpe
On Mon, Nov 11, 2019 at 04:06:48PM -0800, John Hubbard wrote: > @@ -542,7 +541,7 @@ static int ib_umem_odp_map_dma_single_page( > } > > out: > - put_user_page(page); > + put_page(page); > > if (remove_existing_mapping) { >

Re: [PATCH v3 08/23] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM

2019-11-12 Thread Jason Gunthorpe
gt; to take advantage of this, fixing a bug as a result: the VFIO caller > is logically a FOLL_LONGTERM user. > > Thanks to Jason Gunthorpe for pointing out a clean way to fix this. > > Suggested-by: Jason Gunthorpe > Cc: Jerome Glisse > Cc: Ira Weiny > Signed-

Re: [PATCH v3 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM

2019-11-12 Thread Jason Gunthorpe
On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote: > Hi, > > The cover letter is long, so the more important stuff is first: > > * Jason, if you or someone could look at the the VFIO cleanup (patch 8) > and conversion to FOLL_PIN (patch 18), to make sure it's use of > remote and

Re: [PATCH v2 07/18] infiniband: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()

2019-11-04 Thread Jason Gunthorpe
On Mon, Nov 04, 2019 at 02:03:43PM -0800, John Hubbard wrote: > On 11/4/19 12:57 PM, Jason Gunthorpe wrote: > > On Mon, Nov 04, 2019 at 12:48:13PM -0800, John Hubbard wrote: > >> On 11/4/19 12:33 PM, Jason Gunthorpe wrote: > >> ... > >>>> diff --git

Re: [PATCH v2 05/18] mm/gup: introduce pin_user_pages*() and FOLL_PIN

2019-11-04 Thread Jason Gunthorpe
On Mon, Nov 04, 2019 at 12:57:59PM -0800, John Hubbard wrote: > On 11/4/19 12:37 PM, Jason Gunthorpe wrote: > > On Mon, Nov 04, 2019 at 03:31:53PM -0500, Jerome Glisse wrote: > >>> Note for Jason: the (a) or (b) items are talking about the vfio case, > >>> which i

Re: [PATCH v2 07/18] infiniband: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()

2019-11-04 Thread Jason Gunthorpe
On Mon, Nov 04, 2019 at 12:48:13PM -0800, John Hubbard wrote: > On 11/4/19 12:33 PM, Jason Gunthorpe wrote: > ... > >> diff --git a/drivers/infiniband/core/umem.c > >> b/drivers/infiniband/core/umem.c > >> index 24244a2f68cc..c5a78d3e674b 100644 > >

Re: [PATCH v2 05/18] mm/gup: introduce pin_user_pages*() and FOLL_PIN

2019-11-04 Thread Jason Gunthorpe
On Mon, Nov 04, 2019 at 03:31:53PM -0500, Jerome Glisse wrote: > > Note for Jason: the (a) or (b) items are talking about the vfio case, which > > is > > one of the two call sites that now use pin_longterm_pages_remote(), and the > > other one is infiniband: > > > >

Re: [PATCH v2 07/18] infiniband: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()

2019-11-04 Thread Jason Gunthorpe
On Sun, Nov 03, 2019 at 01:18:02PM -0800, John Hubbard wrote: > Convert infiniband to use the new wrapper calls, and stop > explicitly setting FOLL_LONGTERM at the call sites. > > The new pin_longterm_*() calls replace get_user_pages*() > calls, and set both FOLL_LONGTERM and a new FOLL_PIN >

Re: [PATCH v2 05/18] mm/gup: introduce pin_user_pages*() and FOLL_PIN

2019-11-04 Thread Jason Gunthorpe
On Mon, Nov 04, 2019 at 12:09:05PM -0800, John Hubbard wrote: > Note for Jason: the (a) or (b) items are talking about the vfio case, which is > one of the two call sites that now use pin_longterm_pages_remote(), and the > other one is infiniband: > > drivers/infiniband/core/umem_odp.c:646:

Re: [PATCH v9 0/8] KVM: PPC: Driver to manage pages of secure guest

2019-09-25 Thread Jason Gunthorpe
On Wed, Sep 25, 2019 at 10:36:41AM +0530, Bharata B Rao wrote: > [The main change in this version is the introduction of new > locking to prevent concurrent page-in and page-out calls. More > details about this are present in patch 2/8] > > Hi, > > A pseries guest can be run as a secure guest on

Re: [PATCH v9 2/8] KVM: PPC: Move pages between normal and secure memory

2019-09-25 Thread Jason Gunthorpe
On Wed, Sep 25, 2019 at 10:36:43AM +0530, Bharata B Rao wrote: > Manage migration of pages betwen normal and secure memory of secure > guest by implementing H_SVM_PAGE_IN and H_SVM_PAGE_OUT hcalls. > > H_SVM_PAGE_IN: Move the content of a normal page to secure page > H_SVM_PAGE_OUT: Move the

Re: [PATCH v5 7/7] KVM: PPC: Ultravisor: Add PPC_UV config option

2019-07-10 Thread Jason Gunthorpe
On Wed, Jul 10, 2019 at 08:24:56AM -0500, janani wrote: > On 2019-07-09 05:25, Bharata B Rao wrote: > > From: Anshuman Khandual > > > > CONFIG_PPC_UV adds support for ultravisor. > > > > Signed-off-by: Anshuman Khandual > > Signed-off-by: Bharata B Rao > > Signed-off-by: Ram Pai > > [ Update

Re: [PATCH v5 1/7] kvmppc: HMM backend driver to manage pages of secure guest

2019-07-10 Thread Jason Gunthorpe
On Tue, Jul 09, 2019 at 01:55:28PM -0500, janani wrote: > > +int kvmppc_hmm_init(void) > > +{ > > + int ret = 0; > > + unsigned long size; > > + > > + size = kvmppc_get_secmem_size(); > > + if (!size) { > > + ret = -ENODEV; > > + goto out; > > + } > > + > > +

Re: [PATCH v2] tpm: tpm_ibm_vtpm: Fix unallocated banks

2019-07-08 Thread Jason Gunthorpe
On Mon, Jul 08, 2019 at 06:24:04PM -0400, Mimi Zohar wrote: > Hi Jarkko, > > On Mon, 2019-07-08 at 18:11 +0300, Jarkko Sakkinen wrote: > > On Sat, 2019-07-06 at 20:18 -0400, Nayna Jain wrote: > > > +/* > > > + * tpm_get_pcr_allocation() - initialize the chip allocated banks for > > > PCRs > > >

Re: [PATCH 11/16] mm: consolidate the get_user_pages* implementations

2019-06-25 Thread Jason Gunthorpe
On Tue, Jun 25, 2019 at 09:56:50AM +0200, Christoph Hellwig wrote: > On Fri, Jun 21, 2019 at 11:41:31AM -0300, Jason Gunthorpe wrote: > > > static bool gup_fast_permitted(unsigned long start, unsigned long end) > > > { > > > - return true; > > > + return

Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses

2019-06-21 Thread Jason Gunthorpe
On Fri, Jun 21, 2019 at 09:35:11AM -0600, Khalid Aziz wrote: > On 6/21/19 7:39 AM, Jason Gunthorpe wrote: > > On Tue, Jun 11, 2019 at 04:40:47PM +0200, Christoph Hellwig wrote: > >> This will allow sparc64 to override its ADI tags for > >> get_user_pages and get_user_p

Re: switch the remaining architectures to use generic GUP v3

2019-06-21 Thread Jason Gunthorpe
On Tue, Jun 11, 2019 at 04:40:46PM +0200, Christoph Hellwig wrote: > Hi Linus and maintainers, > > below is a series to switch mips, sh and sparc64 to use the generic > GUP code so that we only have one codebase to touch for further > improvements to this code. I don't have hardware for any of

Re: [PATCH 11/16] mm: consolidate the get_user_pages* implementations

2019-06-21 Thread Jason Gunthorpe
On Tue, Jun 11, 2019 at 04:40:57PM +0200, Christoph Hellwig wrote: > @@ -2168,7 +2221,7 @@ static void gup_pgd_range(unsigned long addr, unsigned > long end, > */ > static bool gup_fast_permitted(unsigned long start, unsigned long end) > { > - return true; > + return

Re: [PATCH 10/16] mm: rename CONFIG_HAVE_GENERIC_GUP to CONFIG_HAVE_FAST_GUP

2019-06-21 Thread Jason Gunthorpe
On Tue, Jun 11, 2019 at 04:40:56PM +0200, Christoph Hellwig wrote: > We only support the generic GUP now, so rename the config option to > be more clear, and always use the mm/Kconfig definition of the > symbol and select it from the arch Kconfigs. Looks OK to me Reviewed-by: Jason

Re: [PATCH 04/16] MIPS: use the generic get_user_pages_fast code

2019-06-21 Thread Jason Gunthorpe
(!cpu_has_dc_aliases) > + Today this check is only being done on the get_user_pages_fast() - after this patch it is also done for __get_user_pages_fast(). Which means __get_user_pages_fast is now non-functional on a range of MIPS CPUs, but that seems OK as far as I can tell, so: Reviewed-by:

Re: [PATCH 03/16] mm: lift the x86_32 PAE version of gup_get_pte to common code

2019-06-21 Thread Jason Gunthorpe
| 51 --- > 5 files changed, 52 insertions(+), 52 deletions(-) Yep, the sh and mips conversions look right too. Reviewed-by: Jason Gunthorpe > diff --git a/mm/Kconfig b/mm/Kconfig > index f0c76ba47695..fe51f104a9e0 100644 > --- a/mm/Kconfig > +++ b/mm/Kc

Re: [PATCH 02/16] mm: simplify gup_fast_permitted

2019-06-21 Thread Jason Gunthorpe
> --- > arch/s390/include/asm/pgtable.h | 8 +--- > arch/x86/include/asm/pgtable_64.h | 8 +--- > mm/gup.c | 17 +++-- > 3 files changed, 9 insertions(+), 24 deletions(-) Much cleaner Reviewed-by: Jason Gunthorpe Jason

Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses

2019-06-21 Thread Jason Gunthorpe
On Tue, Jun 11, 2019 at 04:40:47PM +0200, Christoph Hellwig wrote: > This will allow sparc64 to override its ADI tags for > get_user_pages and get_user_pages_fast. > > Signed-off-by: Christoph Hellwig > mm/gup.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses

2019-06-21 Thread Jason Gunthorpe
eletions(-) Reviewed-by: Jason Gunthorpe

Re: [PATCH] mm: add account_locked_vm utility function

2019-05-03 Thread Jason Gunthorpe
> Signed-off-by: Daniel Jordan > Cc: Alan Tull > Cc: Alexey Kardashevskiy > Cc: Alex Williamson > Cc: Andrew Morton > Cc: Benjamin Herrenschmidt > Cc: Christoph Lameter > Cc: Christophe Leroy > Cc: Davidlohr Bueso > Cc: Jason Gunthorpe > Cc: Mark Rutland >

Re: [PATCH 5/6] powerpc/mmu: drop mmap_sem now that locked_vm is atomic

2019-04-24 Thread Jason Gunthorpe
On Tue, Apr 23, 2019 at 07:15:44PM -0700, Davidlohr Bueso wrote: > On Wed, 03 Apr 2019, Daniel Jordan wrote: > > > On Wed, Apr 03, 2019 at 06:58:45AM +0200, Christophe Leroy wrote: > > > Le 02/04/2019 à 22:41, Daniel Jordan a écrit : > > > > With locked_vm now an atomic, there is no need to take

Re: [RESEND 4/7] mm/gup: Add FOLL_LONGTERM capability to GUP fast

2019-03-25 Thread Jason Gunthorpe
On Mon, Mar 25, 2019 at 02:23:15AM -0700, Ira Weiny wrote: > > > Unfortunately holding the lock is required to support FOLL_LONGTERM (to > > > check > > > the VMAs) but we don't want to hold the lock to be optimal (specifically > > > allow > > > FAULT_FOLL_ALLOW_RETRY). So I'm maintaining the

Re: [RESEND 4/7] mm/gup: Add FOLL_LONGTERM capability to GUP fast

2019-03-25 Thread Jason Gunthorpe
On Mon, Mar 25, 2019 at 01:42:26AM -0700, Ira Weiny wrote: > On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote: > > On Sun, Mar 17, 2019 at 7:36 PM wrote: > > > > > > From: Ira Weiny > > > > > > DAX pages were previously unprotected from longterm pins when users > > > called

Re: [PATCH 0/5] use pinned_vm instead of locked_vm to account pinned pages

2019-02-14 Thread Jason Gunthorpe
On Thu, Feb 14, 2019 at 01:46:51PM -0800, Ira Weiny wrote: > > > > Really unclear how to fix this. The pinned/locked split with two > > > > buckets may be the right way. > > > > > > Are you suggesting that we have 2 user limits? > > > > This is what RDMA has done since CL's patch. > > I don't

Re: [PATCH 0/5] use pinned_vm instead of locked_vm to account pinned pages

2019-02-14 Thread Jason Gunthorpe
On Thu, Feb 14, 2019 at 11:33:53AM -0800, Ira Weiny wrote: > > I think it had to do with double accounting pinned and mlocked pages > > and thus delivering a lower than expected limit to userspace. > > > > vfio has this bug, RDMA does not. RDMA has a bug where it can > > overallocate locked

Re: [PATCH V2 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

2019-02-13 Thread Jason Gunthorpe
On Wed, Feb 13, 2019 at 03:04:51PM -0800, ira.we...@intel.com wrote: > From: Ira Weiny > > To facilitate additional options to get_user_pages_fast() change the > singular write parameter to be gup_flags. So now we have: long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,

Re: [PATCH 1/5] vfio/type1: use pinned_vm instead of locked_vm to account pinned pages

2019-02-13 Thread Jason Gunthorpe
On Wed, Feb 13, 2019 at 01:03:30PM -0700, Alex Williamson wrote: > > PeterZ posted an RFC that addresses this point[1]. It kept pinned_vm and > > locked_vm accounting separate, but allowed the two to be added safely to be > > compared against RLIMIT_MEMLOCK. > > Unless I'm incorrect in the

Re: [PATCH 1/5] vfio/type1: use pinned_vm instead of locked_vm to account pinned pages

2019-02-11 Thread Jason Gunthorpe
On Mon, Feb 11, 2019 at 05:44:33PM -0500, Daniel Jordan wrote: > Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned > pages"), locked and pinned pages are accounted separately. Type1 > accounts pinned pages to locked_vm; use pinned_vm instead. > > pinned_vm recently became

Re: [PATCH 0/5] use pinned_vm instead of locked_vm to account pinned pages

2019-02-11 Thread Jason Gunthorpe
On Mon, Feb 11, 2019 at 05:44:32PM -0500, Daniel Jordan wrote: > Hi, > > This series converts users that account pinned pages with locked_vm to > account with pinned_vm instead, pinned_vm being the correct counter to > use. It's based on a similar patch I posted recently[0]. > > The patches are

Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]

2019-01-09 Thread Jason Gunthorpe
On Wed, Jan 09, 2019 at 04:09:02PM +1100, Benjamin Herrenschmidt wrote: > > POWER 8 firmware is good? If the link does eventually come back, is > > the POWER8's D3 resumption timeout long enough? > > > > If this doesn't lead to an obvious conclusion you'll probably need to > > connect to IBM's

Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]

2019-01-07 Thread Jason Gunthorpe
On Sun, Jan 06, 2019 at 09:43:46AM +1100, Benjamin Herrenschmidt wrote: > On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote: > > > > > Interesting. I've investigated this further, though I don't have as > > > many new clues as I'd like. The problem occurs reli

Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]

2019-01-05 Thread Jason Gunthorpe
On Fri, Jan 04, 2019 at 02:44:01PM +1100, David Gibson wrote: > On Thu, Dec 06, 2018 at 08:45:09AM +0200, Leon Romanovsky wrote: > > On Thu, Dec 06, 2018 at 03:19:51PM +1100, David Gibson wrote: > > > Mellanox ConnectX-5 IB cards (MT27800) seem to cause a call trace when > > > unbound from their

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

2018-09-24 Thread Jason Gunthorpe
On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote: > On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe wrote: > > > > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote: > > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > > > >

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

2018-09-18 Thread Jason Gunthorpe
On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote: > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > > > Acked-by: Darren Hart (VMware) > > > > > > As for a longer term solution, would it be possible to

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

2018-09-12 Thread Jason Gunthorpe
const struct file_operations uverbs_mmap_fops = { > .release = ib_uverbs_close, > .llseek = no_llseek, > .unlocked_ioctl = ib_uverbs_ioctl, > - .compat_ioctl = ib_uverbs_ioctl, > + .compat_ioctl = generic_compat_ioctl_ptrarg, > }; > > static struct ib_client uverbs_client = { For uverbs: Acked-by: Jason Gunthorpe It is very strange, this patch did not appear in the RDMA patchworks, I almost missed it :| Jason

Re: [PATCH 0/3] tty: hvc: latency break regression fixes

2018-09-05 Thread Jason Gunthorpe
th another. > > I think those went upstream via Michael's tree, but he's away > at the moment so if you would be able to consider them for > the tty tree that would be appreciated. Series works for me too, thanks. Tested-by: Jason Gunthorpe Jason

Re: Regression from patch 'tty: hvc: hvc_poll() break hv read loop'

2018-09-04 Thread Jason Gunthorpe
On Wed, Sep 05, 2018 at 07:15:29AM +1000, Nicholas Piggin wrote: > On Tue, 4 Sep 2018 11:48:08 -0600 > Jason Gunthorpe wrote: > > > Hi Nicholas, > > > > I am testing 4.19-rc2 and I see bad behavior with my qemu hvc0 > > console.. > > > > Runn

Regression from patch 'tty: hvc: hvc_poll() break hv read loop'

2018-09-04 Thread Jason Gunthorpe
Hi Nicholas, I am testing 4.19-rc2 and I see bad behavior with my qemu hvc0 console.. Running interactive with qemu (qemu-2.11.2-1.fc28) on the console providing hvc0, using options like: -nographic -chardev stdio,id=stdio,mux=on,signal=off -mon chardev=stdio

Re: RFC on writel and writel_relaxed

2018-03-29 Thread Jason Gunthorpe
On Thu, Mar 29, 2018 at 02:58:34PM +, David Laight wrote: > From: Jason Gunthorpe > > Sent: 29 March 2018 15:45 > ... > > > > When talking about ordering between the devices, the relevant question > > > > is what happens if the writel(DEVICE_BAR) tri

Re: RFC on writel and writel_relaxed

2018-03-29 Thread Jason Gunthorpe
On Thu, Mar 29, 2018 at 10:19:41AM +0100, Will Deacon wrote: > On Wed, Mar 28, 2018 at 10:57:32AM -0600, Jason Gunthorpe wrote: > > On Wed, Mar 28, 2018 at 11:13:45AM +0100, Will Deacon wrote: > > > On Wed, Mar 28, 2018 at 09:01:27PM +1100, Benjamin Herrenschmidt wrote: > >

Re: RFC on writel and writel_relaxed

2018-03-28 Thread Jason Gunthorpe
On Wed, Mar 28, 2018 at 11:13:45AM +0100, Will Deacon wrote: > On Wed, Mar 28, 2018 at 09:01:27PM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2018-03-28 at 11:55 +0200, Arnd Bergmann wrote: > > > > powerpc and ARM can't quite make them synchronous I think, but at least > > > > they should

Re: RFC on writel and writel_relaxed

2018-03-27 Thread Jason Gunthorpe
On Tue, Mar 27, 2018 at 10:42:00AM +0100, Will Deacon wrote: > On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote: > > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe <j...@ziepe.ca> wrote: > > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschm

Re: RFC on writel and writel_relaxed

2018-03-27 Thread Jason Gunthorpe
On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: > >> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: &g

Re: RFC on writel and writel_relaxed

2018-03-27 Thread Jason Gunthorpe
On Tue, Mar 27, 2018 at 08:22:55AM -0400, ok...@codeaurora.org wrote: > On 2018-03-27 07:23, Benjamin Herrenschmidt wrote: > >On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote: > >>> The interesting thing is that we do seem to have a whole LOT of these > >>> spurrious wmb before writel all

Re: RFC on writel and writel_relaxed

2018-03-26 Thread Jason Gunthorpe
On Tue, Mar 27, 2018 at 10:59:40AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2018-03-26 at 16:50 -0600, Jason Gunthorpe wrote: > > On Tue, Mar 27, 2018 at 09:36:11AM +1100, Benjamin Herrenschmidt wrote: > > > On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote: > >

Re: RFC on writel and writel_relaxed

2018-03-26 Thread Jason Gunthorpe
On Tue, Mar 27, 2018 at 09:36:11AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote: > > > Otherwise almost all drivers out there are broken which I very much > > > doubt :-) > > > > But.. Sinan is right, you look an

Re: RFC on writel and writel_relaxed

2018-03-26 Thread Jason Gunthorpe
On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: > > On 3/26/2018 5:30 PM, Arnd Bergmann wrote: > > > > But that was never a requirement of writel(), > > > > Documentation/memory-barriers.txt gives an explicit example

Re: RFC on writel and writel_relaxed

2018-03-26 Thread Jason Gunthorpe
On Mon, Mar 26, 2018 at 10:43:43PM +0200, Arnd Bergmann wrote: > On Mon, Mar 26, 2018 at 10:25 PM, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Mon, Mar 26, 2018 at 09:44:15PM +0200, Arnd Bergmann wrote: > >> On Mon, Mar 26, 2018 at 6:54 PM, Jason Gunthorpe <j...@zie

Re: RFC on writel and writel_relaxed

2018-03-26 Thread Jason Gunthorpe
On Mon, Mar 26, 2018 at 09:44:15PM +0200, Arnd Bergmann wrote: > On Mon, Mar 26, 2018 at 6:54 PM, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Mon, Mar 26, 2018 at 11:08:45AM +, David Laight wrote: > >> > > This is a super performance critical operation for most

Re: RFC on writel and writel_relaxed

2018-03-26 Thread Jason Gunthorpe
On Mon, Mar 26, 2018 at 11:08:45AM +, David Laight wrote: > > > This is a super performance critical operation for most drivers and > > > directly impacts network performance. > > Perhaps there ought to be writel_nobarrier() (etc) that never contain > any barriers at all. > This might mean

Re: RFC on writel and writel_relaxed

2018-03-23 Thread Jason Gunthorpe
On Fri, Mar 23, 2018 at 12:52:02AM +1100, Benjamin Herrenschmidt wrote: > > > - Make writel_relaxed() be a simple store without barriers, and > > > readl_relaxed() be "eieio, read, eieio", thus allowing write combining > > > to happen between successive writel_relaxed on WC space (no change on >

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

2018-03-18 Thread Jason Gunthorpe
On Sat, Mar 17, 2018 at 02:30:10PM -0400, Sinan Kaya wrote: > Somebody also has to take a task and work very hard to get rid of > __raw_writeX() > APIs in drivers/net directory. It looked like a very common practice though > it clearly violates multiarch portability concerns Jason and Deve

Re: [PATCH] tpm: vtpm: constify vio_device_id

2017-08-18 Thread Jason Gunthorpe
On Fri, Aug 18, 2017 at 09:32:46PM +1000, Michael Ellerman wrote: > >> drivers/char/tpm/tpm_ibmvtpm.c | 2 +- > > Who merges changes for this driver? I assume it's Jarkko? Yes Jason

Re: [PATCH] tpm: vtpm: constify vio_device_id

2017-08-17 Thread Jason Gunthorpe
v <arvind.yadav...@gmail.com> Reviewed-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> > drivers/char/tpm/tpm_ibmvtpm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c > index f0

Re: ibmvtpm byteswapping inconsistency

2017-01-26 Thread Jason Gunthorpe
On Thu, Jan 26, 2017 at 09:22:48PM +0100, Michal Such??nek wrote: > This is repeated a few times in the driver so I added memset to quiet > gcc and make behavior deterministic in case the unused fields get some > meaning in the future. Yep, reserved certainly needs to be zeroed.. Can you send a

Re: [PATCH v7] powerpc: Do not make the entire heap executable

2016-12-12 Thread Jason Gunthorpe
On Wed, Dec 07, 2016 at 02:15:27PM -0800, Kees Cook wrote: > Can you resend this patch with /proc/$pid/maps output showing the > before/after effects of this change also included here? Showing that > reduction in executable mapping should illustrate the benefit of > avoiding having the execute bit

Re: [PATCH v6] powerpc: Do not make the entire heap executable

2016-10-20 Thread Jason Gunthorpe
hat.com> wrote: > >>> On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt, > >>> or with a toolchain which defaults to it) look like this: > > ... > >>> > >>> Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresea

Re: [PATCH v5] powerpc: Do not make the entire heap executable

2016-09-27 Thread Jason Gunthorpe
On Wed, Sep 28, 2016 at 11:42:11AM +1000, Michael Ellerman wrote: > But this is not really a powerpc patch, and I'm not an ELF expert. So > I'm not comfortable merging it via the powerpc tree. It doesn't look > like we really have a maintainer for binfmt_elf.c, so I'm not sure who > should be

Re: [PATCH v4] powerpc: Do not make the entire heap executable

2016-08-22 Thread Jason Gunthorpe
On Mon, Aug 22, 2016 at 08:37:05PM +0200, Denys Vlasenko wrote: > >Is this going to break any application ? I am asking because you > >mentioned the patch is lightly tested. > > I booted powerpc64 machine with RHEL7 installation, > it did not catch fire. When I authored the original patch my

Re: [PATCH] powerpc: Do not make the entire heap executable

2016-08-02 Thread Jason Gunthorpe
On Mon, Aug 01, 2016 at 11:07:21PM +0200, Denys Vlasenko wrote: > On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt, > or with a toolchain which defaults to it) look like this: Hi Denys, Thanks for resurrecting this, I am still interested here, we have been using this

Re: [PATCH V2] powerpc/infiniband: Use cache inhibitted and guarded mapping on powerpc

2016-04-22 Thread Jason Gunthorpe
On Fri, Apr 22, 2016 at 08:47:56AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2016-04-20 at 03:58 -0400, Aneesh Kumar K.V wrote: > > The driver was requesting for a writethrough mapping. But with thoses > > flags we will end up with a SAO mapping because we now have memory > > conherence

[PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode

2013-11-04 Thread Jason Gunthorpe
is not called, and the bootloader has not set the correct address then the driver will fail to function. Tested on Kirkwood. Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com --- Cc: David Miller da...@davemloft.net Cc: Lennert Buytenhek buyt...@wantstofly.org Cc: Jason Cooper ja

Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?

2013-10-28 Thread Jason Gunthorpe
On Mon, Oct 28, 2013 at 01:03:43PM -0500, Joel Schopp wrote: On 10/27/2013 05:06 PM, Peter H?we wrote: Hi, I was wondering if anyone here on this list still has a machine with an old ATMEL TPM (trusted platform module) lying around? From the kconfig entry it becomes evident that it

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

2013-05-24 Thread Jason Gunthorpe
On Fri, May 24, 2013 at 12:46:36PM -0400, Jason Cooper wrote: Why are you not keen on this? It seems like normal device driver practice, that is what the data field of of_device_id is typically used for.. I'm not keen on it because we don't have a document saying All kirkwood SoCs need

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

2013-05-23 Thread Jason Gunthorpe
On Thu, May 23, 2013 at 12:01:11PM -0400, Jason Cooper wrote: + /* Kirkwood resets some registers on gated clocks. Especially + * CLK125_BYPASS_EN must be cleared but is not available on + * all other SoCs/System Controllers using this driver. + */ + if

  1   2   >