* Re: [PATCH] mm/hugetlb: Fix build failure with HUGETLB_PAGE but not HUGEBTLBFS
From: Christophe Leroy @ 2020-03-17 16:47 UTC (permalink / raw)
To: Mike Kravetz, Baoquan He
Cc: Nick Piggin, Andi Kleen, linux-kernel, linux-mm, Adam Litke,
Nishanth Aravamudan, Andrew Morton, linuxppc-dev
In-Reply-To: <a31c86c9-2f86-4f40-a367-5953037ee137@oracle.com>
Le 17/03/2020 à 17:40, Mike Kravetz a écrit :
> On 3/17/20 1:43 AM, Christophe Leroy wrote:
>>
>>
>> Le 17/03/2020 à 09:25, Baoquan He a écrit :
>>> On 03/17/20 at 08:04am, Christophe Leroy wrote:
>>>> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
>>>> following build failure is encoutered:
>>>
>>> From the definition of HUGETLB_PAGE, isn't it relying on HUGETLBFS?
>>> I could misunderstand the def_bool, please correct me if I am wrong.
>>
>> AFAIU, it means that HUGETLBFS rely on HUGETLB_PAGE, by default HUGETLB_PAGE is not selected when HUGETLBFS is not. But it is still possible for an arch to select HUGETLB_PAGE without selecting HUGETLBFS when it uses huge pages for other purpose than hugetlb file system.
>>
>
> Hi Christophe,
>
> Do you actually have a use case/example of using hugetlb pages without
> hugetlbfs? I can understand that there are some use cases which never
> use the filesystem interface. However, hugetlb support is so intertwined
> with hugetlbfs, I am thinking there would be issues trying to use them
> separately. I will look into this further.
>
Hi Mike,
Series https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=164620
And especially patch 39 to 41.
Thanks
Christophe
^ permalink raw reply
* Re: Slub: Increased mem consumption on cpu,mem-less node powerpc guest
From: Vlastimil Babka @ 2020-03-17 16:45 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Sachin Sant, Andrew Morton, linuxppc-dev, aneesh.kumar, bharata,
Pekka Enberg, linux-mm, David Rientjes, Christoph Lameter,
Michal Hocko, Joonsoo Kim
In-Reply-To: <20200317162536.GB27520@linux.vnet.ibm.com>
On 3/17/20 5:25 PM, Srikar Dronamraju wrote:
> * Vlastimil Babka <vbabka@suse.cz> [2020-03-17 16:56:04]:
>
>>
>> I wonder why do you get a memory leak while Sachin in the same situation [1]
>> gets a crash? I don't understand anything anymore.
>
> Sachin was testing on linux-next which has Kirill's patch which modifies
> slub to use kmalloc_node instead of kmalloc. While Bharata is testing on
> upstream, which doesn't have this.
Yes, that Kirill's patch was about the memcg shrinker map allocation. But the
patch hunk that Bharata posted as a "hack" that fixes the problem, it follows
that there has to be something else that calls kmalloc_node(node) where node is
one that doesn't have present pages.
He mentions alloc_fair_sched_group() which has:
for_each_possible_cpu(i) {
cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
GFP_KERNEL, cpu_to_node(i));
...
se = kzalloc_node(sizeof(struct sched_entity),
GFP_KERNEL, cpu_to_node(i));
I assume one of these structs is 1k and other 512 bytes (rounded) and that for
some possible cpu's cpu_to_node(i) will be 0, which has no present pages. And as
Bharata pasted, node_to_mem_node(0) = 0
So this looks like the same scenario, but it doesn't crash? Is the node 0
actually online here, and/or does it have N_NORMAL_MEMORY state?
>>
>> [1]
>> https://lore.kernel.org/linux-next/3381CD91-AB3D-4773-BA04-E7A072A63968@linux.vnet.ibm.com/
>>
>
^ permalink raw reply
* Re: [PATCH 2/4] mm/slub: Use mem_node to allocate a new slab
From: Srikar Dronamraju @ 2020-03-17 16:41 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Sachin Sant, Michal Hocko, linux-mm, Kirill Tkhai, Mel Gorman,
Joonsoo Kim, Andrew Morton, Bharata B Rao, linuxppc-dev,
Christopher Lameter
In-Reply-To: <ef34b0bb-4dfa-cb0e-1830-9ad59119da5e@suse.cz>
* Vlastimil Babka <vbabka@suse.cz> [2020-03-17 14:34:25]:
>
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1970,14 +1970,8 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
> > struct kmem_cache_cpu *c)
> > {
> > void *object;
> > - int searchnode = node;
> >
> > - if (node == NUMA_NO_NODE)
> > - searchnode = numa_mem_id();
> > - else if (!node_present_pages(node))
> > - searchnode = node_to_mem_node(node);
> > -
> > - object = get_partial_node(s, get_node(s, searchnode), c, flags);
> > + object = get_partial_node(s, get_node(s, node), c, flags);
> > if (object || node != NUMA_NO_NODE)> return object;
> >
> > return get_any_partial(s, flags, c);
>
> I.e. here in this if(), now node will never equal NUMA_NO_NODE (thanks to the
> hunk below), thus the get_any_partial() call becomes dead code?
Very true.
Would it be okay if we remove the node != NUMA_NO_NODE
if (object || node != NUMA_NO_NODE)
return object;
will now become
if (object)
return object;
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH] mm/hugetlb: Fix build failure with HUGETLB_PAGE but not HUGEBTLBFS
From: Mike Kravetz @ 2020-03-17 16:40 UTC (permalink / raw)
To: Christophe Leroy, Baoquan He
Cc: Nick Piggin, Andi Kleen, linux-kernel, linux-mm, Adam Litke,
Nishanth Aravamudan, Andrew Morton, linuxppc-dev
In-Reply-To: <60117fd7-46ff-326b-34f1-0c7087111ca7@c-s.fr>
On 3/17/20 1:43 AM, Christophe Leroy wrote:
>
>
> Le 17/03/2020 à 09:25, Baoquan He a écrit :
>> On 03/17/20 at 08:04am, Christophe Leroy wrote:
>>> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
>>> following build failure is encoutered:
>>
>> From the definition of HUGETLB_PAGE, isn't it relying on HUGETLBFS?
>> I could misunderstand the def_bool, please correct me if I am wrong.
>
> AFAIU, it means that HUGETLBFS rely on HUGETLB_PAGE, by default HUGETLB_PAGE is not selected when HUGETLBFS is not. But it is still possible for an arch to select HUGETLB_PAGE without selecting HUGETLBFS when it uses huge pages for other purpose than hugetlb file system.
>
Hi Christophe,
Do you actually have a use case/example of using hugetlb pages without
hugetlbfs? I can understand that there are some use cases which never
use the filesystem interface. However, hugetlb support is so intertwined
with hugetlbfs, I am thinking there would be issues trying to use them
separately. I will look into this further.
--
Mike Kravetz
^ permalink raw reply
* Re: [PATCH v2 5/8] hv_balloon: don't check for memhp_auto_online manually
From: David Hildenbrand @ 2020-03-17 16:33 UTC (permalink / raw)
To: Vitaly Kuznetsov, linux-kernel
Cc: linux-hyperv, Stephen Hemminger, Baoquan He, Rafael J. Wysocki,
Haiyang Zhang, Wei Liu, Michal Hocko, linux-mm, Wei Yang,
Andrew Morton, K. Y. Srinivasan, linuxppc-dev, Oscar Salvador
In-Reply-To: <877dzj3pyi.fsf@vitty.brq.redhat.com>
On 17.03.20 17:29, Vitaly Kuznetsov wrote:
> David Hildenbrand <david@redhat.com> writes:
>
>> We get the MEM_ONLINE notifier call if memory is added right from the
>> kernel via add_memory() or later from user space.
>>
>> Let's get rid of the "ha_waiting" flag - the wait event has an inbuilt
>> mechanism (->done) for that. Initialize the wait event only once and
>> reinitialize before adding memory. Unconditionally call complete() and
>> wait_for_completion_timeout().
>>
>> If there are no waiters, complete() will only increment ->done - which
>> will be reset by reinit_completion(). If complete() has already been
>> called, wait_for_completion_timeout() will not wait.
>>
>> There is still the chance for a small race between concurrent
>> reinit_completion() and complete(). If complete() wins, we would not
>> wait - which is tolerable (and the race exists in current code as
>> well).
>
> How can we see concurent reinit_completion() and complete()? Obvioulsy,
> we are not onlining new memory in kernel and hv_mem_hot_add() calls are
> serialized, we're waiting up to 5*HZ for the added block to come online
> before proceeding to the next one. Or do you mean we actually hit this
> 5*HZ timeout, proceeded to the next block and immediately after
> reinit_completion() we saw complete() for the previously added block?
Yes exactly - or if an admin manually offlines+re-onlines a random
memory block.
> This is tolerable indeed, we're making forward progress (and this all is
> 'best effort' anyway).
Exactly my thoughts.
[...]
>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 5/8] hv_balloon: don't check for memhp_auto_online manually
From: Vitaly Kuznetsov @ 2020-03-17 16:29 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: linux-hyperv, Stephen Hemminger, Baoquan He, David Hildenbrand,
Haiyang Zhang, Rafael J. Wysocki, Wei Liu, Michal Hocko, linux-mm,
Wei Yang, Andrew Morton, K. Y. Srinivasan, linuxppc-dev,
Oscar Salvador
In-Reply-To: <20200317104942.11178-6-david@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> We get the MEM_ONLINE notifier call if memory is added right from the
> kernel via add_memory() or later from user space.
>
> Let's get rid of the "ha_waiting" flag - the wait event has an inbuilt
> mechanism (->done) for that. Initialize the wait event only once and
> reinitialize before adding memory. Unconditionally call complete() and
> wait_for_completion_timeout().
>
> If there are no waiters, complete() will only increment ->done - which
> will be reset by reinit_completion(). If complete() has already been
> called, wait_for_completion_timeout() will not wait.
>
> There is still the chance for a small race between concurrent
> reinit_completion() and complete(). If complete() wins, we would not
> wait - which is tolerable (and the race exists in current code as
> well).
How can we see concurent reinit_completion() and complete()? Obvioulsy,
we are not onlining new memory in kernel and hv_mem_hot_add() calls are
serialized, we're waiting up to 5*HZ for the added block to come online
before proceeding to the next one. Or do you mean we actually hit this
5*HZ timeout, proceeded to the next block and immediately after
reinit_completion() we saw complete() for the previously added block?
This is tolerable indeed, we're making forward progress (and this all is
'best effort' anyway).
>
> Note: We only wait for "some" memory to get onlined, which seems to be
> good enough for now.
>
> Cc: "K. Y. Srinivasan" <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Cc: Wei Liu <wei.liu@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: linux-hyperv@vger.kernel.org
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/hv/hv_balloon.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index a02ce43d778d..af5e09f08130 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -533,7 +533,6 @@ struct hv_dynmem_device {
> * State to synchronize hot-add.
> */
> struct completion ol_waitevent;
> - bool ha_waiting;
> /*
> * This thread handles hot-add
> * requests from the host as well as notifying
> @@ -634,10 +633,7 @@ static int hv_memory_notifier(struct notifier_block *nb, unsigned long val,
> switch (val) {
> case MEM_ONLINE:
> case MEM_CANCEL_ONLINE:
> - if (dm_device.ha_waiting) {
> - dm_device.ha_waiting = false;
> - complete(&dm_device.ol_waitevent);
> - }
> + complete(&dm_device.ol_waitevent);
> break;
>
> case MEM_OFFLINE:
> @@ -726,8 +722,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
> has->covered_end_pfn += processed_pfn;
> spin_unlock_irqrestore(&dm_device.ha_lock, flags);
>
> - init_completion(&dm_device.ol_waitevent);
> - dm_device.ha_waiting = !memhp_auto_online;
> + reinit_completion(&dm_device.ol_waitevent);
>
> nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
> ret = add_memory(nid, PFN_PHYS((start_pfn)),
> @@ -753,15 +748,14 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
> }
>
> /*
> - * Wait for the memory block to be onlined when memory onlining
> - * is done outside of kernel (memhp_auto_online). Since the hot
> - * add has succeeded, it is ok to proceed even if the pages in
> - * the hot added region have not been "onlined" within the
> - * allowed time.
> + * Wait for memory to get onlined. If the kernel onlined the
> + * memory when adding it, this will return directly. Otherwise,
> + * it will wait for user space to online the memory. This helps
> + * to avoid adding memory faster than it is getting onlined. As
> + * adding succeeded, it is ok to proceed even if the memory was
> + * not onlined in time.
> */
> - if (dm_device.ha_waiting)
> - wait_for_completion_timeout(&dm_device.ol_waitevent,
> - 5*HZ);
> + wait_for_completion_timeout(&dm_device.ol_waitevent, 5 * HZ);
> post_status(&dm_device);
> }
> }
> @@ -1707,6 +1701,7 @@ static int balloon_probe(struct hv_device *dev,
> #ifdef CONFIG_MEMORY_HOTPLUG
> set_online_page_callback(&hv_online_page);
> register_memory_notifier(&hv_memory_nb);
> + init_completion(&dm_device.ol_waitevent);
> #endif
>
> hv_set_drvdata(dev, &dm_device);
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
--
Vitaly
^ permalink raw reply
* Re: Slub: Increased mem consumption on cpu,mem-less node powerpc guest
From: Srikar Dronamraju @ 2020-03-17 16:25 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Sachin Sant, Andrew Morton, linuxppc-dev, aneesh.kumar, bharata,
Pekka Enberg, linux-mm, David Rientjes, Christoph Lameter,
Michal Hocko, Joonsoo Kim
In-Reply-To: <4088ae3c-4dfa-62ae-f56a-b46773788fc7@suse.cz>
* Vlastimil Babka <vbabka@suse.cz> [2020-03-17 16:56:04]:
>
> I wonder why do you get a memory leak while Sachin in the same situation [1]
> gets a crash? I don't understand anything anymore.
Sachin was testing on linux-next which has Kirill's patch which modifies
slub to use kmalloc_node instead of kmalloc. While Bharata is testing on
upstream, which doesn't have this.
>
> [1]
> https://lore.kernel.org/linux-next/3381CD91-AB3D-4773-BA04-E7A072A63968@linux.vnet.ibm.com/
>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v1 16/46] powerpc/mm: Allocate static page tables for fixmap
From: Luc Van Oostenryck @ 2020-03-17 16:00 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <b9c92137-f757-1e6a-bca9-5c522e1083c5@c-s.fr>
On Tue, Mar 17, 2020 at 03:38:46PM +0100, Christophe Leroy wrote:
> > diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> > index f62de06e3d07..9934659cb871 100644
> > --- a/arch/powerpc/mm/pgtable_32.c
> > +++ b/arch/powerpc/mm/pgtable_32.c
> > @@ -29,11 +29,27 @@
> > #include <asm/fixmap.h>
> > #include <asm/setup.h>
> > #include <asm/sections.h>
> > +#include <asm/early_ioremap.h>
> > #include <mm/mmu_decl.h>
> > extern char etext[], _stext[], _sinittext[], _einittext[];
> > +static u8 early_fixmap_pagetable[FIXMAP_PTE_SIZE] __page_aligned_data;
>
> Sparse reports this as a variable size array. This is definitely not. Gcc
> properly sees it is an 8k table (2 pages).
Yes, thing is that FIXMAP_PTE_SIZE is not that constant since it uses
__builtin_ffs() (via PTE_SHIFT / PTE_T_LOG2).
Nevertheless, since Sparse v0.6.1 (released in October) accepts these
in constant expressions, like GCC does.
-- Luc
^ permalink raw reply
* Re: Slub: Increased mem consumption on cpu,mem-less node powerpc guest
From: Vlastimil Babka @ 2020-03-17 15:56 UTC (permalink / raw)
To: bharata, linux-mm
Cc: Sachin Sant, Andrew Morton, aneesh.kumar, Michal Hocko,
Pekka Enberg, linuxppc-dev, David Rientjes, Christoph Lameter,
Joonsoo Kim, srikar
In-Reply-To: <20200317115339.GA26049@in.ibm.com>
On 3/17/20 12:53 PM, Bharata B Rao wrote:
> On Tue, Mar 17, 2020 at 02:56:28PM +0530, Bharata B Rao wrote:
>> Case 1: 2 node NUMA, node0 empty
>> ================================
>> # numactl -H
>> available: 2 nodes (0-1)
>> node 0 cpus:
>> node 0 size: 0 MB
>> node 0 free: 0 MB
>> node 1 cpus: 0 1 2 3 4 5 6 7
>> node 1 size: 16294 MB
>> node 1 free: 15453 MB
>> node distances:
>> node 0 1
>> 0: 10 40
>> 1: 40 10
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index 17dc00e33115..888e4d245444 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -1971,10 +1971,8 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
>> void *object;
>> int searchnode = node;
>>
>> - if (node == NUMA_NO_NODE)
>> + if (node == NUMA_NO_NODE || !node_present_pages(node))
>> searchnode = numa_mem_id();
>> - else if (!node_present_pages(node))
>> - searchnode = node_to_mem_node(node);
>
> For the above topology, I see this:
>
> node_to_mem_node(1) = 1
> node_to_mem_node(0) = 0
> node_to_mem_node(NUMA_NO_NODE) = 0
>
> Looks like the last two cases (returning memory-less node 0) is the
> problem here?
I wonder why do you get a memory leak while Sachin in the same situation [1]
gets a crash? I don't understand anything anymore.
[1]
https://lore.kernel.org/linux-next/3381CD91-AB3D-4773-BA04-E7A072A63968@linux.vnet.ibm.com/
> Regards,
> Bharata.
>
>
^ permalink raw reply
* Re: [PATCH] tpm2: Export tpm2_get_cc_attrs_tbl for ibmvtpm driver as module
From: Stefan Berger @ 2020-03-17 15:30 UTC (permalink / raw)
To: Sachin Sant, Stefan Berger
Cc: LKML, jarkko.sakkinen, Linux Next Mailing List, linux-integrity,
linuxppc-dev
In-Reply-To: <03C24A2B-643D-4CDB-99FA-F5321684EEE4@linux.vnet.ibm.com>
On 3/17/20 11:22 AM, Sachin Sant wrote:
>> On 17-Mar-2020, at 6:38 PM, Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
>>
>> From: Stefan Berger <stefanb@linux.ibm.com>
>>
>> This patch fixes the following problem when the ibmvtpm driver
>> is built as a module:
>>
>> ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko] undefined!
>> make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
>> make: *** [Makefile:1298: modules] Error 2
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Thank you!
Stefan
^ permalink raw reply
* Re: [PATCH 2/4] mm/slub: Use mem_node to allocate a new slab
From: Vlastimil Babka @ 2020-03-17 15:29 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Sachin Sant, Michal Hocko, linux-mm, Kirill Tkhai, Mel Gorman,
Joonsoo Kim, Andrew Morton, Bharata B Rao, linuxppc-dev,
Christopher Lameter
In-Reply-To: <20200317145105.GA27520@linux.vnet.ibm.com>
On 3/17/20 3:51 PM, Srikar Dronamraju wrote:
> * Vlastimil Babka <vbabka@suse.cz> [2020-03-17 14:53:26]:
>
>> >> >
>> >> > Mitigate this by allocating the new slab from the node_numa_mem.
>> >>
>> >> Are you sure this is really needed and the other 3 patches are not enough for
>> >> the current SLUB code to work as needed? It seems you are changing the semantics
>> >> here...
>> >>
>> >
>> > The other 3 patches are not enough because we don't carry the searchnode
>> > when the actual alloc_pages_node gets called.
>> >
>> > With only the 3 patches, we see the above Panic, its signature is slightly
>> > different from what Sachin first reported and which I have carried in 1st
>> > patch.
>>
>> Ah, I see. So that's the missing pgdat after your series [1] right?
>
> Yes the pgdat would be missing after my cpuless, memoryless node patchset.
> However..
>>
>> That sounds like an argument for Michal's suggestions that pgdats exist and have
>> correctly populated zonelists for all possible nodes.
>
> Only the first patch in this series would be affected by pgdat existing or
> not. Even if the pgdat existed, the NODE_DATA[nid]->node_present_pages
> would be 0. Right? So it would look at node_to_mem_node(). And since node 0 is
> cpuless it would return 0.
I thought the point was to return 1 for node 0.
> If we pass this node 0 (which is memoryless/cpuless) to
> alloc_pages_node. Please note I am only setting node_numa_mem only
> for offline nodes. However we could change this to set for all offline and
> memoryless nodes.
That would indeed make sense.
But I guess that alloc_pages would still crash as the result of
numa_to_mem_node() is not passed down to alloc_pages() without this patch. In
__alloc_pages_node() we currently have "The node must be valid and online" so
offline nodes don't have zonelists. Either they get them, or we indeed need
something like this patch. But in order to not make get_any_partial() dead code,
the final replacement of invalid node with a valid one should be done in
alloc_slab_page() I guess?
>> node_to_mem_node() could be just a shortcut for the first zone's node in the
>> zonelist, so that fallback follows the topology.
>>
>> [1]
>> https://lore.kernel.org/linuxppc-dev/20200311110237.5731-1-srikar@linux.vnet.ibm.com/t/#m76e5b4c4084380b1d4b193d5aa0359b987f2290e
>>
>
>
>
^ permalink raw reply
* Re: [PATCH] tpm2: Export tpm2_get_cc_attrs_tbl for ibmvtpm driver as module
From: Sachin Sant @ 2020-03-17 15:22 UTC (permalink / raw)
To: Stefan Berger
Cc: LKML, jarkko.sakkinen, Linux Next Mailing List, linux-integrity,
linuxppc-dev, Stefan Berger
In-Reply-To: <20200317130819.720318-1-stefanb@linux.vnet.ibm.com>
> On 17-Mar-2020, at 6:38 PM, Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
>
> From: Stefan Berger <stefanb@linux.ibm.com>
>
> This patch fixes the following problem when the ibmvtpm driver
> is built as a module:
>
> ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
> make: *** [Makefile:1298: modules] Error 2
>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH v5 09/11] perf/tools: Enhance JSON/metric infrastructure to handle "?"
From: Jiri Olsa @ 2020-03-17 15:10 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200317062333.14555-10-kjain@linux.ibm.com>
On Tue, Mar 17, 2020 at 11:53:31AM +0530, Kajol Jain wrote:
SBIP
> +static int metricgroup__add_metric_runtime_param(struct strbuf *events,
> + struct list_head *group_list, struct pmu_event *pe)
> +{
> + int i, count;
> + int ret = -EINVAL;
> +
> + count = arch_get_runtimeparam();
> +
> + /* This loop is added to create multiple
> + * events depend on count value and add
> + * those events to group_list.
> + */
> +
> + for (i = 0; i < count; i++) {
> + const char **ids;
> + int idnum;
> + struct egroup *eg;
> + char value[PATH_MAX];
> +
> + if (expr__find_other(pe->metric_expr, NULL, &ids, &idnum, i) < 0)
> + return ret;
> +
> + if (events->len > 0)
> + strbuf_addf(events, ",");
> +
> + if (metricgroup__has_constraint(pe))
> + metricgroup__add_metric_non_group(events, ids, idnum);
> + else
> + metricgroup__add_metric_weak_group(events, ids, idnum);
> +
> + eg = malloc(sizeof(*eg));
> + if (!eg) {
> + ret = -ENOMEM;
> + return ret;
> + }
> +
> + sprintf(value, "%s%c%d", pe->metric_name, '_', i);
> + eg->ids = ids;
> + eg->idnum = idnum;
> + eg->metric_name = strdup(value);
> + if (!eg->metric_name) {
> + ret = -ENOMEM;
> + return ret;
> + }
> +
> + eg->metric_expr = pe->metric_expr;
> + eg->metric_unit = pe->unit;
> + list_add_tail(&eg->nd, group_list);
> + ret = 0;
> +
> + if (ret != 0)
> + break;
again, this is part of metricgroup__add_metric_param no? why not use it?
jirka
^ permalink raw reply
* Re: [PATCH v5 08/11] perf/tools: Refactoring metricgroup__add_metric function
From: Jiri Olsa @ 2020-03-17 15:09 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200317062333.14555-9-kjain@linux.ibm.com>
On Tue, Mar 17, 2020 at 11:53:30AM +0530, Kajol Jain wrote:
> This patch refactor metricgroup__add_metric function where
> some part of it move to function metricgroup__add_metric_param.
> No logic change.
>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> tools/perf/util/metricgroup.c | 63 +++++++++++++++++++++--------------
> 1 file changed, 38 insertions(+), 25 deletions(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index c3a8c701609a..b4919bcfbd8b 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -474,6 +474,41 @@ static bool metricgroup__has_constraint(struct pmu_event *pe)
> return false;
> }
>
> +static int metricgroup__add_metric_param(struct strbuf *events,
> + struct list_head *group_list, struct pmu_event *pe)
> +{
> +
> + const char **ids;
> + int idnum;
> + struct egroup *eg;
> + int ret = -EINVAL;
> +
> + if (expr__find_other(pe->metric_expr, NULL, &ids, &idnum, 1) < 0)
> + return ret;
> +
> + if (events->len > 0)
> + strbuf_addf(events, ",");
> +
> + if (metricgroup__has_constraint(pe))
> + metricgroup__add_metric_non_group(events, ids, idnum);
> + else
> + metricgroup__add_metric_weak_group(events, ids, idnum);
> +
> + eg = malloc(sizeof(*eg));
> + if (!eg)
> + ret = -ENOMEM;
> +
> + eg->ids = ids;
> + eg->idnum = idnum;
> + eg->metric_name = pe->metric_name;
> + eg->metric_expr = pe->metric_expr;
> + eg->metric_unit = pe->unit;
> + list_add_tail(&eg->nd, group_list);
> + ret = 0;
> +
> + return ret;
return 0;
jirka
^ permalink raw reply
* Re: [PATCH v5 08/11] perf/tools: Refactoring metricgroup__add_metric function
From: Jiri Olsa @ 2020-03-17 15:10 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200317062333.14555-9-kjain@linux.ibm.com>
On Tue, Mar 17, 2020 at 11:53:30AM +0530, Kajol Jain wrote:
> This patch refactor metricgroup__add_metric function where
> some part of it move to function metricgroup__add_metric_param.
> No logic change.
>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> tools/perf/util/metricgroup.c | 63 +++++++++++++++++++++--------------
> 1 file changed, 38 insertions(+), 25 deletions(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index c3a8c701609a..b4919bcfbd8b 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -474,6 +474,41 @@ static bool metricgroup__has_constraint(struct pmu_event *pe)
> return false;
> }
>
> +static int metricgroup__add_metric_param(struct strbuf *events,
> + struct list_head *group_list, struct pmu_event *pe)
> +{
> +
> + const char **ids;
> + int idnum;
> + struct egroup *eg;
> + int ret = -EINVAL;
> +
> + if (expr__find_other(pe->metric_expr, NULL, &ids, &idnum, 1) < 0)
> + return ret;
> +
> + if (events->len > 0)
> + strbuf_addf(events, ",");
> +
> + if (metricgroup__has_constraint(pe))
> + metricgroup__add_metric_non_group(events, ids, idnum);
> + else
> + metricgroup__add_metric_weak_group(events, ids, idnum);
> +
> + eg = malloc(sizeof(*eg));
> + if (!eg)
> + ret = -ENOMEM;
??? you need to return in here, eg is NULL
> +
> + eg->ids = ids;
> + eg->idnum = idnum;
> + eg->metric_name = pe->metric_name;
> + eg->metric_expr = pe->metric_expr;
> + eg->metric_unit = pe->unit;
> + list_add_tail(&eg->nd, group_list);
> + ret = 0;
> +
> + return ret;
> +}
> +
> static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> struct list_head *group_list)
> {
> @@ -493,35 +528,13 @@ static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> continue;
> if (match_metric(pe->metric_group, metric) ||
> match_metric(pe->metric_name, metric)) {
> - const char **ids;
> - int idnum;
> - struct egroup *eg;
>
> pr_debug("metric expr %s for %s\n", pe->metric_expr, pe->metric_name);
>
> - if (expr__find_other(pe->metric_expr,
> - NULL, &ids, &idnum) < 0)
> + ret = metricgroup__add_metric_param(events,
> + group_list, pe);
> + if (ret == -EINVAL)
> continue;
previous code did 'continue' on ret < 0, why just -EINVAL now?
jirka
^ permalink raw reply
* Re: [PATCH v5 08/11] perf/tools: Refactoring metricgroup__add_metric function
From: Jiri Olsa @ 2020-03-17 15:09 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200317062333.14555-9-kjain@linux.ibm.com>
On Tue, Mar 17, 2020 at 11:53:30AM +0530, Kajol Jain wrote:
> This patch refactor metricgroup__add_metric function where
> some part of it move to function metricgroup__add_metric_param.
> No logic change.
can't compile this change:
[jolsa@krava perf]$ make JOBS=1
BUILD: Doing 'make -j1' parallel build
CC util/metricgroup.o
util/metricgroup.c: In function ‘metricgroup__add_metric_param’:
util/metricgroup.c:486:6: error: too many arguments to function ‘expr__find_other’
486 | if (expr__find_other(pe->metric_expr, NULL, &ids, &idnum, 1) < 0)
| ^~~~~~~~~~~~~~~~
In file included from util/metricgroup.c:14:
util/expr.h:25:5: note: declared here
25 | int expr__find_other(const char *expr, const char *one, const char ***other,
| ^~~~~~~~~~~~~~~~
mv: cannot stat 'util/.metricgroup.o.tmp': No such file or directory
make[4]: *** [/home/jolsa/kernel/linux-perf/tools/build/Makefile.build:97: util/metricgroup.o] Error 1
make[3]: *** [/home/jolsa/kernel/linux-perf/tools/build/Makefile.build:139: util] Error 2
make[2]: *** [Makefile.perf:616: perf-in.o] Error 2
make[1]: *** [Makefile.perf:225: sub-make] Error 2
make: *** [Makefile:70: all] Error 2
jirka
>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> tools/perf/util/metricgroup.c | 63 +++++++++++++++++++++--------------
> 1 file changed, 38 insertions(+), 25 deletions(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index c3a8c701609a..b4919bcfbd8b 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -474,6 +474,41 @@ static bool metricgroup__has_constraint(struct pmu_event *pe)
> return false;
> }
>
> +static int metricgroup__add_metric_param(struct strbuf *events,
> + struct list_head *group_list, struct pmu_event *pe)
> +{
> +
> + const char **ids;
> + int idnum;
> + struct egroup *eg;
> + int ret = -EINVAL;
> +
> + if (expr__find_other(pe->metric_expr, NULL, &ids, &idnum, 1) < 0)
> + return ret;
> +
> + if (events->len > 0)
> + strbuf_addf(events, ",");
> +
> + if (metricgroup__has_constraint(pe))
> + metricgroup__add_metric_non_group(events, ids, idnum);
> + else
> + metricgroup__add_metric_weak_group(events, ids, idnum);
> +
> + eg = malloc(sizeof(*eg));
> + if (!eg)
> + ret = -ENOMEM;
> +
> + eg->ids = ids;
> + eg->idnum = idnum;
> + eg->metric_name = pe->metric_name;
> + eg->metric_expr = pe->metric_expr;
> + eg->metric_unit = pe->unit;
> + list_add_tail(&eg->nd, group_list);
> + ret = 0;
> +
> + return ret;
> +}
> +
> static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> struct list_head *group_list)
> {
> @@ -493,35 +528,13 @@ static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> continue;
> if (match_metric(pe->metric_group, metric) ||
> match_metric(pe->metric_name, metric)) {
> - const char **ids;
> - int idnum;
> - struct egroup *eg;
>
> pr_debug("metric expr %s for %s\n", pe->metric_expr, pe->metric_name);
>
> - if (expr__find_other(pe->metric_expr,
> - NULL, &ids, &idnum) < 0)
> + ret = metricgroup__add_metric_param(events,
> + group_list, pe);
> + if (ret == -EINVAL)
> continue;
> - if (events->len > 0)
> - strbuf_addf(events, ",");
> -
> - if (metricgroup__has_constraint(pe))
> - metricgroup__add_metric_non_group(events, ids, idnum);
> - else
> - metricgroup__add_metric_weak_group(events, ids, idnum);
> -
> - eg = malloc(sizeof(struct egroup));
> - if (!eg) {
> - ret = -ENOMEM;
> - break;
> - }
> - eg->ids = ids;
> - eg->idnum = idnum;
> - eg->metric_name = pe->metric_name;
> - eg->metric_expr = pe->metric_expr;
> - eg->metric_unit = pe->unit;
> - list_add_tail(&eg->nd, group_list);
> - ret = 0;
> }
> }
> return ret;
> --
> 2.18.1
>
^ permalink raw reply
* Re: [PATCH v5 09/11] perf/tools: Enhance JSON/metric infrastructure to handle "?"
From: Jiri Olsa @ 2020-03-17 15:07 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200317062333.14555-10-kjain@linux.ibm.com>
On Tue, Mar 17, 2020 at 11:53:31AM +0530, Kajol Jain wrote:
SNIP
> diff --git a/tools/perf/arch/powerpc/util/header.c b/tools/perf/arch/powerpc/util/header.c
> index 3b4cdfc5efd6..dcc3c6ab2e67 100644
> --- a/tools/perf/arch/powerpc/util/header.c
> +++ b/tools/perf/arch/powerpc/util/header.c
> @@ -7,6 +7,8 @@
> #include <string.h>
> #include <linux/stringify.h>
> #include "header.h"
> +#include "metricgroup.h"
> +#include <api/fs/fs.h>
>
> #define mfspr(rn) ({unsigned long rval; \
> asm volatile("mfspr %0," __stringify(rn) \
> @@ -16,6 +18,8 @@
> #define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
> #define PVR_REV(pvr) (((pvr) >> 0) & 0xFFFF) /* Revison field */
>
> +#define SOCKETS_INFO_FILE_PATH "/devices/hv_24x7/interface/sockets"
> +
> int
> get_cpuid(char *buffer, size_t sz)
> {
> @@ -44,3 +48,9 @@ get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
>
> return bufp;
> }
> +
> +int arch_get_runtimeparam(void)
> +{
> + int count;
> + return sysfs__read_int(SOCKETS_INFO_FILE_PATH, &count) < 0 ? 1 : count;
is that SOCKETS_INFO_FILE_PATH define used later? if not please
put the path directly as an argument to sysfs__read_int
jirka
^ permalink raw reply
* Re: [PATCH v5 09/11] perf/tools: Enhance JSON/metric infrastructure to handle "?"
From: Jiri Olsa @ 2020-03-17 15:06 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200317062333.14555-10-kjain@linux.ibm.com>
On Tue, Mar 17, 2020 at 11:53:31AM +0530, Kajol Jain wrote:
SNIP
> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
> index 0938ad166ece..7786829b048b 100644
> --- a/tools/perf/util/expr.h
> +++ b/tools/perf/util/expr.h
> @@ -17,12 +17,13 @@ struct expr_parse_ctx {
>
> struct expr_scanner_ctx {
> int start_token;
> + int expr__runtimeparam;
no need for expr__ prefix in here.. jsut runtime_param
> diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
> index 402af3e8d287..85ac6d913782 100644
> --- a/tools/perf/util/stat-shadow.c
> +++ b/tools/perf/util/stat-shadow.c
> @@ -336,7 +336,7 @@ void perf_stat__collect_metric_expr(struct evlist *evsel_list)
> metric_events = counter->metric_events;
> if (!metric_events) {
> if (expr__find_other(counter->metric_expr, counter->name,
> - &metric_names, &num_metric_names) < 0)
> + &metric_names, &num_metric_names, 1) < 0)
> continue;
>
> metric_events = calloc(sizeof(struct evsel *),
> @@ -777,7 +777,15 @@ static void generic_metric(struct perf_stat_config *config,
> }
>
> if (!metric_events[i]) {
> - if (expr__parse(&ratio, &pctx, metric_expr) == 0) {
> + int param = 1;
> + if (strstr(metric_expr, "?")) {
> + char *tmp = strrchr(metric_name, '_');
> +
> + tmp++;
> + param = strtol(tmp, &tmp, 10);
> + }
so, if metric_expr contains '?' you go and search metric_name for '_'
and use the number after '_' ... ugh.. what's the logic?
I understand you create as many metrics as the magic runtime param
tells you.. but what's the connection to this?
could you please outline in the changelog or comment the whole scheme
of how this all should work? like step by step on some simple example?
thanks,
jirka
^ permalink raw reply
* Re: [PATCH 2/4] mm/slub: Use mem_node to allocate a new slab
From: Srikar Dronamraju @ 2020-03-17 14:51 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Sachin Sant, Michal Hocko, linux-mm, Kirill Tkhai, Mel Gorman,
Joonsoo Kim, Andrew Morton, Bharata B Rao, linuxppc-dev,
Christopher Lameter
In-Reply-To: <3d9629d4-4a6d-d2b5-28b7-58af497671c7@suse.cz>
* Vlastimil Babka <vbabka@suse.cz> [2020-03-17 14:53:26]:
> >> >
> >> > Mitigate this by allocating the new slab from the node_numa_mem.
> >>
> >> Are you sure this is really needed and the other 3 patches are not enough for
> >> the current SLUB code to work as needed? It seems you are changing the semantics
> >> here...
> >>
> >
> > The other 3 patches are not enough because we don't carry the searchnode
> > when the actual alloc_pages_node gets called.
> >
> > With only the 3 patches, we see the above Panic, its signature is slightly
> > different from what Sachin first reported and which I have carried in 1st
> > patch.
>
> Ah, I see. So that's the missing pgdat after your series [1] right?
Yes the pgdat would be missing after my cpuless, memoryless node patchset.
However..
>
> That sounds like an argument for Michal's suggestions that pgdats exist and have
> correctly populated zonelists for all possible nodes.
Only the first patch in this series would be affected by pgdat existing or
not. Even if the pgdat existed, the NODE_DATA[nid]->node_present_pages
would be 0. Right? So it would look at node_to_mem_node(). And since node 0 is
cpuless it would return 0. If we pass this node 0 (which is memoryless/cpuless) to
alloc_pages_node. Please note I am only setting node_numa_mem only
for offline nodes. However we could change this to set for all offline and
memoryless nodes.
> node_to_mem_node() could be just a shortcut for the first zone's node in the
> zonelist, so that fallback follows the topology.
>
> [1]
> https://lore.kernel.org/linuxppc-dev/20200311110237.5731-1-srikar@linux.vnet.ibm.com/t/#m76e5b4c4084380b1d4b193d5aa0359b987f2290e
>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v1 39/46] powerpc/8xx: Add a function to early map kernel via huge pages
From: Christophe Leroy @ 2020-03-17 14:43 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <202003170938.Z0IuUore%lkp@intel.com>
Le 17/03/2020 à 02:39, kbuild test robot a écrit :
> Hi Christophe,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on next-20200316]
> [cannot apply to powerpc/next v5.6-rc6 v5.6-rc5 v5.6-rc4 v5.6-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we 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/Christophe-Leroy/Use-hugepages-to-map-kernel-mem-on-8xx/20200317-065610
> base: 8548fd2f20ed19b0e8c0585b71fdfde1ae00ae3c
> config: powerpc-tqm8xx_defconfig (attached as .config)
> compiler: powerpc-linux-gcc (GCC) 9.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=9.2.0 make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> In file included from arch/powerpc/mm/fault.c:33:
> include/linux/hugetlb.h: In function 'hstate_inode':
>>> include/linux/hugetlb.h:522:9: error: implicit declaration of function 'HUGETLBFS_SB'; did you mean 'HUGETLBFS_MAGIC'? [-Werror=implicit-function-declaration]
> 522 | return HUGETLBFS_SB(i->i_sb)->hstate;
> | ^~~~~~~~~~~~
> | HUGETLBFS_MAGIC
>>> include/linux/hugetlb.h:522:30: error: invalid type argument of '->' (have 'int')
> 522 | return HUGETLBFS_SB(i->i_sb)->hstate;
> | ^~
> cc1: all warnings being treated as errors
hstate_inode() shouldn't use HUGETLBFS_SB() which CONFIG_HUGETLBFS is
not set.
Proposed fix at https://patchwork.ozlabs.org/patch/1256108/
[...]
>>> include/linux/hugetlb.h:522:30: error: invalid type argument of '->' (have 'int')
> 522 | return HUGETLBFS_SB(i->i_sb)->hstate;
> | ^~
> At top level:
> arch/powerpc//mm/nohash/8xx.c:73:18: error: '__early_map_kernel_hugepage' defined but not used [-Werror=unused-function]
> 73 | static int __ref __early_map_kernel_hugepage(unsigned long va, phys_addr_t pa,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
This patch is a preparation patch. The function is not used yet, that's
normal. Ok, it breaks bisectability. Should it be squashed with the
first user of the function ?
Christophe
^ permalink raw reply
* Re: [PATCH v1 16/46] powerpc/mm: Allocate static page tables for fixmap
From: Christophe Leroy @ 2020-03-17 14:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Luc Van Oostenryck
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d4bd46fe0103f8a8cb7e5affb2a7fcc3185be24e.1584360344.git.christophe.leroy@c-s.fr>
Le 16/03/2020 à 13:36, Christophe Leroy a écrit :
> Allocate static page tables for the fixmap area. This allows
> setting mappings through page tables before memblock is ready.
> That's needed to use early_ioremap() early and to use standard
> page mappings with fixmap.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/include/asm/fixmap.h | 4 ++++
> arch/powerpc/kernel/setup_32.c | 2 +-
> arch/powerpc/mm/pgtable_32.c | 16 ++++++++++++++++
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/fixmap.h b/arch/powerpc/include/asm/fixmap.h
> index 2ef155a3c821..ccbe2e83c950 100644
> --- a/arch/powerpc/include/asm/fixmap.h
> +++ b/arch/powerpc/include/asm/fixmap.h
> @@ -86,6 +86,10 @@ enum fixed_addresses {
> #define __FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
> #define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
>
> +#define FIXMAP_ALIGNED_SIZE (ALIGN(FIXADDR_TOP, PGDIR_SIZE) - \
> + ALIGN_DOWN(FIXADDR_START, PGDIR_SIZE))
> +#define FIXMAP_PTE_SIZE (FIXMAP_ALIGNED_SIZE / PGDIR_SIZE * PTE_TABLE_SIZE)
> +
> #define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_NCG
> #define FIXMAP_PAGE_IO PAGE_KERNEL_NCG
>
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index 5b49b26eb154..3f1e1c0b328a 100644
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -81,7 +81,7 @@ notrace void __init machine_init(u64 dt_ptr)
> /* Configure static keys first, now that we're relocated. */
> setup_feature_keys();
>
> - early_ioremap_setup();
> + early_ioremap_init();
>
> /* Enable early debugging if any specified (see udbg.h) */
> udbg_early_init();
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index f62de06e3d07..9934659cb871 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -29,11 +29,27 @@
> #include <asm/fixmap.h>
> #include <asm/setup.h>
> #include <asm/sections.h>
> +#include <asm/early_ioremap.h>
>
> #include <mm/mmu_decl.h>
>
> extern char etext[], _stext[], _sinittext[], _einittext[];
>
> +static u8 early_fixmap_pagetable[FIXMAP_PTE_SIZE] __page_aligned_data;
Sparse reports this as a variable size array. This is definitely not.
Gcc properly sees it is an 8k table (2 pages).
Christophe
> +
> +notrace void __init early_ioremap_init(void)
> +{
> + unsigned long addr = ALIGN_DOWN(FIXADDR_START, PGDIR_SIZE);
> + pte_t *ptep = (pte_t *)early_fixmap_pagetable;
> + pmd_t *pmdp = pmd_ptr_k(addr);
> +
> + for (; (s32)(FIXADDR_TOP - addr) > 0;
> + addr += PGDIR_SIZE, ptep += PTRS_PER_PTE, pmdp++)
> + pmd_populate_kernel(&init_mm, pmdp, ptep);
> +
> + early_ioremap_setup();
> +}
> +
> static void __init *early_alloc_pgtable(unsigned long size)
> {
> void *ptr = memblock_alloc(size, size);
>
Christophe
^ permalink raw reply
* Re: [PATCH 08/12] docs: fix broken references to text files
From: Mathieu Poirier @ 2020-03-17 14:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: kvm, Linux Doc Mailing List, Peter Zijlstra, Akira Yokosawa,
dri-devel, linux-unionfs, linux-mm, Harry Wei, Alex Shi,
Will Deacon, kvmarm, linux-arch, Jason Gunthorpe, Jonathan Corbet,
linux-rdma, kvm-ppc, David Airlie, Doug Ledford, Alan Stern,
linux-arm-kernel, Federico Vaga, Jade Alglave, Daniel Lustig,
Julien Thierry, Mike Leach, Andrea Parri, Daniel Vetter,
Paul E. McKenney, Suzuki K Poulose, Boqun Feng, Maarten Lankhorst,
Nicholas Piggin, Maxime Ripard, Luc Maranget, OGAWA Hirofumi,
David Howells, Miklos Szeredi, linux-kernel, Alexander Shishkin,
James Morse, Thomas Zimmermann, Marc Zyngier, linux-fsdevel,
Paolo Bonzini, Andrew Morton, linuxppc-dev
In-Reply-To: <35dcbefd50875b92aaf5b7671d4c57c50b4274fe.1584450500.git.mchehab+huawei@kernel.org>
On Tue, Mar 17, 2020 at 02:10:47PM +0100, Mauro Carvalho Chehab wrote:
> Several references got broken due to txt to ReST conversion.
>
> Several of them can be automatically fixed with:
>
> scripts/documentation-file-ref-check --fix
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> Documentation/memory-barriers.txt | 2 +-
> Documentation/process/submit-checklist.rst | 2 +-
> .../translations/it_IT/process/submit-checklist.rst | 2 +-
> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
> .../translations/zh_CN/filesystems/sysfs.txt | 2 +-
> .../translations/zh_CN/process/submit-checklist.rst | 2 +-
> Documentation/virt/kvm/arm/pvtime.rst | 2 +-
> Documentation/virt/kvm/devices/vcpu.rst | 2 +-
> Documentation/virt/kvm/hypercalls.rst | 4 ++--
> arch/powerpc/include/uapi/asm/kvm_para.h | 2 +-
> drivers/gpu/drm/Kconfig | 2 +-
> drivers/gpu/drm/drm_ioctl.c | 2 +-
> drivers/hwtracing/coresight/Kconfig | 2 +-
> fs/fat/Kconfig | 8 ++++----
> fs/fuse/Kconfig | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/overlayfs/Kconfig | 6 +++---
> include/linux/mm.h | 4 ++--
> include/uapi/linux/ethtool_netlink.h | 2 +-
> include/uapi/rdma/rdma_user_ioctl_cmds.h | 2 +-
> mm/gup.c | 12 ++++++------
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 2 +-
> virt/kvm/arm/vgic/vgic.h | 4 ++--
> 24 files changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index df34a4176e58..28be91d4e66b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -960,7 +960,7 @@
> edid/1680x1050.bin, or edid/1920x1080.bin is given
> and no file with the same name exists. Details and
> instructions how to build your own EDID data are
> - available in Documentation/driver-api/edid.rst. An EDID
> + available in Documentation/admin-guide/edid.rst. An EDID
> data set will only be used for a particular connector,
> if its name and a colon are prepended to the EDID
> name. Each connector may use a unique EDID data
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index e1c355e84edd..eaabc3134294 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -620,7 +620,7 @@ because the CPUs that the Linux kernel supports don't do writes
> until they are certain (1) that the write will actually happen, (2)
> of the location of the write, and (3) of the value to be written.
> But please carefully read the "CONTROL DEPENDENCIES" section and the
> -Documentation/RCU/rcu_dereference.txt file: The compiler can and does
> +Documentation/RCU/rcu_dereference.rst file: The compiler can and does
> break dependencies in a great many highly creative ways.
>
> CPU 1 CPU 2
> diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst
> index 8e56337d422d..3f8e9d5d95c2 100644
> --- a/Documentation/process/submit-checklist.rst
> +++ b/Documentation/process/submit-checklist.rst
> @@ -107,7 +107,7 @@ and elsewhere regarding submitting Linux kernel patches.
> and why.
>
> 26) If any ioctl's are added by the patch, then also update
> - ``Documentation/ioctl/ioctl-number.rst``.
> + ``Documentation/userspace-api/ioctl/ioctl-number.rst``.
>
> 27) If your modified source code depends on or uses any of the kernel
> APIs or features that are related to the following ``Kconfig`` symbols,
> diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst
> index 995ee69fab11..3e575502690f 100644
> --- a/Documentation/translations/it_IT/process/submit-checklist.rst
> +++ b/Documentation/translations/it_IT/process/submit-checklist.rst
> @@ -117,7 +117,7 @@ sottomissione delle patch, in particolare
> sorgenti che ne spieghi la logica: cosa fanno e perché.
>
> 25) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate
> - ``Documentation/ioctl/ioctl-number.rst``.
> + ``Documentation/userspace-api/ioctl/ioctl-number.rst``.
>
> 26) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o
> funzionalità del kernel che è associata a uno dei seguenti simboli
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> index 2e831ece6e26..e50fe6541335 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -641,7 +641,7 @@ P 는 짝수 번호 캐시 라인에 저장되어 있고, 변수 B 는 홀수
> 리눅스 커널이 지원하는 CPU 들은 (1) 쓰기가 정말로 일어날지, (2) 쓰기가 어디에
> 이루어질지, 그리고 (3) 쓰여질 값을 확실히 알기 전까지는 쓰기를 수행하지 않기
> 때문입니다. 하지만 "컨트롤 의존성" 섹션과
> -Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 바랍니다:
> +Documentation/RCU/rcu_dereference.rst 파일을 주의 깊게 읽어 주시기 바랍니다:
> 컴파일러는 매우 창의적인 많은 방법으로 종속성을 깰 수 있습니다.
>
> CPU 1 CPU 2
> diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt
> index ee1f37da5b23..a15c3ebdfa82 100644
> --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt
> +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt
> @@ -281,7 +281,7 @@ drivers/ 包含了每个已为特定总线上的设备而挂载的驱动程序
> 假定驱动没有跨越多个总线类型)。
>
> fs/ 包含了一个为文件系统设立的目录。现在每个想要导出属性的文件系统必须
> -在 fs/ 下创建自己的层次结构(参见Documentation/filesystems/fuse.txt)。
> +在 fs/ 下创建自己的层次结构(参见Documentation/filesystems/fuse.rst)。
>
> dev/ 包含两个子目录： char/ 和 block/。在这两个子目录中，有以
> <major>:<minor> 格式命名的符号链接。这些符号链接指向 sysfs 目录
> diff --git a/Documentation/translations/zh_CN/process/submit-checklist.rst b/Documentation/translations/zh_CN/process/submit-checklist.rst
> index 8738c55e42a2..50386e0e42e7 100644
> --- a/Documentation/translations/zh_CN/process/submit-checklist.rst
> +++ b/Documentation/translations/zh_CN/process/submit-checklist.rst
> @@ -97,7 +97,7 @@ Linux内核补丁提交清单
> 24) 所有内存屏障例如 ``barrier()``, ``rmb()``, ``wmb()`` 都需要源代码中的注
> 释来解释它们正在执行的操作及其原因的逻辑。
>
> -25) 如果补丁添加了任何ioctl，那么也要更新 ``Documentation/ioctl/ioctl-number.rst``
> +25) 如果补丁添加了任何ioctl，那么也要更新 ``Documentation/userspace-api/ioctl/ioctl-number.rst``
>
> 26) 如果修改后的源代码依赖或使用与以下 ``Kconfig`` 符号相关的任何内核API或
> 功能，则在禁用相关 ``Kconfig`` 符号和/或 ``=m`` （如果该选项可用）的情况
> diff --git a/Documentation/virt/kvm/arm/pvtime.rst b/Documentation/virt/kvm/arm/pvtime.rst
> index 2357dd2d8655..687b60d76ca9 100644
> --- a/Documentation/virt/kvm/arm/pvtime.rst
> +++ b/Documentation/virt/kvm/arm/pvtime.rst
> @@ -76,5 +76,5 @@ It is advisable that one or more 64k pages are set aside for the purpose of
> these structures and not used for other purposes, this enables the guest to map
> the region using 64k pages and avoids conflicting attributes with other memory.
>
> -For the user space interface see Documentation/virt/kvm/devices/vcpu.txt
> +For the user space interface see Documentation/virt/kvm/devices/vcpu.rst
> section "3. GROUP: KVM_ARM_VCPU_PVTIME_CTRL".
> diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
> index 9963e680770a..ca374d3fe085 100644
> --- a/Documentation/virt/kvm/devices/vcpu.rst
> +++ b/Documentation/virt/kvm/devices/vcpu.rst
> @@ -110,5 +110,5 @@ Returns:
>
> Specifies the base address of the stolen time structure for this VCPU. The
> base address must be 64 byte aligned and exist within a valid guest memory
> -region. See Documentation/virt/kvm/arm/pvtime.txt for more information
> +region. See Documentation/virt/kvm/arm/pvtime.rst for more information
> including the layout of the stolen time structure.
> diff --git a/Documentation/virt/kvm/hypercalls.rst b/Documentation/virt/kvm/hypercalls.rst
> index dbaf207e560d..ed4fddd364ea 100644
> --- a/Documentation/virt/kvm/hypercalls.rst
> +++ b/Documentation/virt/kvm/hypercalls.rst
> @@ -22,7 +22,7 @@ S390:
> number in R1.
>
> For further information on the S390 diagnose call as supported by KVM,
> - refer to Documentation/virt/kvm/s390-diag.txt.
> + refer to Documentation/virt/kvm/s390-diag.rst.
>
> PowerPC:
> It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers.
> @@ -30,7 +30,7 @@ PowerPC:
>
> KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions'
> property inside the device tree's /hypervisor node.
> - For more information refer to Documentation/virt/kvm/ppc-pv.txt
> + For more information refer to Documentation/virt/kvm/ppc-pv.rst
>
> MIPS:
> KVM hypercalls use the HYPCALL instruction with code 0 and the hypercall
> diff --git a/arch/powerpc/include/uapi/asm/kvm_para.h b/arch/powerpc/include/uapi/asm/kvm_para.h
> index be48c2215fa2..a809b1b44ddf 100644
> --- a/arch/powerpc/include/uapi/asm/kvm_para.h
> +++ b/arch/powerpc/include/uapi/asm/kvm_para.h
> @@ -31,7 +31,7 @@
> * Struct fields are always 32 or 64 bit aligned, depending on them being 32
> * or 64 bit wide respectively.
> *
> - * See Documentation/virt/kvm/ppc-pv.txt
> + * See Documentation/virt/kvm/ppc-pv.rst
> */
> struct kvm_vcpu_arch_shared {
> __u64 scratch1;
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 43594978958e..fb92be7e8aa7 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -161,7 +161,7 @@ config DRM_LOAD_EDID_FIRMWARE
> monitor are unable to provide appropriate EDID data. Since this
> feature is provided as a workaround for broken hardware, the
> default case is N. Details and instructions how to build your own
> - EDID data are given in Documentation/driver-api/edid.rst.
> + EDID data are given in Documentation/admin-guide/edid.rst.
>
> config DRM_DP_CEC
> bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 9e41972c4bbc..c2b8d2a953ae 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -741,7 +741,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> * };
> *
> * Please make sure that you follow all the best practices from
> - * ``Documentation/ioctl/botching-up-ioctls.rst``. Note that drm_ioctl()
> + * ``Documentation/process/botching-up-ioctls.rst``. Note that drm_ioctl()
> * automatically zero-extends structures, hence make sure you can add more stuff
> * at the end, i.e. don't put a variable sized array there.
> *
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index 83e841be1081..02dbb5ca3bcf 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -107,7 +107,7 @@ config CORESIGHT_CPU_DEBUG
> can quickly get to know program counter (PC), secure state,
> exception level, etc. Before use debugging functionality, platform
> needs to ensure the clock domain and power domain are enabled
> - properly, please refer Documentation/trace/coresight-cpu-debug.rst
> + properly, please refer Documentation/trace/coresight/coresight-cpu-debug.rst
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> for detailed description and the example for usage.
>
> config CORESIGHT_CTI
> diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
> index 718163d0c621..ca31993dcb47 100644
> --- a/fs/fat/Kconfig
> +++ b/fs/fat/Kconfig
> @@ -69,7 +69,7 @@ config VFAT_FS
>
> The VFAT support enlarges your kernel by about 10 KB and it only
> works if you said Y to the "DOS FAT fs support" above. Please read
> - the file <file:Documentation/filesystems/vfat.txt> for details. If
> + the file <file:Documentation/filesystems/vfat.rst> for details. If
> unsure, say Y.
>
> To compile this as a module, choose M here: the module will be called
> @@ -82,7 +82,7 @@ config FAT_DEFAULT_CODEPAGE
> help
> This option should be set to the codepage of your FAT filesystems.
> It can be overridden with the "codepage" mount option.
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
>
> config FAT_DEFAULT_IOCHARSET
> string "Default iocharset for FAT"
> @@ -96,7 +96,7 @@ config FAT_DEFAULT_IOCHARSET
> Note that "utf8" is not recommended for FAT filesystems.
> If unsure, you shouldn't set "utf8" here - select the next option
> instead if you would like to use UTF-8 encoded file names by default.
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
>
> Enable any character sets you need in File Systems/Native Language
> Support.
> @@ -114,4 +114,4 @@ config FAT_DEFAULT_UTF8
>
> Say Y if you use UTF-8 encoding for file names, N otherwise.
>
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
> diff --git a/fs/fuse/Kconfig b/fs/fuse/Kconfig
> index eb2a585572dc..774b2618018a 100644
> --- a/fs/fuse/Kconfig
> +++ b/fs/fuse/Kconfig
> @@ -12,7 +12,7 @@ config FUSE_FS
> although chances are your distribution already has that library
> installed if you've installed the "fuse" package itself.
>
> - See <file:Documentation/filesystems/fuse.txt> for more information.
> + See <file:Documentation/filesystems/fuse.rst> for more information.
> See <file:Documentation/Changes> for needed library/utility version.
>
> If you want to develop a userspace FS, or if you want to use
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 97eec7522bf2..c7a65cf2bcca 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -2081,7 +2081,7 @@ static void end_polls(struct fuse_conn *fc)
> * The same effect is usually achievable through killing the filesystem daemon
> * and all users of the filesystem. The exception is the combination of an
> * asynchronous request and the tricky deadlock (see
> - * Documentation/filesystems/fuse.txt).
> + * Documentation/filesystems/fuse.rst).
> *
> * Aborting requests under I/O goes as follows: 1: Separate out unlocked
> * requests, they should be finished off immediately. Locked requests will be
> diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
> index 714c14c47ca5..dd188c7996b3 100644
> --- a/fs/overlayfs/Kconfig
> +++ b/fs/overlayfs/Kconfig
> @@ -9,7 +9,7 @@ config OVERLAY_FS
> 'lower' filesystem is either hidden or, in the case of directories,
> merged with the 'upper' object.
>
> - For more information see Documentation/filesystems/overlayfs.txt
> + For more information see Documentation/filesystems/overlayfs.rst
>
> config OVERLAY_FS_REDIRECT_DIR
> bool "Overlayfs: turn on redirect directory feature by default"
> @@ -38,7 +38,7 @@ config OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW
> If backward compatibility is not an issue, then it is safe and
> recommended to say N here.
>
> - For more information, see Documentation/filesystems/overlayfs.txt
> + For more information, see Documentation/filesystems/overlayfs.rst
>
> If unsure, say Y.
>
> @@ -103,7 +103,7 @@ config OVERLAY_FS_XINO_AUTO
> If compatibility with applications that expect 32bit inodes is not an
> issue, then it is safe and recommended to say Y here.
>
> - For more information, see Documentation/filesystems/overlayfs.txt
> + For more information, see Documentation/filesystems/overlayfs.rst
>
> If unsure, say N.
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index bb50335af2ed..0173fa9850ff 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1219,7 +1219,7 @@ void unpin_user_pages(struct page **pages, unsigned long npages);
> * used to track the pincount (instead using of the GUP_PIN_COUNTING_BIAS
> * scheme).
> *
> - * For more information, please see Documentation/vm/pin_user_pages.rst.
> + * For more information, please see Documentation/core-api/pin_user_pages.rst.
> *
> * @page: pointer to page to be queried.
> * @Return: True, if it is likely that the page has been "dma-pinned".
> @@ -2854,7 +2854,7 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
> * releasing pages: get_user_pages*() pages must be released via put_page(),
> * while pin_user_pages*() pages must be released via unpin_user_page().
> *
> - * Please see Documentation/vm/pin_user_pages.rst for more information.
> + * Please see Documentation/core-api/pin_user_pages.rst for more information.
> */
>
> static inline int vm_fault_to_errno(vm_fault_t vm_fault, int foll_flags)
> diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
> index c7c7a1a550af..7e93cf1dc7dc 100644
> --- a/include/uapi/linux/ethtool_netlink.h
> +++ b/include/uapi/linux/ethtool_netlink.h
> @@ -2,7 +2,7 @@
> /*
> * include/uapi/linux/ethtool_netlink.h - netlink interface for ethtool
> *
> - * See Documentation/networking/ethtool-netlink.txt in kernel source tree for
> + * See Documentation/networking/ethtool-netlink.rst in kernel source tree for
> * doucumentation of the interface.
> */
>
> diff --git a/include/uapi/rdma/rdma_user_ioctl_cmds.h b/include/uapi/rdma/rdma_user_ioctl_cmds.h
> index 7b1ec806f8f9..38ab7accb7be 100644
> --- a/include/uapi/rdma/rdma_user_ioctl_cmds.h
> +++ b/include/uapi/rdma/rdma_user_ioctl_cmds.h
> @@ -36,7 +36,7 @@
> #include <linux/types.h>
> #include <linux/ioctl.h>
>
> -/* Documentation/ioctl/ioctl-number.rst */
> +/* Documentation/userspace-api/ioctl/ioctl-number.rst */
> #define RDMA_IOCTL_MAGIC 0x1b
> #define RDMA_VERBS_IOCTL \
> _IOWR(RDMA_IOCTL_MAGIC, 1, struct ib_uverbs_ioctl_hdr)
> diff --git a/mm/gup.c b/mm/gup.c
> index 0361a1dca77e..00823d1ece86 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2832,9 +2832,9 @@ EXPORT_SYMBOL_GPL(get_user_pages_fast);
> * the arguments here are identical.
> *
> * FOLL_PIN means that the pages must be released via unpin_user_page(). Please
> - * see Documentation/vm/pin_user_pages.rst for further details.
> + * see Documentation/core-api/pin_user_pages.rst for further details.
> *
> - * This is intended for Case 1 (DIO) in Documentation/vm/pin_user_pages.rst. It
> + * This is intended for Case 1 (DIO) in Documentation/core-api/pin_user_pages.rst. It
> * is NOT intended for Case 2 (RDMA: long-term pins).
> */
> int pin_user_pages_fast(unsigned long start, int nr_pages,
> @@ -2872,9 +2872,9 @@ EXPORT_SYMBOL_GPL(pin_user_pages_fast);
> * the arguments here are identical.
> *
> * FOLL_PIN means that the pages must be released via unpin_user_page(). Please
> - * see Documentation/vm/pin_user_pages.rst for details.
> + * see Documentation/core-api/pin_user_pages.rst for details.
> *
> - * This is intended for Case 1 (DIO) in Documentation/vm/pin_user_pages.rst. It
> + * This is intended for Case 1 (DIO) in Documentation/core-api/pin_user_pages.rst. It
> * is NOT intended for Case 2 (RDMA: long-term pins).
> */
> long pin_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
> @@ -2908,9 +2908,9 @@ EXPORT_SYMBOL(pin_user_pages_remote);
> * FOLL_PIN is set.
> *
> * FOLL_PIN means that the pages must be released via unpin_user_page(). Please
> - * see Documentation/vm/pin_user_pages.rst for details.
> + * see Documentation/core-api/pin_user_pages.rst for details.
> *
> - * This is intended for Case 1 (DIO) in Documentation/vm/pin_user_pages.rst. It
> + * This is intended for Case 1 (DIO) in Documentation/core-api/pin_user_pages.rst. It
> * is NOT intended for Case 2 (RDMA: long-term pins).
> */
> long pin_user_pages(unsigned long start, unsigned long nr_pages,
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> index 48fd9fc229a2..215409ac8f12 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -300,7 +300,7 @@ static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
> * pending state of interrupt is latched in pending_latch variable.
> * Userspace will save and restore pending state and line_level
> * separately.
> - * Refer to Documentation/virt/kvm/devices/arm-vgic-v3.txt
> + * Refer to Documentation/virt/kvm/devices/arm-vgic-v3.rst
> * for handling of ISPENDR and ICPENDR.
> */
> for (i = 0; i < len * 8; i++) {
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index 769e4802645e..64fcd7511110 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -42,7 +42,7 @@
> VGIC_AFFINITY_LEVEL(val, 3))
>
> /*
> - * As per Documentation/virt/kvm/devices/arm-vgic-v3.txt,
> + * As per Documentation/virt/kvm/devices/arm-vgic-v3.rst,
> * below macros are defined for CPUREG encoding.
> */
> #define KVM_REG_ARM_VGIC_SYSREG_OP0_MASK 0x000000000000c000
> @@ -63,7 +63,7 @@
> KVM_REG_ARM_VGIC_SYSREG_OP2_MASK)
>
> /*
> - * As per Documentation/virt/kvm/devices/arm-vgic-its.txt,
> + * As per Documentation/virt/kvm/devices/arm-vgic-its.rst,
> * below macros are defined for ITS table entry encoding.
> */
> #define KVM_ITS_CTE_VALID_SHIFT 63
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH v1 46/46] powerpc/32s: Implement dedicated kasan_init_region()
From: Christophe Leroy @ 2020-03-17 14:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <165be4c0f0ba674846a244edf9e1116b832d3bfb.1584360344.git.christophe.leroy@c-s.fr>
Le 16/03/2020 à 13:36, Christophe Leroy a écrit :
> Implement a kasan_init_region() dedicated to book3s/32 that
> allocates KASAN regions using BATs.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Note that the sparse warning on pmac32_defconfig is definitely a false
positive. See details patch 16/46 ("powerpc/mm: Allocate static page
tables for fixmap")
Christophe
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/numa: Set fallback nodes for offline nodes
From: Srikar Dronamraju @ 2020-03-17 14:29 UTC (permalink / raw)
To: Bharata B Rao
Cc: Sachin Sant, Michal Hocko, linux-mm, Kirill Tkhai, Mel Gorman,
Joonsoo Kim, Andrew Morton, linuxppc-dev, Christopher Lameter,
Vlastimil Babka
In-Reply-To: <20200317142232.GB26049@in.ibm.com>
* Bharata B Rao <bharata@linux.ibm.com> [2020-03-17 19:52:32]:
Thanks Bharata.
> This patchset can also fix a related problem that I reported earlier at
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-March/206076.html
> with an additional change, suggested by Srikar as shown below:
>
> >
> > - for_each_online_node(node) {
> > + for_each_node(node) {
> > + /*
> > + * For all possible but not yet online nodes, ensure their
> > + * node_numa_mem is set correctly so that kmalloc_node works
> > + * for such nodes.
> > + */
> > + if (!node_online(node)) {
>
> Change the above line to like below:
>
> + if (!node_state(node, N_MEMORY)) {
>
Just to clarify, this is needed if we don't have
http://lore.kernel.org/lkml/20200311110237.5731-1-srikar@linux.vnet.ibm.com/t/#u
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re:Re: [PATCH v3] powerpc/fsl-85xx: fix compile error
From: 王文虎 @ 2020-03-17 14:25 UTC (permalink / raw)
To: Michael Ellerman
Cc: trivial, kernel, linux-kernel, stable, Richard Fontana,
Paul Mackerras, Greg Kroah-Hartman, Thomas Gleixner, linuxppc-dev,
Allison Randal
In-Reply-To: <878sjzfcpm.fsf@mpe.ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2020-03-17 19:22:13
To:"王文虎" <wenhu.wang@vivo.com>
cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,Paul Mackerras <paulus@samba.org>,Allison Randal <allison@lohutok.net>,Richard Fontana <rfontana@redhat.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Thomas Gleixner <tglx@linutronix.de>,linuxppc-dev@lists.ozlabs.org,linux-kernel@vger.kernel.org,trivial@kernel.org,kernel@vivo.com,stable <stable@vger.kernel.org>
Subject: Re: [PATCH v3] powerpc/fsl-85xx: fix compile error>王文虎 <wenhu.wang@vivo.com> writes:
>> From: Michael Ellerman <mpe@ellerman.id.au>
>> Date: 2020-03-16 17:41:12
>> To:WANG Wenhu <wenhu.wang@vivo.com>,Benjamin Herrenschmidt <benh@kernel.crashing.org>,Paul Mackerras <paulus@samba.org>,WANG Wenhu <wenhu.wang@vivo.com>,Allison Randal <allison@lohutok.net>,Richard Fontana <rfontana@redhat.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Thomas Gleixner <tglx@linutronix.de>,linuxppc-dev@lists.ozlabs.org,linux-kernel@vger.kernel.org
>> cc: trivial@kernel.org,kernel@vivo.com,stable <stable@vger.kernel.org>
>> Subject: Re: [PATCH v3] powerpc/fsl-85xx: fix compile error>WANG Wenhu <wenhu.wang@vivo.com> writes:
>>>> Include "linux/of_address.h" to fix the compile error for
>>>> mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
>>>>
>>>> CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
>>>> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
>>>> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration]
>>>> l2ctlr = of_iomap(dev->dev.of_node, 0);
>>>> ^~~~~~~~
>>>> pci_iomap
>>>> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
>>>> l2ctlr = of_iomap(dev->dev.of_node, 0);
>>>> ^
>>>> cc1: all warnings being treated as errors
>>>> scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
>>>> make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
>>>>
>>>> Fixes: commit 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
>>>
>>>The syntax is:
>>>
>>>Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
>>>
>>>> Cc: stable <stable@vger.kernel.org>
>>>
>>>The commit above went into v2.6.37.
>>>
>>>So no one has noticed this bug since then, how? Or did something else
>>>change to expose the problem?
>>
>> Actually a hard question to answer cause it also left me scratching for long.
>> However, I can not find right or definite answer.
>
>Oh, actually it's fairly straight forward, the code can't be built at
>all in upstream because CONFIG_FSL_85XX_CACHE_SRAM is not selectable or
>selected by anything.
Yeah, sure that is the reason, and I meant it was hard to figure out why
nobody had ever compiled the driver with FSL_85XX_CACHE_SRAM enabled
until me.
>
>You sent a patch previously to make it selectable, which Scott thought
>was a bad idea.
>
>So this whole file is dead code as far as I'm concerned, so patches for
>it definitely do not need to go to stable.
>
>If you want to add a user for it then please send a series doing that,
>and this commit can be the first.
For this, as you mentioned, it is dead and do not need to be applied to any stable.
And I recommand the patch as a unit itself cause our module which uses
it is still under developing, and the module itself would be taken as a
complete logical block. Also it would take some time.
Thanks, Wenhu
>
>cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox