> -Original Message-
> From: Andrew Donnellan
> Sent: Wednesday, 27 February 2019 6:55 PM
> To: Alastair D'Silva ; 'Alastair D'Silva'
>
> Cc: 'Greg Kurz' ; 'Frederic Barrat'
> ; 'Arnd Bergmann' ; 'Greg Kroah-
> Hartman' ; linuxppc-dev@lists.ozlabs.org;
> linux-ker...@vger.kernel.org
> Sub
On 27/2/19 7:04 pm, Alastair D'Silva wrote:
-Original Message-
From: Andrew Donnellan
Sent: Wednesday, 27 February 2019 6:55 PM
To: Alastair D'Silva ; 'Alastair D'Silva'
Cc: 'Greg Kurz' ; 'Frederic Barrat'
; 'Arnd Bergmann' ; 'Greg Kroah-
Hartman' ; linuxppc-dev@lists.ozlabs.org;
linux-
With version v8 of the series implementing KASAN on 32 bits powerpc
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309),
I'm now able to activate KASAN on a mac99 is QEMU.
Then I get the following reports at startup. Which of the two reports I
get seems to depend on the opti
On Wed, Feb 27, 2019 at 9:25 AM Christophe Leroy
wrote:
>
> With version v8 of the series implementing KASAN on 32 bits powerpc
> (https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309),
> I'm now able to activate KASAN on a mac99 is QEMU.
>
> Then I get the following reports at sta
We already allocate hardware TCE tables in multiple levels and skip
intermediate levels when we can, now it is a turn of the KVM TCE tables.
Thankfully these are allocated already in 2 levels.
This moves the table's last level allocation from the creating helper to
kvmppc_tce_put() and kvm_spapr_t
Andrew Morton writes:
> [patch 1/4]: OK. I guess. Was this worth consuming our last PF_ flag?
That was done based on request from Andrea and it also helps in avoiding
allocating pages from CMA region where we know we are anyway going to
migrate them out. So yes, this helps.
> [patch 2/4]: un
Andrew Morton writes:
> [patch 1/5]: unreviewed and has unaddressed comments from mpe.
> [patch 2/5]: ditto
> [patch 3/5]: ditto
> [patch 4/5]: seems ready
> [patch 5/5]: reviewed by mpe, but appears to need more work
That was mostly variable naming preferences. I like the christmas
tree style n
On 2/27/19 11:25 AM, Christophe Leroy wrote:
> With version v8 of the series implementing KASAN on 32 bits powerpc
> (https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309), I'm
> now able to activate KASAN on a mac99 is QEMU.
>
> Then I get the following reports at startup. Wh
Le 27/02/2019 à 10:25, Dmitry Vyukov a écrit :
On Wed, Feb 27, 2019 at 10:18 AM Andrey Ryabinin
wrote:
On 2/27/19 11:25 AM, Christophe Leroy wrote:
With version v8 of the series implementing KASAN on 32 bits powerpc
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309), I'
In POWER9, OCC(On-Chip-Controller) provides for hard and soft system
powercapping range. The hard powercap range is guaranteed while soft
powercap may or may not be asserted due to various power-thermal
reasons based on system configuration and workloads. This patch adds
a sysfs file to export the
Decrement the reference count on device_node "node" while breaking out
of the loop. Issue identified by Coccinelle.
Signed-off-by: Himadri Pandya
---
Changes in V2:
- Change subject line
---
Changes in V3:
- Add braces around the if block
---
arch/powerpc/kernel/machine_kexec_64.
Decrement the reference count on device_node "np" while breaking out of
the loop. Issue identified by Coccinelle.
Signed-off-by: Himadri Pandya
---
Changes in V2:
- Change subject line
---
Changes in V3:
- Do not remove the blank line at end of the file
---
arch/powerpc/platforms
On Wed, Feb 27, 2019 at 07:41:21AM +0100, Christophe Leroy wrote:
>
>
> Le 26/02/2019 à 23:24, Paul Mackerras a écrit :
> >On Tue, Feb 26, 2019 at 11:59:08AM +0200, Mike Rapoport wrote:
> >>On Tue, Feb 26, 2019 at 10:39:54AM +0100, Christophe Leroy wrote:
> >>>
> >>>
> >>>Le 26/02/2019 à 09:12, M
"Aneesh Kumar K.V" writes:
> Andrew Morton writes:
>
>> [patch 1/4]: OK. I guess. Was this worth consuming our last PF_ flag?
>
> That was done based on request from Andrea and it also helps in avoiding
> allocating pages from CMA region where we know we are anyway going to
> migrate them out.
Clear the on-stack STACK_FRAME_REGS_MARKER on exception exit in order
to avoid confusing stacktrace like the one below.
Call Trace:
[c0e9dca0] [c01c42a0] print_address_description+0x64/0x2bc (unreliable)
[c0e9dcd0] [c01c4684] kasan_report+0xfc/0x180
[c0e9dd10] [c0895130] memchr+0x24/0x74
[c0e9dd30
Jordan Niethe writes:
> Currently the opal log is globally readable. It is kernel policy to limit
> the visibility of physical addresses / kernel pointers to root.
> Given this and the fact the opal log may contain this information it would
> be better to limit the readability to root.
Yikes, th
The changes look good to me.
On Fri, Feb 08, 2019 at 10:11:03PM +1100, Russell Currey wrote:
> Without restoring the IAMR after idle, execution prevention on POWER9
> with Radix MMU is overwritten and the kernel can freely execute userspace
> without
> faulting.
>
> This is necessary when return
On 02/27/2019 08:34 AM, Dmitry Vyukov wrote:
On Wed, Feb 27, 2019 at 9:25 AM Christophe Leroy
wrote:
With version v8 of the series implementing KASAN on 32 bits powerpc
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309),
I'm now able to activate KASAN on a mac99 is QEMU.
On Wed, Feb 27, 2019 at 1:35 PM Christophe Leroy
wrote:
>
>
>
> On 02/27/2019 08:34 AM, Dmitry Vyukov wrote:
> > On Wed, Feb 27, 2019 at 9:25 AM Christophe Leroy
> > wrote:
> >>
> >> With version v8 of the series implementing KASAN on 32 bits powerpc
> >> (https://patchwork.ozlabs.org/project/lin
Le 27/02/2019 à 10:19, Andrey Ryabinin a écrit :
On 2/27/19 11:25 AM, Christophe Leroy wrote:
With version v8 of the series implementing KASAN on 32 bits powerpc
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309), I'm now
able to activate KASAN on a mac99 is QEMU.
The
Le 27/02/2019 à 05:57, Alastair D'Silva a écrit :
From: Alastair D'Silva
No need for a return value in read_pasid as it only returns 0.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
Thanks!
Acked-by: Frederic Barrat
drivers/misc/ocxl/config.c | 9 ++---
1 file ch
Le 27/02/2019 à 05:57, Alastair D'Silva a écrit :
From: Alastair D'Silva
The 'extern' keyword adds no value here.
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/ocxl_internal.h | 54 +++
include/misc/ocxl.h
Le 27/02/2019 à 05:57, Alastair D'Silva a écrit :
From: Alastair D'Silva
Remove some unused exported symbols.
Signed-off-by: Alastair D'Silva
---
If you have a respin of the series, that patch also adds a comment
around ocxl_context_attach(), which is for later.
But in any case:
Acked-
Le 27/02/2019 à 05:57, Alastair D'Silva a écrit :
From: Alastair D'Silva
Use %# instead of using a literal '0x'
Signed-off-by: Alastair D'Silva
---
I don't really care either way, but it looks ok.
Acked-by: Frederic Barrat
drivers/misc/ocxl/config.c | 6 +++---
drivers/misc/ocx
Le 27/02/2019 à 09:18, Andrew Donnellan a écrit :
On 27/2/19 7:04 pm, Alastair D'Silva wrote:
-Original Message-
From: Andrew Donnellan
Sent: Wednesday, 27 February 2019 6:55 PM
To: Alastair D'Silva ; 'Alastair D'Silva'
Cc: 'Greg Kurz' ; 'Frederic Barrat'
; 'Arnd Bergmann' ; 'Greg K
On Wed, 27 Feb 2019 14:45:44 +0100
Frederic Barrat wrote:
> Le 27/02/2019 à 09:18, Andrew Donnellan a écrit :
> > On 27/2/19 7:04 pm, Alastair D'Silva wrote:
> >>> -Original Message-
> >>> From: Andrew Donnellan
> >>> Sent: Wednesday, 27 February 2019 6:55 PM
> >>> To: Alastair D'Silva
THP pages can get split during different code paths. An incremented reference
count does imply we will not split the compound page. But the pmd entry can be
converted to level 4 pte entries. Keep the code simpler by allowing large
IOMMU page size only if the guest ram is backed by hugetlb pages.
S
This patch adds PF_MEMALLOC_NOCMA which make sure any allocation in that context
is marked non-movable and hence cannot be satisfied by CMA region.
This is useful with get_user_pages_longterm where we want to take a page pin by
migrating pages from CMA region. Marking the section PF_MEMALLOC_NOCMA
ppc64 use CMA area for the allocation of guest page table (hash page table). We
won't
be able to start guest if we fail to allocate hash page table. We have observed
hash table allocation failure because we failed to migrate pages out of CMA
region
because they were pinned. This happen when we ar
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 handle compound pages correctly. The patch a
This patch updates get_user_pages_longterm to migrate pages allocated out
of CMA region. This makes sure that we don't keep non-movable pages (due to page
reference count) in the CMA area.
This will be used by ppc64 in a later patch to avoid pinning pages in the CMA
region. ppc64 uses CMA region f
Russell Currey's on February 8, 2019 9:11 pm:
> Without restoring the IAMR after idle, execution prevention on POWER9
> with Radix MMU is overwritten and the kernel can freely execute userspace
> without
> faulting.
>
> This is necessary when returning from any stop state that modifies user
> sta
We're trying to use Slave-DMA API of the DMA Engine in the linux kernel on
POWER8 OpenPOWER platform. And we discovered that dma_request_channel() always
fails.
Does it mean that Turismo hardware does not support Slave-DMA? Or DMA
subsystem in the linux kernel needs to be fixed, doesn't it?
The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).
Put in a separate file all the code that is specific to pe
The procedure to detect hardlockups is independent of the underlying
mechanism that generated the non-maskable interrupt used to drive the
detector. Thus, it can be put in a separate, generic function. In this
manner, it can be invoked by various implementations of the NMI watchdog.
For this purpo
CPU architectures that have an NMI watchdog use arch_touch_nmi_watchdog()
to briefly ignore the hardlockup detector. If the architecture does not
have an NMI watchdog, one can be constructed using a source of non-
maskable interrupts. In this case, arch_touch_nmi_watchdog() is common
to any underly
Implementations of NMI watchdogs that use a single piece of hardware to
monitor all the CPUs in the system (as opposed to per-CPU implementations
such as perf) need to know which CPUs the watchdog is allowed to monitor.
In this manner, non-maskable interrupts are directed only to the monitored
CPUs
On Wed, Feb 27, 2019 at 08:05:13AM -0800, Ricardo Neri wrote:
> CPU architectures that have an NMI watchdog use arch_touch_nmi_watchdog()
> to briefly ignore the hardlockup detector. If the architecture does not
> have an NMI watchdog, one can be constructed using a source of non-
> maskable interr
On Wed, 27 Feb 2019 15:57:37 +1100
"Alastair D'Silva" wrote:
> From: Alastair D'Silva
>
> The term 'link' is ambiguous (especially when the struct is used for a
> list), so rename it for clarity.
>
> Signed-off-by: Alastair D'Silva
> Reviewed-by: Greg Kurz
> ---
> drivers/misc/ocxl/file.c |
On Tue, Feb 19, 2019 at 09:30:33PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> Resending these as I had only 1 minor comment which I believe we have covered
> in this series. I was anticipating these going through the mm tree as they
> depend on a cleanup patch there and the IB changes are v
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_large() functions/macros.
For powerpc pmd_large() was already implemented, so hoist
arch/powerpc/mm/init_64.c: In function 'vmemmap_free':
arch/powerpc/mm/init_64.c:277:16: error: variable 'section_base' set but
not used [-Werror=unused-but-set-variable]
Signed-off-by: Qian Cai
---
arch/powerpc/mm/init_64.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/mm/in
Quoting Vabhav Sharma (2019-02-26 02:10:46)
> These patches were reviewed and acked but dropped during merge window.
> Patchwork link was https://lore.kernel.org/patchwork/cover/1004155/
>
> Changes for v1:
> - Updated lx2160a clockgen in alphabetical order
>
> Vabhav Sharma (2):
> dt-bindings:
On Wed, Feb 27, 2019 at 07:42:35PM +1100, Alexey Kardashevskiy wrote:
> We already allocate hardware TCE tables in multiple levels and skip
> intermediate levels when we can, now it is a turn of the KVM TCE tables.
> Thankfully these are allocated already in 2 levels.
>
> This moves the table's la
arch/powerpc/mm/hugetlbpage-hash64.c: In function '__hash_page_huge':
arch/powerpc/mm/hugetlbpage-hash64.c:29:28: warning: variable 'sz' set
but not used [-Wunused-but-set-variable]
Signed-off-by: Qian Cai
---
arch/powerpc/mm/hugetlbpage-hash64.c | 3 +--
1 file changed, 1 insertion(+), 2 deleti
Shilpasri G Bhat writes:
> In POWER9, OCC(On-Chip-Controller) provides for hard and soft system
> powercapping range. The hard powercap range is guaranteed while soft
> powercap may or may not be asserted due to various power-thermal
> reasons based on system configuration and workloads. This pat
On 27/02/19 9:07 AM, Daniel Axtens wrote:
Hi Hari,
Hi Daniel,
Firmware-Assisted Dump (FADump) is currently supported only on pseries
platform. This patch series adds support for powernv platform too.
The first and third patches refactor the FADump code to make use of common
code across m
On 27/2/19 3:57 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
Use %# instead of using a literal '0x'
Signed-off-by: Alastair D'Silva
Not hugely fussed either way, but today I learned about %#...
Acked-by: Andrew Donnellan
---
drivers/misc/ocxl/config.c | 6 +++---
drivers/misc
On 27/2/19 3:57 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
No need for a return value in read_pasid as it only returns 0.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
Acked-by: Andrew Donnellan
---
drivers/misc/ocxl/config.c | 9 ++---
1 file changed, 2 insertio
On 27/2/19 3:57 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
The 'extern' keyword adds no value here.
Signed-off-by: Alastair D'Silva
Acked-by: Andrew Donnellan
---
drivers/misc/ocxl/ocxl_internal.h | 54 +++
include/misc/ocxl.h | 36 ++
Hi Nick,
On 27/02/19 9:48 AM, Nicholas Piggin wrote:
Hari Bathini's on February 22, 2019 3:35 am:
Firmware-Assisted Dump (FADump) is currently supported only on pseries
platform. This patch series adds support for powernv platform too.
The first and third patches refactor the FADump code to m
Hi,
On 02/28/2019 10:14 AM, Daniel Axtens wrote:
> Shilpasri G Bhat writes:
>
>> In POWER9, OCC(On-Chip-Controller) provides for hard and soft system
>> powercapping range. The hard powercap range is guaranteed while soft
>> powercap may or may not be asserted due to various power-thermal
>> rea
cs42xx8 is a 24-bit A/D and 24-bit D/A device, so the S32_LE
should not be in the supported format list.
Signed-off-by: Shengjiu Wang
---
sound/soc/codecs/cs42xx8.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/codecs/cs42xx8.c b/sound/soc/codecs/cs42xx8.c
index
Hi,
> I think I observed a potential problem, is this the correct place to report
> it? (CC me, not on list)
Yes
> [1.] One line summary: monotonic clock can be made to decrease on ppc64
> [2.] Full description:
> Setting the realtime clock can sometimes make the monotonic clock go back by
> o
On Tue, Feb 26, 2019 at 9:36 PM Jakub Drnec wrote:
>
> Hi all,
>
> I think I observed a potential problem, is this the correct place to report
> it? (CC me, not on list)
>
> [1.] One line summary: monotonic clock can be made to decrease on ppc64
> [2.] Full description:
> Setting the realtime clo
55 matches
Mail list logo
