On 5/23/19 3:50 PM, John Hubbard wrote:
> [...]
> I was thinking of it as a temporary measure, only up until, but not including
> the
> point where put_user_pages() becomes active. That is, the point when
> put_user_pages
> starts decrementing GUP_PIN_COUNTING_BIAS, instead
w put_user_pages() could be interchangeable.
>
> Cc: Jérôme Glisse
> Cc: Dan Williams
> Cc: Michal Hocko
> Cc: John Hubbard
> Signed-off-by: Ira Weiny
> ---
> mm/swap.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/mm/swa
From: John Hubbard
For the !CONFIG_PROVE_LOCKING case, the "class" variable is left unused.
Rather than tease apart the functionality in lockdep_stats_show(), where
class is used to increment up to 15 local variables, this patch merely
adds yet another ifdef to fix the build warning.
From: John Hubbard
Hi,
I just ran into this while building other things against today's linux.git.
For the !CONFIG_PROVE_LOCKING case, the "class" variable is left unused.
Rather than tease apart the functionality in lockdep_stats_show(), where
class is used to increment up t
From: John Hubbard
Recent gcc compilers (gcc 9.1) generate warnings about an
out of bounds memset, if you trying memset across several fields
of a struct. This generated a couple of warnings on x86_64 builds.
Because struct boot_params is __packed__, normal variable
variable assignment
From: John Hubbard
Hi,
I just ran across this on the latest (well, any -rc1) linux.git, while
working on something else. It generates an ugly multiline warning:
In file included from arch/x86/kernel/head64.c:35:
In function ?sanitize_boot_params?,
inlined from ?copy_bootdata? at arch/x86
On 7/24/19 7:12 PM, h...@zytor.com wrote:
On July 24, 2019 4:15:28 PM PDT, john.hubb...@gmail.com wrote:
From: John Hubbard
...
+ boot_params->ext_ramdisk_image = 0;
+ boot_params->ext_ramdisk_size = 0;
+ boot_params->ext_cmd_lin
On 7/25/19 12:22 AM, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, h...@zytor.com wrote:
>> On July 24, 2019 4:15:28 PM PDT, john.hubb...@gmail.com wrote:
>>> From: John Hubbard
>>>
>>> Recent gcc compilers (gcc 9.1) generate warnings about an
>>> out
like a bit too far.
thanks,
--
John Hubbard
NVIDIA
e, memset the area to zero, copy back preserved
fields? This seems like it would have the same gcc warnings as we have now,
due to the requirement to memset a range of a struct...
b) Iterate through all fields, memsetting to zero items that are *not*
marked "to preserve"?
c) Something else? Sorry for the naivete here. I really did read
Documentation/x86/boot.rst, honest. :)
thanks,
--
John Hubbard
NVIDIA
to jump in and do that, since I have an easy repro of the warning here.
In case you missed an earlier response [1], I did have a lingering question
about what you had in mind for the "to preserve" approach:
[1] https://lore.kernel.org/r/ffd7a9b6-8017-2d2c-c4f7-65563094c...@nvidia.com
thanks,
--
John Hubbard
NVIDIA
On 6/9/19 6:51 AM, Paul E. McKenney wrote:
> On Tue, May 21, 2019 at 12:08:08AM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
>>
>> Commit 0d2cc3b34532 ("locking/lockdep: Move valid_state() inside
>> CONFIG_TRACE_IRQFLAGS && CON
From: John Hubbard
Commit 0d2cc3b34532 ("locking/lockdep: Move valid_state() inside
CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING") moved the only usage of
print_lock_trace() that was originally outside of the CONFIG_PROVE_LOCKING
case. It moved that usage int
From: John Hubbard
This fixes a build warning to that effect.
Signed-off-by: John Hubbard
---
Hi,
I ran into this while working on unrelated changes, to
convert ceph over to put_user_page().
This patch is against the latest linux.git.
thanks,
John Hubbard
NVIDIA
fs/ceph/debugfs.c | 1
From: John Hubbard
Provide more capable variation of put_user_pages_dirty_lock(),
and delete put_user_pages_dirty(). This is based on the
following:
1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions&q
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
Hi,
These are best characterized as miscellaneous conversions: many (not all)
call sites that don't involve biovec or iov_iter, nor mm/. It also leaves
out a few call sites that require some more work. These are mostly pretty
simple ones.
It's probably best to send all
From: John Hubbard
The HMM_MIRROR option in Kconfig is a little underdocumented and
mysterious, and leaves people wondering whether to enable it.
Add text explaining just a little bit more about HMM, and also
mention which hardware would benefit from having HMM_MIRROR
enabled.
Suggested
On 7/18/19 9:34 PM, Ira Weiny wrote:
> On Thu, Jul 18, 2019 at 06:32:53PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
...
>> + Select HMM_MIRROR if you have hardware that meets the above
>> + description. An early, partial list of such hardware is:
&g
e been merged yet.)
Longer term, I vaguely recall that there is no strong reason preventing
HMM from being made to work on other arches, and am hoping that it was
just done this way to save development time. I don't want to leave it
this way unless there's a good reason to.
thanks,
--
John Hubbard
NVIDIA
On 7/19/19 1:59 PM, Matt Sickler wrote:
>> From: Bharath Vedartham
>> Changes since v2
>>- Added back PageResevered check as suggested by John Hubbard.
>>
>> The PageReserved check needs a closer look and is not worth messing
>> around with for
user_page*(), placeholder versions").
For the change itself, you will need to rebase it onto the latest
linux.git, as it doesn't quite apply there.
Testing is good if we can get it, but as far as I can tell this is
correct, so you can also add:
Reviewed-by: John Hubbard
thanks,
--
Jo
en
in use in that case, too, so ZONE_DEVICE couldn't use that, either. I don't
think we need to explicitly say that, though, with this new layout.
nit: the above comment can be deleted, because it merely echoes the actual
code that directly follows it.
Either way, you can add:
Revie
memory or worse.
>
> Clear the page->mapping field when freeing the ZONE_DEVICE page so stale
> pointer data doesn't affect future page use.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
>
> Fixes: b7a523109fb5c9d2d6dd ("mm: don't clear ->mapping in hmm_dev
ect_pmd,
> + .pte_hole = migrate_vma_collect_hole,
> + .vma = migrate->vma,
> + .mm = migrate->vma->vm_mm,
> + .private = migrate,
> + };
Neatly done.
>
> mmu_notifier_range_init(, MMU_NOTIFY_CLEAR, 0, NULL, mm_walk.mm,
> migrate->start,
>
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
roduce put_user_page*(), placeholder versions").
>
> Cc: Ira Weiny
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Greg Kroah-Hartman
> Cc: Dimitri Sivanich
> Cc: Arnd Bergmann
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
> Signed-off-by: Bharath
oes not fall back to the slow gup
> path.
>
> This is largely inspired from kvm code. kvm uses __get_user_pages_fast
> in hva_to_pfn_fast function which can run in an atomic context.
>
> Cc: Ira Weiny
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Greg Kroah-Hartm
in the code.
>
> Cc: Ira Weiny
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Greg Kroah-Hartman
> Cc: Dimitri Sivanich
> Cc: Arnd Bergmann
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
> Signed-off-by: Bharath Vedartham
> ---
> drivers/mi
ee below).
> Cc: Ira Weiny
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Greg Kroah-Hartman
> Cc: Matt Sickler
> Cc: de...@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
> Reviewed-by: John Hubbard
> Signed-off-by: Bharath Vedartha
from NFSv3 to NFSv4 is that the easy authentication (matching UIDs on
client and server) now works perfectly. Yea! So I'm enjoying v4, despite
the occasional minor glitch. :)
[1] https://lore.kernel.org/r/20190802022005.5117-1-jhubb...@nvidia.com
thanks,
--
John Hubbard
NVIDIA
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
On 7/30/19 10:46 PM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Hi,
>
> This uses the "save each field explicitly" approach that we discussed
> during the first review [1]. As in [1], this is motivated by a desire
> to clear the compiler wa
From: John Hubbard
Hi,
Here are a few more mm/ files that I wasn't ready to send with the
larger 34-patch set.
John Hubbard (3):
mm/mlock.c: convert put_page() to put_user_page*()
mm/mempolicy.c: convert put_page() to put_user_page*()
mm/ksm: convert put_page() to put_user_page*()
mm
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeh
fter the gup_fast()
irq disable/enable points:
https://lore.kernel.org/r/20190920195047.7703-4-leona...@linux.ibm.com
...and that lead to noticing a general lack of barriers there.
thanks,
--
John Hubbard
NVIDIA
ld not be
determined". The efi_main function in arch/x86/boot/compressed/eboot.c sets
this field early but it is subsequently zeroed by the above referenced commit
in the file arch/x86/include/asm/bootparam_utils.h
Applies to 5.3-rc6.
Hi,
The fix itself looks good, so you can add:
if (pud_none(pud))
> return 0;
> + if (unlikely(!pud_present(pud)))
> + return 0;
If the MCE hwpoison behavior puts in swap entries, then it seems like all
page table walkers would need to check for p*d_present(), and maybe at
On 8/12/19 2:00 PM, Ira Weiny wrote:
On Fri, Aug 09, 2019 at 05:09:54PM -0700, John Hubbard wrote:
On 8/9/19 3:58 PM, ira.we...@intel.com wrote:
From: Ira Weiny
...
At one point I wanted to (and had in my tree) a new flag but I went away from
it. Prior to the discussion on mlock last week
On 8/12/19 3:03 PM, Ira Weiny wrote:
> On Sun, Aug 11, 2019 at 06:50:44PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
...
>> +/**
>> + * vaddr_pin_pages pin pages by virtual address and return the pages to the
>
> vaddr_pin_pages_remote
>
On 8/12/19 4:49 PM, Ira Weiny wrote:
On Sun, Aug 11, 2019 at 06:50:44PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
...
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index 53085896d718..fdff034a8a30 100644
--- a/drivers/infiniband/core
ddr_pin_user_pages()
...which also sounds close enough to get_user_pages() that a bit of
history and continuity is preserved, too.
thanks,
--
John Hubbard
NVIDIA
On 8/13/19 2:08 PM, Ira Weiny wrote:
> On Mon, Aug 12, 2019 at 05:07:32PM -0700, John Hubbard wrote:
>> On 8/12/19 4:49 PM, Ira Weiny wrote:
>>> On Sun, Aug 11, 2019 at 06:50:44PM -0700, john.hubb...@gmail.com wrote:
>>>> From: John Hubbard
>> ...
>&
On 8/13/19 5:51 PM, John Hubbard wrote:
> On 8/13/19 2:08 PM, Ira Weiny wrote:
>> On Mon, Aug 12, 2019 at 05:07:32PM -0700, John Hubbard wrote:
>>> On 8/12/19 4:49 PM, Ira Weiny wrote:
>>>> On Sun, Aug 11, 2019 at 06:50:44PM -0700, john.hubb...@gmail.com w
On 8/14/19 4:50 PM, Ira Weiny wrote:
On Tue, Aug 13, 2019 at 05:56:31PM -0700, John Hubbard wrote:
On 8/13/19 5:51 PM, John Hubbard wrote:
On 8/13/19 2:08 PM, Ira Weiny wrote:
On Mon, Aug 12, 2019 at 05:07:32PM -0700, John Hubbard wrote:
On 8/12/19 4:49 PM, Ira Weiny wrote:
On Sun, Aug 11
On 8/14/19 5:02 PM, John Hubbard wrote:
On 8/14/19 4:50 PM, Ira Weiny wrote:
On Tue, Aug 13, 2019 at 05:56:31PM -0700, John Hubbard wrote:
On 8/13/19 5:51 PM, John Hubbard wrote:
On 8/13/19 2:08 PM, Ira Weiny wrote:
On Mon, Aug 12, 2019 at 05:07:32PM -0700, John Hubbard wrote:
On 8/12/19 4
M *does* require those callbacks. Because we've been, so
far, equating FOLL_LONGTERM with the vaddr_pin struct and with a lease.
What am I missing here?
thanks,
--
John Hubbard
NVIDIA
From: John Hubbard
release_pages() has been available to modules since Oct, 2010,
when commit 0be8557bcd34 ("fuse: use release_pages()") added
EXPORT_SYMBOL(release_pages). However, this ceph code was still
using a workaround.
Remove the workaround, and call release_pages() directly.
On 8/9/19 1:23 AM, Michal Hocko wrote:
On Fri 09-08-19 10:12:48, Vlastimil Babka wrote:
On 8/9/19 12:59 AM, John Hubbard wrote:
That's true. However, I'm not sure munlocking is where the
put_user_page() machinery is intended to be used anyway? These are
short-term pins for struct page
On 8/9/19 2:44 AM, Bharath Vedartham wrote:
On Thu, Aug 08, 2019 at 04:21:44PM -0700, John Hubbard wrote:
On 8/8/19 11:55 AM, Bharath Vedartham wrote:
...
static int gru_vtop(struct gru_thread_state *gts, unsigned long vaddr,
int write, int atomic, unsigned long *gpa, int
On 8/9/19 11:14 AM, Weiny, Ira wrote:
On Fri 09-08-19 15:58:13, Jan Kara wrote:
On Fri 09-08-19 10:23:07, Michal Hocko wrote:
On Fri 09-08-19 10:12:48, Vlastimil Babka wrote:
On 8/9/19 12:59 AM, John Hubbard wrote:
...
In principle, I'm not strongly opposed to a new FOLL flag to determine
(-)
>
Looks good, although you may want to combine it with the next patch.
Otherwise it feels like a "to be continued" when you're reading them.
Either way, though:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> ind
d memory within
> the address range.
>
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
> Signed-off-by: Ira Weiny
> ---
> mm/gup.c | 65 ++--
> 1 file changed, 40 insertions(+), 25 deletions(-)
>
> diff --git a/m
proper
> + * tracking.
> + */
> +void vaddr_unpin_pages_dirty_lock(struct page **pages, unsigned long
> nr_pages,
> + struct vaddr_pin *vaddr_pin, bool make_dirty)
> +{
> + __put_user_pages_dirty_lock(vaddr_pin, pages, nr_pages, make_dirty);
> +}
> +EXPORT_SYMBOL(vaddr_unpin_pages_dirty_lock);
>
OK, whew, I'm glad to see the updated _dirty_lock() API used here. :)
thanks,
--
John Hubbard
NVIDIA
gned long
> addr,
> + pmd_t *pmd, int flags, struct follow_page_context *ctx);
> +struct page *follow_devmap_pud(struct vm_area_struct *vma, unsigned long
> addr,
> + pud_t *pud, int flags, struct follow_page_context *ctx);
> +#else
> +static inline struct page *follow_devmap_pmd(struct vm_area_struct *vma,
> + unsigned long addr, pmd_t *pmd, int flags,
> + struct follow_page_context *ctx)
> +{
> + return NULL;
> +}
> +
> +static inline struct page *follow_devmap_pud(struct vm_area_struct *vma,
> + unsigned long addr, pud_t *pud, int flags,
> + struct follow_page_context *ctx)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> +
> +
> /*
> * The set of flags that only affect watermark checking and reclaim
> * behaviour. This is used by the MM to obey the caller constraints
>
thanks,
--
John Hubbard
NVIDIA
lock);
>
> /**
> @@ -102,15 +162,7 @@ EXPORT_SYMBOL(put_user_pages_dirty_lock);
> */
> void put_user_pages(struct page **pages, unsigned long npages)
> {
> - unsigned long index;
> -
> - /*
> - * TODO: this can be optimized for huge pages: if a series of pages is
> - * physically contiguous and part of the same compound page, then a
> - * single operation to the head page should suffice.
> - */
> - for (index = 0; index < npages; index++)
> - put_user_page(pages[index]);
> + __put_user_pages(NULL, pages, npages);
> }
> EXPORT_SYMBOL(put_user_pages);
>
>
This all looks pretty good, so regardless of the outcome of the minor
points above,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
From: John Hubbard
Hi,
This happens on today's linux-next.
If the commit message of the original patch were just a bit clearer,
I might have been able to attempt a fix, instead of a revert, but so far,
both the Perl and the English are beyond me. And we can't leave
checkpatch broken.
I'll
From: John Hubbard
commit 1a47005dd5aa ("checkpatch: add *_NOTIFIER_HEAD as var
definition") causes the following warning when run on some
patches:
Unescaped left brace in regex is passed through in regex;
marked by < --HERE in m/(?:
...
[238 lines of appalling perl outpu
pages to the
> + * user.
> + *
> + * @addr, start address
> + * @nr_pages, number of pages to pin
> + * @gup_flags, flags to use for the pin
> + * @pages, array of pages returned
> + * @vaddr_pin, initalized meta information this pin is to be associated
Typo:
initialized
thanks,
--
John Hubbard
NVIDIA
From: John Hubbard
FOLL_PIN is set by vaddr_pin_pages(). This is different than
FOLL_LONGTERM, because even short term page pins need a new kind
of tracking, if those pinned pages' data is going to potentially
be modified.
This situation is described in more detail in commit fc1d8e7cca2d
(&qu
From: John Hubbard
This is the "vaddr_pin_pages" corresponding variant to
get_user_pages_remote(), but with FOLL_PIN semantics: the implementation
sets FOLL_PIN. That, in turn, means that the pages must ultimately be
released by put_user_page*()--typically, via vaddr_unpin_pages
From: John Hubbard
Hi,
Dave Chinner's head didn't seem to explode...much, when he saw Ira's
series, so I optimistically started taking it from there...this builds on
top of Ira's patchset that he just sent out:
"[RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-
a90118c445cc7f07781de26a9684d4ec58bfcfd1 is the first bad commit
commit a90118c445cc7f07781de26a9684d4ec58bfcfd1
Author: John Hubbard
Date: Tue Jul 30 22:46:27 2019 -0700
x86/boot: Save fields explicitly, zero out everything else
Recent gcc compilers (gcc 9.1) generate warnings about an out of bounds
to add lease support
to drivers like XDP, which is otherwise looking pretty difficult to
set up with an fd. (It's socket-based, and not immediately clear where
to connect up the fd.)
thanks,
--
John Hubbard
NVIDIA
Why not just have a single table someplace of all the layout leases
with the file
On 8/19/19 8:36 PM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 08:09:33PM -0700, John Hubbard wrote:
On 8/19/19 6:20 PM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote:
On 8/19/19 2:24 AM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan
];/* 0xcd0 */
struct edd_info eddbuf[EDDMAXNR]; /* 0xd00 */
__u8 _pad9[276]; /* 0xeec */
} __attribute__((packed));
thanks,
--
John Hubbard
NVIDIA
The OS I'm testing is LibreELEC, which is a custom x86_64 build
On 8/21/19 11:51 AM, Thomas Gleixner wrote:
On Wed, 21 Aug 2019, John Hubbard wrote:
On 8/21/19 10:05 AM, Neil MacLeod wrote:
static void sanitize_boot_params(struct boot_params *boot_params)
{
...
const struct boot_params_to_save to_save
ot: Save fields explicitly, zero out everything
else")
Reported-by: Neil MacLeod
Suggested-by: Thomas Gleixner
Cc: H. Peter Anvin
Cc: sta...@vger.kernel.org
Signed-off-by: John Hubbard
---
arch/x86/include/asm/bootparam_utils.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On 8/21/19 12:49 PM, Neil MacLeod wrote:
The fix looks good - many thanks for the quick turnaround!
Great news, and thanks for the bug report!
thanks,
--
John Hubbard
NVIDIA
On Wed, 21 Aug 2019 at 19:56, John Hubbard wrote:
On 8/21/19 11:51 AM, Thomas Gleixner wrote:
On Wed, 21 Aug
On 8/22/19 5:24 PM, Ira Weiny wrote:
> On Tue, Aug 20, 2019 at 09:07:24PM -0700, John Hubbard wrote:
>> Hi Ira,
>>
>> This is for your tree. I'm dropping the RFC because this aspect is
>> starting to firm up pretty well.
>>
>> I've moved FOLL_PIN insid
m having trouble finding a tree that this applies cleanly too,
which one did you use? (latest linux-next, or linux.git would be
nice).
thanks,
John Hubbard
NVIDIA
>
> Changes in V3:
>
> - Added an in-code comment per Michal and David
>
> Changes in V2:
>
> - Rephras
capping
at chip level")
Cc: Shilpasri G Bhat
Cc: Preeti U Murthy
Cc: Viresh Kumar
Cc: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: John Hubbard
---
Hi,
I have only compile-tested this, so I would appreciate if anyone
could do a basic
On 10/17/19 9:27 PM, Viresh Kumar wrote:
> On 17-10-19, 17:04, John Hubbard wrote:
>> The following build warning occurred on powerpc 64-bit builds:
>>
>> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
>> drivers/cpufreq/powernv-cpufreq.c:1070:1: warn
capping
at chip level")
Cc: Shilpasri G Bhat
Cc: Preeti U Murthy
Cc: Viresh Kumar
Cc: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: John Hubbard
---
Changes since v1: includes Viresh's review commit fixes.
drivers/cpufreq/powernv-c
On 10/17/19 9:38 PM, Viresh Kumar wrote:
> On 17-10-19, 21:34, John Hubbard wrote:
>> On 10/17/19 9:27 PM, Viresh Kumar wrote:
>>> On 17-10-19, 17:04, John Hubbard wrote:
>>>> The following build warning occurred on powerpc 64-bit builds:
>>>>
>>&
On 10/17/19 8:28 PM, Anshuman Khandual wrote:
> On 10/18/2019 02:44 AM, John Hubbard wrote:
>> On 10/17/19 1:24 AM, Anshuman Khandual wrote:
...
> Yeah, it is bit non-trivial because v5 of the pgtable tests are still
> on the latest linux-next (20191015 or 20191017). You will n
u still advocating for this?
If you want to change the gup/pup API so that asking for zero pages
means -EINVAL, then fine, go for it. That's a large thing, and a
tree-wide audit, but if you feel it's worth pursuing then it's at
least consistent.
But this patch here needs to be abandoned.
thanks,
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
There is no reason for a user to select this or not directly - it should
be selected by drivers that are going to use the feature, similar to how
CONFIG_HMM_MIRROR works.
Yes, this is a nice touch.
Reviewed-by: John Hubbard
low will be narrowly focused.
Thinking again about this I am no longer sure. Adding John Hubbard.
Documentation/core-api/pin_user_pages.rst says:
---snip--
Another way of thinking about these flags is as a progression of restrictions:
FOLL_GET is for struct page manipulation, with
deletions(-)
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
diff --git a/mm/gup.c b/mm/gup.c
index 7ce796c..4952f12 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2864,10 +2864,10 @@ int get_user_pages_fast(unsigned long start, int
nr_pages,
* the arguments here are identical
On 10/22/19 10:14 AM, Jerome Glisse wrote:
> On Mon, Oct 21, 2019 at 02:24:35PM -0700, John Hubbard wrote:
>> The MAP_HUGETLB ("-H" option) of gup_benchmark fails:
>>
>> $ sudo ./gup_benchmark -H
>> mmap: Invalid argument
>>
>> This is becaus
On 10/22/19 11:57 AM, Jerome Glisse wrote:
> On Tue, Oct 22, 2019 at 11:41:57AM -0700, John Hubbard wrote:
>> On 10/22/19 10:14 AM, Jerome Glisse wrote:
>>> On Mon, Oct 21, 2019 at 02:24:35PM -0700, John Hubbard wrote:
>>>> The MAP_HUGETLB ("-H" optio
mmap_sem held. It may be released. See below.
*
Patch ordering: I'll have to change the above as part of my upcoming series, to
make it refer to "put_page() or put_user_page(), depending on FOLL_PIN",
approximately. (Just more of a note to self than anything else, here.)
thanks,
John Hubbard
NVIDIA
ssing "int" on pdshift.
Cc: Christoph Hellwig
Cc: Aneesh Kumar K.V
Signed-off-by: John Hubbard
---
mm/gup.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 23a9f9c9d377..0438221d8c53 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1973
John Hubbard (2):
mm/gup_benchmark: add a missing "w" to getopt string
mm/gup: fix a misnamed "write" argument: should be "flags"
mm/gup.c | 12 +++-
tools/testing/selftests/vm/gup_benchmark.c | 2 +-
2 files changed
k: invalid option -- 'w'
...which is fixed, with this commit.
Cc: Kirill A. Shutemov
Cc: Keith Busch
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/gup_benchmark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/too
also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/John-Hubbard/gup-c-gup_benchmark-c-trivial-fixes-before-the-storm/20191014-114158
config: powerpc-defconfig (attached
k: invalid option -- 'w'
...which is fixed, with this commit.
Acked-by: Kirill A. Shutemov
Cc: Keith Busch
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/gup_benchmark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Kumar K.V
Cc: Kirill A. Shutemov
Cc: Keith Busch
Cc: Ira Weiny
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
John Hubbard (2):
mm/gup_benchmark: add a missing "w" to getopt string
mm/gup: fix a misnamed "write" argument, and a related bug
mm/gup.c
ixes: b798bec4741b ("mm/gup: change write parameter to flags in fast walk")
Reported-by: kbuild test robot
Suggested-by: Kirill A. Shutemov
Suggested-by: Ira Weiny
Cc: Christoph Hellwig
Cc: Aneesh Kumar K.V
Signed-off-by: John Hubbard
---
mm/gup.c | 14 --
1 file changed, 8 in
On 9/23/19 1:23 PM, Leonardo Bras wrote:
> On Mon, 2019-09-23 at 12:58 -0700, John Hubbard wrote:
>>
>> CPU 0CPU 1
>> -- --
>>READ(p
low multiple processes to take FL_UNBREAKABLE
leases on the same file/range, so that we can make RDMA setups
reasonable. By "reasonable" I mean, "no need to have a lead process
that owns all the leases".
thanks,
--
John Hubbard
NVIDIA
of
CONFIG_GPIOLIB.
Fixes: commit c7663fa2a663 ("gpio: Move gpiochip_lock/unlock_as_irq to
gpio/driver.h")
Cc: YueHaibing
Cc: Linus Walleij
Signed-off-by: John Hubbard
---
Hi,
This is for today's linux-next.
More background:
It *looks* like the original commit did correctly p
701 - 800 of 1254 matches
Mail list logo
