QXdaw
g9XLuqaxKRxp2lnuoVdFK0T90Hfu/71T+S8asZZYhH9zHY2Wzhgp1VkR07ZtXmMNqI
W/lB00RAVtj3Q==
I looked at that, and the equivalent iov_iter_get_pages* and related stuff was
just EXPORT_SYMBOL, so I tried to match that. But if it needs to be _GPL then
that's fine too...
thanks,
--
Jo
...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: John Hubbard
---
OK, one more try, this time actually handling the _USER_MAPPED vs.
_KERNEL_MAPPED pages!
thanks,
John Hubbard
NVIDIA
drivers/tee/tee_shm.c | 32 +++-
1 file
ify it now.
Signed-off-by: John Hubbard
---
OK, here's a v2 that does EXPORT_SYMBOL_GPL, instead of EXPORT_SYMBOL,
that's the only change from v1. That should help give this patch a
clear bill of passage. :)
thanks,
John Hubbard
NVIDIA
fs/ceph/file.c | 3 +--
include/linu
On 8/24/20 6:54 PM, Al Viro wrote:
On Fri, Aug 21, 2020 at 09:20:54PM -0700, John Hubbard wrote:
Direct IO behavior:
ITER_IOVEC:
pin_user_pages_fast();
break;
ITER_KVEC:// already elevated page refcount, leave alone
ITER_BVEC:// already elevated page
On 8/24/20 7:07 PM, Al Viro wrote:
On Tue, Aug 25, 2020 at 02:54:28AM +0100, Al Viro wrote:
On Fri, Aug 21, 2020 at 09:20:54PM -0700, John Hubbard wrote:
Direct IO behavior:
ITER_IOVEC:
pin_user_pages_fast();
break;
ITER_KVEC:// already elevated page refcount
On 8/24/20 7:22 PM, Al Viro wrote:
On Mon, Aug 24, 2020 at 07:07:02PM -0700, John Hubbard wrote:
On 8/24/20 6:54 PM, Al Viro wrote:
On Fri, Aug 21, 2020 at 09:20:54PM -0700, John Hubbard wrote:
Direct IO behavior:
ITER_IOVEC:
pin_user_pages_fast();
break
On 8/25/20 1:32 AM, Jens Wiklander wrote:
On Mon, Aug 24, 2020 at 02:11:25PM -0700, John Hubbard wrote:
...
OK, one more try, this time actually handling the _USER_MAPPED vs.
_KERNEL_MAPPED pages!
thanks,
John Hubbard
NVIDIA
Looks good and it works too! :-) I've tested it on my Hikey
On 9/1/20 1:14 PM, Souptick Joarder wrote:
Hi John,
On Tue, Sep 1, 2020 at 4:28 AM John Hubbard wrote:
On 8/31/20 3:07 PM, Souptick Joarder wrote:
First, when memory allocation for sg_list_unaligned failed, there
is a bug of calling put_pages() as we haven't pinned any pages.
"
these changes, minor update in documentation.
Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor
management driver")
Signed-off-by: Souptick Joarder
Reviewed-by: Dan Carpenter
Reviewed-by: John Hubbard
---
This looks good to me.
thanks,
--
John Hubbard
NVIDIA
v2:
A
ptep, pte)
static inline void native_set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep , pte_t pte)
{
native_set_pte(ptep, pte);
}
This type of abstraction has worked out very well, IMHO.
thanks,
--
John Hubbard
NVIDIA
On 9/4/20 6:16 PM, Souptick Joarder wrote:
Hi Andrew,
On Wed, Sep 2, 2020 at 3:00 AM John Hubbard wrote:
On 9/1/20 2:21 PM, Souptick Joarder wrote:
First, when memory allocation for sg_list_unaligned failed, there
is a bug of calling put_pages() as we haven't pinned any pages.
Secon
On 8/29/20 7:54 AM, Christoph Hellwig wrote:
On Sat, Aug 29, 2020 at 01:08:51AM -0700, John Hubbard wrote:
pin_user_page() is the FOLL_PIN equivalent of get_page().
This was always a missing piece of the pin/unpin API calls (early
reviewers of pin_user_pages() asked about it, in fact), but
On 8/29/20 7:58 AM, Christoph Hellwig wrote:
On Sat, Aug 29, 2020 at 01:08:52AM -0700, John Hubbard wrote:
...
@@ -1280,7 +1281,11 @@ static inline ssize_t __pipe_get_pages(struct iov_iter
*i,
maxsize = n;
n += *start;
while (n > 0) {
- get_page(*pa
will run one bio_put() against the BIO.
Nit: the ant and the will still fit on the previous line.
Sorry about that, *usually* my text editor does the Right Thing for
those, I must have interfered with the natural flow of things. :)
thanks,
--
John Hubbard
NVIDIA
s are definitely welcome
here.
thanks,
--
John Hubbard
NVIDIA
g/kvm/20190724061750.ga19...@infradead.org/
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Cc: Christoph Hellwig
Cc: Al Viro
Signed-off-by: John Hubbard
---
block/bio.c | 24
block/blk-map.c |
c: Al Viro
Signed-off-by: John Hubbard
---
include/linux/uio.h | 5 ++
lib/iov_iter.c | 113
2 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 3835a8a8e9ea..e44eed12afdf 100644
---
gs to pin_user_page*() and unpin_user_page*().
[1] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
[2] Documentation/core-api/pin_user_pages.rst
Cc: Christoph Hellwig
Signed-off-by: John Hubbard
---
include/linux/mm.h | 2 ++
mm/gup.c
page(), so it's already done there.
[1] https://lore.kernel.org/kvm/20190724061750.ga19...@infradead.org/
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
John Hubbard (3):
mm/gup: introduce pin_page()
iov_iter: introduce iov_ite
On 8/31/20 9:52 AM, Ira Weiny wrote:
On Mon, Aug 31, 2020 at 12:14:39AM -0700, John Hubbard wrote:
@@ -1113,8 +1113,8 @@ int bio_iov_iter_get_pages(struct bio *bio, struct
iov_iter *iter)
} else {
if (is_bvec)
ret
n situations like this, but that's beyond the scope of
your work here.
thanks,
--
John Hubbard
NVIDIA
enter
Reviewed-by: John Hubbard
Few questions ->
First, there are minor updates from v2 -> v3 other than addressing your
review comments in v2. Would you like to review it again?
I reviewed it again.
Second, I think, as per Documentation/core-api/pin_user_pages.rst,
this is cas
a
Cc: Kirill A. Shutemov
Signed-off-by: John Hubbard
---
Hi,
I'm assuming that a fix is not required for -stable, but let me know if
others feel differently. The dump_page() code has changed a lot in that
area.
Changes since v1 [1]:
1) Rebased onto mmotm
2) Used a simpler head_*count()
() with FOLL_LONGTERM,
mm/gup_benchmark.c seems to the only exception in which FOLL_PIN is not
a prerequisite to FOLL_LONGTERM.
Cc: John Hubbard
Cc: Jan Kara
Cc: Jérôme Glisse
Cc: "Matthew Wilcox (Oracle)"
Cc: Al Viro
Cc: Christoph Hellwig
Cc: Dan Williams
Cc: Dave Chinner
Cc: Jason Gun
: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
--
v2: Use
nor Case 2, it may still require
FOLL_PIN, for patterns like this:
Correct (uses FOLL_PIN calls):
pin_user_pages()
write to the data within the pages
unpin_user_pages()
thanks,
--
John Hubbard
NVIDIA
+ if (npages != 1)
+ return -EFAULT;
+
On 10/27/20 6:15 AM, Jason Gunthorpe wrote:
On Tue, Oct 27, 2020 at 10:33:01AM +0100, Jan Kara wrote:
On Fri 23-10-20 21:44:17, John Hubbard wrote:
On 10/23/20 5:19 PM, Jason Gunthorpe wrote:
+ start += (unsigned long)nr_pinned << PAGE_SHIFT;
+ pages += nr_pinned;
+
On 10/27/20 11:00 PM, John Hubbard wrote:
On 10/27/20 6:15 AM, Jason Gunthorpe wrote:
On Tue, Oct 27, 2020 at 10:33:01AM +0100, Jan Kara wrote:
On Fri 23-10-20 21:44:17, John Hubbard wrote:
On 10/23/20 5:19 PM, Jason Gunthorpe wrote:
...
I'll fix up that one above (using your Report
.
And maybe it can go further, at some point, but that's a good way to start.
I'm leaning toward just sending out a small series to do that, unless there
are objections and/or better ways to improve this area...
thanks,
--
John Hubbard
NVIDIA
On 10/22/20 4:49 AM, Matthew Wilcox wrote:
On Tue, Oct 20, 2020 at 01:25:59AM -0700, John Hubbard wrote:
Should copy_to_guest() use pin_user_pages_unlocked() instead of gup_unlocked?
We wrote a "Case 5" in Documentation/core-api/pin_user_pages.rst, just for this
situation, I think
t care. :)
- if (nr_pinned > 0) {
- if (ret < 0)
- ret = nr_pinned;
- else
- ret += nr_pinned;
- }
+ if (nr_pinned)
+ return nr_pinned;
+ return ret;
}
-
- return ret;
+ return ret + nr_pinned;
}
/**
* get_user_pages_fast_only() - pin user pages in memory
thanks,
--
John Hubbard
NVIDIA
On 10/25/20 9:21 PM, Matthew Wilcox wrote:
On Thu, Oct 22, 2020 at 12:58:14PM -0700, John Hubbard wrote:
On 10/22/20 4:49 AM, Matthew Wilcox wrote:
On Tue, Oct 20, 2020 at 01:25:59AM -0700, John Hubbard wrote:
Should copy_to_guest() use pin_user_pages_unlocked() instead of gup_unlocked?
We
s rid of one special rule already.
Signed-off-by: John Hubbard
Cc: Jérôme Glisse
Cc: Jonathan Corbet
Cc: Ralph Campbell
Cc: Shuah Khan
---
tools/testing/selftests/vm/Makefile | 10 --
tools/testing/selftests/vm/gup_test.c | 1 -
2 files changed, 4 insertions(+), 7 deletions(-)
cation down to about 1.0
sec. This should still provide a reasonable smoke test, while staying
within a nominal time budget of around 1 second or so per test. And this
brings the overall running time of run_vmtests.sh down to 11 second.
Cc: Mike Rapoport
Cc: Shuah Khan
Signed-off-by: John Hubbard
-t: use THP pages
-F 1:use pin_user_pages() instead of get_user_pages()
0 19 0x1000: dump pages 0, 19, and 4096
Signed-off-by: John Hubbard
Cc: Jérôme Glisse
Cc: Jonathan Corbet
Cc: Ralph Campbell
Cc: Shuah Khan
---
mm/Kconfig
nteger type for cmd, now that it's being compared
Otherwise it doesn't work, because in this case cmd is about 3 billion,
which is the perfect size for problems with signed vs unsigned int.
Signed-off-by: John Hubbard
Cc: Jérôme Glisse
Cc: Jonathan Corbet
Cc: Ralph
n two files, one for inclusion in hmm-test.c
(local_config.h), and one for inclusion in the Makefile (local_config.mk).
Signed-off-by: John Hubbard
Cc: Ralph Campbell
Cc: Jérôme Glisse
Cc: Jonathan Corbet
Cc: Shuah Khan
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/sel
, but this low-level, kernel-developer-oriented selftests/vm
system is very much not subject to ABI stability. So "expansion" and
"reserved" fields are unnecessary here.
Signed-off-by: John Hubbard
Cc: Jérôme Glisse
Cc: Jonathan Corbet
Cc: Ralph Campbell
Cc: Shuah Khan
Rename to *.sh, in order to match the conventions of all of the other
items in selftest/vm.
The only reason not to use a .sh suffix a shell script like this, might be
to make it look more like a normal program, but that's not an issue here.
Signed-off-by: John Hubbard
Cc: Jérôme Gliss
sh.
c) Other minor assorted improvements.
[1] v2 is here:
https://lore.kernel.org/linux-doc/20200929212747.251804-1-jhubb...@nvidia.com/
[2]
https://lore.kernel.org/r/CAHk-=wgh-tmphly3juehx7y2fwh3d+nmbqvs__azm6-oorq...@mail.gmail.com
John Hubbard (9):
mm/gup_benchmark: rename to mm/gup_test
selftes
Run benchmarks on the _fast variants of gup and pup, as originally
intended.
Run the new gup_test sub-test: dump pages. In addition to exercising the
dump_page() call, it also demonstrates the various options you can use to
specify which pages to dump, and how.
Signed-off-by: John Hubbard
Cc
importantly,
however, subsequent patches are about to add some functionality that is
non-benchmark related.
Closely related changes:
* Kconfig: in addition to renaming the options from GUP_BENCHMARK to
GUP_TEST, update the help text to reflect that it's no longer a
benchmark-only test.
Signed
Despite a comment that said that page fault accounting would be charged
to whatever task_struct* was passed into __access_remote_vm(), the tsk
argument was actually unused.
Delete both the comment, and the argument.
Signed-off-by: John Hubbard
Cc: Oleg Nesterov
---
Hi,
Just something that
On 10/26/20 6:28 AM, Matthew Wilcox wrote:
On Sun, Oct 25, 2020 at 09:44:07PM -0700, John Hubbard wrote:
On 10/25/20 9:21 PM, Matthew Wilcox wrote:
I don't think the page pinning approach is ever valid. For file
Could you qualify that? Surely you don't mean that the entire pin_
can be streamlined a bit
No functional change.
Signed-off-by: Jason Gunthorpe
---
mm/gup.c | 99 ++--
1 file changed, 54 insertions(+), 45 deletions(-)
Everything still looks correct.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
below about this:
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Gliss
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: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Arnd Bergmann
Cc:
On 10/31/20 7:45 AM, Daniel Vetter wrote:
On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote:
On 10/30/20 3:08 AM, Daniel Vetter wrote:
...
By removing this check from this location, and changing from
pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up
losing the check
On 11/1/20 2:30 AM, Daniel Vetter wrote:
On Sun, Nov 1, 2020 at 6:22 AM John Hubbard wrote:
On 10/31/20 7:45 AM, Daniel Vetter wrote:
On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote:
On 10/30/20 3:08 AM, Daniel Vetter wrote:
...
By removing this check from this location, and changing
accepted, and the maintainer will
eventually merge it", and I left it at that. It's still desirable.
thanks,
--
John Hubbard
NVIDIA
ify it now.
Signed-off-by: John Hubbard
---
fs/ceph/file.c | 3 +--
include/linux/uio.h | 3 ++-
lib/iov_iter.c | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index d51c3f2fdca0..d3d7dd957390 100644
--- a/fs/ceph/file.c
+++
.
[1] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
[2] Documentation/core-api/pin_user_pages.rst
Signed-off-by: John Hubbard
---
include/linux/mm.h | 2 ++
mm/gup.c | 30 ++
2 files changed, 32 insertions(+)
diff
https://lwn.net/Articles/807108/
Signed-off-by: John Hubbard
---
block/bio.c | 24
block/blk-map.c | 6 +++---
fs/direct-io.c | 28 ++--
fs/iomap/direct-io.c | 2 +-
4 files changed, 30 insertions(+), 30 deletions(-)
routines that specifically call one or the other systems, for both page
acquisition and page release.
Signed-off-by: John Hubbard
---
include/linux/uio.h | 5 +++
lib/iov_iter.c | 80 +
2 files changed, 85 insertions(+)
diff --git a/include
moment include: net, crypto, cifs, ceph, vhost, fuse, nfs/direct,
vhost/scsi.
About-to-be-converted sites (in a subsequent patch) are: Direct IO for
filesystems that use the generic read/write functions.
[1] https://lore.kernel.org/kvm/20190724061750.ga19...@infradead.org/
[2] "Explicit pin
O_FOLL_PIN whenever pin_user_pages_fast() is used, and check for
BIO_FOLL_PIN before using unpin_user_page().
Signed-off-by: John Hubbard
---
block/bio.c | 9 +++--
block/blk-map.c | 3 ++-
fs/direct-io.c| 4 ++--
include/linux/blk_types.h | 5 +++--
inc
On 8/22/20 11:25 PM, Christoph Hellwig wrote:
On Fri, Aug 21, 2020 at 09:20:58PM -0700, John Hubbard wrote:
Add a new BIO_FOLL_PIN flag to struct bio, whose "short int" flags field
was full, thuse triggering an expansion of the field from 16, to 32
bits. This allows for a nice as
er splitting, a migration retry was used for it's sub-pages.
Just a documentation nit: "its sub-pages", not "it's sub-pages".
thanks,
--
John Hubbard
NVIDIA
On 10/9/20 12:59 AM, Daniel Vetter wrote:
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc
less than
ret == nr_frames. And the whole partially pinned region idea turns out
to be just not useful for almost everyone, from what I recall of the gup/pup
call sites. So I wonder if we should just have get_vaddr_frames do the
cleanup here and return -EFAULT, if ret != nr_frames ?
thanks,
--
John Hubbard
NVIDIA
VERSION < 11
# error Sorry, your version of Clang is too old - please use 10.0.1 or newer.
#endif
+#endif
/* Compiler specific definitions for Clang compiler */
thanks,
--
John Hubbard
NVIDIA
ct pin counts for huge pages")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
...but that commit happened in April, 2020. Surely if this were a serious issue
we
would have some other indication...is this worth following up on?? I'm inclined
to
ignore it, hon
understandable? :)
Make alot more sense to me..
I think this patch needs to do something about the naming..
A third counter also seems like the tipping point, to me.
thanks,
--
John Hubbard
NVIDIA
the __do_ prefix instead.
Note, a plain "__" prefix is not used since seqlock.h already uses it
for some of its exported functions; e.g. __read_seqcount_begin() and
__read_seqcount_retry().
Reported-by: Jason Gunthorpe
Reported-by: John Hubbard
Reported-by: Linus Torvalds
Lin
age, get_futex_key requires a
* get_user_pages_fast_only implementation that can pin pages. Thus it's still
* useful to have gup_huge_pmd even if we can't operate on ptes.
*/
thanks,
--
John Hubbard
NVIDIA
On 11/8/20 12:37 AM, Barry Song wrote:
Without DEBUG_FS, all the code in gup_test becomes meaningless. For sure
kernel provides debugfs stub while DEBUG_FS is disabled, but the point
here is that GUP_TEST can do nothing without DEBUG_FS.
Cc: John Hubbard
Cc: Ralph Campbell
Cc: Randy Dunlap
t;official API for general use", also identifying
those as such.
c) A comment about what makes "raw" actually raw, for seqlock.
Since I'm proposing new work, I'll also offer to help, perhaps by putting
together
a small patch to get it kicked off, if you approve of the idea.
thanks,
--
John Hubbard
NVIDIA
/O RESET_REG.
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
oliver.s...@intel.com
thanks,
--
John Hubbard
NVIDIA
ly, and I'm not
seeing a pud_mkhugespecial anywhere. So not sure this works, but probably
just me missing something again.
It means ioremap can't create an IO page PUD, it has to be broken up.
Does ioremap even create anything larger than PTEs?
From my reading, yes. See ioremap_try_hug
On 11/4/20 2:05 AM, Barry Song wrote:
Without DEBUG_FS, all the code in gup_benchmark becomes meaningless.
For sure kernel provides debugfs stub while DEBUG_FS is disabled, but
the point here is that GUP_BENCHMARK can do nothing without DEBUG_FS.
Cc: John Hubbard
Cc: Ralph Campbell
Inspired
On 11/7/20 12:24 AM, Souptick Joarder wrote:
Fixed typo s/Poiner/Pointer
Fixes: 5b636857fee6 ("TOMOYO: Allow using argv[]/envp[] of execve() as
conditions.")
Signed-off-by: Souptick Joarder
Cc: John Hubbard
---
security/tomoyo/domain.c | 2 +-
1 file changed, 1 insertion(+),
, to keep us on the straight and narrow, just in case
I'm misunderstanding something.
[1] https://lore.kernel.org/r/e78fb7af-627b-ce80-275e-51f97f1f3...@nvidia.com
thanks,
--
John Hubbard
NVIDIA
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
On 11/7/20 11:05 AM, Song Bao Hua (Barry Song) wrote:
-Original Message-
From: John Hubbard [mailto:jhubb...@nvidia.com]
...
config GUP_BENCHMARK
bool "Enable infrastructure for get_user_pages() and related calls
benchmarking"
+ depends on DEBUG_FS
I thi
On 11/7/20 1:04 AM, John Hubbard wrote:
On 11/7/20 12:24 AM, Souptick Joarder wrote:
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].
On 11/7/20 2:20 PM, Randy Dunlap wrote:
On 11/7/20 11:16 AM, John Hubbard wrote:
On 11/7/20 11:05 AM, Song Bao Hua (Barry Song) wrote:
-Original Message-
From: John Hubbard [mailto:jhubb...@nvidia.com]
...
config GUP_BENCHMARK
bool "Enable infrastructur
On 11/7/20 4:24 PM, Randy Dunlap wrote:
On 11/7/20 4:03 PM, John Hubbard wrote:
On 11/7/20 2:20 PM, Randy Dunlap wrote:
On 11/7/20 11:16 AM, John Hubbard wrote:
On 11/7/20 11:05 AM, Song Bao Hua (Barry Song) wrote:
...
OK, thanks, I see how you get that list now.
JFTR, those are not 42
On 11/7/20 5:13 PM, Tetsuo Handa wrote:
On 2020/11/08 4:17, John Hubbard wrote:
On 11/7/20 1:04 AM, John Hubbard wrote:
On 11/7/20 12:24 AM, Souptick Joarder wrote:
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] &
On 11/7/20 6:58 PM, Song Bao Hua (Barry Song) wrote:
On 11/7/20 2:20 PM, Randy Dunlap wrote:
On 11/7/20 11:16 AM, John Hubbard wrote:
On 11/7/20 11:05 AM, Song Bao Hua (Barry Song) wrote:
From: John Hubbard [mailto:jhubb...@nvidia.com]
...
But if you really disagree, then I'd go with,
On 11/7/20 7:14 PM, John Hubbard wrote:
On 11/7/20 6:58 PM, Song Bao Hua (Barry Song) wrote:
On 11/7/20 2:20 PM, Randy Dunlap wrote:
On 11/7/20 11:16 AM, John Hubbard wrote:
On 11/7/20 11:05 AM, Song Bao Hua (Barry Song) wrote:
From: John Hubbard [mailto:jhubb...@nvidia.com]
...
But if you
abled"
depends on !GUP_TEST && !DEBUG_FS
Sweet--I just applied that here, and it does exactly what I wanted: puts a nice
clear
message on the "make menuconfig" screen. No more hidden item. Brilliant!
Let's go with that, shall we?
thanks,
--
John Hubbard
NVIDIA
On 11/7/20 8:12 PM, Tetsuo Handa wrote:
On 2020/11/08 11:17, John Hubbard wrote:
Excuse me, but Documentation/core-api/pin_user_pages.rst says
"CASE 5: Pinning in order to _write_ to the data within the page"
while tomoyo_dump_page() is for "_read_ the data within the page&
nd it quite difficult, having options appear and disappear on me,
in this system. If they all had this "comment" behavior by default, to show up
as a placeholder, I think it would be a better user experience.
thanks,
--
John Hubbard
NVIDIA
On 11/8/20 7:41 PM, Souptick Joarder wrote:
On Sat, Nov 7, 2020 at 2:27 PM John Hubbard wrote:
On 11/7/20 12:24 AM, Souptick Joarder wrote:
Fixed typo s/Poiner/Pointer
Fixes: 5b636857fee6 ("TOMOYO: Allow using argv[]/envp[] of execve() as
conditions.")
Signed-off-by: Souptick J
ossibly future flags itself, I'd
lean toward making it its own new syscall, maybe:
compact_huge_pages(nbytes or npages, flags /* page size, etc */);
...thus leaving madvise() and it's remaining flags still available, to
further refine things.
thanks,
--
John Hubbard
NVIDIA
: Souptick Joarder
Cc: John Hubbard
Cc: Ira Weiny
Cc: Dan Carpenter
---
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
drivers/misc/mic/scif/scif_rma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic
t get rid of the get_user_pages*() side of it. But the pin
count will need to remain, in order to discern between DMA pins and
temporary refcount boosts.
thanks,
--
John Hubbard
NVIDIA
nt, but I didn't want to completely
miss the opportunity to make it a tiny bit cleaner to the reader.
thanks,
--
John Hubbard
NVIDIA
On 9/21/20 4:53 PM, John Hubbard wrote:
On 9/21/20 2:17 PM, Peter Xu wrote:
(Commit message collected from Jason Gunthorpe)
Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
Not yet, it doesn't. :) More:
track if the mm_struct has ever been used
On 9/21/20 3:27 PM, Jann Horn wrote:
On Tue, Sep 22, 2020 at 12:18 AM John Hubbard wrote:
On 9/21/20 2:55 PM, Jann Horn wrote:
On Mon, Sep 21, 2020 at 11:20 PM Peter Xu wrote:
...
Ah... the documentation you linked implies that FOLL_WRITE should more
or less imply FOLL_PIN? I didn&#
wind?
It seems like if you could do a check near the beginning of this routine, and
handle it there, with less unwinding? In fact, after taking only the src_ptl,
the check could be made, right?
thanks,
--
John Hubbard
NVIDIA
at their
contents are unstable. Even if pXd_none()==true.
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"?
thanks,
--
John Hubbard
NVIDIA
On 9/10/20 3:11 PM, Jason Gunthorpe wrote:
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 t
et's fix up the callers.
thanks,
--
John Hubbard
NVIDIA
ng incorrect
values such as an *occasionally* incomplete LDLIBS value.
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/Makefile | 12
1 file changed, 12 insertions(+)
diff --git a/tools/testing/selftests/vm/Makefile
b/tools/testing/selftests/vm/Makefile
index 9f2625bebf07..3
it's not supported):
$ make userfaultfd
# ...userfaultfd fails to link, due to incomplete LDLIBS
That's what Patch 0002 fixes.
John Hubbard (2):
selftests/vm: fix false build success on the second and later attempts
selftests/vm: fix incorrect gcc invocation in some cases
tools/testi
into believing that there's
nothing else to build.
Fix this by telling Make to delete targets that didn't completely
succeed.
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/vm/
re to the mechanism used internally, rather than the behavior of the
function. "anon_" adds more meaning.)
...now I better go and try to grok what Jason is recommending for the new
meaning of FOLL_PIN, in another tributary of this thread. I don't *think* it
affects
this naming point, though. :)
thanks,
--
John Hubbard
NVIDIA
On 9/17/20 7:21 PM, Souptick Joarder wrote:
On Thu, Sep 17, 2020 at 11:17 PM John Hubbard wrote:
...
I sort of feel like returning partial successes is not working. We
could easily make a wrapper which either pins everything or it returns
an error code.
Yes we could. And I have the same
ybe_dma_pinned() callers yet.
Although I think we're getting closer to using it. There was a recent
attempt at using this stuff, from Chris Wilson. [1]
[1]
https://lore.kernel.org/intel-gfx/20200624191417.16735-1-chris%40chris-wilson.co.uk/
thanks,
--
John Hubbard
NVIDIA
On 9/19/20 8:03 PM, Souptick Joarder wrote:
On Thu, Sep 17, 2020 at 1:11 PM Dan Carpenter wrote:
On Wed, Sep 16, 2020 at 11:57:06PM -0700, John Hubbard wrote:
As suggested by Dan Carpenter, fortify unpin_user_pages() just a bit,
against a typical caller mistake: check if the npages arg is
801 - 900 of 1012 matches
Mail list logo
