On Wed, 2 Oct 2019 14:48:54 -0700, Dmitry Torokhov wrote:
> Now that instances of input_dev support polling mode natively,
> we no longer need to create input_polled_dev instance.
Applied to powerpc/next.
[1/1] macintosh/ams-input: switch to using input device polling mode
On Thu, 21 May 2020 16:55:51 + (UTC), Christophe Leroy wrote:
> v1 and v2 of this series were aiming at removing 40x entirely,
> but it led to protests.
>
> v3 is trying to start modernising powerpc 40x:
> - Rework TLB miss handlers to not use PTE_ATOMIC_UPDATES and _PAGE_HWWRITE
> - Remove
On Wed, 29 Apr 2020 09:51:19 +0200, Cédric Le Goater wrote:
> Here are a couple of fixes for PCI hotplug issues for machines running
> under the POWER hypervisor using hash MMU and the XIVE interrupt mode.
>
> Commit 1ca3dec2b2df ("powerpc/xive: Prevent page fault issues in the
> machine crash
On Tue, 19 May 2020 05:48:42 + (UTC), Christophe Leroy wrote:
> The main purpose of this big series is to:
> - reorganise huge page handling to avoid using mm_slices.
> - use huge pages to map kernel memory on the 8xx.
>
> The 8xx supports 4 page sizes: 4k, 16k, 512k and 8M.
> It uses 2 Level
On Sat, 30 May 2020 17:16:33 + (UTC), Christophe Leroy wrote:
> 'thread' doesn't exist in kuap_check() macro.
>
> Use 'current' instead.
Applied to powerpc/next.
[1/1] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
On Thu, 28 May 2020 10:17:04 + (UTC), Christophe Leroy wrote:
> Mapping of early shadow area is implemented by using a single static
> page table having all entries pointing to the same early shadow page.
> The shadow area must therefore occupy full PGD entries.
>
> The shadow area has a size
On Tue, 31 Mar 2020 16:03:36 + (UTC), Christophe Leroy wrote:
> kprobe does not handle events happening in real mode, all
> functions running with MMU disabled have to be blacklisted.
Applied to powerpc/next.
[01/12] powerpc/52xx: Blacklist functions running with MMU disabled for kprobe
On Wed, 15 Apr 2020 14:57:11 + (UTC), Christophe Leroy wrote:
> On book3s/32, KUEP is an heavy process as it requires to
> set/unset the NX bit in each of the 12 user segments
> everytime the kernel is entered/exited from/to user space.
>
> Don't select KUEP by default on book3s/32.
Applied
On Wed, 15 Apr 2020 14:57:09 + (UTC), Christophe Leroy wrote:
> On book3s/32, KUAP is an heavy process as it requires to
> determine which segments are impacted and unlock/lock
> each of them.
>
> And since the implementation of user_access_begin/end, it
> is even worth for the time being
On Mon, 24 Feb 2020 18:02:10 + (UTC), Christophe Leroy wrote:
> In order to avoid Oopses, use probe_address() to read the
> instruction at the address where the trap happened.
Applied to powerpc/next.
[1/1] powerpc/kprobes: Use probe_address() to read instructions
On Wed, 15 Apr 2020 10:06:09 + (UTC), Christophe Leroy wrote:
> To enable/disable kernel access to user space, the 8xx has to
> modify the properties of access group 1. This is done by writing
> predefined values into SPRN_Mx_AP registers.
>
> As of today, a __put_user() gives:
>
> 0d64
On Sat, 9 May 2020 10:08:38 +0800, Chen Zhou wrote:
> Fixes coccicheck warning:
>
> ./arch/powerpc/platforms/powernv/opal.c:813:1-5:
> alloc with no test, possible model on line 814
>
> Add NULL check after kzalloc.
Applied to powerpc/next.
[1/1] powerpc/powernv: add NULL check after
On Thu, 5 Mar 2020 23:48:52 -0500, Qian Cai wrote:
> Booting a power9 server with hash MMU could trigger an undefined
> behaviour because pud_offset(p4d, 0) will do,
>
> 0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
>
> Fix it by converting pud_index() and friends to static
On Wed, 13 May 2020 08:36:16 +0530, Aneesh Kumar K.V wrote:
> With a 64K page size flush with start and end value as below
> (start, end) = (721f680d, 721f680e) results in
> (hstart, hend) = (721f6820, 721f6800)
>
> Avoid doing a __tlbie_va_range with the wrong hstart and hend
On Thu, 28 May 2020 13:34:56 +0530, Aneesh Kumar K.V wrote:
> This patch fix the below warning reported during migration.
>
> find_kvm_secondary_pte called with kvm mmu_lock not held
> CPU: 23 PID: 5341 Comm: qemu-system-ppc Tainted: GW
> 5.7.0-rc5-kvm-00211-g9ccf10d6d088 #432
On Thu, 21 May 2020 11:43:34 +1000, Alistair Popple wrote:
> This series brings together several previously posted patches required for
> POWER10 support and introduces a new patch enabling POWER10 architected
> mode to enable booting as a POWER10 pseries guest.
>
> It includes support for
On Wed, 26 Feb 2020 15:39:23 +1100, Andrew Donnellan wrote:
> In ocxl_context_free() we note that the AFU reference we're releasing was
> taken in "ocxl_context_init", a function that doesn't actually exist.
>
> Fix it to say ocxl_context_alloc() instead, which I expect was what was
> intended.
On Tue, 2 Jun 2020 14:03:41 +1000, Andrew Donnellan wrote:
> The CXL_AFU_DRIVER_OPS and CXL_LIB Kconfig options were added to coordinate
> merging of new features. They no longer serve any purpose, so remove them.
Applied to powerpc/next.
[1/1] cxl: Remove dead Kconfig options
On Wed Jun 3, 2020 at 9:20 AM, Christophe Leroy wrote:
>
>
>
>
> Le 03/06/2020 à 07:19, Christopher M. Riedl a écrit :
> > When live patching with STRICT_KERNEL_RWX, the CPU doing the patching
> > must use a temporary mapping which allows for writing to kernel text.
> > During the entire window
On Wed Jun 3, 2020 at 9:14 AM, Christophe Leroy wrote:
>
>
>
>
> Le 03/06/2020 à 07:19, Christopher M. Riedl a écrit :
> > When live patching a STRICT_RWX kernel, a mapping is installed at a
> > "patching address" with temporary write permissions. Provide a
> > LKDTM-only accessor function for
On systems with large number of cpus, test fails trying to set
affinity for child process by calling sched_setaffinity() with
smaller size for cpuset. This patch fixes it by making sure that
the size of allocated cpu set is dependent on the number of CPUs
as reported by get_nprocs().
Fixes:
On 06/08/2020 06:22 PM, Aneesh Kumar K.V wrote:
> Architectures can have CONFIG_TRANSPARENT_HUGEPAGE enabled but
> no THP support enabled based on platforms. For ex: with 4K
> PAGE_SIZE ppc64 supports THP only with radix translation.
>
> This results in below crash when running with hash
The kvm_vcpu_read_guest/kvm_vcpu_write_guest used for nested guests
eventually call srcu_dereference_check to dereference a memslot and
lockdep produces a warning as neither kvm->slots_lock nor
kvm->srcu lock is held and kvm->users_count is above zero (>100 in fact).
This wraps mentioned VCPU
On Mon, Jun 8, 2020 at 5:16 PM kernel test robot wrote:
>
> Hi Vaibhav,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on powerpc/next]
> [also build test WARNING on linus/master v5.7 next-20200605]
> [cannot apply to linux-nvdimm/libnvdimm-for-next
Hi Vaibhav,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on linus/master v5.7 next-20200605]
[cannot apply to linux-nvdimm/libnvdimm-for-next scottwood/next]
[if your patch is applied to the wrong git tree, please drop
From: Jeremy Kerr
[ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.
This change uses a temporary buffer for the context save
From: Jeremy Kerr
[ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.
This change uses a temporary buffer for the context save
From: Jeremy Kerr
[ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.
This change uses a temporary buffer for the context save
From: Jeremy Kerr
[ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.
This change uses a temporary buffer for the context save
From: Peter Zijlstra
[ Upstream commit bf2c59fce4074e55d622089b34be3a6bc95484fb ]
In the CPU-offline process, it calls mmdrop() after idle entry and the
subsequent call to cpuhp_report_idle_dead(). Once execution passes the
call to rcu_report_dead(), RCU is ignoring the CPU, which results in
From: Jeremy Kerr
[ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.
This change uses a temporary buffer for the context save
From: Peter Zijlstra
[ Upstream commit bf2c59fce4074e55d622089b34be3a6bc95484fb ]
In the CPU-offline process, it calls mmdrop() after idle entry and the
subsequent call to cpuhp_report_idle_dead(). Once execution passes the
call to rcu_report_dead(), RCU is ignoring the CPU, which results in
From: Michael Ellerman
commit 8659a0e0efdd975c73355dbc033f79ba3b31e82c upstream.
Several strange crashes have been eventually traced back to
STRICT_KERNEL_RWX and its interaction with code patching.
Various paths in our ftrace, kprobes and other patching code need to
be hardened against
From: Juliet Kim
[ Upstream commit f9c6cea0b38518741c8dcf26ac056d26ee2fd61d ]
During MTU change, the following events may happen.
Client-driven CRQ initialization fails due to partner’s CRQ closed,
causing client to enqueue a reset task for FATAL_ERROR. Then passive
(server-driven) CRQ
From: Tyrel Datwyler
[ Upstream commit b36522150e5b85045f868768d46fbaaa034174b2 ]
While removing an ibmvscsi client adapter a WARN_ON like the following is
seen in the kernel log:
drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1
WARNING: CPU: 9 PID: 24062 at
From: Nicholas Piggin
commit d02f6b7dab8228487268298ea1f21081c0b4b3eb upstream.
get/put_user() can be called with nontrivial arguments. fs/proc/page.c
has a good example:
if (put_user(stable_page_flags(ppage), out)) {
stable_page_flags() is quite a lot of code, including spin locks in
the
From: Nayna Jain
commit fa4f3f56ccd28ac031ab275e673ed4098855fed4 upstream.
To prevent verifying the kernel module appended signature
twice (finit_module), once by the module_sig_check() and again by IMA,
powerpc secure boot rules define an IMA architecture specific policy
rule only if
From: Christophe Leroy
commit 4833ce06e6855d526234618b746ffb71d6612c9a upstream.
gpr2 is not a parametre of kuap_check(), it doesn't exist.
Use gpr instead.
Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access
Protection")
Signed-off-by: Christophe Leroy
Signed-off-by:
From: Christophe Leroy
commit e963b7a28b2bf2416304e1a15df967fcf662aff5 upstream.
There are other clocks than the standard ones, for instance
per process clocks. Therefore, being above the last standard clock
doesn't mean it is a bad clock. So, fallback to syscall instead
of returning -EINVAL
From: Jeremy Kerr
[ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ]
Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.
This change uses a temporary buffer for the context save
From: Peter Zijlstra
[ Upstream commit bf2c59fce4074e55d622089b34be3a6bc95484fb ]
In the CPU-offline process, it calls mmdrop() after idle entry and the
subsequent call to cpuhp_report_idle_dead(). Once execution passes the
call to rcu_report_dead(), RCU is ignoring the CPU, which results in
From: Ioana Ciornei
[ Upstream commit 7596ac9d19a9df25707ecaac0675881f62dd8c18 ]
Mask the consumer index before using it. Without this, we would be
writing frame descriptors beyond the ring size supported by the QBMAN
block.
Fixes: 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array mode with
'seq_buf' provides a very useful abstraction for writing to a string
buffer without needing to worry about it over-flowing. However even
though the API has been stable for couple of years now its still not
exported to kernel loadable modules limiting its usage.
Hence this patch proposes update to
This patch implements support for PDSM request 'PAPR_PDSM_HEALTH'
that returns a newly introduced 'struct nd_papr_pdsm_health' instance
containing dimm health information back to user space in response to
ND_CMD_CALL. This functionality is implemented in newly introduced
papr_pdsm_health() that
Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
module and add the command family NVDIMM_FAMILY_PAPR to the white list
of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the
nvdimm command mask and implement necessary scaffolding in the module
to handle
Since papr_scm_ndctl() can be called from outside papr_scm, its
exposed to the possibility of receiving NULL as value of 'cmd_rc'
argument. This patch updates papr_scm_ndctl() to protect against such
possibility by assigning it pointer to a local variable in case cmd_rc
== NULL.
Finally the patch
Implement support for fetching nvdimm health information via
H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
of 64-bit bitmap, bitwise-and of which is then stored in
'struct papr_scm_priv' and subsequently partially exposed to
user-space via newly introduced dimm specific
Add documentation to 'papr_hcalls.rst' describing the bitmap flags
that are returned from H_SCM_HEALTH hcall as per the PAPR-SCM
specification.
Cc: "Aneesh Kumar K . V"
Cc: Dan Williams
Cc: Michael Ellerman
Cc: Ira Weiny
Acked-by: Ira Weiny
Signed-off-by: Vaibhav Jain
---
Changelog:
Changes since v11 [1]:
* Minor update to 'papr_pdsm.h' fixing a misleading comment about
'possible' padding being added by GCC which doesn't apply in case
structs are marked as __packed.
* Fix the order of initialization of 'struct nd_papr_pdsm_health' in
papr_pdsm_health().
* Added acks
Thanks Ira,
Ira Weiny writes:
> On Sun, Jun 07, 2020 at 06:43:39PM +0530, Vaibhav Jain wrote:
>> This patch implements support for PDSM request 'PAPR_PDSM_HEALTH'
>> that returns a newly introduced 'struct nd_papr_pdsm_health' instance
>> containing dimm health information back to user space in
Ira Weiny writes:
> On Sun, Jun 07, 2020 at 06:43:38PM +0530, Vaibhav Jain wrote:
>> Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
>> module and add the command family NVDIMM_FAMILY_PAPR to the white list
>> of NVDIMM command sets. Also advertise support for ND_CMD_CALL
Hi Ira,
During v9 you had provided your ack to this patch [1] and also had made a
review comment in a later patch regarding an avoidable 'goto'
statement. I have since updated the patch addressing that review
comment. Can you please provide your ack to this patch too.
[1]
On systems with large number of cpus, test fails trying to set
affinity by calling sched_setaffinity() with smaller size for
cpuset. This patch fixes it by making sure that the size of
allocated cpu set is dependent on the number of CPUs as reported
by get_nprocs().
Reported-by: Shirisha Ganta
On Sun, Jun 07, 2020 at 06:43:39PM +0530, Vaibhav Jain wrote:
> This patch implements support for PDSM request 'PAPR_PDSM_HEALTH'
> that returns a newly introduced 'struct nd_papr_pdsm_health' instance
> containing dimm health information back to user space in response to
> ND_CMD_CALL. This
On Sun, Jun 07, 2020 at 06:43:38PM +0530, Vaibhav Jain wrote:
> Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
> module and add the command family NVDIMM_FAMILY_PAPR to the white list
> of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the
> nvdimm command
On Sun, Jun 07, 2020 at 06:43:37PM +0530, Vaibhav Jain wrote:
> Since papr_scm_ndctl() can be called from outside papr_scm, its
> exposed to the possibility of receiving NULL as value of 'cmd_rc'
> argument. This patch updates papr_scm_ndctl() to protect against such
> possibility by assigning it
On 6/8/20 8:12 PM, Sandipan Das wrote:
> The size of the cpu set must be large enough for systems
> with a very large number of CPUs. Otherwise, tests which
> try to determine the first online CPU by calling
> sched_getaffinity() will fail. This makes sure that the
> size of the allocated cpu set
The size of the cpu set must be large enough for systems
with a very large number of CPUs. Otherwise, tests which
try to determine the first online CPU by calling
sched_getaffinity() will fail. This makes sure that the
size of the allocated cpu set is dependent on the number
of CPUs as reported by
Architectures can have CONFIG_TRANSPARENT_HUGEPAGE enabled but
no THP support enabled based on platforms. For ex: with 4K
PAGE_SIZE ppc64 supports THP only with radix translation.
This results in below crash when running with hash translation and
4K PAGE_SIZE.
kernel BUG at
POWER8 and POWER9 have 12-bit LPIDs. Change LPID_RSVD to support up to
(4096 - 2) guests on these processors. POWER7 is kept the same with a
limitation of (1024 - 2), but it might be time to drop KVM support for
POWER7.
Tested with 2048 guests * 4 vCPUs on a witherspoon system with 512G
RAM and a
On 06/08/2020 04:46 PM, Aneesh Kumar K.V wrote:
> On 6/8/20 4:31 PM, Anshuman Khandual wrote:
>> Hi Aneesh,
>>
>> On 06/08/2020 11:57 AM, Aneesh Kumar K.V wrote:
>>> Architectures can have CONFIG_TRANSPARENT_HUGEPAGE enabled but
>>> no THP support enabled based on platforms. For ex: with 4K
>>>
Hi Prakhar,
On Sun, 2020-06-07 at 16:33 -0700, Prakhar Srivastava wrote:
> This patch moves the non-architecture specific code out of powerpc and
> adds to security/ima.
> Update the arm64 and powerpc kexec file load paths to carry the IMA
> measurement
> logs.
>From your patch description,
On 6/8/20 4:31 PM, Anshuman Khandual wrote:
Hi Aneesh,
On 06/08/2020 11:57 AM, Aneesh Kumar K.V wrote:
Architectures can have CONFIG_TRANSPARENT_HUGEPAGE enabled but
no THP support enabled based on platforms. For ex: with 4K
PAGE_SIZE ppc64 supports THP only with radix translation.
Good
Hi Aneesh,
On 06/08/2020 11:57 AM, Aneesh Kumar K.V wrote:
> Architectures can have CONFIG_TRANSPARENT_HUGEPAGE enabled but
> no THP support enabled based on platforms. For ex: with 4K
> PAGE_SIZE ppc64 supports THP only with radix translation.
Good catch, never hit this before.
>
> This
H_REGISTER_PROC_TBL asks for GTSE by default. GTSE flag bit should
be set only when GTSE is supported.
Signed-off-by: Bharata B Rao
---
arch/powerpc/platforms/pseries/lpar.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c
From: Nicholas Piggin
When platform doesn't support GTSE, let TLB invalidation requests
for radix guests be off-loaded to the host using H_RPT_INVALIDATE
hcall
Signed-off-by: Nicholas Piggin
Signed-off-by: Bharata B Rao
---
arch/powerpc/include/asm/hvcall.h | 1 +
Make GTSE as an MMU feature and enable it by default for radix.
However for guest, conditionally enable it if hypervisor supports it
via OV5 vector.
Making GTSE as a MMU feature will make it easy to enable radix
without GTSE.
Signed-off-by: Bharata B Rao
---
arch/powerpc/include/asm/mmu.h|
In the case of radix, don't ask for GTSE by default but ask
only if GTSE is enabled.
Signed-off-by: Bharata B Rao
---
arch/powerpc/kernel/prom_init.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c
Hypervisor may choose not to enable Guest Translation Shootdown Enable
(GTSE) option for the guest. When GTSE isn't ON, the guest OS isn't
permitted to use instructions like tblie and tlbsync directly, but is
expected to make hypervisor calls to get the TLB flushed.
This series enables the TLB
"Aneesh Kumar K.V" writes:
> On 6/3/20 1:56 PM, Jan Kara wrote:
>> On Tue 02-06-20 17:59:08, Williams, Dan J wrote:
>>> [ forgive formatting, a series of unfortunate events has me using Outlook
>>> for the moment ]
>>>
From: Jan Kara
>>> These flags are device properties that
The issue log is:
[ 48.021506] CPU: 0 PID: 664 Comm: aplay Not tainted
5.7.0-rc1-13120-g12b434cbbea0 #343
[ 48.031063] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 48.037638] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 48.045413] [] (show_stack) from []
"Aneesh Kumar K.V" writes:
> Implement page mapping percpu first chunk allocator as a fallback to
> the embedding allocator. With 4K hash translation we limit our page
> table range to 64TB and commit: 0034d395f89d ("powerpc/mm/hash64: Map all the
> kernel regions in the same 0xc range") moved
With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
regions in the same 0xc range"), we now split the 64TB address range
into 4 contexts each of 16TB. That implies we can do only 16TB linear
mapping.
On some systems, eg. Power9, memory attached to nodes > 0 will appear
above 16TB in
MAX_PHYSMEM #define is used along with sparsemem to determine the SECTION_SHIFT
value. Powerpc also uses the same value to limit the max memory enabled on the
system. With 4K PAGE_SIZE and hash translation mode, we want to limit the max
memory enabled to 64TB due to page table size restrictions.
This update the ppc64 version to be closer to x86/sparc.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kernel/setup_64.c | 45 --
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
Implement page mapping percpu first chunk allocator as a fallback to
the embedding allocator. With 4K hash translation we limit our page
table range to 64TB and commit: 0034d395f89d ("powerpc/mm/hash64: Map all the
kernel regions in the same 0xc range") moved all kernel mapping to
that 64TB range.
On Sat, Jun 06, 2020 at 07:30:21AM +, Christophe Leroy wrote:
> devm_gpiod_get_index() doesn't return NULL but -ENOENT when the
> requested GPIO doesn't exist, leading to the following messages:
>
> [2.742468] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.748147] can't set
Architectures can have CONFIG_TRANSPARENT_HUGEPAGE enabled but
no THP support enabled based on platforms. For ex: with 4K
PAGE_SIZE ppc64 supports THP only with radix translation.
This results in below crash when running with hash translation and
4K PAGE_SIZE.
kernel BUG at
78 matches
Mail list logo
