Hi Sachin,
On 03/24/20 at 11:25am, Sachin Sant wrote:
> While running ndctl[1] tests against 5.6.0-rc7 following crash is encountered.
>
> Bisect leads me to commit d41e2f3bd546
> mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
>
> Reverting this commit helps and the tests comple
On Tue, Mar 24, 2020 at 02:37:59PM +1100, Alexey Kardashevskiy wrote:
> dma_alloc_direct() and dma_map_direct() do the same thing now which is
> good, did I miss anything else?
dma_alloc_direct looks at coherent_dma_mask, dma_map_direct looks
at dma_mask.
On Tue, Mar 24, 2020 at 02:05:54PM +1100, Alexey Kardashevskiy wrote:
> This is for persistent memory which you can DMA to/from but yet it does
> not appear in the system as a normal memory and therefore requires
> special handling anyway (O_DIRECT or DAX, I do not know the exact
> mechanics). All
On Tue, Mar 24, 2020 at 12:00:09PM +0530, Aneesh Kumar K.V wrote:
> dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
> unsigned long offset, size_t size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> phys_addr_t phys = page_to_phys(
On Mon, Mar 23, 2020 at 02:23:49PM -0400, Joel Fernandes wrote:
> On Sun, Mar 22, 2020 at 08:51:15AM +0200, Kalle Valo wrote:
> > "Joel Fernandes (Google)" writes:
> >
> > > Reword and clarify better about the rwsem non-owner release issue.
> > >
> > > Link: https://lore.kernel.org/linux-pci/2020
Hi
Am 14.03.20 um 11:59 schrieb Krzysztof Kozlowski:
> On Thu, Mar 12, 2020 at 11:49:05AM +0100, Thomas Zimmermann wrote:
>> Hi Krzysztof,
>>
>> I just received a resend email from 3 weeks ago :/
>>
>> Do you want me to merge the mgag200 patch into drm-misc-next?
>
> Thanks but it depends on the
Michal Suchanek's on March 19, 2020 10:19 pm:
> There are two almost identical copies for 32bit and 64bit.
>
> The function is used only in 32bit code which will be split out in next
> patch so consolidate to one function.
>
> Signed-off-by: Michal Suchanek
> Reviewed-by: Christophe Leroy
> ---
Michal Suchanek's on March 19, 2020 10:19 pm:
> diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
> index 4b0152108f61..a264989626fd 100644
> --- a/arch/powerpc/kernel/signal.c
> +++ b/arch/powerpc/kernel/signal.c
> @@ -247,7 +247,6 @@ static void do_signal(struct task_struct
Sachin Sant writes:
> While running ndctl[1] tests against 5.6.0-rc7 following crash is encountered.
>
> Bisect leads me to commit d41e2f3bd546
> mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
>
> Reverting this commit helps and the tests complete without any crash.
>
> pmem0: de
> On 24-Mar-2020, at 2:45 PM, Aneesh Kumar K.V
> wrote:
>
> Sachin Sant writes:
>
>> While running ndctl[1] tests against 5.6.0-rc7 following crash is
>> encountered.
>>
>> Bisect leads me to commit d41e2f3bd546
>> mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
>>
>> Rev
Hi All,
The DMA mapping works great on our PowerPC machines currently. It was a
long way to get the new DMA mapping code to work successfully on our
PowerPC machines.
P L E A S E don't modify the good working DMA mapping code. There are
many other topics which needs improvements. For us (fi
On 03/24/20 at 03:06pm, Sachin Sant wrote:
>
>
> > On 24-Mar-2020, at 2:45 PM, Aneesh Kumar K.V
> > wrote:
> >
> > Sachin Sant writes:
> >
> >> While running ndctl[1] tests against 5.6.0-rc7 following crash is
> >> encountered.
> >>
> >> Bisect leads me to commit d41e2f3bd546
> >> mm/hot
Hi Michael Ellerman,
On Thu, Mar 12, 2020 at 12:12:55PM +0530, afzal mohammed wrote:
> request_irq() is preferred over setup_irq(). Invocations of setup_irq()
> occur after memory allocators are ready.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the tim
On Tue, 24 Mar 2020 10:43:23 +1100
Paul Mackerras wrote:
> On Fri, Mar 20, 2020 at 01:22:48PM +0100, Greg Kurz wrote:
> > On Fri, 20 Mar 2020 11:26:42 +0100
> > Laurent Dufour wrote:
> >
> > > The Hcall named H_SVM_* are reserved to the Ultravisor. However, nothing
> > > prevent a malicious VM
On 3/23/20 8:02 PM, Haren Myneni wrote:
> On Mon, 2020-03-23 at 10:27 +0100, Cédric Le Goater wrote:
>> On 3/23/20 10:06 AM, Cédric Le Goater wrote:
>>> On 3/19/20 7:14 AM, Haren Myneni wrote:
Alloc IRQ and get trigger port address for each VAS instance. Kernel
register this IRQ per
On Fri, Mar 20, 2020 at 06:24:04PM +0530, Kajol Jain wrote:
SNIP
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 52fb119d25c8..b4b91d8ad5be 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -474,8 +474,13 @@ static bool me
On Fri, Mar 20, 2020 at 06:24:04PM +0530, Kajol Jain wrote:
> Patch enhances current metric infrastructure to handle "?" in the metric
> expression. The "?" can be use for parameters whose value not known while
> creating metric events and which can be replace later at runtime to
> the proper value
Le 24/03/2020 à 13:00, Greg Kurz a écrit :
On Tue, 24 Mar 2020 10:43:23 +1100
Paul Mackerras wrote:
On Fri, Mar 20, 2020 at 01:22:48PM +0100, Greg Kurz wrote:
On Fri, 20 Mar 2020 11:26:42 +0100
Laurent Dufour wrote:
The Hcall named H_SVM_* are reserved to the Ultravisor. However, nothing
p
From: Vlastimil Babka
commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x73b0
Faulting instruction address: 0xc03d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
LE
From: Vlastimil Babka
commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x73b0
Faulting instruction address: 0xc03d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
LE
From: Vlastimil Babka
commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x73b0
Faulting instruction address: 0xc03d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
LE
On 3/24/20 3:26 AM, Oliver O'Halloran wrote:
> On Mon, Mar 23, 2020 at 8:28 PM Cédric Le Goater wrote:
>>
>> On 3/23/20 10:06 AM, Cédric Le Goater wrote:
>>> On 3/19/20 7:14 AM, Haren Myneni wrote:
Alloc IRQ and get trigger port address for each VAS instance. Kernel
register this IR
On 3/19/20 7:13 AM, Haren Myneni wrote:
>
> pnv_ocxl_alloc_xive_irq() in ocxl.c allocates IRQ and gets trigger port
> address. VAS also needs this function, but based on chip ID. So moved
> this common function to xive/native.c.
>
> Signed-off-by: Haren Myneni
I think we should work on a new in
On 3/19/20 7:12 AM, Haren Myneni wrote:
>
> This function allocates IRQ on a specific chip. VAS needs per chip
> IRQ allocation and will have IRQ handler per VAS instance.
>
> Signed-off-by: Haren Myneni
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> arch/powerpc/include/asm/xive.h | 9
On 3/19/20 7:14 AM, Haren Myneni wrote:
>
> Alloc IRQ and get trigger port address for each VAS instance. Kernel
> register this IRQ per VAS instance and sets this port for each send
> window. NX interrupts the kernel when it sees page fault.
>
> Signed-off-by: Haren Myneni
> ---
> arch/powerpc
Le 23/03/2020 à 15:04, Christophe Leroy a écrit :
On 03/23/2020 11:30 AM, Christophe Leroy wrote:
On 03/23/2020 04:52 AM, Christopher M. Riedl wrote:
When compiled with CONFIG_STRICT_KERNEL_RWX, the kernel must create
temporary mappings when patching itself. These mappings temporarily
ov
Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
x86 supports the notion of a temporary mm which restricts access to
temporary PTEs to a single CPU. A temporary mm is useful for situations
where a CPU needs to perform sensitive operations (such as patching a
STRICT_KERNEL_RWX kernel) requ
Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
When code patching a STRICT_KERNEL_RWX kernel the page containing the
address to be patched is temporarily mapped with permissive memory
protections. Currently, a per-cpu vmalloc patch area is used for this
purpose. While the patch area is
Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
Currently, code patching a STRICT_KERNEL_RWX exposes the temporary
mappings to other CPUs. These mappings should be kept local to the CPU
doing the patching. Use the pre-initialized temporary mm and patching
address for this purpose. Also a
On Tue, Mar 24, 2020 at 08:15:39AM +, Will Deacon wrote:
> On Mon, Mar 23, 2020 at 02:23:49PM -0400, Joel Fernandes wrote:
> > On Sun, Mar 22, 2020 at 08:51:15AM +0200, Kalle Valo wrote:
> > > "Joel Fernandes (Google)" writes:
> > >
> > > > Reword and clarify better about the rwsem non-owner
The if statement that this comment referred to was removed in
commit 11fdb309341c ("powerpc/prom_init: Remove support for OPAL v2").
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kernel/prom_init.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/
On Tue, Mar 24, 2020 at 06:54:20PM +1000, Nicholas Piggin wrote:
> Michal Suchanek's on March 19, 2020 10:19 pm:
> > diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
> > index 4b0152108f61..a264989626fd 100644
> > --- a/arch/powerpc/kernel/signal.c
> > +++ b/arch/powerpc/ker
On Tue, Mar 24, 2020 at 06:48:20PM +1000, Nicholas Piggin wrote:
> Michal Suchanek's on March 19, 2020 10:19 pm:
> > There are two almost identical copies for 32bit and 64bit.
> >
> > The function is used only in 32bit code which will be split out in next
> > patch so consolidate to one function.
On Tue, 2020-03-24 at 15:47 +1100, Michael Ellerman wrote:
> Chris Packham writes:
> > Hi All,
> >
> > Just booting up v5.5.11 on a Freescale T2080RDB and I'm seeing the
> > following mesage.
> >
> > kern.warning linuxbox kernel: Argh, can't find dcache properties !
> > kern.warning linuxbox ker
QEMU can now print the ibm,os-term message[1], so let's include it in
the RTAS call. E.g.:
qemu-system-ppc64: OS terminated: Switch to secure mode failed.
1- https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a4c3791ae0
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kernel/prom_init.c | 3 +++
1
ernel Userspace Access Prevention
[0.00][T0] radix-mmu: Mapped 0x-0x0160
with 2.00 MiB pages (exec)
[0.00][T0] radix-mmu: Mapped 0x0160-0x4000
with 2.00 MiB pages
[0.00][T0] radix-mmu: Mapped 0x4
On Tue, 2020-03-24 at 15:48 +0100, Cédric Le Goater wrote:
> On 3/19/20 7:14 AM, Haren Myneni wrote:
> >
> > Alloc IRQ and get trigger port address for each VAS instance. Kernel
> > register this IRQ per VAS instance and sets this port for each send
> > window. NX interrupts the kernel when it see
On 3/24/20 10:57 AM, Michael Ellerman wrote:
Ganesh Goudar writes:
If we hit UE at an instruction with a fixup entry, flag to
ignore the event and set nip to continue execution at the
fixup entry.
You don't explain why we would want to do that. Or what the consequences
are if we *don't* do it
On 24 Mar 2020, at 1:22, Anshuman Khandual wrote:
> This adds new tests validating arch page table helpers for these following
> core memory features. These tests create and test specific mapping types at
> various page table levels.
>
> 1. SPECIAL mapping
> 2. PROTNONE mapping
> 3. DEVMAP mapping
Add the d-cache/i-cache properties for the T208x SoCs. The L1 cache on
these SoCs is 32KiB and is split into 64 byte blocks (lines).
Signed-off-by: Chris Packham
---
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/boot
Paul,
"Paul E. McKenney" writes:
> On Sat, Mar 21, 2020 at 12:25:57PM +0100, Thomas Gleixner wrote:
> In the normal case where the task sleeps through the entire lock
> acquisition, the sequence of events is as follows:
>
> state = UNINTERRUPTIBLE
> lock()
>block()
> re
On Wed, Mar 25, 2020 at 12:13:34AM +0100, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" writes:
> > On Sat, Mar 21, 2020 at 12:25:57PM +0100, Thomas Gleixner wrote:
> > In the normal case where the task sleeps through the entire lock
> > acquisition, the sequence of events is as follows:
On 3/23/20 8:47 PM, Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
wrote:
>
>
> On 2020/3/24 8:43, Mina Almasry wrote:
>> On Wed, Mar 18, 2020 at 3:07 PM Mike Kravetz wrote:
>>> +default_hugepagesz - Specify the default huge page size. This parameter
>>> can
>>> + only be s
Chris Packham writes:
> Add the d-cache/i-cache properties for the T208x SoCs. The L1 cache on
> these SoCs is 32KiB and is split into 64 byte blocks (lines).
>
> Signed-off-by: Chris Packham
> ---
> arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 16
> 1 file changed, 16 insertion
On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> Chris Packham writes:
> > Add the d-cache/i-cache properties for the T208x SoCs. The L1 cache on
> > these SoCs is 32KiB and is split into 64 byte blocks (lines).
> >
> > Signed-off-by: Chris Packham
> > ---
> > arch/powerpc/boot/dts/
On Tue, 2020-03-24 at 21:08 -0500, Scott Wood wrote:
> On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> > Chris Packham writes:
> > > Add the d-cache/i-cache properties for the T208x SoCs. The L1
> > > cache on
> > > these SoCs is 32KiB and is split into 64 byte blocks (lines).
> > >
On Wed, 2020-03-25 at 15:38 +1300, Chris Packham wrote:
> On Tue, 2020-03-24 at 21:08 -0500, Scott Wood wrote:
> > On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> > > Chris Packham writes:
> > > > Add the d-cache/i-cache properties for the T208x SoCs. The L1
> > > > cache on
> > > > t
On 23/3/20 3:52 pm, Christopher M. Riedl wrote:
When compiled with CONFIG_STRICT_KERNEL_RWX, the kernel must create
temporary mappings when patching itself. These mappings temporarily
override the strict RWX text protections to permit a write. Currently,
powerpc allocates a per-CPU VM area for pa
On 2020/3/19 6:52, Mike Kravetz wrote:
> On 3/18/20 3:15 PM, Dave Hansen wrote:
>> Hi Mike,
>>
>> The series looks like a great idea to me. One nit on the x86 bits,
>> though...
>>
>>> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
>>> index 5bfd5aef5378..51e6208fdeec 100644
On Mon, 2020-03-23 at 12:23 +1000, Nicholas Piggin wrote:
> Haren Myneni's on March 19, 2020 4:15 pm:
> >
> > Setup thread IRQ handler per each VAS instance. When NX sees a fault
> > on CRB, kernel gets an interrupt and vas_fault_handler will be
> > executed to process fault CRBs. Read all valid C
On Mon, 2020-03-23 at 12:40 +1000, Nicholas Piggin wrote:
> Haren Myneni's on March 19, 2020 4:18 pm:
> >
> > System checkstops if RxFIFO overruns with more requests than the
> > maximum possible number of CRBs allowed in FIFO at any time. So
> > max credits value (rxattr.wcreds_max) is set and is
Quoting Mauro Carvalho Chehab (2020-02-22 01:00:03)
> 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
> ---
> drivers/hwtracing/core
If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, use
the block-size value for both. Per the devicetree spec cache-line-size
is only needed if it differs from the block size.
Signed-off-by: Chris Packham
---
It looks as though the bsizep = lsizep is not required per the spec but
Fixes the below crash
BUG: Kernel NULL pointer dereference on read at 0x
Faulting instruction address: 0xc0c3447c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1
On Mon, 2020-03-23 at 12:44 +1000, Nicholas Piggin wrote:
> Haren Myneni's on March 19, 2020 4:19 pm:
> >
> > NX expects OS to return credit for send window after processing each
> > fault. Also credit has to be returned even for fault window.
>
> And this should be merged in the fault handler fu
On Tue, 2020-03-24 at 14:41 +1100, Michael Ellerman wrote:
> Daniel Axtens writes:
> > Michael Ellerman writes:
> >> Daniel Axtens writes:
> >>> Haren Myneni writes:
> diff --git a/arch/powerpc/platforms/powernv/vas-api.c
> b/arch/powerpc/platforms/powernv/vas-api.c
> new file m
The ISA has a quirk that's useful for the Linux implementation.
Document it here so others are less likely to trip over it.
Signed-off-by: Michael Neuling
Suggested-by: Michael Ellerman
---
.../powerpc/transactional_memory.rst | 27 +++
1 file changed, 27 insertions(+)
On 24/03/2020 18:54, Christoph Hellwig wrote:
> On Tue, Mar 24, 2020 at 02:05:54PM +1100, Alexey Kardashevskiy wrote:
>> This is for persistent memory which you can DMA to/from but yet it does
>> not appear in the system as a normal memory and therefore requires
>> special handling anyway (O_DIR
On Wed, 25 Mar 2020 at 05:19, Fangrui Song wrote:
>
> .globl sets the symbol binding to STB_GLOBAL while .weak sets the
> binding to STB_WEAK. They should not be used together. It is accidetal
> rather then intentional that GNU as let .weak override .globl while
> clang integrated assembler let th
Qian Cai writes:
>> On Mar 24, 2020, at 4:06 PM, Chris Packham
>> wrote:
>> On Tue, 2020-03-24 at 15:47 +1100, Michael Ellerman wrote:
>>> Chris Packham writes:
Hi All,
Just booting up v5.5.11 on a Freescale T2080RDB and I'm seeing the
following mesage.
kern.warn
On Tue, Mar 24, 2020 at 10:18:20PM -0700, Fangrui Song wrote:
> .globl sets the symbol binding to STB_GLOBAL while .weak sets the
> binding to STB_WEAK. They should not be used together. It is accidetal
> rather then intentional that GNU as let .weak override .globl while
> clang integrated assembl
61 matches
Mail list logo
