The function get_user() can sleep while trying to fetch instruction
from user address space and causes the following warning from the
scheduler.
BUG: sleeping function called from invalid context
Though interrupts get enabled back but it happens bit later after
get_user() is called. This change m
Nicholas Piggin writes:
> On Wed, 07 Mar 2018 21:50:04 +1100
> Michael Ellerman wrote:
>> Nicholas Piggin writes:
>> > This series allows numa aware allocations for various early data
>> > structures for radix. Hash still has a bolted SLB limitation that
>> > prevents at least pacas and stacks f
In sleep mode, the clocks of CPU core and unused IP blocks are turned
off (IP blocks allowed to wake up system will running).
Some QorIQ SoCs like MPC8536, P1022 and T104x, have deep sleep PM mode
in addtion to the sleep PM mode. While in deep sleep mode,
additionally, the power supply is removed
Enable Power Management feature on device tree, including MPC8536,
MPC8544, MPC8548, MPC8572, P1010, P1020, P1021, P1022, P2020, P2041,
P3041, T104X, T1024.
Signed-off-by: Zhao Chenhui
Signed-off-by: Ran Wang
---
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 14 ++-
arch/powerpc/boot/dt
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all cach
Also, unselect FSL_PMC which is for older platfroms instead.
Signed-off-by: Ran Wang
---
arch/powerpc/Kconfig |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd..ed60c83 100644
--- a/arch/powerpc/Kconfig
+++ b/arc
In the last stage of deep sleep, software will trigger a Finite
State Machine (FSM) to control the hardware procedure, such a
board isolation, killing PLLs, removing power, and so on.
When the system is waked up by an interrupt, the FSM controls
the hardware to complete the early resume procedure.
time_init() will set up tb_ticks_per_usec based on reality.
time_init() is called *after* udbg_init_opal_common() during boot.
from arch/powerpc/kernel/time.c:
unsigned long tb_ticks_per_usec = 100; /* sane default */
Currently, all powernv systems have a timebase frequency of 512mhz
(51200
Nicholas Piggin writes:
> diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
> index 328ff9abc333..435b19e74508 100644
> --- a/arch/powerpc/mm/pgtable-radix.c
> +++ b/arch/powerpc/mm/pgtable-radix.c
> @@ -862,9 +862,9 @@ static void remove_pagetable(unsigned long start
Nicholas Piggin writes:
> ---
> arch/powerpc/include/asm/paca.h| 3 +-
> arch/powerpc/kernel/paca.c | 90
> --
> arch/powerpc/kernel/prom.c | 5 ++-
> arch/powerpc/kernel/setup-common.c | 24 +++---
> 4 files changed, 51 insertions(+)
Nicholas Piggin writes:
> Build an array that finds hardware CPU number from logical CPU
> number in firmware CPU discovery. Use that rather than setting
> paca of other CPUs directly, to begin with. Subsequent patch will
> not have pacas allocated at this point.
> ---
> arch/powerpc/include/asm
Nicholas Piggin writes:
> Per-node allocations are possible on 64s with radix that does
> not have the bolted SLB limitation.
>
> Hash would be able to do the same if all CPUs had the bottom of
> their node-local memory bolted as well. This is left as an
> exercise for the reader.
> ---
> arch/p
The function get_user() can sleep while trying to fetch instruction
from user address space and causes the following warning from the
scheduler.
BUG: sleeping function called from invalid context
Though interrupts get enabled back but it happens bit later after
get_user() is called. This change m
Nicholas Piggin writes:
> opal_nvram_write currently just assumes success if it encounters an
> error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
> on other errors instead.
>
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
> 1 file ch
From: Mahesh Salgaonkar
For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. But this memory area is currently not
protected from hot-remove operations. Hence, fadump ser
From: Mahesh Salgaonkar
fadump fails to register when there are holes in reserved memory area.
This can happen if user has hot-removed a memory that falls in the fadump
reserved memory area. Throw a meaningful error message to the user in
such case.
Signed-off-by: Mahesh Salgaonkar
---
arch/po
From: Mahesh Salgaonkar
The second kernel, during early boot after the crash, reserves rest of
the memory above boot memory size to make sure it does not touch any of the
dump memory area. It uses memblock_reserve() that reserves the specified
memory region irrespective of memory holes present wi
From: Mahesh Salgaonkar
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is in
On Thu, Mar 29, 2018 at 4:06 AM, Rob Herring wrote:
> On Tue, Mar 27, 2018 at 9:53 AM, Oliver wrote:
>> On Tue, Mar 27, 2018 at 9:24 AM, Rob Herring wrote:
>>> On Fri, Mar 23, 2018 at 07:12:09PM +1100, Oliver O'Halloran wrote:
Add device-tree binding documentation for the nvdimm region driv
2018-03-29 10:26 GMT+08:00 Ganesh Mahendran :
> Hi, Laurent
>
> 2018-02-16 23:25 GMT+08:00 Laurent Dufour :
>> When the speculative page fault handler is returning VM_RETRY, there is a
>> chance that VMA fetched without grabbing the mmap_sem can be reused by the
>> legacy page fault handler. By re
Hi, Laurent
2018-02-16 23:25 GMT+08:00 Laurent Dufour :
> When the speculative page fault handler is returning VM_RETRY, there is a
> chance that VMA fetched without grabbing the mmap_sem can be reused by the
> legacy page fault handler. By reusing it, we avoid calling find_vma()
> again. To achi
On Wed, Mar 28, 2018 at 09:55:07AM -0700, Kees Cook wrote:
>On Wed, Mar 28, 2018 at 8:26 AM, Shea Levy wrote:
>> Now only those architectures that have custom initrd free requirements
>> need to define free_initrd_mem.
>>
>> Signed-off-by: Shea Levy
>
>Yay consolidation! :)
>
>> --- a/usr/Kconfig
On Thu, 29 Mar 2018 09:37:52 +1100
Oliver wrote:
> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >> > On Wed, Mar 28, 2018 at 10:58:5
No change to object files.
Cc: Benjamin Herrenschmidt
Signed-off-by: Finn Thain
---
drivers/macintosh/adb-iop.c| 14 +++---
drivers/macintosh/macio-adb.c | 15 +++
drivers/macintosh/via-macii.c | 14 +++---
drivers/macintosh/via-pmu.c| 14 +++---
d
Dave Hansen writes:
> On 03/28/2018 01:47 PM, Thiago Jung Bauermann wrote:
if (flags)
- assert(rdpkey_reg() > orig_pkey_reg);
+ assert(rdpkey_reg() < orig_pkey_reg);
}
void pkey_write_allow(int pkey)
>>> This seems so horribly wrong that I won
On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
wrote:
> On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>>
>>
>> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> >> On 03/28/2018 10:26 AM, Shea Levy
On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>
>
> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >>> Now only those architectures that have custom initrd free
> On 28 Mar 2018, at 02:49, Matthew Wilcox wrote:
>
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space befor
On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> On 03/28/2018 10:26 AM, Shea Levy wrote:
>>> Now only those architectures that have custom initrd free requirements
>>> need to define free_initrd_mem.
>> ...
>>> --- a/arch/a
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o wrote:
>
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a
>> performance
>> issue.
>
> You may want to take a look at the g
> On 27 Mar 2018, at 17:38, Michal Hocko wrote:
>
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>
>>> On 27 Mar 2018, at 10:24, Michal Hocko wrote:
>>>
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> On 26 Mar 2018, at 11:46, Michal Hocko wrote:
>
> On Fri 23-03-18 20:5
On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > Now only those architectures that have custom initrd free requirements
> > need to define free_initrd_mem.
> ...
> > --- a/arch/arc/mm/init.c
> > +++ b/arch/arc/mm/init.c
> > @@ -229,10 +229,
Hi Rob,
Rob Landley writes:
> On 03/28/2018 10:26 AM, Shea Levy wrote:
>> Now only those architectures that have custom initrd free requirements
>> need to define free_initrd_mem.
> ...
>> --- a/arch/arc/mm/init.c
>> +++ b/arch/arc/mm/init.c
>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
On 03/28/2018 10:26 AM, Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
...
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> {
> free_initmem_default(-1);
>
Now only those architectures that have custom initrd free requirements
need to define free_initrd_mem.
Signed-off-by: Shea Levy
---
arch/alpha/mm/init.c | 8
arch/arc/mm/init.c| 7 ---
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig| 1 +
arch/blackfin/K
On Tue, Mar 27, 2018 at 09:13:32PM +0200, Thorsten Leemhuis wrote:
> On 26.03.2018 01:37, Linus Torvalds wrote:
> > […] Anyway. Go out and test. And let's hope next week is nice and calm and
> > I can release the final 4.16 next Sunday without any extra rc's.
> >
> >Linus
>
> Hi!
On Wed, Mar 28, 2018 at 8:26 AM, Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
>
> Signed-off-by: Shea Levy
Yay consolidation! :)
> --- a/usr/Kconfig
> +++ b/usr/Kconfig
> @@ -233,3 +233,7 @@ config INITRAMFS_COMPRESS
On Thu, 29 Mar 2018 08:31:32 +1100
Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-29 at 02:23 +1000, Nicholas Piggin wrote:
> > On Wed, 28 Mar 2018 11:55:09 -0400 (EDT)
> > David Miller wrote:
> >
> > > From: Benjamin Herrenschmidt
> > > Date: Thu, 29 Mar 2018 02:13:16 +1100
> > >
> > >
Uma,
> This patch series adds OCXL support to the cxlflash driver. With this
> support, new devices using the OCXL transport will be supported by the
> cxlflash driver along with the existing CXL devices. An effort is made
> to keep this transport specific function independent of the existing
> c
On Thu, 2018-03-29 at 02:23 +1000, Nicholas Piggin wrote:
> On Wed, 28 Mar 2018 11:55:09 -0400 (EDT)
> David Miller wrote:
>
> > From: Benjamin Herrenschmidt
> > Date: Thu, 29 Mar 2018 02:13:16 +1100
> >
> > > Let's fix all archs, it's way easier than fixing all drivers. Half of
> > > the archs
On Wed, 28 Mar 2018, Laurent Dufour wrote:
> >> @@ -326,7 +336,10 @@ static unsigned long move_vma(struct vm_area_struct
> >> *vma,
> >>mremap_userfaultfd_prep(new_vma, uf);
> >>arch_remap(mm, old_addr, old_addr + old_len,
> >> new_addr, new_addr + ne
On Wed, 28 Mar 2018, Laurent Dufour wrote:
> > Putting this in mm/Kconfig is definitely the right way to go about it
> > instead of any generic option in arch/*.
> >
> > My question, though, was making this configurable by the user:
> >
> > config SPECULATIVE_PAGE_FAULT
> > bool "Speculativ
On 03/28/2018 01:47 PM, Thiago Jung Bauermann wrote:
>>> if (flags)
>>> - assert(rdpkey_reg() > orig_pkey_reg);
>>> + assert(rdpkey_reg() < orig_pkey_reg);
>>> }
>>>
>>> void pkey_write_allow(int pkey)
>> This seems so horribly wrong that I wonder how it worked in the firs
Joe Perches writes:
> On Wed, 2018-03-28 at 16:36 -0400, Shea Levy wrote:
>> Signed-off-by: Shea Levy
>
> Most people seem to want some form of commit message
> and not just your sign-off.
>
Ah, if the subject is insufficient I can add some more detail.
>
> And btw:
>
> It seems you used get_m
Dave Hansen writes:
> On 02/21/2018 05:55 PM, Ram Pai wrote:
>> --- a/tools/testing/selftests/vm/protection_keys.c
>> +++ b/tools/testing/selftests/vm/protection_keys.c
>> @@ -461,7 +461,7 @@ void pkey_disable_clear(int pkey, int flags)
>> pkey, pkey, pkey_rights);
>> p
On Wed, 2018-03-28 at 16:36 -0400, Shea Levy wrote:
> Signed-off-by: Shea Levy
Most people seem to want some form of commit message
and not just your sign-off.
And btw:
It seems you used get_maintainer to determine who to
send these patches to.
I suggest you add --nogit and --nogit-fallback to
On Tue, Mar 27, 2018 at 05:22:32PM +0200, LEROY Christophe wrote:
> Shile Zhang a écrit :
>
> >fix the missed point in Paul's patch:
> >"powerpc/64: Fix checksum folding in csum_tcpudp_nofold and
> >ip_fast_csum_nofold"
> >
> >Signed-off-by: Shile Zhang
> >---
> > arch/powerpc/include/asm/checks
Signed-off-by: Shea Levy
---
arch/powerpc/mm/mem.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index fe8c61149fb8..e85b2a3cd264 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -404,13 +404,6 @@ void free_initmem(void)
Directly use fault_in_pages_readable instead of manual __get_user code. Fix
warning treated as error with W=1:
arch/powerpc/kernel/kvm.c:675:6: error: variable ‘tmp’ set but not used
[-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy
Signed-off-by: Mathieu Malaterre
---
v2: use
These functions can all be static, make it so. Fix warnings treated as
errors with W=1:
arch/powerpc/platforms/powermac/pci.c:1022:6: error: no previous prototype
for ‘pmac_pci_fixup_ohci’ [-Werror=missing-prototypes]
arch/powerpc/platforms/powermac/pci.c:1057:6: error: no previous prototype
Remove variable declaration idu_size and associated code since not used.
These functions can all be static, make it so. Fix warnings treated as
errors with W=1:
arch/powerpc/platforms/chrp/setup.c:97:6: error: no previous prototype for
‘chrp_show_cpuinfo’ [-Werror=missing-prototypes]
arch/po
Add gcc attribute unused for two variables. Fix warnings treated as errors
with W=1:
arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not
used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy
Signed-off-by: Mathieu Malaterre
---
v2: move path within ifde
Since the value of x is never intended to be read, remove it. Fix warning
treated as error with W=1:
arch/powerpc/platforms/powermac/udbg_scc.c:76:9: error: variable ‘x’ set but
not used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy
Signed-off-by: Mathieu Malaterre
---
v2:
Since the value of x is never intended to be read, declare it with gcc
attribute as unused. Fix warning treated as error with W=1:
arch/powerpc/platforms/powermac/bootx_init.c:471:21: error: variable ‘x’ set
but not used [-Werror=unused-but-set-variable]
Signed-off-by: Mathieu Malaterre
---
v
On Fri, Mar 23, 2018 at 1:20 PM, christophe leroy
wrote:
>
>
> Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit :
>>
>> Add one missing prototype for function rh_dump_blk. Fix warning treated as
>> error in W=1:
>>
>>arch/powerpc/lib/rheap.c:740:6: error: no previous prototype for
>> ‘rh_dump_
On Fri, Mar 23, 2018 at 1:13 PM, christophe leroy
wrote:
>
>
> Le 22/03/2018 à 21:19, Mathieu Malaterre a écrit :
>>
>> The pmac_pfunc_base_install prototype was declared in powermac/smp.c since
>> function was used there, move it to pmac_pfunc.h header to be visible in
>> pfunc_base.c. Fix a warn
Some functions prototypes were missing for the non-altivec code. Add the
missing prototypes in a new header file, fix warnings treated as errors
with W=1:
arch/powerpc/lib/xor_vmx_glue.c:18:6: error: no previous prototype for
‘xor_altivec_2’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_v
Some functions prototypes were missing for the non-altivec code. Add the
missing prototypes in a new header file, fix warnings treated as errors
with W=1:
arch/powerpc/lib/xor_vmx_glue.c:18:6: error: no previous prototype for
‘xor_altivec_2’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_v
On 28/03/2018 00:12, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 88042d843668..ef6ef0627090 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -2189,16 +2189,24 @@ void anon_vma_interval_t
On 27/03/2018 23:30, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index faf85699f1a1..5898255d0aeb 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -558,6 +558,10 @@ void __vma_link_rb(struct mm_struct *mm, struct
>> vm_area_str
On Wed, Mar 28, 2018 at 10:06 AM, Rob Herring wrote:
[..]
> >> Are DIMMs always going to be the only form factor for NV memory?
> >>
> >> And if you have multiple DIMMs, does each DT node correspond to a DIMM?
> >
> > A nvdimm-region might correspond to a single NVDIMM, a set of
> > interleaved NV
On 03/27/2018 01:08 PM, Nicholas Piggin wrote:
On Tue, 27 Mar 2018 12:47:31 +0530
Vasant Hegde wrote:
On 03/26/2018 08:32 PM, Nicholas Piggin wrote:
opal_nvram_write currently just assumes success if it encounters an
error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
on other
On 27/03/2018 23:57, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 5898255d0aeb..d6533cb85213 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -847,17 +847,18 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned
>> long
On 03/27/2018 12:58 PM, Nicholas Piggin wrote:
On Tue, 27 Mar 2018 12:42:32 +0530
Vasant Hegde wrote:
On 03/26/2018 08:39 PM, Nicholas Piggin wrote:
xmon can be entered via sreset NMI (from a management sreset, or an
NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc
or sp ar
On Tue, Mar 27, 2018 at 9:53 AM, Oliver wrote:
> On Tue, Mar 27, 2018 at 9:24 AM, Rob Herring wrote:
>> On Fri, Mar 23, 2018 at 07:12:09PM +1100, Oliver O'Halloran wrote:
>>> Add device-tree binding documentation for the nvdimm region driver.
>>>
>>> Cc: devicet...@vger.kernel.org
>>> Signed-off-
On Wed, Mar 28, 2018 at 11:13:45AM +0100, Will Deacon wrote:
> On Wed, Mar 28, 2018 at 09:01:27PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2018-03-28 at 11:55 +0200, Arnd Bergmann wrote:
> > > > powerpc and ARM can't quite make them synchronous I think, but at least
> > > > they should have
On 27/03/2018 23:45, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 65ae54659833..a2d9c87b7b0b 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -1136,8 +1136,11 @@ static ssize_t clear_refs_w
On Wed, 28 Mar 2018 11:55:09 -0400 (EDT)
David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Thu, 29 Mar 2018 02:13:16 +1100
>
> > Let's fix all archs, it's way easier than fixing all drivers. Half of
> > the archs are unused or dead anyway.
>
> Agreed.
While we're making decrees her
From: Benjamin Herrenschmidt
> Sent: 28 March 2018 16:13
...
> > I've always wondered exactly what the twi;isync were for - always seemed
> > very heavy handed for most mmio reads.
> > Particularly if you are doing mmio reads from a data fifo.
>
> If you do that you should use the "s" version of t
From: Benjamin Herrenschmidt
Date: Thu, 29 Mar 2018 02:13:16 +1100
> Let's fix all archs, it's way easier than fixing all drivers. Half of
> the archs are unused or dead anyway.
Agreed.
On Wed, Mar 28, 2018 at 04:36:05PM +0300, Yury Norov wrote:
> On Mon, Mar 26, 2018 at 05:45:55AM -0700, Paul E. McKenney wrote:
> > On Sun, Mar 25, 2018 at 11:11:54PM +0300, Yury Norov wrote:
> > > On Sun, Mar 25, 2018 at 12:23:28PM -0700, Paul E. McKenney wrote:
> > > > On Sun, Mar 25, 2018 at 08:
On Wed, 2018-03-28 at 07:41 -0400, ok...@codeaurora.org wrote:
> Yes, we want to get there indeed. It is because of some arch not
> implementing writel properly. Maintainers want to play safe.
>
> That is why I asked if IA64 and other well known archs follow the
> strongly ordered rule at this m
On Wed, 2018-03-28 at 11:30 +, David Laight wrote:
> From: Benjamin Herrenschmidt
> > Sent: 28 March 2018 10:56
>
> ...
> > For example, let's say I have a device with a reset bit and the spec
> > says the reset bit needs to be set for at least 10us.
> >
> > This is wrong:
> >
> > writel
Go one step further, if we're going to put a tlbie on the bus
at all, make it count. Always flush all others and restore our
mm to a local one.
---
arch/powerpc/mm/tlb-radix.c | 45 +++--
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/p
When a single-threaded process has a non-local mm_cpumask and requires
a full PID tlbie invalidation, use that as an opportunity to reset the
cpumask back to the current CPU we're running on.
No other thread can concurrently switch to this mm, because it must
have had a reference on mm_users befor
Book3S does not require TLB flushing when protection is being relaxed.
>From Power ISA v3.0B, p.1090:
Setting a Reference or Change Bit or Upgrading Access Authority
(PTE Subject to Atomic Hardware Updates)
If the only change being made to a valid PTE that is subject to
atomic har
Last time this came up, there was concern about whether we can trim
the mm cpumask, and what concurrency there is vs use_mm(). I've had
more of a look and still think this is okay. I haven't thought of a
good way to add debug checks to ensure it though.
When doing a parallel kernel build on a 2 so
On Mon, Mar 26, 2018 at 11:35:42AM -0500, Uma Krishnan wrote:
> The following Oops can occur when there is heavy I/O traffic and the host
> is reset by a tool such as sg_reset.
>
> [c000200fff3fbc90] c0081690117c process_cmd_doneq+0x104/0x500
>[cxlflash]
On Mon, Mar 26, 2018 at 11:35:34AM -0500, Uma Krishnan wrote:
> The following Oops can occur if an internal command sent to the AFU does
> not complete within the timeout:
>
> [c00ff101b810] c00816020d94 term_mc+0xfc/0x1b0 [cxlflash]
> [c00ff101b8a0] c00816020fb0 term_afu+0x168/0x2
On Wed, Mar 28, 2018 at 05:41:40PM +0300, Yury Norov wrote:
> On Wed, Mar 28, 2018 at 06:56:17AM -0700, Paul E. McKenney wrote:
> > On Wed, Mar 28, 2018 at 04:36:05PM +0300, Yury Norov wrote:
> > > On Mon, Mar 26, 2018 at 05:45:55AM -0700, Paul E. McKenney wrote:
> > > > On Sun, Mar 25, 2018 at 11:
On Mon, Mar 26, 2018 at 11:35:27AM -0500, Uma Krishnan wrote:
> The following Oops can be encountered if a device removal or system
> shutdown is initiated while an EEH recovery is in process:
>
> [c00ff2f479c0] c00815256f18 cxlflash_pci_slot_reset+0xa0/0x100
>
On Wed, Mar 28, 2018 at 06:56:17AM -0700, Paul E. McKenney wrote:
> On Wed, Mar 28, 2018 at 04:36:05PM +0300, Yury Norov wrote:
> > On Mon, Mar 26, 2018 at 05:45:55AM -0700, Paul E. McKenney wrote:
> > > On Sun, Mar 25, 2018 at 11:11:54PM +0300, Yury Norov wrote:
> > > > On Sun, Mar 25, 2018 at 12:
On Tue, 2018-03-27 at 12:01:44 UTC, Michael Ellerman wrote:
> This commit adds security feature flags to reflect the settings we
> receive from firmware regarding Spectre/Meltdown mitigations.
>
> The feature names reflect the names we are given by firmware on bare
> metal machines. See the hostbo
On Tue, 2018-03-27 at 04:37:17 UTC, Michael Neuling wrote:
> Add ppc_breakpoint_available() to determine if a breakpoint is
> available currently via the DAWR or DABR.
>
> Signed-off-by: Michael Neuling
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/404b27d66ed657ebccb
On Wed, 2018-03-21 at 11:40:26 UTC, Madhavan Srinivasan wrote:
> Sampled Data Address Register (SDAR) is a 64-bit
> register that contains the effective address of
> the storage operand of an instruction that was
> being executed, possibly out-of-order, at or around
> the time that the Performance
On Wed, 2018-03-21 at 11:40:25 UTC, Madhavan Srinivasan wrote:
> The current Branch History Rolling Buffer (BHRB) code does
> not check for any privilege levels before updating the data
> from BHRB. This leaks kernel addresses to userspace even when
> profiling only with userspace privileges. Add p
On Wed, 2018-03-21 at 11:40:24 UTC, Madhavan Srinivasan wrote:
> From: Michael Ellerman
>
> Current code in power_pmu_disable() does not clear the sampling
> registers like Sampling Instruction Address Register (SAIR) and
> Sampling Data Address Register (SDAR) after disabling the PMU.
> Since th
On Mon, 2018-03-19 at 02:46:20 UTC, Sam Bobroff wrote:
> The function eeh_handle_event(pe) does nothing other than switching
> between calling eeh_handle_normal_event(pe) and
> eeh_handle_special_event(). However it is only called in two places,
> one where pe can't be NULL and the other where it m
On Wed, 2018-03-14 at 22:40:38 UTC, Mauricio Faria de Oliveira wrote:
> From: Michael Ellerman
>
> rfi_flush_enable() includes a check to see if we're already
> enabled (or disabled), and in that case does nothing.
>
> But that means calling setup_rfi_flush() a 2nd time doesn't actually
> work,
On Fri, 2018-03-09 at 20:45:58 UTC, Mauricio Faria de Oliveira wrote:
> Fix the warning messages for stop_machine_change_mapping(), and a number
> of other affected functions in its call chain.
>
> All modified functions are under CONFIG_MEMORY_HOTPLUG, so __meminit
> is okay (keeps them / does no
On Sun, 2018-03-04 at 11:56:26 UTC, Madhavan Srinivasan wrote:
> Introduce code to support addition of blacklisted events for a
> processor version. A 'pointer' and 'int' variable to hold the
> number of events are added to 'struct power_pmu', along with a
> generic function to loop through the lis
On Tue, 2018-02-13 at 05:51:35 UTC, Alexey Kardashevskiy wrote:
> GPUs and the corresponding NVLink bridges get different PEs as they have
> separate translation validation entries (TVEs). We put these PEs to
> the same IOMMU group so they cannot be passed through separately.
> So the iommu_table_g
On Thu, 2018-02-01 at 05:07:25 UTC, Alexey Kardashevskiy wrote:
> Fixes: 912cc87a6 "powerpc/mm/radix: Add LPID based tlb flush helpers"
> Signed-off-by: Alexey Kardashevskiy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b574df94883df4d37f1b9d648867d6
cheers
On Tue, 2018-01-09 at 05:52:14 UTC, Alexey Kardashevskiy wrote:
> With enabled DEBUG, there is a compile error:
> "error: âflagsâ is used uninitialized in this function".
>
> This moves pr_devel() little further where @flags are initialized.
>
> Signed-off-by: Alexey Kardashevskiy
Applied t
On Tue, 2018-01-09 at 05:45:20 UTC, Alexey Kardashevskiy wrote:
> Currently the pseries kernel advertises radix MMU support even if
> the actual support is disabled via the CONFIG_PPC_RADIX_MMU option.
>
> This adds a check for CONFIG_PPC_RADIX_MMU to avoid advertising radix
> to the hypervisor.
>
On Thu, 2017-02-16 at 05:03:39 UTC, Paul Mackerras wrote:
> On POWER9, since commit cc3d2940133d ("powerpc/64: Enable use of radix
> MMU under hypervisor on POWER9", 2017-01-30), we set both the radix and
> HPT bits in the client-architecture-support (CAS) vector, which tells
> the hypervisor that
On Wed, 28 Mar 2018 23:40:05 +1100
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > asm/barrier.h is not always included after asm/synch.h, which meant
> > it was missing __SUBARCH_HAS_LWSYNC, so in some files smp_wmb() would
> > be eieio when it should be lwsync. kernel/time/hrtimer.c i
On Mon, Mar 26, 2018 at 05:45:55AM -0700, Paul E. McKenney wrote:
> On Sun, Mar 25, 2018 at 11:11:54PM +0300, Yury Norov wrote:
> > On Sun, Mar 25, 2018 at 12:23:28PM -0700, Paul E. McKenney wrote:
> > > On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote:
> > > > kick_all_cpus_sync() forces
On 26/03/2018 00:10, David Rientjes wrote:
> On Wed, 21 Mar 2018, Laurent Dufour wrote:
>
>> I found the root cause of this lockdep warning.
>>
>> In mmap_region(), unmap_region() may be called while vma_link() has not been
>> called. This happens during the error path if call_mmap() failed.
>>
>>
1 - 100 of 141 matches
Mail list logo
