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
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
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 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
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
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
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
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
> ---
>
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
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
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
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
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
> > > >
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 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
> > ---
> >
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
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
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:
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()
>
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
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
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
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
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 0x4000-0x0020
with 1.00 GiB pages
[0
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 +++
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
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, 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
> > +++
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
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
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
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 :
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)
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
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
> ---
>
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 |
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
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
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]
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]
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 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
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
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
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 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
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
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
> >>
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
> 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
>>
>>
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:
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
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
>
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
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:
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 =
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 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.
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
On 3/24/20 12:08 PM, Michael Ellerman wrote:
"Aneesh Kumar K.V" writes:
THP config can result in compound pages. Make sure kernel enables the
PageCompound() check when only THP is enabled.
Or else what happens ... nothing, rampant data corruption, something in
between?
We can get a stale
"Aneesh Kumar K.V" writes:
> THP config can result in compound pages. Make sure kernel enables the
> PageCompound() check when only THP is enabled.
Or else what happens ... nothing, rampant data corruption, something in
between?
And "when only THP is enabled" is not very clear, AFAIK there is
"Rafael J. Wysocki" writes:
> On Monday, March 16, 2020 2:57:43 PM CET Pratik Rajesh Sampat wrote:
>> The patch avoids allocating cpufreq_policy on stack hence fixing frame
>> size overflow in 'powernv_cpufreq_work_fn'
>>
>> Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to
Alexey Kardashevskiy writes:
> On 24/03/2020 04:22, Christoph Hellwig wrote:
>> On Mon, Mar 23, 2020 at 09:07:38PM +0530, Aneesh Kumar K.V wrote:
>>>
>>> This is what I was trying, but considering I am new to DMA subsystem, I
>>> am not sure I got all the details correct. The idea is to look at
Christophe Leroy writes:
> On 03/20/2020 02:12 AM, Michael Ellerman wrote:
>> Christophe Leroy writes:
>>> Move ADV_DEBUG_REGS functions out of ptrace.c, into
>>> ptrace-adv.c and ptrace-noadv.c
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> v4: Leave hw_breakpoint.h for ptrace.c
>>> ---
On Tue, 2020-03-24 at 14:18 +1100, Jordan Niethe wrote:
> On Mon, Mar 23, 2020 at 10:13 PM Balamuruhan S wrote:
> > On Fri, 2020-03-20 at 16:18 +1100, Jordan Niethe wrote:
> > > In preparation for prefixed instructions where all instructions are no
> > > longer words, use an accessor for getting
On Tue, 2020-03-24 at 14:52 +1100, Michael Ellerman wrote:
> "Naveen N. Rao" writes:
> > Segher Boessenkool wrote:
> > > On Mon, Mar 23, 2020 at 04:55:48PM +0530, Balamuruhan S wrote:
> > > > Data Cache Block Invalidate (dcbi) instruction implemented in 32-bit
> > > > designs prior to PowerPC
On Mon, 2020-03-23 at 07:46 -0500, Segher Boessenkool wrote:
> On Mon, Mar 23, 2020 at 04:55:48PM +0530, Balamuruhan S wrote:
> > Data Cache Block Invalidate (dcbi) instruction implemented in 32-bit
> > designs prior to PowerPC architecture version 2.01 and got obsolete
> > from version 2.01.
>
>
67 matches
Mail list logo