tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: f855455dee0b970f3a9d930ec9b3a2a7138c0f5e Automatic merge of
'next' into merge (2021-11-05 22:19)
elapsed time: 797m
configs tested: 53
configs skipped: 3
The following configs have been built suc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: 11c41994b1c3a7cb08c87883cc19d469258882b6 KVM: PPC: Book3S HV: Use
GLOBAL_TOC for kvmppc_h_set_dabr/xdabr()
elapsed time: 740m
configs tested: 32
configs skipped: 53
The following configs hav
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
topic/ppc-kvm
branch HEAD: 235cee162459d96153d63651ce7ff51752528c96 KVM: PPC: Tick
accounting should defer vtime accounting 'til after IRQ handling
elapsed time: 5687m
configs tested: 193
configs skipped: 93
The fo
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: c12ab8dbc492b992e1ea717db933cee568780c47 powerpc/8xx: Fix Oops
with STRICT_KERNEL_RWX without DEBUG_RODATA_TEST
elapsed time: 5687m
configs tested: 197
configs skipped: 4
The following configs hav
At least on arm64 and x86, the vcpus array is pretty huge (512 entries),
and is mostly empty in most cases (running 512 vcpu VMs is not that
common). This mean that we end-up with a 4kB block of unused memory
in the middle of the kvm structure.
Instead of wasting away this memory, let's use an xar
All architectures have similar loops iterating over the vcpus,
freeing one vcpu at a time, and eventually wiping the reference
off the vcpus array. They are also inconsistently taking
the kvm->lock mutex when wiping the references from the array.
Make this code common, which will simplify further
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/x86/kvm/vmx/posted_intr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/s390/kvm/kvm-s390.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kv
The kvm structure is pretty large. A large portion of it is the vcpu
array, which is 4kB on x86_64 and arm64 as they deal with 512 vcpu
VMs. Of course, hardly anyone runs VMs this big, so this is often a
net waste of memory and cache locality.
A possible approach is to turn the fixed-size array in
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/mips/kvm/loongson_ipi.c | 4 ++--
arch/mips/kvm/mips.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/a
On 04 November 2021 at 10:42 pm, Vivek Kasireddy wrote:
> When virgl is not enabled, vfpriv pointer would not be allocated.
> Therefore, check for a valid value before dereferencing.
>
> Reported-by: Christian Zigotzky
> Cc: Gurchetan Singh
> Cc: Gerd Hoffmann
> Signed-off-by: Vivek Kasireddy
On Fri, Nov 05, 2021 at 10:36:18AM +1100, Finn Thain wrote:
> There is no __get_user_asm2_goto in this tree, and __get_user_asm2 already
> has the "=&r" constraint:
>
> #define __get_user_asm2(x, addr, err) \
> __asm__ __volatile__( \
>
Le 05/11/2021 à 00:36, Finn Thain a écrit :
On Thu, 4 Nov 2021, Christophe Leroy wrote:
Le 02/11/2021 à 03:20, Finn Thain a écrit :
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc
Le 04/11/2021 à 22:44, Andrew Morton a écrit :
On Fri, 01 Oct 2021 17:14:41 +1000 Daniel Axtens wrote:
#ifdef __KERNEL__
+/*
+ * Check if an address is part of freed initmem. After initmem is freed,
+ * memory can be allocated from it, and such allocations would then have
+ * addresses wi
On Fri, 2021-11-05 at 16:43 +0100, Alexandre Ghiti wrote:
> This config was removed so remove all references to it.
>
> Fixes: f7e33bdbd6d1 ("fs: remove mandatory file locking support")
> Signed-off-by: Alexandre Ghiti
> ---
> arch/mips/configs/decstation_64_defconfig | 1 -
> arch/mips/configs
Le 04/11/2021 à 17:10, Nicholas Piggin a écrit :
Most updates to wd_smp_cpus_pending are under lock except the watchdog
interrupt bit clear.
This can race with non-atomic RMW updates to the mask under lock, which
can happen in two instances:
Firstly, if another CPU detects this one is stuck, re
The pull request you sent on Sat, 06 Nov 2021 00:02:09 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.16-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5c0b0c676ac2d84f69568715af91e45b610fe17a
Thank you!
--
Deet-doot-d
Nicholas Piggin writes:
> In case the FORM2 distance table from firmware is not the expected size,
> there is fallback code that just populates the lookup table as local vs
> remote.
>
> However it then continues on to use the distance table. Fix.
>
Reviewed-by: Aneesh Kumar K.V
> Cc: Aneesh K
On Fri, Nov 5, 2021 at 4:43 PM Alexandre Ghiti
wrote:
>
> While bumping from 5.13 to 5.15, I found that a few deleted configs had
> left some pieces here and there: this patchset cleans that.
>
> Alexandre Ghiti (7):
> Documentation, arch: Remove leftovers from fscache/cachefiles
> histogram
This driver was removed so remove all references to it.
Fixes: d249ff28b1d8 ("intersil: remove obsolete prism54 wireless driver")
Signed-off-by: Alexandre Ghiti
---
arch/mips/configs/ip27_defconfig| 1 -
arch/mips/configs/malta_defconfig | 1 -
arch/mips/configs/malta_kvm_defconfig
This driver was removed so remove all references to it.
Fixes: 52a5502507bc ("watchdog: bd70528 drop bd70528 support")
Signed-off-by: Alexandre Ghiti
---
include/linux/mfd/rohm-bd70528.h | 24
1 file changed, 24 deletions(-)
diff --git a/include/linux/mfd/rohm-bd70528.h
A few references to the fscache object list were left in the
Documentation, some arch defconfigs and in fs: remove them since this
config does not exists anymore.
Fixes: 58f386a73f16 ("fscache: Remove the object list procfile")
Signed-off-by: Alexandre Ghiti
---
Documentation/filesystems/caching
This config was removed so remove all references to it.
Fixes: f7e33bdbd6d1 ("fs: remove mandatory file locking support")
Signed-off-by: Alexandre Ghiti
---
arch/mips/configs/decstation_64_defconfig | 1 -
arch/mips/configs/decstation_defconfig | 1 -
arch/mips/configs/decstation_r4k_defcon
This config was removed so remove all references to it.
Fixes: 76a3c92ec9e0 ("cifs: remove support for NTLM and weaker authentication
algorithms")
Signed-off-by: Alexandre Ghiti
---
Documentation/admin-guide/cifs/usage.rst| 7 +++
arch/arm/configs/cm_x300_defconfig | 1 -
arch/
Raw device interface was removed so remove all references to configs
related to it.
Fixes: 603e4922f1c8 ("remove the raw driver")
Signed-off-by: Alexandre Ghiti
---
Documentation/admin-guide/devices.txt | 8 +---
arch/arm/configs/spear13xx_defconfig | 1 -
arch/arm/configs/spear3xx_defcon
A few references to the fscache and cachefiles histograms were left in
the Documentation and some arch defconfigs: remove them since those
configs do not exist anymore.
Fixes: 6ae9bd8bb037("fscache, cachefiles: Remove the histogram stuff")
Signed-off-by: Alexandre Ghiti
---
.../filesystems/cachi
While bumping from 5.13 to 5.15, I found that a few deleted configs had
left some pieces here and there: this patchset cleans that.
Alexandre Ghiti (7):
Documentation, arch: Remove leftovers from fscache/cachefiles
histograms
Documentation, arch: Remove leftovers from raw device
Document
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.15 next-20211105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documente
On Fri, 29 Oct 2021 17:10:45 +0200, Christophe Leroy wrote:
> Until now, all tests involving CONFIG_STRICT_KERNEL_RWX were done with
> DEBUG_RODATA_TEST to check the result. But now that
> CONFIG_STRICT_KERNEL_RWX is selected by default, it came without
> CONFIG_DEBUG_RODATA_TEST and led to the fol
Le 04/11/2021 à 17:10, Nicholas Piggin a écrit :
When taking watchdog actions, printing messages, comparing and
re-setting wd_smp_last_reset_tb, etc., read TB close to the point of use
and under wd_smp_lock or printing lock (if applicable).
This should keep timebase mostly monotonic with kernel
Slab is up at this point, using the bootmem allocator triggers a
warning. Switch to using the regular cpumask allocator.
Signed-off-by: Nicholas Piggin
---
This only matters when CONFIG_CPUMASK_OFFNODE=y, which has not been
possible before on powerpc.
Thanks,
Nick
arch/powerpc/platforms/pseri
In case the FORM2 distance table from firmware is not the expected size,
there is fallback code that just populates the lookup table as local vs
remote.
However it then continues on to use the distance table. Fix.
Cc: Aneesh Kumar K.V
Fixes: 1c6b5a7e7405 ("powerpc/pseries: Add support for FORM2
On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote:
> Michal Suchanek writes:
>
> > S390 uses appended signature for kernel but implements the check
> > separately from module loader.
> >
> > Support for secure boot on powerpc with appended signature is planned -
> > grub patches submi
> On 05-Nov-2021, at 9:20 AM, Nicholas Piggin wrote:
>
> This function builds the cores online map with on-stack cpumasks which
> can cause high stack usage with large NR_CPUS.
>
> It is not used in any performance sensitive paths, so instead just check
> for first thread sibling.
>
> Signed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull a small batch of powerpc updates for 5.16:
The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82:
Linux 5.15-rc2 (2021-09-19 17:28:22 -0700)
are available in the git repository at:
https://git.kern
Le 05/11/2021 à 12:46, Nicholas Piggin a écrit :
Excerpts from Laurent Dufour's message of November 5, 2021 7:20 pm:
Le 04/11/2021 à 17:10, Nicholas Piggin a écrit :
It is possible for all CPUs to miss the pending cpumask becoming clear,
and then nobody resetting it, which will cause the lockup
https://bugzilla.kernel.org/show_bug.cgi?id=214913
--- Comment #4 from Zorro Lang (zl...@redhat.com) ---
(In reply to Michal Suchanek from comment #3)
> What CPU is this?
>
> Does it go away if you boot with ppc_tm=off
(In reply to Michael Ellerman from comment #2)
> Thanks for the report, I agr
Excerpts from Laurent Dufour's message of November 5, 2021 7:20 pm:
> Le 04/11/2021 à 17:10, Nicholas Piggin a écrit :
>> It is possible for all CPUs to miss the pending cpumask becoming clear,
>> and then nobody resetting it, which will cause the lockup detector to
>> stop working. It will eventua
Michal Suchanek writes:
> S390 uses appended signature for kernel but implements the check
> separately from module loader.
>
> Support for secure boot on powerpc with appended signature is planned -
> grub patches submitted upstream but not yet merged.
Power Non-Virtualised / OpenPower already
The XIVE driver under Linux uses a single interrupt priority and only
one event queue is configured per CPU. Expose the contents under
a 'xive/eqs/cpuX' debugfs file.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 37 +++
1 file changed, 37 in
Use a 'cpus' file to dump CPU states and 'interrupts' to dump IRQ states.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 36 +--
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/
On processors with a XIVE interrupt controller (POWER9 and above), the
kernel can use either doorbells or XIVE to generate CPU IPIs. Sending
doorbell is generally preferred to using the XIVE IC because it is
faster. There are cases where we want to avoid doorbells and use XIVE
only, for debug or pe
and remove the EQ entries output which is not very useful since only
the next two events of the queue are taken into account. We will
improve the dump of the EQ in the next patches.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 27 +++
1 file cha
It can be used to deactivate temporarily StoreEOI for tests or
performance on platforms supporting the feature (POWER10)
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysde
Hello,
This series tries to improve diagnostic support in the XIVE driver. It
adds pr_debug() primitives that can be activated at run-time and changes
the debugfs xive entry to expose more information :
/sys/kernel/debug/powerpc/xive/
├── eqs/
│ ├── cpu0
│ ├── cpu1
│ ├── c
These routines are not on hot code paths and pr_debug() is easier to
activate. Also add a '0x' prefix to hex printed values (HW IRQ number).
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 29 +++
arch/powerpc/sysdev/xive/spapr.c | 38 +++-
and extend output of debugfs and xmon with addresses of the ESB
management and trigger pages.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 54 +++
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/commo
StoreEOI is activated by default on platforms supporting the feature
(POWER10) and will be used as soon as firmware advertises its
availability. The kernel parameter provides a way to deactivate its
use. It can be still be reactivated through debugfs.
Signed-off-by: Cédric Le Goater
---
arch/pow
On POWER10, the automatic "save & restore" of interrupt context is
always available. Provide a way to deactivate it for tests or
performance.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/xive-internal.h | 1 +
arch/powerpc/sysdev/xive/common.c| 1 +
arch/powerpc/sysdev/xi
StoreEOI (the capability to EOI with a store) requires load-after-store
ordering in some cases to be reliable. P10 introduced a new offset for
load operations to enforce correct ordering and the XIVE driver has
the required support since kernel 5.8, commit b1f9be9392f0
("powerpc/xive: Enforce load-
and fix some compile issues when !CONFIG_DEBUG_FS.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 3d558cad1f1
Multiple users of mod_check_sig check for the marker, then call
mod_check_sig, extract signature length, and remove the signature.
Put this code in one place together with mod_check_sig.
Signed-off-by: Michal Suchanek
---
include/linux/module_signature.h| 1 +
kernel/module_signature.c
There is one more copy of the code checking appended signarutes.
Merge the common code to module_signature.c
Thanks
Michal
Michal Suchanek (2):
module: Use key_being_used_for for log messages in
verify_appended_signature
module: Move duplicate mod_check_sig users code to mod_parse_sig
Add value for kexec appended signature and pass in key_being_used_for
enum rather than a string to verify_appended_signature to produce log
messages about the signature.
Signed-off-by: Michal Suchanek
---
arch/powerpc/kexec/elf_64.c | 2 +-
arch/s390/kernel/machine_kexec_file.c
Le 04/11/2021 à 17:10, Nicholas Piggin a écrit :
It is possible for all CPUs to miss the pending cpumask becoming clear,
and then nobody resetting it, which will cause the lockup detector to
stop working. It will eventually expire, but watchdog_smp_panic will
avoid doing anything if the pending m
55 matches
Mail list logo