On Sat, Apr 23, 2022 at 6:26 AM Bjorn Helgaas wrote:
>
> [+cc Rafael, linux-pm; sorry forgot this last time]
>
> On Fri, Apr 22, 2022 at 05:24:36PM -0500, Bjorn Helgaas wrote:
> > On Fri, Apr 08, 2022 at 11:31:58PM +0800, Kai-Heng Feng wrote:
> > > On Intel Alder Lake platforms, Thunderbolt
On Thu, Jun 30, 2022 at 03:46:56PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.52 release.
> There are 28 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Wed, 29 Jun 2022 20:54:41 +0800 you wrote:
> Delete the redundant word 'a'.
>
> Signed-off-by: Jilin Yuan
> ---
> drivers/net/ethernet/freescale/fs_enet/fs_enet.h | 2 +-
> 1 file changed, 1 insertion(+), 1
Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.
Signed-off-by: Stefan Berger
Cc: Rob Herring
Cc: Frank Rowand
Cc: Mimi Zohar
---
v4:
- Move debug output into setup_buffer()
---
drivers/of/kexec.c | 131
From: Vaibhav Jain
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the
Simplify tpm_read_log_of() by moving reusable parts of the code into
an inline function that makes it commonly available so it can be
used also for kexec support. Call the new of_tpm_get_sml_parameters()
function from the TPM Open Firmware driver.
Signed-off-by: Stefan Berger
Cc: Jarkko Sakkinen
The memory area of the TPM measurement log is currently not properly
duplicated for carrying it across kexec when an Open Firmware
Devicetree is used. Therefore, the contents of the log get corrupted.
Fix this for the kexec_file_load() syscall by allocating a buffer and
copying the contents of the
From: Palmer Dabbelt
RISC-V recently added kexec_file() support, which uses enables kexec
IMA. We're the first 32-bit platform to support this, so we found a
build bug.
[ Several tags removed; for testing by krobot ]
Signed-off-by: Palmer Dabbelt
---
drivers/of/kexec.c | 4 ++--
1 file
The of-tree subsystem does not currently preserve the IBM vTPM 1.2 and
vTPM 2.0 measurement logs across a kexec on PowerVM and PowerKVM. This
series fixes this for the kexec_file_load() syscall using the flattened
device tree (fdt) to carry the TPM measurement log's buffer across kexec.
Stefan
Hi Christoph,
On 29/06/22 18:25, Christoph Hellwig wrote:
On Wed, Jun 29, 2022 at 09:38:00AM +1200, Michael Schmitz wrote:
That's one of the 'liberties' I alluded to. The reason I left these in is
that I'm none too certain what device feature the DMA API uses to decide a
device isn't
Hi Christoph,
On 29/06/22 18:21, Christoph Hellwig wrote:
On Wed, Jun 29, 2022 at 11:09:00AM +1200, Michael Schmitz wrote:
And all SCSI buffers are allocated using kmalloc? No way at all for user
space to pass unaligned data?
Most that you will see actually comes from the page allocator. But
https://bugzilla.kernel.org/show_bug.cgi?id=216190
--- Comment #2 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Problem is likely due to commit 4291d085b0b0 ("powerpc/32s: Make pte_update()
non atomic on 603 core")
kasan_early_init() calls __set_pte_at(), which calls pte_update() if
Following warning is seen while booting recent -next kernel on IBM Power server.
[1.544420] [ cut here ]
[1.544422] alg: self-tests for rsa-generic (rsa) failed (rc=-22)
[1.544429] WARNING: CPU: 18 PID: 512 at crypto/testmgr.c:5774
alg_test+0x42c/0x850
[
s(+), 51 deletions(-)
> >
>
> I tried these 2 patches + previous one (to fix kobject warning) on
> top of 5.19.0-rc4-next-20220630 next on a Power8 server.
>
> 5.19.0-rc4-next-20220630 +
> powerpc/powernv: delay rng of node creation until later in boot +
> powerpc/pow
t; arch/powerpc/platforms/powernv/rng.c | 65 ++-
> drivers/char/hw_random/powernv-rng.c | 2 +-
> 4 files changed, 30 insertions(+), 51 deletions(-)
>
I tried these 2 patches + previous one (to fix kobject warning) on
top of 5.19.0-rc4-next-20220630 next on a Power8 server.
On Thu, Jun 30, 2022 at 04:07:47PM +0530, Naveen N. Rao wrote:
> Objtool classifies 'ud2' as INSN_BUG, and 'int3' as INSN_TRAP. In x86
> BUG(), there is no need for an annotation since objtool assumes that
> 'ud2' terminates control flow. But, for __WARN_FLAGS(), since 'ud2' is
> used, an
On POWER8 systems that don't have ibm,power-rng available, a guest that
ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
dereference a NULL pointer. And on machines with darn instead of
ibm,power-rng, H_RANDOM won't work at all.
This patch kills two birds with one stone, by
These are two small cleanups for -next.
I'm sending this v3 because very likely
https://lore.kernel.org/all/20220630121654.1939181-1-ja...@zx2c4.com/
will land first, in which case this needs a small adjustment.
Jason A. Donenfeld (2):
powerpc/powernv: rename remaining rng powernv_ functions
The preferred nomenclature is pnv_, not powernv_, but rng.c used
powernv_ for some reason, which isn't consistent with the rest. A recent
commit added a few pnv_ functions to rng.c, making the file a bit of a
mishmash. This commit just replaces the rest of them.
Cc: Michael Ellerman
Fixes:
> On 30-Jun-2022, at 5:46 PM, Jason A. Donenfeld wrote:
>
> The of node for the rng must be created much later in boot. Otherwise it
> tries to connect to a parent that doesn't yet exist, resulting on this
> splat:
>
> [0.000478] kobject: '(null)' ((ptrval)): is not initialized,
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #32 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Michael Ellerman from comment #30)
> It's a bit of a stab in the dark, but can you try turning preempt off?
>
> ie. CONFIG_PREEMPT_NONE=y
Looks like your intuition was not
On Tue, Jun 28, 2022 at 09:12:48PM +0530, Naveen N. Rao wrote:
> commit 3e35142ef99fe6b4fe5d834ad43ee13cca10a2dc upstream.
>
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This
The of node for the rng must be created much later in boot. Otherwise it
tries to connect to a parent that doesn't yet exist, resulting on this
splat:
[0.000478] kobject: '(null)' ((ptrval)): is not initialized, yet
kobject_get() is being called.
[0.002925] [c2a0fb30]
Hi Sachin,
On Thu, Jun 30, 2022 at 05:01:57PM +0530, Sachin Sant wrote:
> [0.000478] kobject: '(null)' ((ptrval)): is not initialized, yet
> kobject_get() is being called.
> [0.002925] [c2a0fb30] [c073b0bc] kobject_get+0x8c/0x100
> (unreliable)
> [0.003071]
While booting linux-next (5.19.0-rc4-next-20220629) on Power8 non-virtualised
following koject warning is seen:
[0.000184] clocksource: timebase mult[1f4] shift[24] registered
[0.000303] clockevent: decrementer mult[83126e98] shift[32] cpu[0]
[0.000397] [ cut here
On Mon, Jun 27, 2022 at 11:09:29PM +0530, Naveen N. Rao wrote:
> commit 84ade0a6655bee803d176525ef457175cbf4df22 upstream.
>
> Stop using the ftrace trampoline for init section once kernel init is
> complete.
>
> Fixes: 67361cf8071286 ("powerpc/ftrace: Handle large kernel configs")
> Cc:
Christophe Leroy wrote:
Le 30/06/2022 à 10:05, Naveen N. Rao a écrit :
Christophe Leroy wrote:
The builtin variant of unreachable (__builtin_unreachable()) works.
How about using that instead of unreachable() ?
In fact the problem comes from the macro annotate_unreachable() which
is
Le 30/06/2022 à 11:58, Christophe Leroy a écrit :
Le 30/06/2022 à 10:05, Naveen N. Rao a écrit :
Christophe Leroy wrote:
Hi Sathvika,
Adding ARM people as they seem to face the same kind of problem (see
From: Christophe Leroy
> Sent: 30 June 2022 10:40
>
> Le 30/06/2022 à 10:04, David Laight a écrit :
> > From: Michael Schmitz
> >> Sent: 29 June 2022 00:09
> >>
> >> Hi Arnd,
> >>
> >> On 29/06/22 09:50, Arnd Bergmann wrote:
> >>> On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
> >>> wrote:
>
Le 30/06/2022 à 10:05, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> Hi Sathvika,
>>
>> Adding ARM people as they seem to face the same kind of problem (see
>> https://patchwork.kernel.org/project/linux-kbuild/patch/20220623014917.199563-33-chenzhong...@huawei.com/)
>>
>>
>>
>> Le
Le 30/06/2022 à 10:04, David Laight a écrit :
> From: Michael Schmitz
>> Sent: 29 June 2022 00:09
>>
>> Hi Arnd,
>>
>> On 29/06/22 09:50, Arnd Bergmann wrote:
>>> On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
>>> wrote:
On 28/06/22 19:03, Geert Uytterhoeven wrote:
>> The driver
Jiang Jian wrote:
> there is an unexpected word "the" in the comments that need to be dropped
>
>>- * The DDE is setup with the the DDE count, byte count, and address of
>>+ * The DDE is setup with the DDE count, byte count, and address of
>
> Signed-off-by: Jiang Jian
> ---
>
Jiang Jian wrote:
> there is an unexpected word 'for' in the comments that need to be dropped
>
> file - drivers/crypto/vmx/ghashp8-ppc.pl
> line - 19
>
> "# GHASH for for PowerISA v2.07."
>
> changed to:
>
> "# GHASH for PowerISA v2.07."
>
> Signed-off-by: Jiang Jian
> ---
>
Christophe Leroy wrote:
Hi Sathvika,
Adding ARM people as they seem to face the same kind of problem (see
https://patchwork.kernel.org/project/linux-kbuild/patch/20220623014917.199563-33-chenzhong...@huawei.com/)
Le 27/06/2022 à 17:35, Sathvika Vasireddy a écrit :
On 25/06/22 12:16,
From: Michael Schmitz
> Sent: 29 June 2022 00:09
>
> Hi Arnd,
>
> On 29/06/22 09:50, Arnd Bergmann wrote:
> > On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
> > wrote:
> >> On 28/06/22 19:03, Geert Uytterhoeven wrote:
> The driver allocates bounce buffers using kmalloc if it hits an
>
During kdump, two set of NMI IPIs are sent to secondary CPUs, if
'crash_kexec_post_notifiers' option is set. The first set of NMI IPIs
to stop the CPUs and the other set to collect register data. Instead,
capture register data for secondary CPUs while stopping them itself.
Also, fallback to
Please ignore this thread. Will resend with v2 tag..
On 30/06/22 11:00 am, Hari Bathini wrote:
During kdump, two set of NMI IPIs are sent to secondary CPUs, if
'crash_kexec_post_notifiers' option is set. The first set of NMI IPIs
to stop the CPUs and the other set to collect register data.
37 matches
Mail list logo
