(added Andrey Konovalov)
On Thu, Jan 31, 2019 at 07:15:26AM +0100, Christophe Leroy wrote:
>
> Le 31/01/2019 à 07:06, Stephen Rothwell a écrit :
> >Hi all,
> >
> >On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
> >wrote:
> >>
> >>[I am guessing that is is something in Andrew's tree that
On Thu, Jan 31, 2019 at 08:07:29AM +0100, Christophe Leroy wrote:
>
>
> Le 31/01/2019 à 07:44, Christophe Leroy a écrit :
> >
> >
> >Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
> >>On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
> >>>
> >>>
> >>>Le 21/01/2019 à 09:04, Mike
Hi Mike,
On Thu, 31 Jan 2019 08:39:30 +0200 Mike Rapoport wrote:
>
> On Thu, Jan 31, 2019 at 07:15:26AM +0100, Christophe Leroy wrote:
> >
> > Le 31/01/2019 à 07:06, Stephen Rothwell a écrit :
> > >>My qemu boot of the powerpc pseries_le_defconfig config failed like this:
> > >>
> >
Le 31/01/2019 à 07:44, Christophe Leroy a écrit :
Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
Hi Masahiro,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc4 next-20190130]
[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
Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
>
>
> Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
> >Add check for the return value of memblock_alloc*() functions and call
> >panic() in case of error.
> >The panic message repeats the one used by panicing memblock allocators
On Thu, Jan 31, 2019 at 07:15:26AM +0100, Christophe Leroy wrote:
>
>
> Le 31/01/2019 à 07:06, Stephen Rothwell a écrit :
> >Hi all,
> >
> >On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
> >wrote:
> >>
> >>[I am guessing that is is something in Andrew's tree that has caused
> >>this.]
>
Le 31/01/2019 à 07:06, Stephen Rothwell a écrit :
Hi all,
On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
wrote:
[I am guessing that is is something in Andrew's tree that has caused
this.]
My qemu boot of the powerpc pseries_le_defconfig config failed like this:
htab_hash_mask=
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.
The replacement
Hi all,
On Thu, 31 Jan 2019 16:38:54 +1100 Stephen Rothwell
wrote:
>
> [I am guessing that is is something in Andrew's tree that has caused
> this.]
>
> My qemu boot of the powerpc pseries_le_defconfig config failed like this:
>
> htab_hash_mask= 0x1
>
Jiri Kosina writes:
> On Wed, 30 Jan 2019, Michael Ellerman wrote:
>
>> I'm happy to take it, unless there's some reason you'd rather it go via
>> the LP tree?
>
> As this is more about reliable stack unwinding than live patching per se
> (which is only a user of that facility), I'd actually
Nicolai Stange writes:
> Michael Ellerman writes:
>
>> Joe Lawrence writes:
>>> From: Nicolai Stange
>>>
>>> The ppc64 specific implementation of the reliable stacktracer,
>>> save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
>>> trace" whenever it finds an exception frame
Michael Bringmann writes:
> This patch is to check for cede'ed CPUs during LPM. Some extreme
> tests encountered a problem ehere Linux has put some threads to
> sleep (possibly to save energy or something), LPM was attempted,
> and the Linux kernel didn't awaken the sleeping threads, but issued
Hi all,
[I am guessing that is is something in Andrew's tree that has caused
this.]
My qemu boot of the powerpc pseries_le_defconfig config failed like this:
htab_hash_mask= 0x1
-
numa: NODE_DATA [mem 0x7ffe7000-0x7ffebfff]
Kernel
Michael Ellerman writes:
> "Aneesh Kumar K.V" writes:
>> NestMMU requires us to mark the pte invalid and flush the tlb when we do a
>> RW upgrade of pte. We fixed a variant of this in the fault path in commit
>> Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle
>>
Michael Ellerman writes:
> "Aneesh Kumar K.V" writes:
>
>> Architectures like ppc64 require to do a conditional tlb flush based on the
>> old
>> and new value of pte. Enable that by passing old pte value as the arg.
>
> It's not actually the architecture, it's to work around a specific bug
>
Michael Ellerman writes:
> "Aneesh Kumar K.V" writes:
>
>> The current code doesn't do page migration if the page allocated is a
>> compound page.
>> With HugeTLB migration support, we can end up allocating hugetlb pages from
>> CMA region. Also, THP pages can be allocated from CMA region.
Christophe Leroy writes:
> In powerpc code, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a pagefault_disable()/enable()
> pair, etc.
Christophe Leroy writes:
> Instead of opencoding, use probe_user_read() to failessly
> read a user location.
>
> Signed-off-by: Christophe Leroy
> ---
> v3: No change
>
> v2: Using probe_user_read() instead of probe_user_address()
>
> arch/powerpc/kernel/process.c | 12 +---
>
On Wed, Jan 30, 2019 at 08:01:22AM +0100, Cédric Le Goater wrote:
> On 1/30/19 5:29 AM, Paul Mackerras wrote:
> > On Mon, Jan 28, 2019 at 06:35:34PM +0100, Cédric Le Goater wrote:
> >> On 1/22/19 6:05 AM, Paul Mackerras wrote:
> >>> On Mon, Jan 07, 2019 at 07:43:17PM +0100, Cédric Le Goater wrote:
On Wed, Jan 30, 2019 at 04:54:23PM +0100, Cédric Le Goater wrote:
> On 1/30/19 7:20 AM, Paul Mackerras wrote:
> > On Tue, Jan 29, 2019 at 02:47:55PM +0100, Cédric Le Goater wrote:
> >> On 1/29/19 3:45 AM, Paul Mackerras wrote:
> >>> On Mon, Jan 28, 2019 at 07:26:00PM +0100, Cédric Le Goater wrote:
It is fragile to rely on the compiler's optimization to avoid the
section mismatch. Some functions may not be necessarily inlined
when the compiler's inlining heuristic changes.
Add __init markers consistently.
As for prom_getprop() and prom_getproplen(), they are marked as
'inline', so inlining
When binding an SCM volume to a physical address the hypervisor has the
option to return early with a continue token with the expectation that
the guest will resume the bind operation until it completes. A quirk of
this interface is that the bind address will only be returned by the
first bind
This patch is to check for cede'ed CPUs during LPM. Some extreme
tests encountered a problem ehere Linux has put some threads to
sleep (possibly to save energy or something), LPM was attempted,
and the Linux kernel didn't awaken the sleeping threads, but issued
the H_JOIN for the active threads.
From: Mathias Thore
Date: Mon, 28 Jan 2019 10:07:47 +0100
> After a timeout event caused by for example a broadcast storm, when
> the MAC and PHY are reset, the BQL TX queue needs to be reset as
> well. Otherwise, the device will exhibit severe performance issues
> even after the storm has
Michael Ellerman writes:
> Joe Lawrence writes:
>> From: Nicolai Stange
>>
>> The ppc64 specific implementation of the reliable stacktracer,
>> save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
>> trace" whenever it finds an exception frame on the stack. Stack frames
>> are
On Fri, Jan 25, 2019 at 11:43:16AM -0800, Nicolin Chen wrote:
> On Tue, Jan 22, 2019 at 11:14:27AM +, Viorel Suman wrote:
> > Add the DT binding documentation for NXP Audio Mixer
> > CPU DAI driver.
> >
> > Signed-off-by: Viorel Suman
> > ---
> > .../devicetree/bindings/sound/fsl,audmix.txt
On 1/30/19 6:46 AM, Breno Leitao wrote:
> 'regno' is directly controlled by user space, hence leading to a potential
> exploitation of the Spectre variant 1 vulnerability.
>
> On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
> register number that would be read or written.
On 1/30/19 7:20 AM, Paul Mackerras wrote:
> On Tue, Jan 29, 2019 at 02:47:55PM +0100, Cédric Le Goater wrote:
>> On 1/29/19 3:45 AM, Paul Mackerras wrote:
>>> On Mon, Jan 28, 2019 at 07:26:00PM +0100, Cédric Le Goater wrote:
On 1/28/19 7:13 AM, Paul Mackerras wrote:
> Would we end up with
On 1/30/19 6:40 AM, Paul Mackerras wrote:
> On Tue, Jan 29, 2019 at 02:51:05PM +0100, Cédric Le Goater wrote:
> Another general comment is that you seem to have written all this
> code assuming we are using HV KVM in a host running bare-metal.
Yes. I didn't look at the other
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: .
The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96, v4.9.153,
v4.4.172, v3.18.133.
v4.20.5: Build OK!
v4.19.18: Build OK!
v4.14.96: Build OK!
v4.9.153: Failed
On Mon 2019-01-21 10:04:08, Mike Rapoport wrote:
> As all the memblock allocation functions return NULL in case of error
> rather than panic(), the duplicates with _nopanic suffix can be removed.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Greg Kroah-Hartman
> ---
> arch/arc/kernel/unwind.c
Reza Arbab writes:
> On Tue, Jan 29, 2019 at 08:37:28PM +0530, Aneesh Kumar K.V wrote:
>>Not sure what the fix is about. We set the related hash pte flags via
>>
>> if ((pteflags & _PAGE_CACHE_CTL) == _PAGE_TOLERANT)
>> rflags |= HPTE_R_I;
>> else if ((pteflags &
On Wed, 30 Jan 2019, Michael Ellerman wrote:
> I'm happy to take it, unless there's some reason you'd rather it go via
> the LP tree?
As this is more about reliable stack unwinding than live patching per se
(which is only a user of that facility), I'd actually slightly prefer if
it goes via
Michael Ellerman writes:
> FYI RESEND means you didn't change anything, but you sent the patch
> again for some other reason, like the Cc list was wrong or you thought
> it had been ignored.
>
> In this case you should have just sent a v4, updating the change log is
> a perfectly valid reason
Alexander Fomichev writes:
> get_dma_ops() falls into arch-dependant get_arch_dma_ops(), which
> historically returns NULL on PowerPC. Therefore dma_set_mask() fails.
> This affects Switchtec (and probably other) NTB devices, that they fail
> to initialize.
What's an NTB device?
drivers/ntb I
'regno' is directly controlled by user space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
register number that would be read or written. This register number is
called 'regno' which is part
Vaibhav Jain writes:
> Within cxl module, iteration over array 'adapter->afu' may be racy
> at few points as it might be simultaneously read during an EEH and its
> contents being set to NULL while driver is being unloaded or unbound
> from the adapter. This might result in a NULL pointer to
Christophe Leroy writes:
> Today's message is useless:
>
> [ 42.253267] Kernel stack overflow in process (ptrval), r1=c65500b0
>
> This patch fixes it:
>
> [ 66.905235] Kernel stack overflow in process sh[356], r1=c65560b0
>
> Fixes: ad67b74d2469 ("printk: hash addresses printed with %p")
>
Michael Bringmann writes:
> On 1/29/19 3:37 AM, Michael Ellerman wrote:
>> Michael Bringmann writes:
>>
>>> On 10/29/18 1:43 PM, Nathan Fontenot wrote:
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system.
Presently when an error is encountered during probe of the cxlflash
adapter, a deadlock is seen with cpu thread stuck inside
cxlflash_remove(). Below is the trace of the deadlock as logged by
khungtaskd:
cxlflash 0006:00:00.0: cxlflash_probe: init_afu failed rc=-16
INFO: task kworker/80:1:890
Joe Lawrence writes:
> From: Nicolai Stange
>
> The ppc64 specific implementation of the reliable stacktracer,
> save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
> trace" whenever it finds an exception frame on the stack. Stack frames
> are classified as exception frames if
Jiri Kosina writes:
> On Tue, 22 Jan 2019, Joe Lawrence wrote:
>
>> This patchset fixes a false negative report (ie, unreliable) from the
>> ppc64 reliable stack unwinder, discussed here [1] when it may
>> inadvertently trip over a stale exception marker left on the stack.
>>
>> The first two
Christophe Leroy writes:
> In transfer_to_handler() (entry_32.S), we have:
>
> #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> ...
> #ifdef CONFIG_SMP
> CURRENT_THREAD_INFO(r9, r1)
> lwz r9,TI_CPU(r9)
> slwir9,r9,3
> add r11,r11,r9
> #endif
> #endif
>
>
"Aneesh Kumar K.V" writes:
> The current code doesn't do page migration if the page allocated is a
> compound page.
> With HugeTLB migration support, we can end up allocating hugetlb pages from
> CMA region. Also, THP pages can be allocated from CMA region. This patch
> updates
> the code to
an FPGA-based system controller, called “Qixis”, which
manages several critical system features, including:
• Reset sequencing
• Power supply configuration
• Board configuration
• hardware configuration
The qixis registers are accessible over one or more system-specific
interfaces, typically I2C,
FPGA on LX2160AQDS/LX2160ARDB connected on I2C bus, so add qixis
driver which is basically an i2c client driver to control FPGA.
This driver is essential to control MDIO mux multiplexing.
This driver is dependent on below patches:
FPGA on LX2160AQDS/LX2160ARDB connected on I2C bus, so add qixis
driver which is basically an i2c client driver to control FPGA.
Signed-off-by: Wang Dongsheng
Signed-off-by: Pankaj Bansal
---
Notes:
V2:
- Modify the driver to not create platform devices corresponding to
subnodes.
"Aneesh Kumar K.V" writes:
> NestMMU requires us to mark the pte invalid and flush the tlb when we do a
> RW upgrade of pte. We fixed a variant of this in the fault path in commit
> Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle
> nest MMU hang")
Odd "Fixes:"
"Aneesh Kumar K.V" writes:
> Architectures like ppc64 require to do a conditional tlb flush based on the
> old
> and new value of pte. Follow the regular pte change protection sequence for
> hugetlb too. This allows the architectures to override the update sequence.
>
> Signed-off-by: Aneesh
"Aneesh Kumar K.V" writes:
> NestMMU requires us to mark the pte invalid and flush the tlb when we do a
> RW upgrade of pte. We fixed a variant of this in the fault path in commit
> Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle
> nest MMU hang")
You don't want the
"Aneesh Kumar K.V" writes:
> Architectures like ppc64 require to do a conditional tlb flush based on the
> old
> and new value of pte. Enable that by passing old pte value as the arg.
It's not actually the architecture, it's to work around a specific bug
on Power9.
> diff --git
"Aneesh Kumar K.V" writes:
> Some architecture may want to call flush_tlb_range from these helpers.
That's what we want to do, but wouldn't a better description be that
some architectures may need access to the vma for some reason, one of
which might be flushing the TLB.
> Signed-off-by:
On 1/30/19 6:55 AM, Paul Mackerras wrote:
> On Tue, Jan 29, 2019 at 06:44:50PM +0100, Cédric Le Goater wrote:
>> On 1/29/19 5:12 AM, Paul Mackerras wrote:
>>> On Mon, Jan 28, 2019 at 07:26:00PM +0100, Cédric Le Goater wrote:
Is clearing the PTEs and repopulating the VMA unsafe ?
>>>
>>>
Le 24/01/2019 à 17:19, Christophe Leroy a écrit :
40x/booke have another path to reach 3f from transfer_to_handler,
so ACCOUNT_CPU_USER_ENTRY() have to be moved there.
Signed-off-by: Christophe Leroy
Now ACCOUNT_CPU_USER_ENTRY() is also in the non-user entry path.
This change is crazy,
56 matches
Mail list logo
