Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()

2019-06-09 Thread Dave Hansen
On 6/9/19 9:34 PM, Anshuman Khandual wrote: >> Do you really think this is easier to read? >> >> Why not just move the x86 version to include/linux/kprobes.h, and replace >> the int with bool? > Will just return bool directly without an additional variable here as > suggested > before. But for

Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()

2019-06-07 Thread Dave Hansen
e and a bool, though. It's also not a horrible thing to add a single line comment to this sucker to say: /* returns true if kprobes handled the fault */ In any case, and even if you don't clean any of this up: Reviewed-by: Dave Hansen

[PATCH] [v2] x86/mpx: fix recursive munmap() corruption

2019-04-19 Thread Dave Hansen
Changes from v1: * Fix compile errors on UML and non-x86 arches * Clarify commit message and Fixes about the origin of the bug and add the impact to powerpc / uml / unicore32 -- This is a bit of a mess, to put it mildly. But, it's a bug that only seems to have showed up in 4.20 but

Re: [PATCH 0/2] x86, numa: always initialize all possible nodes

2019-04-15 Thread Dave Hansen
through the cracks. These look sane to me. Because it pokes around mm/page_alloc.c a bit, and could impact other architectures, my preference would be for Andrew to pick these up for -mm. But, I don't feel that strongly about it. Reviewed-by: Dave Hansen

Re: [PATCH v6 0/4] Fix free/allocation of runtime gigantic pages

2019-03-13 Thread Dave Hansen
ocated gigantic pages although unrelated. Looks good, thanks for all the changes. For everything generic in the set, plus the x86 bits: Acked-by: Dave Hansen

Re: [PATCH v5 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

2019-03-06 Thread Dave Hansen
On 3/6/19 12:08 PM, Alex Ghiti wrote: >>> >>> +    /* >>> + * Gigantic pages allocation depends on the capability for large >>> page >>> + * range allocation. If the system cannot provide >>> alloc_contig_range, >>> + * allow users to free gigantic pages. >>> + */ >>> +    if

Re: [PATCH v5 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

2019-03-06 Thread Dave Hansen
On 3/6/19 11:00 AM, Alexandre Ghiti wrote: > +static int set_max_huge_pages(struct hstate *h, unsigned long count, > + nodemask_t *nodes_allowed) > { > unsigned long min_count, ret; > > - if (hstate_is_gigantic(h) && !gigantic_page_supported()) > -

[PATCH 1/5] mm/resource: return real error codes from walk failures

2019-02-25 Thread Dave Hansen
From: Dave Hansen walk_system_ram_range() can return an error code either becuase *it* failed, or because the 'func' that it calls returned an error. The memory hotplug does the following: ret = walk_system_ram_range(..., func); if (ret) return ret; and 'ret

Re: [PATCH v3] hugetlb: allow to free gigantic pages regardless of the configuration

2019-02-15 Thread Dave Hansen
> -#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || > defined(CONFIG_CMA) > +#ifdef CONFIG_CONTIG_ALLOC > /* The below functions must be run on a range from a single zone. */ > extern int alloc_contig_range(unsigned long start, unsigned long end, >

Re: [PATCH v2] hugetlb: allow to free gigantic pages regardless of the configuration

2019-02-13 Thread Dave Hansen
> -#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || > defined(CONFIG_CMA) > +#ifdef CONFIG_COMPACTION_CORE > static __init int gigantic_pages_init(void) > { > /* With compaction or CMA we can allocate gigantic pages at runtime */ > diff --git a/fs/Kconfig

Re: [PATCH v3 2/2] mm: be more verbose about zonelist initialization

2019-02-13 Thread Dave Hansen
On 2/13/19 1:43 AM, Michal Hocko wrote: > > We have seen several bugs where zonelists have not been initialized > properly and it is not really straightforward to track those bugs down. > One way to help a bit at least is to dump zonelists of each node when > they are (re)initialized. Were you

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

2019-01-24 Thread Dave Hansen
On 1/24/19 6:17 AM, Michal Hocko wrote: > and nr_cpus set to 4. The underlying reason is tha the device is bound > to node 2 which doesn't have any memory and init_cpu_to_node only > initializes memory-less nodes for possible cpus which nr_cpus restrics. > This in turn means that proper zonelists

Re: pkeys: Reserve PKEY_DISABLE_READ

2018-11-27 Thread Dave Hansen
On 11/27/18 3:57 AM, Florian Weimer wrote: > I would have expected something that translates PKEY_DISABLE_WRITE | > PKEY_DISABLE_READ into PKEY_DISABLE_ACCESS, and also accepts > PKEY_DISABLE_ACCESS | PKEY_DISABLE_READ, for consistency with POWER. > > (My understanding is that PKEY_DISABLE_ACCESS

Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data

2018-10-29 Thread Dave Hansen
On 10/29/18 2:55 PM, Michael Sammler wrote: >> PKRU getting reset on signals, and the requirement now that it *can't* >> be changed if you make syscalls probably needs to get thought about very >> carefully before we do this, though. > I am not sure, whether I follow you. Are you saying, that PKRU

Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data

2018-10-29 Thread Dave Hansen
On 10/29/18 9:48 AM, Jann Horn wrote: > On Mon, Oct 29, 2018 at 5:37 PM Dave Hansen wrote: >> I'm not sure this is a great use for PKRU. I *think* the basic problem >> is that you want to communicate some rights information down into a >> filter, and you want to communicate

Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data

2018-10-29 Thread Dave Hansen
On 10/29/18 10:02 AM, Michael Sammler wrote: >>> Also, I'm not sure the kernel provides the PKRU guarantees you want at >>> the moment.  Our implementation *probably* works, but it's mostly by >>> accident. > I don't know, which guarantees about the PKRU are provided at the > moment, but the only

Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data

2018-10-29 Thread Dave Hansen
On 10/29/18 9:25 AM, Kees Cook wrote: > On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler wrote: >> Add the current value of an architecture specific protection keys >> register (currently PKRU on x86) to data available for seccomp-bpf >> programs to work on. This allows filters based on the

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-03 Thread Dave Hansen
On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote: > It is more than just memmaps (e.g. forking udev process doing memory > onlining also needs memory) but yes, the main idea is to make the > onlining synchronous with hotplug. That's a good theoretical concern. But, is it a problem we need to solve

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-10-01 Thread Dave Hansen
> How should a policy in user space look like when new memory gets added > - on s390x? Not onlining paravirtualized memory is very wrong. Because we're going to balloon it away in a moment anyway? We have auto-onlining. Why isn't that being used on s390? > So the type of memory is very

Re: [PATCH v9 0/3] powerpc: Detection and scheduler optimization for POWER9 bigcore

2018-10-01 Thread Dave Hansen
On 10/01/2018 06:16 AM, Gautham R. Shenoy wrote: > > Patch 3: Creates a pair of sysfs attributes named > /sys/devices/system/cpu/cpuN/topology/smallcore_thread_siblings > and > /sys/devices/system/cpu/cpuN/topology/smallcore_thread_siblings_list > exposing the

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

2018-09-28 Thread Dave Hansen
It's really nice if these kinds of things are broken up. First, replace the old want_memblock parameter, then add the parameter to the __add_page() calls. > +/* > + * NONE: No memory block is to be created (e.g. device memory). > + * NORMAL: Memory block that represents normal (boot or

Re: [PATCH v8 0/3] powerpc: Detection and scheduler optimization for POWER9 bigcore

2018-09-25 Thread Dave Hansen
On 09/22/2018 04:03 AM, Gautham R Shenoy wrote: > Without this patchset, the SMT domain would be defined as the group of > threads that share L2 cache. Could you try to make a more clear, concise statement about the current state of the art vs. what you want it to be? Right now, the sched

Re: [PATCH v8 0/3] powerpc: Detection and scheduler optimization for POWER9 bigcore

2018-09-20 Thread Dave Hansen
On 09/20/2018 10:22 AM, Gautham R. Shenoy wrote: > - > |L1 Cache | >-- >|L2| | | | | >| | 0 | 2 | 4 | 6 |Small Core0 >|C | | | | | >

Re: [PATCH v14 22/22] selftests/vm: test correct behavior of pkey-0

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > Ensure pkey-0 is allocated on start. Ensure pkey-0 can be attached > dynamically in various modes, without failures. Ensure pkey-0 can be > freed and allocated. > > Signed-off-by: Ram Pai > --- > tools/testing/selftests/vm/protection_keys.c | 66 >

Re: [PATCH v14 20/22] selftests/vm: testcases must restore pkey-permissions

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > Generally the signal handler restores the state of the pkey register > before returning. However there are times when the read/write operation > can legitamely fail without invoking the signal handler. Eg: A > sys_read() operaton to a write-protected page

Re: [PATCH v14 16/22] selftests/vm: fix an assertion in test_pkey_alloc_exhaust()

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > The maximum number of keys that can be allocated has to > take into consideration, that some keys are reserved by > the architecture for specific purpose. Hence cannot > be allocated. Back to incomplete sentences, I see. :) How about: Some

Re: [PATCH v14 15/22] selftests/vm: powerpc implementation to check support for pkey

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > -static inline int cpu_has_pku(void) > +static inline bool is_pkey_supported(void) > { > - return 1; > + /* > + * No simple way to determine this. > + * Lets try allocating a key and see if it succeeds. > + */ > + int ret =

Re: [PATCH v14 14/22] selftests/vm: Introduce generic abstractions

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > Introduce generic abstractions and provide architecture > specific implementation for the abstractions. I really wanted to see these two things separated: 1. introduce abstractions 2. introduce ppc implementation But, I guess most of it is done except for

Re: [PATCH v14 13/22] selftests/vm: generic cleanup

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > cleanup the code to satisfy coding styles. > > cc: Dave Hansen > cc: Florian Weimer > Signed-off-by: Ram Pai > --- > tools/testing/selftests/vm/protection_keys.c | 64 + > 1 files changed, 43 ins

Re: [PATCH v14 12/22] selftests/vm: pkey register should match shadow pkey

2018-07-18 Thread Dave Hansen
w pkey register, which is supposed to track the bits > accurately all throughout This is getting dangerously close to full sentences that actually describe the patch. You forgot a period, but much this is a substantial improvement over earlier parts of the series. Thanks for writing this, seri

Re: [PATCH v14 11/22] selftests/vm: introduce two arch independent abstraction

2018-07-18 Thread Dave Hansen
pages. > get_start_key() <-- provides the first non-reserved key. Does powerpc not start on key 0? Why do you need this? > cc: Dave Hansen > cc: Florian Weimer > Signed-off-by: Ram Pai > Signed-off-by: Thiago Jung Bauermann > Reviewed-by: Dave Hansen > --- > tools/te

Re: [PATCH v14 10/22] selftests/vm: fix alloc_random_pkey() to make it really random

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > alloc_random_pkey() was allocating the same pkey every time. > Not all pkeys were geting tested. fixed it. This fixes a real issue but also unnecessarily munges whitespace. If you rev these again, please fix the munging. Otherwise: Acked-by: Dave Hansen

Re: [PATCH v14 09/22] selftests/vm: fixed bugs in pkey_disable_clear()

2018-07-18 Thread Dave Hansen
ng bit value will be less than the original. > > This hasn't been a problem so far because this code isn't currently > used. > > cc: Dave Hansen > cc: Florian Weimer > Signed-off-by: Ram Pai > --- > tools/testing/selftests/vm/protection_keys.c |4 ++-- > 1 f

Re: [PATCH v14 08/22] selftests/vm: fix the wrong assert in pkey_disable_set()

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > If the flag is 0, no bits will be set. Hence we cant expect > the resulting bitmap to have a higher value than what it > was earlier. ... > --- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -415,7

Re: [PATCH v14 07/22] selftests/vm: generic function to handle shadow key register

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > - shifted_pkey_reg = (pkey_reg >> (pkey * PKEY_BITS_PER_PKEY)); > + shifted_pkey_reg = right_shift_bits(pkey, pkey_reg); > dprintf2("%s() shifted_pkey_reg: "PKEY_REG_FMT"\n", __func__, > shifted_pkey_reg); >

Re: [PATCH v14 06/22] selftests/vm: typecast the pkey register

2018-07-18 Thread Dave Hansen
eg: %*llx\n", PKEY_FMT_LEN, pkey_reg); But, I don't _really_ care in the end. Acked-by: Dave Hansen

Re: [PATCH v14 04/22] selftests/vm: move arch-specific definitions to arch-specific header

2018-07-18 Thread Dave Hansen
On 07/17/2018 06:49 AM, Ram Pai wrote: > In preparation for multi-arch support, move definitions which have > arch-specific values to x86-specific header. Acked-by: Dave Hansen

Re: [PATCH v14 03/22] selftests/vm: move generic definitions to header file

2018-07-18 Thread Dave Hansen
Acked-by: Dave Hansen

Re: [PATCH v14 01/22] selftests/x86: Move protecton key selftest to arch neutral directory

2018-07-18 Thread Dave Hansen
Acked-by: Dave Hansen

Re: [PATCH v13 19/24] selftests/vm: associate key on a mapped page and detect access violation

2018-07-17 Thread Dave Hansen
On 07/17/2018 09:13 AM, Ram Pai wrote: > I have incorporated almost all of your comments. But there are some > comments that take some effort to implement. Shall we get the patches > merged in the current form? This code has been sitting out for a while. > > In the current form its tested and

Re: [PATCH v13 08/24] selftests/vm: fix the wrong assert in pkey_disable_set()

2018-07-17 Thread Dave Hansen
On 07/17/2018 08:58 AM, Ram Pai wrote: > On Wed, Jun 20, 2018 at 07:47:02AM -0700, Dave Hansen wrote: >> On 06/13/2018 05:44 PM, Ram Pai wrote: >>> If the flag is 0, no bits will be set. Hence we cant expect >>> the resulting bitmap to have a higher value t

Re: [PATCH v13 24/24] selftests/vm: test correct behavior of pkey-0

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > Ensure pkey-0 is allocated on start. Ensure pkey-0 can be attached > dynamically in various modes, without failures. Ensure pkey-0 can be > freed and allocated. I like this. Looks very useful. Acked-by: Dave Hansen

Re: [PATCH v13 22/24] selftests/vm: testcases must restore pkey-permissions

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > Generally the signal handler restores the state of the pkey register > before returning. However there are times when the read/write operation > can legitamely fail without invoking the signal handler. Eg: A > sys_read() operaton to a write-protected page

Re: [PATCH v13 19/24] selftests/vm: associate key on a mapped page and detect access violation

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > +void test_read_of_access_disabled_region_with_page_already_mapped(int *ptr, > + u16 pkey) > +{ > + int ptr_contents; > + > + dprintf1("disabling access to PKEY[%02d], doing read @ %p\n", > + pkey, ptr); > +

Re: [PATCH v13 18/24] selftests/vm: fix an assertion in test_pkey_alloc_exhaust()

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > /* > - * There are 16 pkeys supported in hardware. Three are > - * allocated by the time we get here: > - * 1. The default key (0) > - * 2. One possibly consumed by an execute-only mapping. > - * 3. One allocated by the

Re: [PATCH v13 17/24] selftests/vm: powerpc implementation to check support for pkey

2018-06-20 Thread Dave Hansen
> - if (cpu_has_pku()) { > - dprintf1("SKIP: %s: no CPU support\n", __func__); > + if (is_pkey_supported()) { > + dprintf1("SKIP: %s: no CPU/kernel support\n", __func__); > return; > } I actually kinda wanted a specific message for when the

Re: [PATCH v13 16/24] selftests/vm: clear the bits in shadow reg when a pkey is freed.

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > --- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -577,7 +577,8 @@ int sys_pkey_free(unsigned long pkey) > int ret = syscall(SYS_pkey_free, pkey); > > if (!ret) > -

Re: [PATCH v13 15/24] selftests/vm: powerpc implementation for generic abstraction

2018-06-20 Thread Dave Hansen
> +static inline u32 *siginfo_get_pkey_ptr(siginfo_t *si) > +{ > +#ifdef si_pkey > + return >si_pkey; > +#else > + return (u32 *)(((u8 *)si) + si_pkey_offset); > +#endif > } FWIW, this isn't ppc-specific. > diff --git a/tools/testing/selftests/vm/protection_keys.c >

Re: [PATCH v13 14/24] selftests/vm: generic cleanup

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > cleanup the code to satisfy coding styles. A lot of this makes the code look worse and more unreadable than before. I think someone just ran it through lindent or something. I also took a few CodingStyle liberties in here because it's _not_ main kernel

Re: [PATCH v13 13/24] selftests/vm: pkey register should match shadow pkey

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -916,10 +916,10 @@ void expected_pkey_fault(int pkey) > pkey_assert(last_si_pkey == pkey); > > /* > - * The signal handler shold have cleared out PKEY register to let the > +

Re: [PATCH v13 10/24] selftests/vm: clear the bits in shadow reg when a pkey is freed.

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:45 PM, Ram Pai wrote: > When a key is freed, the key is no more effective. > Clear the bits corresponding to the pkey in the shadow > register. Otherwise it will carry some spurious bits > which can trigger false-positive asserts. ...---

Re: [PATCH v13 08/24] selftests/vm: fix the wrong assert in pkey_disable_set()

2018-06-20 Thread Dave Hansen
On 06/13/2018 05:44 PM, Ram Pai wrote: > If the flag is 0, no bits will be set. Hence we cant expect > the resulting bitmap to have a higher value than what it > was earlier ... > if (flags) > - pkey_assert(read_pkey_reg() > orig_pkey_reg); > +

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

2018-05-16 Thread Dave Hansen
On 05/14/2018 08:34 AM, Florian Weimer wrote: >>> The initial PKRU value can currently be configured by the system >>> administrator.  I fear this approach has too many moving parts to be >>> viable. >> >> Honestly, I think we should drop that option. I don’t see how we can >> expect an

Re: [PATCH v3] powerpc, pkey: make protection key 0 less special

2018-05-09 Thread Dave Hansen
On 05/09/2018 08:43 AM, Michal Suchánek wrote: > It seems it is somehow assumed this is key 0 but I did not find it > documented anywhere nor did I notice an interface for determining the > default key. Does the manpage not count as documentation? :) "pkey 0 is used as the default key"

Re: [PATCH 8/8] mm/pkeys, x86, powerpc: Display pkey in smaps if arch supports pkeys

2018-05-08 Thread Dave Hansen
This patch changes the implementation. It displays the pkey only if > the architecture support pkeys, i.e arch_pkeys_enabled() returns true. For this, along with 6/8 and 7/8: Reviewed-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH 5/8] x86/pkeys: Move vma_pkey() into asm/pkeys.h

2018-05-08 Thread Dave Hansen
On 05/08/2018 07:59 AM, Michael Ellerman wrote: > Move the last remaining pkey helper, vma_pkey() into asm/pkeys.h Fine with me, as long as it compiles. :) Reviewed-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH 4/8] mm/pkeys, powerpc, x86: Provide an empty vma_pkey() in linux/pkeys.h

2018-05-08 Thread Dave Hansen
to me. Thanks for consolidating these. Reviewed-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

2018-05-04 Thread Dave Hansen
On 05/04/2018 06:12 PM, Ram Pai wrote: >> That new line boils down to: >> >> [ilog2(0)] = "", >> >> on x86. It wasn't *obvious* to me that it is OK to do that. The other >> possibly undefined bits (VM_SOFTDIRTY for instance) #ifdef themselves >> out of this array. >> >> I would

Re: [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

2018-05-04 Thread Dave Hansen
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 0c9e392..3c7 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -679,6 +679,7 @@ static void show_smap_vma_flags(struct seq_file *m, > struct vm_area_struct *vma) > [ilog2(VM_PKEY_BIT1)] = "", >

Re: [PATCH v3] powerpc, pkey: make protection key 0 less special

2018-05-04 Thread Dave Hansen
On 05/04/2018 02:26 PM, Michal Suchánek wrote: > If it is not ok to change permissions of pkey 0 is it ok to free it? It's pretty much never OK to free it on x86 or ppc. But, we're not going to put code in to keep userspace from shooting itself in the foot, at least on x86.

Re: [PATCH v3] powerpc, pkey: make protection key 0 less special

2018-05-04 Thread Dave Hansen
On 05/04/2018 12:22 PM, Ram Pai wrote: > @@ -407,9 +414,6 @@ static bool pkey_access_permitted(int pkey, bool write, > bool execute) > int pkey_shift; > u64 amr; > > - if (!pkey) > - return true; > - > if (!is_pkey_enabled(pkey)) > return true;

Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()

2018-03-28 Thread Dave Hansen
On 03/28/2018 01:47 PM, Thiago Jung Bauermann wrote: >>> if (flags) >>> - assert(rdpkey_reg() > orig_pkey_reg); >>> + assert(rdpkey_reg() < orig_pkey_reg); >>> } >>> >>> void pkey_write_allow(int pkey) >> This seems so horribly wrong that I wonder how it worked in the

Re: [PATCH v12 22/22] selftests/vm: Fix deadlock in protection_keys.c

2018-03-16 Thread Dave Hansen
e > frozen process: Ugh, yeah, I've run into this too. Acked-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v12 21/22] selftests/vm: sub-page allocator

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: ... > @@ -888,6 +917,7 @@ void setup_hugetlbfs(void) > void *(*pkey_malloc[])(long size, int prot, u16 pkey) = { > > malloc_pkey_with_mprotect, > + malloc_pkey_with_mprotect_subpage, > malloc_pkey_anon_huge, > malloc_pkey_hugetlb >

Re: [PATCH v12 20/22] selftests/vm: testcases must restore pkey-permissions

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > Generally the signal handler restores the state of the pkey register > before returning. However there are times when the read/write operation > can legitamely fail without invoking the signal handler. Eg: A > sys_read() operaton to a write-protected page

Re: [PATCH v12 19/22] selftests/vm: detect write violation on a mapped access-denied-key page

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > detect write-violation on a page to which access-disabled > key is associated much after the page is mapped. Acked-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v12 18/22] selftests/vm: associate key on a mapped page and detect write violation

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > detect write-violation on a page to which write-disabled > key is associated much after the page is mapped. The more tests the merrier. Acked-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v12 17/22] selftests/vm: associate key on a mapped page and detect access violation

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > detect access-violation on a page to which access-disabled > key is associated much after the page is mapped. Looks fine to me. Did this actually find a bug for you? Acked-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v12 16/22] selftests/vm: fix an assertion in test_pkey_alloc_exhaust()

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > +static inline int arch_reserved_keys(void) > +{ > +#if defined(__i386__) || defined(__x86_64__) /* arch */ > + return NR_RESERVED_PKEYS; > +#elif __powerpc64__ /* arch */ > + if (sysconf(_SC_PAGESIZE) == 4096) > + return

Re: [PATCH v12 15/22] selftests/vm: powerpc implementation to check support for pkey

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > #define PAGE_SIZE (0x1UL << 16) > -static inline int cpu_has_pku(void) > +static inline bool is_pkey_supported(void) > { > - return 1; > + /* > + * No simple way to determine this. > + * lets try allocating a key and see if it succeeds.

Re: [PATCH v12 14/22] selftests/vm: clear the bits in shadow reg when a pkey is freed.

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > diff --git a/tools/testing/selftests/vm/protection_keys.c > b/tools/testing/selftests/vm/protection_keys.c > index c4c73e6..e82bd88 100644 > --- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -586,7

Re: [PATCH v12 13/22] selftests/vm: powerpc implementation for generic abstraction

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > static inline u32 pkey_to_shift(int pkey) > { > +#if defined(__i386__) || defined(__x86_64__) /* arch */ > return pkey * PKEY_BITS_PER_PKEY; > +#elif __powerpc64__ /* arch */ > + return (NR_PKEYS - pkey - 1) * PKEY_BITS_PER_PKEY; > +#endif /*

Re: [PATCH v12 12/22] selftests/vm: generic cleanup

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > cleanup the code to satisfy coding styles. > > cc: Dave Hansen <dave.han...@intel.com> > cc: Florian Weimer <fwei...@redhat.com> > Signed-off-by: Ram Pai <linux...@us.ibm.com> > --- > tools/testin

Re: [PATCH v12 11/22] selftests/vm: pkey register should match shadow pkey

2018-03-16 Thread Dave Hansen
w pkey register, which is supposed to track the bits > accurately all throughout > > cc: Dave Hansen <dave.han...@intel.com> > cc: Florian Weimer <fwei...@redhat.com> > Signed-off-by: Ram Pai <linux...@us.ibm.com> > --- > tools/testing/selftests/vm/protection_key

Re: [PATCH v12 10/22] selftests/vm: introduce two arch independent abstraction

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > open_hugepage_file() <- opens the huge page file > get_start_key() <-- provides the first non-reserved key. > Looks reasonable. Reviewed-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v12 09/22] selftests/vm: fix alloc_random_pkey() to make it really random

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > alloc_random_pkey() was allocating the same pkey every time. > Not all pkeys were geting tested. fixed it. ... > @@ -602,13 +603,15 @@ int alloc_random_pkey(void) > int alloced_pkeys[NR_PKEYS]; > int nr_alloced = 0; > int random_index; > +

Re: [PATCH v12 08/22] selftests/vm: clear the bits in shadow reg when a pkey is freed.

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > When a key is freed, the key is no more effective. > Clear the bits corresponding to the pkey in the shadow > register. Otherwise it will carry some spurious bits > which can trigger false-positive asserts. ... > diff --git

Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > --- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -461,7 +461,7 @@ void pkey_disable_clear(int pkey, int flags) > pkey, pkey, pkey_rights); > pkey_assert(pkey_rights >=

Re: [PATCH v12 06/22] selftests/vm: fix the wrong assert in pkey_disable_set()

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > If the flag is 0, no bits will be set. Hence we cant expect > the resulting bitmap to have a higher value than what it > was earlier. > > cc: Dave Hansen <dave.han...@intel.com> > cc: Florian Weimer <fwei...@redhat.com> &

Re: [PATCH v12 05/22] selftests/vm: generic function to handle shadow key register

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > +static inline u32 pkey_to_shift(int pkey) > +{ > + return pkey * PKEY_BITS_PER_PKEY; > +} pkey_bit_position(), perhaps? > +static inline pkey_reg_t reset_bits(int pkey, pkey_reg_t bits) > +{ > + u32 shift = pkey_to_shift(pkey); > + > + return

Re: [PATCH v12 04/22] selftests/vm: typecast the pkey register

2018-03-16 Thread Dave Hansen
On 02/21/2018 05:55 PM, Ram Pai wrote: > -static inline unsigned int _rdpkey_reg(int line) > +static inline pkey_reg_t _rdpkey_reg(int line) > { > - unsigned int pkey_reg = __rdpkey_reg(); > + pkey_reg_t pkey_reg = __rdpkey_reg(); > > - dprintf4("rdpkey_reg(line=%d) pkey_reg: %x

Re: [PATCH v12 02/22] selftests/vm: rename all references to pkru to a generic name

2018-03-16 Thread Dave Hansen
u32 new_pkey_reg; If we're not using the _actual_ instruction names ("rdpkru"), I think I'd rather this be something more readable, like: __read_pkey_reg(). But, it's OK-ish the way it is. Reviewed-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v3] x86: treat pkey-0 special

2018-03-15 Thread Dave Hansen
On 03/15/2018 10:21 AM, Ram Pai wrote: > On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote: >> On 03/15/2018 02:46 AM, Thomas Gleixner wrote: >>>> + if (!pkey || !mm_pkey_is_allocated(mm, pkey)) >>> Why this extra check? mm_pkey_is_allocated(mm, 0) s

Re: [PATCH v3] x86: treat pkey-0 special

2018-03-15 Thread Dave Hansen
On 03/15/2018 02:46 AM, Thomas Gleixner wrote: >> +if (!pkey || !mm_pkey_is_allocated(mm, pkey)) > Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true > ever. If it does, then this wants to be fixed. I was thinking that we _do_ actually want it to seem allocated. It just

Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0

2018-03-14 Thread Dave Hansen
On 03/14/2018 11:54 AM, Ram Pai wrote: >>> (e) it bypasses key-permission checks when assigned. >> I don't think this is necessary. I think the only rule we *need* is: >> >> pkey-0 is allocated implicitly at execve() time. You do not >> need to call pkey_alloc() to allocate it. > And

Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0

2018-03-14 Thread Dave Hansen
On 03/14/2018 10:14 AM, Ram Pai wrote: > I look at key-0 as 'the key'. It has special status. > (a) It always exist. Do you mean "is always allocated"? > (b) it cannot be freed. This is the one I'm questioning. > (c) it is assigned by default. I agree on this totally. :) > (d) its

Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0

2018-03-14 Thread Dave Hansen
On 03/14/2018 12:46 AM, Ram Pai wrote: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. I'm trying to remember why we cared in the first

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

2018-03-14 Thread Dave Hansen
On 03/14/2018 01:00 AM, Florian Weimer wrote: > ... but not the key which is used for PROT_EXEC emulation, which is still > reserved The PROT_EXEC key is dynamically allocated. There is no "the key".

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

2018-03-12 Thread Dave Hansen
On 03/09/2018 12:06 PM, Ram Pai wrote: > On Fri, Mar 09, 2018 at 09:19:53PM +1100, Michael Ellerman wrote: >> Ram Pai writes: >> >>> Once an address range is associated with an allocated pkey, it cannot be >>> reverted back to key-0. There is no valid reason for the above

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

2018-03-09 Thread Dave Hansen
On 03/09/2018 09:55 PM, Ram Pai wrote: > On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote: >> On 03/09/2018 12:12 AM, Ram Pai wrote: >>> Once an address range is associated with an allocated pkey, it cannot be >>> reverted back to key-0. There is no valid re

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

2018-03-09 Thread Dave Hansen
On 03/09/2018 12:12 AM, Ram Pai wrote: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. Why don't we just set pkey 0 to be allocated in

Re: mm, x86, powerpc: pkey semantics for key-0 ?

2018-03-08 Thread Dave Hansen
On 03/08/2018 10:25 AM, Ram Pai wrote: > Is there a reason why the default key; key-0, is not allowed to be > explicitly associated with pages using pkey_mprotect()? No, it's a bug if it is not permitted. I have a vague recollection of knowing about this and having a patch.

Re: [PATCH v12 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

2018-02-26 Thread Dave Hansen
looks fine to me. Thanks for doing these, Ram. Reviewed-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v12 2/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

2018-02-26 Thread Dave Hansen
On 02/21/2018 03:52 PM, Ram Pai wrote: > diff --git a/include/linux/mm.h b/include/linux/mm.h > index ad207ad..d534f46 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -231,9 +231,10 @@ extern int overcommit_kbytes_handler(struct ctl_table *, > int, void __user *, > #ifdef

Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

2018-02-26 Thread Dave Hansen
s fine to me. Reviewed-by: Dave Hansen <dave.han...@intel.com>

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

2017-12-20 Thread Dave Hansen
On 12/20/2017 10:19 AM, Matthew Wilcox wrote: > I don't know what the right interface is, but my laptop has a set of > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the > right place to expose write_bw (etc). Those directories are already too redundant and wasteful. I think

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

2017-12-18 Thread Dave Hansen
On 12/18/2017 02:18 PM, Ram Pai wrote: > b) minimum number of keys available to the application. > if libraries consumes a few, they could provide a library > interface to the application informing the number available to > the application. The library interface can leverage (b)

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

2017-12-18 Thread Dave Hansen
On 11/06/2017 12:57 AM, Ram Pai wrote: > Expose useful information for programs using memory protection keys. > Provide implementation for powerpc and x86. > > On a powerpc system with pkeys support, here is what is shown: > > $ head /sys/kernel/mm/protection_keys/* > ==>

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

2017-11-07 Thread Dave Hansen
On 11/07/2017 02:39 PM, Ram Pai wrote: > > As per the current semantics of sys_pkey_free(); the way I understand it, > the calling thread is saying disassociate me from this key. No. It is saying: "this *process* no longer has any uses of this key, it can be reused".

Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma

2017-07-13 Thread Dave Hansen
On 07/13/2017 01:03 AM, Ram Pai wrote: > On Tue, Jul 11, 2017 at 11:13:56AM -0700, Dave Hansen wrote: >> On 07/05/2017 02:22 PM, Ram Pai wrote: >>> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS >>> +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)

  1   2   3   >