On Sun 15-09-19 16:20:56, Yunsheng Lin wrote:
> When passing the return value of dev_to_node() to cpumask_of_node()
> without checking if the device's node id is NUMA_NO_NODE, there is
> global-out-of-bounds detected by KASAN.
>
> >From the discussion [1], NUMA_NO_NODE really means no node affinit
Alistair Popple writes:
> Currently the reserved bits of the Processor Compatibility Register
> (PCR) are cleared as per the Programming Note in Section 1.3.3 of
> version 3.0B of the Power ISA. This causes all new architecture
> features to be made available when running on newer processors with
Since the commit ba2dd8a26baa ("powerpc/pseries/mm: call H_BLOCK_REMOVE"),
the call to H_BLOCK_REMOVE is always done if the feature is exhibited.
However, the hypervisor may not support all the block size for the hcall
H_BLOCK_REMOVE depending on the segment base page size and actual page
size.
W
The PAPR document specifies the TLB Block Invalidate Characteristics which
tells for each couple segment base page size, actual page size, the size of
the block the hcall H_BLOCK_REMOVE is supporting.
These characteristics are loaded at boot time in a new table hblkr_size.
The table is appart the
Now we do not call _BLOCK_REMOVE all the time when the feature is
exhibited.
Depending on the hardware and the hypervisor, the hcall H_BLOCK_REMOVE may
not be able to process all the page size for a segment base page size, as
reported by the TLB Invalidate Characteristics.o
For each couple base s
On Sat, Sep 14, 2019 at 7:37:54, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Gustavo Pimentel
> > Sent: 2019年9月12日 19:24
> > To: Andrew Murray ; Xiaowei Bao
> >
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li ; kis...@ti.com; lorenzo.piera
The patch fix a bug that FlexTimer cannot
wakeup system in deep sleep.
Signed-off-by: Biwen Li
---
arch/arm/boot/dts/ls1021a.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index e3973b611c3a..377bb4717584
The 'fsl,rcpm-scfg' property is used to fix a bug
that FlexTimer cannot wakeup system in deep sleep on LS1021A
Signed-off-by: Biwen Li
---
.../devicetree/bindings/soc/fsl/rcpm.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/
Why:
- Cannot write register RCPM_IPPDEXPCR1 on LS1021A,
Register RCPM_IPPDEXPCR1's default value is zero.
So the register value that reading from register
RCPM_IPPDEXPCR1 is always zero.
How:
- Save register RCPM_IPPDEXPCR1's value to
register SCFG_SPARECR8.(uboot'
Hi all,
the linux patch depended by RCPM driver,FlexTimer driver and FlexTimer
dts, need apply these patches as follows:
1. RCPM driver:
https://patchwork.kernel.org/series/162731/mbox/
(https://patchwork.kernel.org/patch/11105279/)
2. FlexTimer dts:
ht
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #12 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284991
--> https://bugzilla.kernel.org/attachment.cgi?id=284991&action=edit
dmesg v2 (5.3-rc8 + ptdump patch)
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #13 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284993
--> https://bugzilla.kernel.org/attachment.cgi?id=284993&action=edit
kernel_page_tables v2 (5.3-rc8 + ptdump patch)
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284995
--> https://bugzilla.kernel.org/attachment.cgi?id=284995&action=edit
objdump firewire-ohci v2 (5.3-rc8 + ptdump patch)
--
You are receiving this mail because:
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284997
--> https://bugzilla.kernel.org/attachment.cgi?id=284997&action=edit
objdump usbcore v2 (5.3-rc8 + ptdump patch)
--
You are receiving this mail because:
You ar
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284999
--> https://bugzilla.kernel.org/attachment.cgi?id=284999&action=edit
dmesg v3 (5.3-rc8 + ptdump patch, NO SMP)
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285001
--> https://bugzilla.kernel.org/attachment.cgi?id=285001&action=edit
kernel_page_tables v3 (5.3-rc8 + ptdump patch, NO SMP)
--
You are receiving this mail beca
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285003
--> https://bugzilla.kernel.org/attachment.cgi?id=285003&action=edit
objdump usbcore v3 (5.3-rc8 + ptdump patch, NO SMP)
--
You are receiving this mail because
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285005
--> https://bugzilla.kernel.org/attachment.cgi?id=285005&action=edit
objdump ohci-hcd v3 (5.3-rc8 + ptdump patch, NO SMP)
--
You are receiving this mail becaus
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #20 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285007
--> https://bugzilla.kernel.org/attachment.cgi?id=285007&action=edit
objdump firewire-ohci v3 (5.3-rc8 + ptdump patch, NO SMP)
--
You are receiving this mail b
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #21 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285009
--> https://bugzilla.kernel.org/attachment.cgi?id=285009&action=edit
objdump ehci-pci v3 (5.3-rc8 + ptdump patch, NO SMP)
--
You are receiving this mail becaus
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #22 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #11)
> I have carefully reviewed the flushing calls and have not been able to
> identify any issue.
>
> Maybe a SMP issue ? Does this problem als
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #23 from Christophe Leroy (christophe.le...@c-s.fr) ---
Thanks. The third one is interesting, as it shows :
Sep 16 12:57:39 T600 kernel: BUG: Unable to handle kernel data access at
0xfe295404
0xfe295000-0xfe295fff 0x00d05000
On 2019/9/16 16:43, Michal Hocko wrote:
> On Sun 15-09-19 16:20:56, Yunsheng Lin wrote:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking if the device's node id is NUMA_NO_NODE, there is
>> global-out-of-bounds detected by KASAN.
>>
>> >From the discussion
On Mon 16-09-19 20:07:22, Yunsheng Lin wrote:
[...]
> >> @@ -861,9 +861,12 @@ void numa_remove_cpu(int cpu)
> >> */
> >> const struct cpumask *cpumask_of_node(int node)
> >> {
> >> - if (node >= nr_node_ids) {
> >> + if (node == NUMA_NO_NODE)
> >> + return cpu_online_mask;
> >> +
> >
https://bugzilla.kernel.org/show_bug.cgi?id=204819
--- Comment #24 from Christophe Leroy (christophe.le...@c-s.fr) ---
Do you confirm that the two patches done in the scope of bug #204479 are
included in your config, especially the first one:
https://git.kernel.org/pub/scm/linux/kernel/git/next/li
On 2019/9/16 20:23, Michal Hocko wrote:
> On Mon 16-09-19 20:07:22, Yunsheng Lin wrote:
> [...]
@@ -861,9 +861,12 @@ void numa_remove_cpu(int cpu)
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (node >= nr_node_ids) {
+ if (node == NUMA_NO_NODE)
+
When passing the return value of dev_to_node() to cpumask_of_node()
without checking if the device's node id is NUMA_NO_NODE, there is
global-out-of-bounds detected by KASAN.
>From the discussion [1], NUMA_NO_NODE really means no node affinity,
which also means all cpus should be usable. So the cp
https://bugzilla.kernel.org/show_bug.cgi?id=204819
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
On Sat, Sep 14, 2019 at 04:10:22AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: 2019年9月12日 20:50
> > To: Xiaowei Bao
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.
On Mon, 2019-09-16 at 06:42 +, Christophe Leroy wrote:
> @@ -145,6 +147,15 @@ void __init mpc83xx_setup_arch(void)
> if (ppc_md.progress)
> ppc_md.progress("mpc83xx_setup_arch()", 0);
>
> + if (!__map_without_bats) {
> + phys_addr_t immrbase = get_immrbase(
On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V
wrote:
>
> With commit: 7cc7867fb061 ("mm/devm_memremap_pages: enable sub-section remap")
> pmem namespaces are remapped in 2M chunks. On architectures like ppc64 we
> can map the memmap area using 16MB hugepage size and that can cover
> a memory ra
On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V
wrote:
>
> With PFN_MODE_PMEM namespace, the memmap area is allocated from the device
> area. Some architectures map the memmap area with large page size. On
> architectures like ppc64, 16MB page for memap mapping can map 262144 pfns.
> This maps a
Le 16/09/2019 à 17:04, Scott Wood a écrit :
On Mon, 2019-09-16 at 06:42 +, Christophe Leroy wrote:
@@ -145,6 +147,15 @@ void __init mpc83xx_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc83xx_setup_arch()", 0);
+ if (!__map_without_bats) {
+
If no BAT is given to setbat(), select an available BAT.
Signed-off-by: Christophe Leroy
---
v2: no change
v3: no change
---
arch/powerpc/mm/book3s32/mmu.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/m
On mpc83xx with a QE, IMMR is 2Mbytes and aligned on 2Mbytes boundarie.
On mpc83xx without a QE, IMMR is 1Mbyte and 1Mbyte aligned.
Each driver will map a part of it to access the registers it needs.
Some drivers will map the same part of IMMR as other drivers.
In order to reduce TLB misses, map
On Mon, 2019-09-16 at 20:25 +, Christophe Leroy wrote:
> On mpc83xx with a QE, IMMR is 2Mbytes and aligned on 2Mbytes boundarie.
> On mpc83xx without a QE, IMMR is 1Mbyte and 1Mbyte aligned.
>
> Each driver will map a part of it to access the registers it needs.
> Some drivers will map the sam
If a process (qemu) with a lot of CPUs (128) try to munmap() a large chunk
of memory (496GB) mapped with THP, it takes an average of 275 seconds,
which can cause a lot of problems to the load (in qemu case, the guest
will lock for this time).
Trying to find the source of this bug, I found out most
On Fri, Sep 13, 2019 at 05:48:40AM +, S.j. Wang wrote:
> Hi
>
> >
> > On Tue, Sep 10, 2019 at 02:07:25AM +, S.j. Wang wrote:
> > > > On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote:
> > > > > The ASRC support 24bit/16bit/8bit input width, so S20_3LE format
> > > > > should n
On Fri, Sep 13, 2019 at 05:42:13PM +0800, Shengjiu Wang wrote:
> Add the DT binding documentation for NXP MQS driver
>
> Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
> ---
> Changes in v2
> -refine the comments for properties
>
> .../devicetree/bindings/sound/fsl,mqs.txt | 36
On Fri, Sep 13, 2019 at 05:42:14PM +0800, Shengjiu Wang wrote:
> MQS (medium quality sound), is used to generate medium quality
> audio via a standard digital output pin. It can be used to
> connect stereo speakers or headphones simply via power amplifier
> stages without an additional DAC chip. It
On Tue, Sep 03, 2019 at 08:15:52PM +1000, Oliver O'Halloran wrote:
> When the last device in an eeh_pe is removed the eeh_pe structure itself
> (and any empty parents) are freed since they are no longer needed. This
> results in a crash when a hotplug driver is involved since the following
> may oc
Commit 388cc6e133132 ("KVM: PPC: Book3S HV: Support POWER6
compatibility mode on POWER7") introduced new macros defining the PCR
bits. When used from assembly files these definitions lead to build
errors using older versions of binutils that don't support the 'ul'
suffix. This fixes the build error
From: Jordan Niethe
Currently the reserved bits of the Processor Compatibility Register
(PCR) are cleared as per the Programming Note in Section 1.3.3 of
version 3.0B of the Power ISA. This causes all new architecture
features to be made available when running on newer processors with
new archite
Those definitions were introduced in a previous commit so I've posted a new
series to fix the definitions first. Thanks.
- Alistair
On Monday, 16 September 2019 7:49:26 PM AEST Michael Ellerman wrote:
> Alistair Popple writes:
> > Currently the reserved bits of the Processor Compatibility Regis
On Tue, Sep 03, 2019 at 08:15:53PM +1000, Oliver O'Halloran wrote:
> When hot-adding devices we rely on the hotplug driver to create pci_dn's
> for the devices under the hotplug slot. Converse, when hot-removing the
> driver will remove the pci_dn's that it created. This is a problem because
> the
On Tue, Sep 03, 2019 at 08:15:54PM +1000, Oliver O'Halloran wrote:
> If a device is torn down by a hotplug slot driver it's marked as removed
> and marked as permaantly failed. There's no point in trying to recover a
permanently
> permernantly failed device so it should be considered un-actionable.
On Tue, Sep 03, 2019 at 08:15:55PM +1000, Oliver O'Halloran wrote:
> When a device is surprise removed while undergoing IO we will probably
> get an EEH PE freeze due to MMIO timeouts and other errors. When a freeze
> is detected we send a recovery event to the EEH worker thread which will
> notify
On Tue, Sep 03, 2019 at 08:15:56PM +1000, Oliver O'Halloran wrote:
> Currently we print a stack trace in the event handler to help with
> debugging EEH issues. In the case of suprise hot-unplug this is unneeded,
> so we want to prevent printing the stack trace unless we know it's due to
> an actual
On Tue, Sep 03, 2019 at 08:15:57PM +1000, Oliver O'Halloran wrote:
> Support for switching CAPI cards into and out of CAPI mode was removed a
> while ago. Drop the comment since it's no longer relevant.
>
> Cc: Andrew Donnellan
> Signed-off-by: Oliver O'Halloran
LGTM
Reviewed-by: Sam Bobroff
On Tue, Sep 03, 2019 at 08:15:58PM +1000, Oliver O'Halloran wrote:
> When we reset PCI devices managed by a hotplug driver the reset may
> generate spurious hotplug events that cause the PCI device we're resetting
> to be torn down accidently. This is a problem for EEH (when the driver is
> EEH awa
On Tue, Sep 03, 2019 at 08:16:02PM +1000, Oliver O'Halloran wrote:
> I am the RAS team. Hear me roar.
>
> Roar.
>
> On a more serious note, being able to locate failed devices can be helpful.
> Set the attention indicator if the slot supports it once we've determined
> the device is present and o
On Tue, Sep 17, 2019 at 11:04 AM Sam Bobroff wrote:
>
> On Tue, Sep 03, 2019 at 08:15:56PM +1000, Oliver O'Halloran wrote:
> > Currently we print a stack trace in the event handler to help with
> > debugging EEH issues. In the case of suprise hot-unplug this is unneeded,
> > so we want to prevent
From: Alastair D'Silva
This series provides the prerequisite infrastructure to allow
external drivers to map & access OpenCAPI LPC memory.
Alastair D'Silva (5):
powerpc: Add OPAL calls for LPC memory alloc/release
powerpc: Map & release OpenCAPI LPC memory
ocxl: Tally up the LPC memory on
From: Alastair D'Silva
Add OPAL calls for LPC memory alloc/release
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/opal-api.h| 4 +++-
arch/powerpc/include/asm/opal.h| 3 +++
arch/powerpc/platforms/powernv/opal-call.c | 2 ++
3 files changed, 8 insertions(+), 1
From: Alastair D'Silva
Map & release OpenCAPI LPC memory.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/pnv-ocxl.h | 2 ++
arch/powerpc/platforms/powernv/ocxl.c | 42 +++
2 files changed, 44 insertions(+)
diff --git a/arch/powerpc/include/asm/pnv-ocxl
From: Alastair D'Silva
Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/core.c | 9 +
drivers/misc/ocxl/link.c | 61 +++
drivers/misc/ocxl/ocxl_internal.h | 42 ++
From: Alastair D'Silva
Add functions to map/unmap LPC memory
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c| 4 +++
drivers/misc/ocxl/core.c | 50 +++
drivers/misc/ocxl/link.c | 4 +--
drivers/misc/ocxl/ocxl_internal.h | 1
From: Alastair D'Silva
This patch exposes the OpenCAPI device serial number to
userspace.
It also includes placeholders for the LPC & special purpose
memory information (which will be populated in a subsequent patch)
to avoid creating excessive versions of the IOCTL.
Signed-off-by: Alastair D'S
Hi Rafael,
On Wednesday, August 21, 2019 11:16, Ran Wang wrote:
>
> Some user might want to go through all registered wakeup sources and doing
> things accordingly. For example, SoC PM driver might need to do HW
> programming to prevent powering down specific IP which wakeup source
> depending on
On 9/17/19 2:25 AM, Leonardo Bras wrote:
If a process (qemu) with a lot of CPUs (128) try to munmap() a large chunk
of memory (496GB) mapped with THP, it takes an average of 275 seconds,
which can cause a lot of problems to the load (in qemu case, the guest
will lock for this time).
Trying to fi
On Tue, Sep 03, 2019 at 08:16:03PM +1000, Oliver O'Halloran wrote:
> Detecting an frozen EEH PE usually occurs when an MMIO load returns a 0xFFs
> response. When performing EEH testing using the EEH error injection feature
> available on some platforms there is no simple way to kick-off the kernel'
On Tue, Sep 03, 2019 at 08:16:04PM +1000, Oliver O'Halloran wrote:
> Add an interface to debugfs for generating an EEH event on a given device.
> This works by disabling memory accesses to and from the device by setting
> the PCI_COMMAND register (or the VF Memory Space Enable on the parent PF).
>
On Tue, Sep 17, 2019 at 11:45:14AM +1000, Oliver O'Halloran wrote:
> On Tue, Sep 17, 2019 at 11:04 AM Sam Bobroff wrote:
> >
> > On Tue, Sep 03, 2019 at 08:15:56PM +1000, Oliver O'Halloran wrote:
> > > Currently we print a stack trace in the event handler to help with
> > > debugging EEH issues. I
On Tue, Sep 17, 2019 at 1:16 PM Sam Bobroff wrote:
>
> On Tue, Sep 03, 2019 at 08:16:03PM +1000, Oliver O'Halloran wrote:
> > Detecting an frozen EEH PE usually occurs when an MMIO load returns a 0xFFs
> > response. When performing EEH testing using the EEH error injection feature
> > available on
On Tue, Sep 17, 2019 at 1:35 PM Sam Bobroff wrote:
>
> On Tue, Sep 17, 2019 at 11:45:14AM +1000, Oliver O'Halloran wrote:
> >
> > Two reasons:
> >
> > 1) the eeh_event structures are allocated with GFP_ATOMIC since
> > eeh_dev_check_failure() can be called from any context. Minimising the
> > numb
On Tue, Sep 17, 2019 at 11:01 AM Sam Bobroff wrote:
>
> On Tue, Sep 03, 2019 at 08:15:55PM +1000, Oliver O'Halloran wrote:
> > When a device is surprise removed while undergoing IO we will probably
> > get an EEH PE freeze due to MMIO timeouts and other errors. When a freeze
> > is detected we sen
On Tue, Sep 17, 2019 at 1:36 PM Oliver O'Halloran wrote:
>
> On Tue, Sep 17, 2019 at 1:16 PM Sam Bobroff wrote:
> >
> > On Tue, Sep 03, 2019 at 08:16:03PM +1000, Oliver O'Halloran wrote:
> > > Detecting an frozen EEH PE usually occurs when an MMIO load returns a
> > > 0xFFs
> > > response. When
Hi Alastair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190916]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
Why:
- Cannot write register RCPM_IPPDEXPCR1 on LS1021A,
Register RCPM_IPPDEXPCR1's default value is zero.
So the register value that reading from register
RCPM_IPPDEXPCR1 is always zero.
How:
- Save register RCPM_IPPDEXPCR1's value to
register SCFG_SPARECR8.(uboot'
The patch fix a bug that FlexTimer cannot
wakeup system in deep sleep.
Signed-off-by: Biwen Li
---
Change in v2:
- None
arch/arm/boot/dts/ls1021a.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
in
The 'fsl,rcpm-scfg' property is used to fix a bug
that FlexTimer cannot wakeup system in deep sleep on LS1021A
Signed-off-by: Biwen Li
---
Change in v2:
- update desc of the property 'fsl,rcpm-scfg'
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 13 +
1 file changed, 1
Hi all,
the linux patches depended by RCPM driver,FlexTimer driver and
FlexTimer dts, need apply these patches as follows:
1. RCPM driver:
https://patchwork.kernel.org/series/162731/mbox/
(https://patchwork.kernel.org/patch/11105279/)
2. FlexTimer dts:
Yunsheng Lin writes:
> When passing the return value of dev_to_node() to cpumask_of_node()
> without checking if the device's node id is NUMA_NO_NODE, there is
> global-out-of-bounds detected by KASAN.
>
> From the discussion [1], NUMA_NO_NODE really means no node affinity,
> which also means all
Cc Kexec list. And keep the original content.
On Thu, Sep 12, 2019 at 10:50 AM Pingfan Liu wrote:
>
> 'mem=" option is an easy way to put high pressure on memory during some
> test. Hence in stead of total mem, the effective usable memory size should
> be considered when reserving mem for crashke
On Tue, Sep 10, 2019 at 4:29 PM Aneesh Kumar K.V
wrote:
>
> With commit: 7cc7867fb061 ("mm/devm_memremap_pages: enable sub-section remap")
> pmem namespaces are remapped in 2M chunks. On architectures like ppc64 we
> can map the memmap area using 16MB hugepage size and that can cover
> a memory ra
On 2019/9/17 13:28, Michael Ellerman wrote:
> Yunsheng Lin writes:
>> When passing the return value of dev_to_node() to cpumask_of_node()
>> without checking if the device's node id is NUMA_NO_NODE, there is
>> global-out-of-bounds detected by KASAN.
>>
>> From the discussion [1], NUMA_NO_NODE rea
On Tue, 2019-09-17 at 11:43 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> This patch exposes the OpenCAPI device serial number to
> userspace.
>
> It also includes placeholders for the LPC & special purpose
> memory information (which will be populated in a subsequent patch)
> to a
77 matches
Mail list logo
