On 3/17/20 4:02 PM, Christophe Leroy wrote:
Le 09/03/2020 à 09:57, Ravi Bangoria a écrit :
Instead of disabling only one watchpooint, get num of available
watchpoints dynamically and disable all of them.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hw_breakpoint.h | 15
This is a good readme, the instructions for compiling and testing work.
Reviewed-by: Daniel Axtens
Regards,
Daniel
Raphael Moreira Zinsly writes:
> Include a README file with the instructions to use the
> testcases at selftests/powerpc/nx-gzip.
>
> Signed-off-by: Bulent Abali
> Signed-off-by
On 3/17/20 3:58 PM, Christophe Leroy wrote:
Le 09/03/2020 à 09:57, Ravi Bangoria a écrit :
Introduce new parameter 'nr' to set_dawr() which indicates which DAWR
should be programed.
While we are at it (In another patch I think), we should do the same to
set_dabr() so that we can use both
Raphael Moreira Zinsly writes:
> Include a decompression testcase for the powerpc NX-GZIP
> engine.
I compiled gzip with the AFL++ fuzzer and generated a corpus of tests to
run against this decompressor. I also fuzzed the decompressor
directly. I found a few issues. I _think_ they're just in the
Some specific tests in powerpc can take longer than the default 45
seconds that added in commit 852c8cbf34d3 ("selftests/kselftest/runner.sh:
Add 45 second timeout per test") to run, the following test result was
collected across 2 Power8 nodes and 1 Power9 node in our pool:
powerpc/benchmarks/fu
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index f2f8d8aa8e3b..741c4f7573c4 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -43,6 +43,8 @@ struct arch_hw_breakpoint {
#define DABR_MA
On Tue, 17 Mar 2020 08:04:14 + (UTC) Christophe Leroy
wrote:
> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
> following build failure is encoutered:
>
> In file included from arch/powerpc/mm/fault.c:33:0:
> ./include/linux/hugetlb.h: In function 'hstate_inode':
> ./include/
On Wed, Mar 18, 2020 at 08:50:44AM +0530, Srikar Dronamraju wrote:
> * Vlastimil Babka [2020-03-17 17:45:15]:
>
> > On 3/17/20 5:25 PM, Srikar Dronamraju wrote:
> > > * Vlastimil Babka [2020-03-17 16:56:04]:
> > >
> > >>
> > >> I wonder why do you get a memory leak while Sachin in the same sit
On 18/02/2020 18:36, Alexey Kardashevskiy wrote:
> Here is an attempt to support bigger DMA space for devices
> supporting DMA masks less than 59 bits (GPUs come into mind
> first). POWER9 PHBs have an option to map 2 windows at 0
> and select a windows based on DMA address being below or above
Raphael Moreira Zinsly writes:
> Include a decompression testcase for the powerpc NX-GZIP
> engine.
>
> Signed-off-by: Bulent Abali
> Signed-off-by: Raphael Moreira Zinsly
> ---
> .../selftests/powerpc/nx-gzip/Makefile|7 +-
> .../selftests/powerpc/nx-gzip/gunz_test.c | 1058 ++
Hi,
This is throwing a number of snowpatch warnings, as well as a whitespace
warning when I apply it. Please could you check the warnings at
https://patchwork.ozlabs.org/patch/1255779/
It looks like the rest of the series also throws some warnings - please
check those also.
Kind regards,
Daniel
* Vlastimil Babka [2020-03-17 17:45:15]:
> On 3/17/20 5:25 PM, Srikar Dronamraju wrote:
> > * Vlastimil Babka [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.
> >
> >
This patch enables ACPI support in Rcpm driver.
Signed-off-by: Peng Ma
---
drivers/soc/fsl/rcpm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index a093dbe..7da6bbd 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@
generic-64bit_defconfig
pariscgeneric-32bit_defconfig
parisc allyesconfig
x86_64 randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386
generic-32bit_defconfig
pariscgeneric-64bit_defconfig
x86_64 randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386 randconfig
randconfig-a002-20200316
i386 randconfig-a003-20200316
x86_64 randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386 randconfig-a002
randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386 randconfig-a002-20200317
i386 randconfig-a003-20200317
alpharandconfig
Hi Borislav,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/x86/mm]
[cannot apply to linux/master powerpc/next s390/features tip/x86/core
linus/master v5.6-rc6 next-20200317]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Borislav,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/x86/mm]
[cannot apply to linux/master powerpc/next s390/features tip/x86/core
linus/master v5.6-rc6 next-20200317]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Pratik,
Thanks.
I have checked:
- for matching puts/gets
- that all the '.' to '->' conversions, aud uses of '&' check out
- that the Snowpatch checks pass (https://patchwork.ozlabs.org/patch/1255580/)
On that basis:
Reviewed-by: Daniel Axtens
Regards,
Daniel
> The patch avoids alloca
On Tue, Mar 17, 2020 at 11:49:40AM +0100, David Hildenbrand wrote:
>All in-tree users except the mm-core are gone. Let's drop the export.
>
>Cc: Andrew Morton
>Cc: Michal Hocko
>Cc: Oscar Salvador
>Cc: "Rafael J. Wysocki"
>Cc: Baoquan He
>Cc: Wei Yang
>Signed-off-by: David Hildenbrand
Revie
On Tue, Mar 17, 2020 at 11:49:38AM +0100, David Hildenbrand wrote:
>Let's always try to online the re-added memory blocks. In case add_memory()
>already onlined the added memory blocks, the first device_online() call
>will fail and stop processing the remaining memory blocks.
>
>This avoids manuall
On Mon, Mar 16, 2020 at 4:08 PM Rasmus Villemoes
wrote:
>
> On 12/03/2020 23.28, Li Yang wrote:
> > Fixes the following sparse warnings:
> >
> [snip]
> >
> > Also removed the unneccessary clearing for kzalloc'ed structure.
>
> Please don't mix that in the same patch, do it in a preparatory patch.
Borislav Petkov writes:
> On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
>> On 3/17/20 4:18 AM, Borislav Petkov wrote:
>> > Back then when the whole SME machinery started getting mainlined, it
>> > was agreed that for simplicity, clarity and sanity's sake, the terms
>> > denoting en
On Tue, 2020-03-17 at 14:24 -0700, Dave Hansen wrote:
> On 3/17/20 2:06 PM, Borislav Petkov wrote:
> > On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
> > > On 3/17/20 4:18 AM, Borislav Petkov wrote:
> > > > Back then when the whole SME machinery started getting mainlined, it
> > > > w
On Tue, Mar 17, 2020 at 02:24:59PM -0700, Dave Hansen wrote:
> No, there are just two states. I just think the "!encrypted" case
> should not be called "decrypted".
Yeah, we suck at naming - news at 11! :-)
I believe we even considered things like "encrypted" vs "clear" but
that sucked too. ;-\
On 3/17/20 2:06 PM, Borislav Petkov wrote:
> On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
>> On 3/17/20 4:18 AM, Borislav Petkov wrote:
>>> Back then when the whole SME machinery started getting mainlined, it
>>> was agreed that for simplicity, clarity and sanity's sake, the terms
>
On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
> On 3/17/20 4:18 AM, Borislav Petkov wrote:
> > Back then when the whole SME machinery started getting mainlined, it
> > was agreed that for simplicity, clarity and sanity's sake, the terms
> > denoting encrypted and not-encrypted memory
On 3/17/20 4:18 AM, Borislav Petkov wrote:
> Back then when the whole SME machinery started getting mainlined, it
> was agreed that for simplicity, clarity and sanity's sake, the terms
> denoting encrypted and not-encrypted memory should be "encrypted" and
> "decrypted". And the majority of the cod
On Tue, 2020-03-17 at 16:28 +1100, Michael Ellerman wrote:
> Haren Myneni writes:
> > For each fault CRB, update fault address in CRB (fault_storage_addr)
> > and translation error status in CSB so that user space can touch the
> > fault address and resend the request. If the user space passed inv
On Tue, 2020-03-17 at 15:09 +1100, Michael Ellerman wrote:
> Haren Myneni writes:
> > Process close windows after its requests are completed. In multi-thread
> > applications, child can open a window but release FD will not be called
> > upon its exit. Parent thread will be closing it later upon i
> @@ -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);
I'll move this one line up.
> #endif
>
>
On 3/17/20 1:04 AM, Christophe Leroy wrote:
> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
> following build failure is encoutered:
>
> In file included from arch/powerpc/mm/fault.c:33:0:
> ./include/linux/hugetlb.h: In function 'hstate_inode':
> ./include/linux/hugetlb.h:477:9: e
On 3/17/20 9:47 AM, Christophe Leroy wrote:
>
>
> 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
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:
Fr
On 3/17/20 5:25 PM, Srikar Dronamraju wrote:
> * Vlastimil Babka [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
* Vlastimil Babka [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;
> >
> >
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,
On 17.03.20 17:29, Vitaly Kuznetsov wrote:
> David Hildenbrand 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)
David Hildenbrand 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
>
* Vlastimil Babka [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. Wh
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 @@
> > #inc
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
On 3/17/20 11:22 AM, Sachin Sant wrote:
On 17-Mar-2020, at 6:38 PM, Stefan Berger wrote:
From: Stefan Berger
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]: ***
On 3/17/20 3:51 PM, Srikar Dronamraju wrote:
> * Vlastimil Babka [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
> On 17-Mar-2020, at 6:38 PM, Stefan Berger wrote:
>
> From: Stefan Berger
>
> 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.m
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_ge
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
> ---
> tools/perf/util/metricgroup.c | 63 +
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
> ---
> tools/perf/util/metricgroup.c | 63 +
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' para
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
>
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_
* Vlastimil Babka [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
> >>
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-0
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 Ler
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
> ---
> Docum
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
Note that the sparse warning on pmac32_defconfig is definitely a false
positive. See details patch 16/46 ("powe
* Bharata B Rao [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_onl
From: Michael Ellerman
Date: 2020-03-17 19:22:13
To:"王文虎"
cc: Benjamin Herrenschmidt ,Paul Mackerras
,Allison Randal ,Richard Fontana
,Greg Kroah-Hartman ,Thomas
Gleixner
,linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org,triv...@kernel.org,ker...@vivo.com,stable
Subject: Re: [PA
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:
On Tue, Mar 17, 2020 at 06:47:53PM +0530, Srikar Dronamraju wrote:
> Currently fallback node
Skiboot patches v4:
https://lists.ozlabs.org/pipermail/skiboot/2020-February/016404.html
Linux patches v4: https://lkml.org/lkml/2020/2/12/446
Changelog
v4 --> v5
Based on Michael Ellerman's comments, in patch3:
1. Added documentation in power-mgt.txt for self-save and self-restore
2. Used bitmap
Parse the device tree for nodes self-save, self-restore and populate
support for the preferred SPRs based what was advertised by the device
tree.
Signed-off-by: Pratik Rajesh Sampat
Reviewed-by: Ram Pai
---
.../bindings/powerpc/opal/power-mgt.txt | 10 +++
arch/powerpc/platforms/powernv/i
This commit introduces and leverages the Self save API which OPAL now
supports.
Add the new Self Save OPAL API call in the list of OPAL calls.
Implement the self saving of the SPRs based on the support populated
while respecting it's preferences.
This implementation allows mixing of support for t
Define a bitmask interface to determine support for the Self Restore,
Self Save or both.
Also define an interface to determine the preference of that SPR to
be strictly saved or restored or encapsulated with an order of preference.
The preference bitmask is shown as below:
---
Thank you Michael for the review.
On 17/03/20 8:43 am, Michael Ellerman wrote:
Pratik Rajesh Sampat writes:
Parse the device tree for nodes self-save, self-restore and populate
support for the preferred SPRs based what was advertised by the device
tree.
These should be documented in:
Docu
On Tue 17-03-20 14:44:45, Vlastimil Babka wrote:
> On 3/16/20 10:06 AM, Michal Hocko wrote:
> > On Thu 12-03-20 17:41:58, Vlastimil Babka wrote:
> > [...]
> >> with nid present in:
> >> N_POSSIBLE - pgdat might not exist, node_to_mem_node() must return some
> >> online
> >
> > I would rather have
On 3/17/20 2:45 PM, Srikar Dronamraju wrote:
> * Vlastimil Babka [2020-03-17 14:34:25]:
>
>> On 3/17/20 2:17 PM, Srikar Dronamraju wrote:
>> > Currently while allocating a slab for a offline node, we use its
>> > associated node_numa_mem to search for a partial slab. If we don't find
>> > a parti
* Vlastimil Babka [2020-03-17 14:34:25]:
> On 3/17/20 2:17 PM, Srikar Dronamraju wrote:
> > Currently while allocating a slab for a offline node, we use its
> > associated node_numa_mem to search for a partial slab. If we don't find
> > a partial slab, we try allocating a slab from the offline no
On 3/16/20 10:06 AM, Michal Hocko wrote:
> On Thu 12-03-20 17:41:58, Vlastimil Babka wrote:
> [...]
>> with nid present in:
>> N_POSSIBLE - pgdat might not exist, node_to_mem_node() must return some
>> online
>
> I would rather have a dummy pgdat for those. Have a look at
> $ git grep "NODE_DATA
* Srikar Dronamraju [2020-03-17 18:47:50]:
>
> Reported-by: Sachin Sant
> Tested-by: Sachin Sant
> Signed-off-by: Srikar Dronamraju
> ---
> include/linux/mmzone.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>
On 3/17/20 2:17 PM, Srikar Dronamraju wrote:
> Currently while allocating a slab for a offline node, we use its
> associated node_numa_mem to search for a partial slab. If we don't find
> a partial slab, we try allocating a slab from the offline node using
> __alloc_pages_node. However this is boun
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
> Documentati
Calling a kmalloc_node on a possible node which is not yet onlined can
lead to panic. Currently node_present_pages() doesn't verify the node is
online before accessing the pgdat for the node. However pgdat struct may
not be available resulting in a crash.
NIP [c03d55f4] ___slab_alloc+0x1f4
Currently fallback nodes for offline nodes aren't set. Hence by default
node 0 ends up being the default node. However node 0 might be offline.
Fix this by explicitly setting fallback node. Ensure first_memory_node
is set before kernel does explicit setting of fallback node.
Cc: Andrew Morton
Cc
For a memoryless or offline nodes, node_numa_mem refers to a N_MEMORY
fallback node. Currently kernel has an API set_numa_mem that sets
node_numa_mem for memoryless node. However this API cannot be used for
offline nodes. Hence all offline nodes will have their node_numa_mem set
to 0. However syste
Sachin recently reported that linux-next was no more bootable on few
systems.
https://lore.kernel.org/linux-next/3381cd91-ab3d-4773-ba04-e7a072a63...@linux.vnet.ibm.com/
# 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 8 9 10 11 12
Currently while allocating a slab for a offline node, we use its
associated node_numa_mem to search for a partial slab. If we don't find
a partial slab, we try allocating a slab from the offline node using
__alloc_pages_node. However this is bound to fail.
NIP [c039a300] __alloc_pages_node
On Sat, 2020-03-07 at 10:09:15 UTC, Christophe Leroy wrote:
> Commit 2efc7c085f05 ("powerpc/32: drop get_pteptr()"),
> replaced get_pteptr() by virt_to_kpte(). But virt_to_kpte() lacks a
> NULL pmd check and returns an invalid non NULL pointer when there
> is no page table.
>
> Reported-by: Nick D
On Tue, 2020-03-03 at 08:56:04 UTC, YueHaibing wrote:
> core99_l2_cache/core99_l3_cache no need to mark as volatile,
> just remove it.
>
> Signed-off-by: YueHaibing
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a4037d1f1fc4e92b69d7196d4568c33078d465ea
cheers
On Mon, 2020-03-02 at 01:04:10 UTC, Nicholas Piggin wrote:
> Signed-off-by: Nicholas Piggin
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/993cfecc59e57de237ae27fadc84ed24efa87a4d
cheers
On Fri, 2020-02-28 at 00:00:09 UTC, Christophe Leroy wrote:
> The commit identified below added tlbie_test but
> forgot to add it in .gitignore.
>
> Fixes: 93cad5f78995 ("selftests/powerpc: Add test case for tlbie vs mtpidr
> ordering issue")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christop
On Wed, 2020-02-26 at 05:53:02 UTC, Nicholas Piggin wrote:
> Signed-off-by: Nicholas Piggin
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/59ed2adf393109c56d383e568f2e57bb5ad6d901
cheers
On Mon, 2020-02-24 at 21:18:48 UTC, Joe Lawrence wrote:
> The original 2005 patch that introduced the powerpc vdso, pre-git
> ("ppc64: Implement a vDSO and use it for signal trampoline") notes that:
>
> ... symbols exposed by the vDSO aren't "normal" function symbols, apps
> can't be expected
On Thu, 2020-02-06 at 06:26:21 UTC, Oliver O'Halloran wrote:
> The cpufreq driver has a use-after-free that we can hit if:
>
> a) There's an OCC message pending when the notifier is registered, and
> b) The cpufreq driver fails to register with the core.
>
> When a) occurs the notifier schedules
On Thu, 2020-01-23 at 11:19:25 UTC, Laurentiu Tudor wrote:
> In the current implementation, the call to loadcam_multi() is wrapped
> between switch_to_as1() and restore_to_as0() calls so, when it tries
> to create its own temporary AS=3D1 TLB1 entry, it ends up duplicating the
> existing one create
On Thu, 2020-01-09 at 07:39:12 UTC, Stephen Rothwell wrote:
> ev_byte_channel_send() assumes that its third argument is a 16 byte array.
> Some places where it is called it may not be (or we can't easily tell
> if it is). Newer compilers have started producing warnings about this,
> so make sure w
On Fri, 2019-09-20 at 15:39:51 UTC, Ilie Halip wrote:
> When building with ppc64_defconfig, the compiler reports
> that these 2 variables are not used:
> warning: unused variable 'core99_l2_cache' [-Wunused-variable]
> warning: unused variable 'core99_l3_cache' [-Wunused-variable]
>
> They
Some filesystem references got broken by a previous patch
series I submitted. Address those.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/sysfs-devices-node | 2 +-
Documentation/ABI/testing/procfs-smaps_rollup | 2 +-
Documentation/admin-guide/cpu-load.rst| 2 +
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
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
Documentation/memory-barriers.
From: Stefan Berger
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
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:
王文虎 writes:
> From: Michael Ellerman
> Date: 2020-03-16 17:41:12
> To:WANG Wenhu ,Benjamin Herrenschmidt
> ,Paul Mackerras ,WANG Wenhu
> ,Allison Randal ,Richard Fontana
> ,Greg Kroah-Hartman ,Thomas
> Gleixner
> ,linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org
> cc: triv...@ker
Hi all,
this hasn't been fully tested yet but it is mechanical rename only so
there shouldn't be any problems (famous last words :-)).
I'll run it through the randconfig bench today and take it through tip if
there are no objections.
Thx.
---
Back then when the whole SME machinery started gett
Le 09/03/2020 à 09:58, Ravi Bangoria a écrit :
Add support for 2nd DAWR in xmon. With this, we can have two
simultaneous breakpoints from xmon.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/xmon/xmon.c | 101 ++-
1 file changed, 69 insertions(+), 32 del
Le 09/03/2020 à 09:58, Ravi Bangoria a écrit :
Xmon allows overwriting breakpoints because it's supported by only
one dawr. But with multiple dawrs, overwriting becomes ambiguous
or unnecessary complicated. So let's not allow it.
Could we drop this completely (I mean the functionnality, not
Le 09/03/2020 à 09:58, Ravi Bangoria a écrit :
ptrace and perf watchpoints on powerpc behaves differently. Ptrace
On the 8xx, ptrace generates signal after executing the instruction.
watchpoint works in one-shot mode and generates signal before executing
instruction. It's ptrace user's job
On 17.03.20 11:49, David Hildenbrand wrote:
> For now, distributions implement advanced udev rules to essentially
> - Don't online any hotplugged memory (s390x)
> - Online all memory to ZONE_NORMAL (e.g., most virt environments like
> hyperv)
> - Online all memory to ZONE_MOVABLE in case the zone
On 17.03.20 12:01, Michal Hocko wrote:
> On Tue 17-03-20 11:49:42, David Hildenbrand wrote:
>> For now, distributions implement advanced udev rules to essentially
>> - Don't online any hotplugged memory (s390x)
>> - Online all memory to ZONE_NORMAL (e.g., most virt environments like
>> hyperv)
>>
On Tue 17-03-20 11:49:42, David Hildenbrand wrote:
> For now, distributions implement advanced udev rules to essentially
> - Don't online any hotplugged memory (s390x)
> - Online all memory to ZONE_NORMAL (e.g., most virt environments like
> hyperv)
> - Online all memory to ZONE_MOVABLE in case t
On Tue 17-03-20 11:49:41, David Hildenbrand wrote:
> ... and rename it to memhp_default_online_type. This is a preparation
> for more detailed default online behavior.
>
> Reviewed-by: Wei Yang
> Cc: Greg Kroah-Hartman
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: "Rafael
1 - 100 of 134 matches
Mail list logo
