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
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 s
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);
> +
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
> - 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 *CPU*
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)
> - shadow_p
> +static inline u32 *siginfo_get_pkey_ptr(siginfo_t *si)
> +{
> +#ifdef si_pkey
> + return &si->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
> b/tools/testing
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 co
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
> +
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.
...--- a/tools/testing/selftests/vm/protecti
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);
> + pkey_assert(read_pkey_re
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 administrat
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"
https://
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
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
me. Thanks for consolidating these.
Reviewed-by: 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
> 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)] = "",
>
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.
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;
Lo
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 firs
eah, I've run into this too.
Acked-by: 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
> /*
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 s
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
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
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
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 NR_RESERVED_PKEY
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.
>
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
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 /* arc
On 02/21/2018 05:55 PM, 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 | 81
> ++
> 1 files changed, 43
w pkey register, which is supposed to track the bits
> accurately all throughout
>
> cc: Dave Hansen
> cc: Florian Weimer
> Signed-off-by: Ram Pai
> ---
> tools/testing/selftests/vm/protection_keys.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
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
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;
> +
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 a/tools/testing/selftests/v
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 >= 0)
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
> cc: Florian Weimer
> Signed-off-by: Ram Pai
> ---
> tools/testing/sel
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
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 shad
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
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) should n
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
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 ca
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 permission
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 p
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".
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 behavior. On
>>> the con
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
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 th
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.
looks fine to me. Thanks for doing these, Ram.
Reviewed-by: 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 CONFIG
s fine to me.
Reviewed-by: 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 we
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)
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/*
> ==> /sys/kernel/mm/protectio
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".
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)
On 07/11/2017 03:14 PM, Ram Pai wrote:
> Now how many does the kernel use to reserve for itself is something
> the kernel knows too and hence can expose it, though the information
> may change dynamically as the kernel reserves and releases the key
> based on its internal needs.
>
> So i think we
On 07/11/2017 02:51 PM, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
>> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
>>> On 07/05/2017 02:21 PM, Ram Pai wrote:
>>>> Currently sys_pkey_create() provides the ability
On 07/05/2017 02:22 PM, Ram Pai wrote:
> Add documentation updates that capture PowerPC specific changes.
>
> Signed-off-by: Ram Pai
> ---
> Documentation/vm/protection-keys.txt | 85
> ++
> 1 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/D
On 07/05/2017 02:21 PM, Ram Pai wrote:
> x86 does not support disabling execute permissions on a pkey.
>
> Signed-off-by: Ram Pai
> ---
> arch/x86/kernel/fpu/xstate.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/f
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)
> +{
> + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> +}
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
This seems like k
On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently sys_pkey_create() provides the ability to disable read
> and write permission on the key, at creation. powerpc has the
> hardware support to disable execute on a pkey as well.This patch
> enhances the interface to let disable execute at key c
On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently there are only 4bits in the vma flags to support 16 keys
> on x86. powerpc supports 32 keys, which needs 5bits. This patch
> introduces an addition bit in the vma flags.
>
> Signed-off-by: Ram Pai
> ---
> fs/proc/task_mmu.c |6 +-
> inc
On 07/05/2017 02:22 PM, Ram Pai wrote:
> Abstracted out the arch specific code into the header file, and
> added powerpc specific changes.
>
> a) added 4k-backed hpte, memory allocator, powerpc specific.
> b) added three test case where the key is associated after the page is
> accessed/allo
On 12/06/2016 02:37 PM, Balbir Singh wrote:
> I think Michael found this as well, its related to adding our gigantic
> page to the hugetlb list
> and the WARN_ON that Dave Hansen added (commit
> a3a18061c987aa9da4f5d3cbb31a9e71e9d7191d)
>
> I've not looked at this issue
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'curr
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in
On 08/16/2016 10:27 AM, christophe leroy wrote:
> If I debug a very small app, it gets stuck quickly after the app has
> stopped: indeed, the console seems ok but as soon as I try to execute
> something simple, like a ps or top, it get stuck. The target still
> responds to pings, but nothing else.
On 08/15/2016 07:35 AM, Holger Brunck wrote:
> I tried this but unfortunately the error only occurs while remote debugging.
> Locally with gdb everything works fine. BTW we double-checked with a 85xx ppc
> target which is also 32-bit and it ends up with the same behaviour.
>
> I was also investiga
On 08/12/2016 08:47 AM, Holger Brunck wrote:
> On 12/08/16 17:14, Dave Hansen wrote:
>> On 08/12/2016 07:50 AM, Holger Brunck wrote:
>>> When I try to debug our multithreaded userspace application with gdb I get
>>> stuck when trying to single step code.
>>
>
On 08/12/2016 07:50 AM, Holger Brunck wrote:
> When I try to debug our multithreaded userspace application with gdb I get
> stuck when trying to single step code.
Can you clarify "stuck"? Like the instructions don't advance? Have you
been able to find a root cause for this?
> Does anyone have
On 08/02/2016 11:38 PM, Srikar Dronamraju wrote:
> * Dave Hansen [2016-08-02 11:09:21]:
>> On 08/02/2016 06:19 AM, Srikar Dronamraju wrote:
>>> Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise
>>> only certain size memory per node. The certain size
On 08/02/2016 06:19 AM, Srikar Dronamraju wrote:
> Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise
> only certain size memory per node. The certain size takes into account
> the dentry and inode cache sizes. However such a kernel when booting a
> secondary kernel will not be
On 07/09/2016 09:29 AM, cheng...@emindsoft.com.cn wrote:
> -static inline int arch_validate_prot(unsigned long prot)
> +static inline bool arch_validate_prot(unsigned long prot)
> {
> if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
> - return 0;
> - if
On 03/09/2016 04:10 AM, Anshuman Khandual wrote:
> Currently the 'huge_pte_offset' function has only one version for
> all the configuations and platforms. This change splits the function
> into two versions, one for 64K page size based BOOK3S implementation
> and the other one for everything else.
On 02/18/2016 08:50 AM, Aneesh Kumar K.V wrote:
> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
>
> Inorder to support both current and future ppc64 systems with a single
> kernel we need to make sure kern
ll prevent the udev rule from onlining
> memory until the reservation of the entire block is complete.
Seems sane to me. Makes the code simpler too, so win win.
Acked-by: Dave Hansen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https:
On 03/27/2015 12:28 PM, Nishanth Aravamudan wrote:
> @@ -2585,7 +2585,7 @@ static bool pfmemalloc_watermark_ok(pg_data_t *pgdat)
>
> for (i = 0; i <= ZONE_NORMAL; i++) {
> zone = &pgdat->node_zones[i];
> - if (!populated_zone(zone))
> + if (!pop
On 07/18/2014 12:55 AM, Wang Nan wrote:
> + if (!zone_is_empty(movable_zone))
> + if (zone_spans_pfn(movable_zone, start_pfn) ||
> + (zone_end_pfn(movable_zone) <= start_pfn))
> + zone = movable_zone;
> +
It's nice that you hit so man
On 04/09/2014 01:20 AM, Peter Zijlstra wrote:
> This still misses out on Ben's objection that its impossible to get this
> right at compile time for many kernels, since they can boot and run on
> many different subarchs.
Completely agree. The Kconfig-time stuff should probably just be a knob
to t
On 04/08/2014 06:32 PM, Madhavan Srinivasan wrote:
>> > In mm/Kconfig, put
>> >
>> >config FAULT_AROUND_ORDER
>> >int
>> >default 1234 if POWERPC
>> >default 4
>> >
>> > The way you have it now, every single architecture that needs to enable
>> > this has t
On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote:
> This patch creates infrastructure to move the FAULT_AROUND_ORDER
> to arch/ using Kconfig. This will enable architecture maintainers
> to decide on suitable FAULT_AROUND_ORDER value based on
> performance data for that architecture. Patch also ad
On 03/25/2014 10:36 AM, Kirill A. Shutemov wrote:
>> > +/*
>> > + * Fault around order is a control knob to decide the fault around pages.
>> > + * Default value is set to 0UL (disabled), but the arch can override it as
>> > + * desired.
>> > + */
>> > +#ifndef FAULT_AROUND_ORDER
>> > +#define FAUL
On 07/11/2012 09:52 PM, Yasuaki Ishimatsu wrote:
> Does the following patch include your comment? If O.K., I will separate
> the patch from the series and send it for bug fix.
Looks sane to me. It does now mean that the calling conventions for
some of the other firmware_map*() functions are diffe
On 07/09/2012 03:25 AM, Yasuaki Ishimatsu wrote:
> @@ -642,7 +642,7 @@ int __ref add_memory(int nid, u64 start,
> }
>
> /* create new memmap entry */
> - firmware_map_add_hotplug(start, start + size, "System RAM");
> + firmware_map_add_hotplug(start, start + size - 1, "System R
On 01/26/2012 01:39 PM, Benjamin Herrenschmidt wrote:
> Can you explain to me a bit more the whole business in this patch set
> about doing kmap_atomic() vs. manually trying to populate the PTEs ?
They're compressing pages and the allocator is trying getting very poor
packing of compressed pages
On Tue, 2011-10-11 at 18:24 +0530, Suzuki Poulose wrote:
> On 10/10/11 23:30, Scott Wood wrote:
> > On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
> >> #if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
> >> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) - PHYSICAL_START
> >> + (K
On Wed, 2011-10-05 at 18:19 +0530, Suzuki Poulose wrote:
> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) -
> PHYSICAL_START + KERNELBASE)
>
> where,
> PHYSICAL_START is #define'd to kernstart_addr variable, updated at
> boot
Wh
On Wed, 2011-06-29 at 20:21 +1000, Paul Mackerras wrote:
> +struct kvmppc_pginfo {
> + unsigned long pfn;
> + atomic_t refcnt;
> +};
I only see this refcnt inc'd in one spot and never decremented or read.
Is the refcnt just the number of hptes we have for this particular page
at the momen
On Thu, 2011-01-20 at 08:45 -0800, Greg KH wrote:
> On Thu, Jan 20, 2011 at 10:36:40AM -0600, Nathan Fontenot wrote:
> > The root of this issue is in sysfs directory creation. Every time
> > a directory is created a string compare is done against sibling
> > directories ( see sysfs_find_dirent() )
On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote:
> On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
> > * Nathan Fontenot [2010-10-01 13:35:54]:
> >
> > > Define a version of memory_block_size_bytes() for powerpc/pseries such
> > > that
> > > a memory block spans an entire lmb.
On Tue, 2010-09-28 at 04:29 -0500, Robin Holt wrote:
> Also, I don't think I much care for the weirdness that occurs if a
> memory block spans two nodes. I have not thought through how possible
> (or likely) this is, but the code certainly permits it. If that were
> the case, how would we know wh
On Tue, 2010-09-28 at 14:44 +0200, Avi Kivity wrote:
> Why not update sysfs directory creation to be fast, for example by using
> an rbtree instead of a linked list. This fixes an implementation
> problem in the kernel instead of working around it and creating a new ABI.
>
> New ABIs mean old t
On Mon, 2010-09-27 at 14:25 -0500, Nathan Fontenot wrote:
> +static inline int base_memory_block_id(int section_nr)
> +{
> + return section_nr / sections_per_block;
> +}
...
> - mutex_lock(&mem_sysfs_mutex);
> -
> - mem->phys_index = __section_nr(section);
> + scn_nr = __sec
On Wed, 2010-09-22 at 13:40 -0500, Nathan Fontenot wrote:
> On 09/22/2010 10:20 AM, Dave Hansen wrote:
> >and phys_index's calculation needs to be:
> >
> > mem->start_phys_index * SECTION_SIZE / memory_block_size_bytes()
>
>
On Wed, 2010-09-22 at 09:15 -0500, Nathan Fontenot wrote:
> For architectures that define their own version of this routine,
> as is done for powerpc in this patchset, the view in userspace
> would change such that each memoryXXX directory would span
> multiple memory sections. The number of secti
On Mon, 2010-08-16 at 09:34 -0500, Nathan Fontenot wrote:
> > It's not an unresolvable issue, as this is a must-fix problem. But you
> > should tell us what your proposal is to prevent breakage of existing
> > installations. A Kconfig option would be good, but a boot-time kernel
> > command line
101 - 200 of 268 matches
Mail list logo
