2022-08-19 17:14:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 00/14] 5.15.62-rc1 review

This is the start of the stable review cycle for the 5.15.62 release.
There are 14 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 know.

Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.62-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.15.62-rc1

Coiby Xu <[email protected]>
arm64: kexec_file: use more system keyrings to verify kernel image signature

Coiby Xu <[email protected]>
kexec, KEYS: make the code in bzImage64_verify_sig generic

Coiby Xu <[email protected]>
kexec: clean up arch_kexec_kernel_verify_sig

Naveen N. Rao <[email protected]>
kexec_file: drop weak attribute from functions

Qu Wenruo <[email protected]>
btrfs: raid56: don't trust any cached sector in __raid56_parity_recover()

Qu Wenruo <[email protected]>
btrfs: only write the sectors in the vertical stripe which has data stripes

Peter Zijlstra <[email protected]>
x86/ftrace: Use alternative RET encoding

Peter Zijlstra <[email protected]>
x86/ibt,ftrace: Make function-graph play nice

Thadeu Lima de Souza Cascardo <[email protected]>
Revert "x86/ftrace: Use alternative RET encoding"

Namjae Jeon <[email protected]>
ksmbd: fix heap-based overflow in set_ntacl_dacl()

Hyunchul Lee <[email protected]>
ksmbd: prevent out of bound read for SMB2_WRITE

Jamal Hadi Salim <[email protected]>
net_sched: cls_route: disallow handle of 0

Jens Wiklander <[email protected]>
tee: add overflow check in register_shm_helper()

Jens Axboe <[email protected]>
io_uring: use original request task for inflight tracking


-------------

Diffstat:

Makefile | 4 +-
arch/arm64/include/asm/kexec.h | 4 +-
arch/arm64/kernel/kexec_image.c | 11 +---
arch/powerpc/include/asm/kexec.h | 9 +++
arch/s390/include/asm/kexec.h | 3 +
arch/x86/include/asm/kexec.h | 6 ++
arch/x86/kernel/ftrace.c | 7 +-
arch/x86/kernel/ftrace_64.S | 19 ++++--
arch/x86/kernel/kexec-bzimage64.c | 20 +-----
drivers/tee/tee_shm.c | 3 +
fs/btrfs/raid56.c | 74 +++++++++++++++++-----
fs/io_uring.c | 2 +-
fs/ksmbd/smb2misc.c | 7 +-
fs/ksmbd/smb2pdu.c | 45 +++++++------
fs/ksmbd/smbacl.c | 130 ++++++++++++++++++++++++++------------
fs/ksmbd/smbacl.h | 2 +-
fs/ksmbd/vfs.c | 5 ++
include/linux/kexec.h | 50 ++++++++++++---
kernel/kexec_file.c | 83 +++++++++---------------
net/sched/cls_route.c | 10 +++
20 files changed, 312 insertions(+), 182 deletions(-)



2022-08-19 17:18:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 01/14] io_uring: use original request task for inflight tracking

From: Jens Axboe <[email protected]>

commit 386e4fb6962b9f248a80f8870aea0870ca603e89 upstream.

In prior kernels, we did file assignment always at prep time. This meant
that req->task == current. But after deferring that assignment and then
pushing the inflight tracking back in, we've got the inflight tracking
using current when it should in fact now be using req->task.

Fixup that error introduced by adding the inflight tracking back after
file assignments got modifed.

Fixes: 9cae36a094e7 ("io_uring: reinstate the inflight tracking")
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/io_uring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1405,7 +1405,7 @@ static void io_req_track_inflight(struct
{
if (!(req->flags & REQ_F_INFLIGHT)) {
req->flags |= REQ_F_INFLIGHT;
- atomic_inc(&current->io_uring->inflight_tracked);
+ atomic_inc(&req->task->io_uring->inflight_tracked);
}
}



2022-08-19 17:19:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 04/14] ksmbd: prevent out of bound read for SMB2_WRITE

From: Hyunchul Lee <[email protected]>

commit ac60778b87e45576d7bfdbd6f53df902654e6f09 upstream.

OOB read memory can be written to a file,
if DataOffset is 0 and Length is too large
in SMB2_WRITE request of compound request.

To prevent this, when checking the length of
the data area of SMB2_WRITE in smb2_get_data_area_len(),
let the minimum of DataOffset be the size of
SMB2 header + the size of SMB2_WRITE header.

This bug can lead an oops looking something like:

[ 798.008715] BUG: KASAN: slab-out-of-bounds in copy_page_from_iter_atomic+0xd3d/0x14b0
[ 798.008724] Read of size 252 at addr ffff88800f863e90 by task kworker/0:2/2859
...
[ 798.008754] Call Trace:
[ 798.008756] <TASK>
[ 798.008759] dump_stack_lvl+0x49/0x5f
[ 798.008764] print_report.cold+0x5e/0x5cf
[ 798.008768] ? __filemap_get_folio+0x285/0x6d0
[ 798.008774] ? copy_page_from_iter_atomic+0xd3d/0x14b0
[ 798.008777] kasan_report+0xaa/0x120
[ 798.008781] ? copy_page_from_iter_atomic+0xd3d/0x14b0
[ 798.008784] kasan_check_range+0x100/0x1e0
[ 798.008788] memcpy+0x24/0x60
[ 798.008792] copy_page_from_iter_atomic+0xd3d/0x14b0
[ 798.008795] ? pagecache_get_page+0x53/0x160
[ 798.008799] ? iov_iter_get_pages_alloc+0x1590/0x1590
[ 798.008803] ? ext4_write_begin+0xfc0/0xfc0
[ 798.008807] ? current_time+0x72/0x210
[ 798.008811] generic_perform_write+0x2c8/0x530
[ 798.008816] ? filemap_fdatawrite_wbc+0x180/0x180
[ 798.008820] ? down_write+0xb4/0x120
[ 798.008824] ? down_write_killable+0x130/0x130
[ 798.008829] ext4_buffered_write_iter+0x137/0x2c0
[ 798.008833] ext4_file_write_iter+0x40b/0x1490
[ 798.008837] ? __fsnotify_parent+0x275/0xb20
[ 798.008842] ? __fsnotify_update_child_dentry_flags+0x2c0/0x2c0
[ 798.008846] ? ext4_buffered_write_iter+0x2c0/0x2c0
[ 798.008851] __kernel_write+0x3a1/0xa70
[ 798.008855] ? __x64_sys_preadv2+0x160/0x160
[ 798.008860] ? security_file_permission+0x4a/0xa0
[ 798.008865] kernel_write+0xbb/0x360
[ 798.008869] ksmbd_vfs_write+0x27e/0xb90 [ksmbd]
[ 798.008881] ? ksmbd_vfs_read+0x830/0x830 [ksmbd]
[ 798.008892] ? _raw_read_unlock+0x2a/0x50
[ 798.008896] smb2_write+0xb45/0x14e0 [ksmbd]
[ 798.008909] ? __kasan_check_write+0x14/0x20
[ 798.008912] ? _raw_spin_lock_bh+0xd0/0xe0
[ 798.008916] ? smb2_read+0x15e0/0x15e0 [ksmbd]
[ 798.008927] ? memcpy+0x4e/0x60
[ 798.008931] ? _raw_spin_unlock+0x19/0x30
[ 798.008934] ? ksmbd_smb2_check_message+0x16af/0x2350 [ksmbd]
[ 798.008946] ? _raw_spin_lock_bh+0xe0/0xe0
[ 798.008950] handle_ksmbd_work+0x30e/0x1020 [ksmbd]
[ 798.008962] process_one_work+0x778/0x11c0
[ 798.008966] ? _raw_spin_lock_irq+0x8e/0xe0
[ 798.008970] worker_thread+0x544/0x1180
[ 798.008973] ? __cpuidle_text_end+0x4/0x4
[ 798.008977] kthread+0x282/0x320
[ 798.008982] ? process_one_work+0x11c0/0x11c0
[ 798.008985] ? kthread_complete_and_exit+0x30/0x30
[ 798.008989] ret_from_fork+0x1f/0x30
[ 798.008995] </TASK>

Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
Cc: [email protected]
Reported-by: [email protected] # ZDI-CAN-17817
Signed-off-by: Hyunchul Lee <[email protected]>
Acked-by: Namjae Jeon <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ksmbd/smb2misc.c | 7 +++++--
fs/ksmbd/smb2pdu.c | 6 ++----
2 files changed, 7 insertions(+), 6 deletions(-)

--- a/fs/ksmbd/smb2misc.c
+++ b/fs/ksmbd/smb2misc.c
@@ -132,8 +132,11 @@ static int smb2_get_data_area_len(unsign
*len = le16_to_cpu(((struct smb2_read_req *)hdr)->ReadChannelInfoLength);
break;
case SMB2_WRITE:
- if (((struct smb2_write_req *)hdr)->DataOffset) {
- *off = le16_to_cpu(((struct smb2_write_req *)hdr)->DataOffset);
+ if (((struct smb2_write_req *)hdr)->DataOffset ||
+ ((struct smb2_write_req *)hdr)->Length) {
+ *off = max_t(unsigned int,
+ le16_to_cpu(((struct smb2_write_req *)hdr)->DataOffset),
+ offsetof(struct smb2_write_req, Buffer) - 4);
*len = le32_to_cpu(((struct smb2_write_req *)hdr)->Length);
break;
}
--- a/fs/ksmbd/smb2pdu.c
+++ b/fs/ksmbd/smb2pdu.c
@@ -6471,10 +6471,8 @@ int smb2_write(struct ksmbd_work *work)
(offsetof(struct smb2_write_req, Buffer) - 4)) {
data_buf = (char *)&req->Buffer[0];
} else {
- if ((u64)le16_to_cpu(req->DataOffset) + length > get_rfc1002_len(req)) {
- pr_err("invalid write data offset %u, smb_len %u\n",
- le16_to_cpu(req->DataOffset),
- get_rfc1002_len(req));
+ if (le16_to_cpu(req->DataOffset) <
+ offsetof(struct smb2_write_req, Buffer)) {
err = -EINVAL;
goto out;
}


2022-08-19 17:36:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 11/14] kexec_file: drop weak attribute from functions

From: Naveen N. Rao <[email protected]>

commit 65d9a9a60fd71be964effb2e94747a6acb6e7015 upstream.

As requested
(http://lkml.kernel.org/r/[email protected]),
this series converts weak functions in kexec to use the #ifdef approach.

Quoting the 3e35142ef99fe ("kexec_file: drop weak attribute from
arch_kexec_apply_relocations[_add]") changelog:

: Since commit d1bcae833b32f1 ("ELF: Don't generate unused section symbols")
: [1], binutils (v2.36+) started dropping section symbols that it thought
: were unused. This isn't an issue in general, but with kexec_file.c, gcc
: is placing kexec_arch_apply_relocations[_add] into a separate
: .text.unlikely section and the section symbol ".text.unlikely" is being
: dropped. Due to this, recordmcount is unable to find a non-weak symbol in
: .text.unlikely to generate a relocation record against.

This patch (of 2);

Drop __weak attribute from functions in kexec_file.c:
- arch_kexec_kernel_image_probe()
- arch_kimage_file_post_load_cleanup()
- arch_kexec_kernel_image_load()
- arch_kexec_locate_mem_hole()
- arch_kexec_kernel_verify_sig()

arch_kexec_kernel_image_load() calls into kexec_image_load_default(), so
drop the static attribute for the latter.

arch_kexec_kernel_verify_sig() is not overridden by any architecture, so
drop the __weak attribute.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/2cd7ca1fe4d6bb6ca38e3283c717878388ed6788.1656659357.git.naveen.n.rao@linux.vnet.ibm.com
Signed-off-by: Naveen N. Rao <[email protected]>
Suggested-by: Eric Biederman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/include/asm/kexec.h | 4 ++-
arch/powerpc/include/asm/kexec.h | 9 +++++++
arch/s390/include/asm/kexec.h | 3 ++
arch/x86/include/asm/kexec.h | 6 +++++
include/linux/kexec.h | 44 +++++++++++++++++++++++++++++++++------
kernel/kexec_file.c | 35 +------------------------------
6 files changed, 61 insertions(+), 40 deletions(-)

--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -103,7 +103,9 @@ extern const struct kexec_file_ops kexec

struct kimage;

-extern int arch_kimage_file_post_load_cleanup(struct kimage *image);
+int arch_kimage_file_post_load_cleanup(struct kimage *image);
+#define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
+
extern int load_other_segments(struct kimage *image,
unsigned long kernel_load_addr, unsigned long kernel_size,
char *initrd, unsigned long initrd_len,
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -119,6 +119,15 @@ int setup_purgatory(struct kimage *image
#ifdef CONFIG_PPC64
struct kexec_buf;

+int arch_kexec_kernel_image_probe(struct kimage *image, void *buf, unsigned long buf_len);
+#define arch_kexec_kernel_image_probe arch_kexec_kernel_image_probe
+
+int arch_kimage_file_post_load_cleanup(struct kimage *image);
+#define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
+
+int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf);
+#define arch_kexec_locate_mem_hole arch_kexec_locate_mem_hole
+
int load_crashdump_segments_ppc64(struct kimage *image,
struct kexec_buf *kbuf);
int setup_purgatory_ppc64(struct kimage *image, const void *slave_code,
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -92,5 +92,8 @@ int arch_kexec_apply_relocations_add(str
const Elf_Shdr *relsec,
const Elf_Shdr *symtab);
#define arch_kexec_apply_relocations_add arch_kexec_apply_relocations_add
+
+int arch_kimage_file_post_load_cleanup(struct kimage *image);
+#define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
#endif
#endif /*_S390_KEXEC_H */
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -193,6 +193,12 @@ int arch_kexec_apply_relocations_add(str
const Elf_Shdr *relsec,
const Elf_Shdr *symtab);
#define arch_kexec_apply_relocations_add arch_kexec_apply_relocations_add
+
+void *arch_kexec_kernel_image_load(struct kimage *image);
+#define arch_kexec_kernel_image_load arch_kexec_kernel_image_load
+
+int arch_kimage_file_post_load_cleanup(struct kimage *image);
+#define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
#endif
#endif

--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -182,21 +182,53 @@ int kexec_purgatory_get_set_symbol(struc
void *buf, unsigned int size,
bool get_value);
void *kexec_purgatory_get_symbol_addr(struct kimage *image, const char *name);
+void *kexec_image_load_default(struct kimage *image);
+
+#ifndef arch_kexec_kernel_image_probe
+static inline int
+arch_kexec_kernel_image_probe(struct kimage *image, void *buf, unsigned long buf_len)
+{
+ return kexec_image_probe_default(image, buf, buf_len);
+}
+#endif
+
+#ifndef arch_kimage_file_post_load_cleanup
+static inline int arch_kimage_file_post_load_cleanup(struct kimage *image)
+{
+ return kexec_image_post_load_cleanup_default(image);
+}
+#endif
+
+#ifndef arch_kexec_kernel_image_load
+static inline void *arch_kexec_kernel_image_load(struct kimage *image)
+{
+ return kexec_image_load_default(image);
+}
+#endif

-/* Architectures may override the below functions */
-int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
- unsigned long buf_len);
-void *arch_kexec_kernel_image_load(struct kimage *image);
-int arch_kimage_file_post_load_cleanup(struct kimage *image);
#ifdef CONFIG_KEXEC_SIG
int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
unsigned long buf_len);
#endif
-int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf);

extern int kexec_add_buffer(struct kexec_buf *kbuf);
int kexec_locate_mem_hole(struct kexec_buf *kbuf);

+#ifndef arch_kexec_locate_mem_hole
+/**
+ * arch_kexec_locate_mem_hole - Find free memory to place the segments.
+ * @kbuf: Parameters for the memory search.
+ *
+ * On success, kbuf->mem will have the start address of the memory region found.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+static inline int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf)
+{
+ return kexec_locate_mem_hole(kbuf);
+}
+#endif
+
/* Alignment required for elf header segment */
#define ELF_CORE_HEADER_ALIGN 4096

--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -62,14 +62,7 @@ int kexec_image_probe_default(struct kim
return ret;
}

-/* Architectures can provide this probe function */
-int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
- unsigned long buf_len)
-{
- return kexec_image_probe_default(image, buf, buf_len);
-}
-
-static void *kexec_image_load_default(struct kimage *image)
+void *kexec_image_load_default(struct kimage *image)
{
if (!image->fops || !image->fops->load)
return ERR_PTR(-ENOEXEC);
@@ -80,11 +73,6 @@ static void *kexec_image_load_default(st
image->cmdline_buf_len);
}

-void * __weak arch_kexec_kernel_image_load(struct kimage *image)
-{
- return kexec_image_load_default(image);
-}
-
int kexec_image_post_load_cleanup_default(struct kimage *image)
{
if (!image->fops || !image->fops->cleanup)
@@ -93,11 +81,6 @@ int kexec_image_post_load_cleanup_defaul
return image->fops->cleanup(image->image_loader_data);
}

-int __weak arch_kimage_file_post_load_cleanup(struct kimage *image)
-{
- return kexec_image_post_load_cleanup_default(image);
-}
-
#ifdef CONFIG_KEXEC_SIG
static int kexec_image_verify_sig_default(struct kimage *image, void *buf,
unsigned long buf_len)
@@ -110,8 +93,7 @@ static int kexec_image_verify_sig_defaul
return image->fops->verify_sig(buf, buf_len);
}

-int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
- unsigned long buf_len)
+int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, unsigned long buf_len)
{
return kexec_image_verify_sig_default(image, buf, buf_len);
}
@@ -617,19 +599,6 @@ int kexec_locate_mem_hole(struct kexec_b
}

/**
- * arch_kexec_locate_mem_hole - Find free memory to place the segments.
- * @kbuf: Parameters for the memory search.
- *
- * On success, kbuf->mem will have the start address of the memory region found.
- *
- * Return: 0 on success, negative errno on error.
- */
-int __weak arch_kexec_locate_mem_hole(struct kexec_buf *kbuf)
-{
- return kexec_locate_mem_hole(kbuf);
-}
-
-/**
* kexec_add_buffer - place a buffer in a kexec segment
* @kbuf: Buffer contents and memory parameters.
*


2022-08-19 17:36:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 14/14] arm64: kexec_file: use more system keyrings to verify kernel image signature

From: Coiby Xu <[email protected]>

commit 0d519cadf75184a24313568e7f489a7fc9b1be3b upstream.

Currently, when loading a kernel image via the kexec_file_load() system
call, arm64 can only use the .builtin_trusted_keys keyring to verify
a signature whereas x86 can use three more keyrings i.e.
.secondary_trusted_keys, .machine and .platform keyrings. For example,
one resulting problem is kexec'ing a kernel image would be rejected
with the error "Lockdown: kexec: kexec of unsigned images is restricted;
see man kernel_lockdown.7".

This patch set enables arm64 to make use of the same keyrings as x86 to
verify the signature kexec'ed kernel image.

Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
Cc: [email protected] # 105e10e2cf1c: kexec_file: drop weak attribute from functions
Cc: [email protected] # 34d5960af253: kexec: clean up arch_kexec_kernel_verify_sig
Cc: [email protected] # 83b7bb2d49ae: kexec, KEYS: make the code in bzImage64_verify_sig generic
Acked-by: Baoquan He <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Co-developed-by: Michal Suchanek <[email protected]>
Signed-off-by: Michal Suchanek <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Coiby Xu <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kernel/kexec_image.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)

--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -14,7 +14,6 @@
#include <linux/kexec.h>
#include <linux/pe.h>
#include <linux/string.h>
-#include <linux/verification.h>
#include <asm/byteorder.h>
#include <asm/cpufeature.h>
#include <asm/image.h>
@@ -130,18 +129,10 @@ static void *image_load(struct kimage *i
return NULL;
}

-#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
-static int image_verify_sig(const char *kernel, unsigned long kernel_len)
-{
- return verify_pefile_signature(kernel, kernel_len, NULL,
- VERIFYING_KEXEC_PE_SIGNATURE);
-}
-#endif
-
const struct kexec_file_ops kexec_image_ops = {
.probe = image_probe,
.load = image_load,
#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
- .verify_sig = image_verify_sig,
+ .verify_sig = kexec_kernel_verify_pe_sig,
#endif
};


2022-08-19 17:37:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 12/14] kexec: clean up arch_kexec_kernel_verify_sig

From: Coiby Xu <[email protected]>

commit 689a71493bd2f31c024f8c0395f85a1fd4b2138e upstream.

Before commit 105e10e2cf1c ("kexec_file: drop weak attribute from
functions"), there was already no arch-specific implementation
of arch_kexec_kernel_verify_sig. With weak attribute dropped by that
commit, arch_kexec_kernel_verify_sig is completely useless. So clean it
up.

Note later patches are dependent on this patch so it should be backported
to the stable tree as well.

Cc: [email protected]
Suggested-by: Eric W. Biederman <[email protected]>
Reviewed-by: Michal Suchanek <[email protected]>
Acked-by: Baoquan He <[email protected]>
Signed-off-by: Coiby Xu <[email protected]>
[[email protected]: reworded patch description "Note"]
Link: https://lore.kernel.org/linux-integrity/[email protected]/
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/kexec.h | 5 -----
kernel/kexec_file.c | 33 +++++++++++++--------------------
2 files changed, 13 insertions(+), 25 deletions(-)

--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -206,11 +206,6 @@ static inline void *arch_kexec_kernel_im
}
#endif

-#ifdef CONFIG_KEXEC_SIG
-int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
- unsigned long buf_len);
-#endif
-
extern int kexec_add_buffer(struct kexec_buf *kbuf);
int kexec_locate_mem_hole(struct kexec_buf *kbuf);

--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -81,24 +81,6 @@ int kexec_image_post_load_cleanup_defaul
return image->fops->cleanup(image->image_loader_data);
}

-#ifdef CONFIG_KEXEC_SIG
-static int kexec_image_verify_sig_default(struct kimage *image, void *buf,
- unsigned long buf_len)
-{
- if (!image->fops || !image->fops->verify_sig) {
- pr_debug("kernel loader does not support signature verification.\n");
- return -EKEYREJECTED;
- }
-
- return image->fops->verify_sig(buf, buf_len);
-}
-
-int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, unsigned long buf_len)
-{
- return kexec_image_verify_sig_default(image, buf, buf_len);
-}
-#endif
-
/*
* Free up memory used by kernel, initrd, and command line. This is temporary
* memory allocation which is not needed any more after these buffers have
@@ -141,13 +123,24 @@ void kimage_file_post_load_cleanup(struc
}

#ifdef CONFIG_KEXEC_SIG
+static int kexec_image_verify_sig(struct kimage *image, void *buf,
+ unsigned long buf_len)
+{
+ if (!image->fops || !image->fops->verify_sig) {
+ pr_debug("kernel loader does not support signature verification.\n");
+ return -EKEYREJECTED;
+ }
+
+ return image->fops->verify_sig(buf, buf_len);
+}
+
static int
kimage_validate_signature(struct kimage *image)
{
int ret;

- ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
- image->kernel_buf_len);
+ ret = kexec_image_verify_sig(image, image->kernel_buf,
+ image->kernel_buf_len);
if (ret) {

if (sig_enforce) {


2022-08-19 17:38:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 09/14] btrfs: only write the sectors in the vertical stripe which has data stripes

From: Qu Wenruo <[email protected]>

commit bd8f7e627703ca5707833d623efcd43f104c7b3f upstream.

If we have only 8K partial write at the beginning of a full RAID56
stripe, we will write the following contents:

0 8K 32K 64K
Disk 1 (data): |XX| | |
Disk 2 (data): | | |
Disk 3 (parity): |XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXX|

|X| means the sector will be written back to disk.

Note that, although we won't write any sectors from disk 2, but we will
write the full 64KiB of parity to disk.

This behavior is fine for now, but not for the future (especially for
RAID56J, as we waste quite some space to journal the unused parity
stripes).

So here we will also utilize the btrfs_raid_bio::dbitmap, anytime we
queue a higher level bio into an rbio, we will update rbio::dbitmap to
indicate which vertical stripes we need to writeback.

And at finish_rmw(), we also check dbitmap to see if we need to write
any sector in the vertical stripe.

So after the patch, above example will only lead to the following
writeback pattern:

0 8K 32K 64K
Disk 1 (data): |XX| | |
Disk 2 (data): | | |
Disk 3 (parity): |XX| | |

Acked-by: David Sterba <[email protected]>
Signed-off-by: Qu Wenruo <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/raid56.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 51 insertions(+), 4 deletions(-)

--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -324,6 +324,9 @@ static void merge_rbio(struct btrfs_raid
{
bio_list_merge(&dest->bio_list, &victim->bio_list);
dest->bio_list_bytes += victim->bio_list_bytes;
+ /* Also inherit the bitmaps from @victim. */
+ bitmap_or(dest->dbitmap, victim->dbitmap, dest->dbitmap,
+ dest->stripe_npages);
dest->generic_bio_cnt += victim->generic_bio_cnt;
bio_list_init(&victim->bio_list);
}
@@ -865,6 +868,12 @@ static void rbio_orig_end_io(struct btrf

if (rbio->generic_bio_cnt)
btrfs_bio_counter_sub(rbio->fs_info, rbio->generic_bio_cnt);
+ /*
+ * Clear the data bitmap, as the rbio may be cached for later usage.
+ * do this before before unlock_stripe() so there will be no new bio
+ * for this bio.
+ */
+ bitmap_clear(rbio->dbitmap, 0, rbio->stripe_npages);

/*
* At this moment, rbio->bio_list is empty, however since rbio does not
@@ -1197,6 +1206,9 @@ static noinline void finish_rmw(struct b
else
BUG();

+ /* We should have at least one data sector. */
+ ASSERT(bitmap_weight(rbio->dbitmap, rbio->stripe_npages));
+
/* at this point we either have a full stripe,
* or we've read the full stripe from the drive.
* recalculate the parity and write the new results.
@@ -1268,6 +1280,11 @@ static noinline void finish_rmw(struct b
for (stripe = 0; stripe < rbio->real_stripes; stripe++) {
for (pagenr = 0; pagenr < rbio->stripe_npages; pagenr++) {
struct page *page;
+
+ /* This vertical stripe has no data, skip it. */
+ if (!test_bit(pagenr, rbio->dbitmap))
+ continue;
+
if (stripe < rbio->nr_data) {
page = page_in_rbio(rbio, stripe, pagenr, 1);
if (!page)
@@ -1292,6 +1309,11 @@ static noinline void finish_rmw(struct b

for (pagenr = 0; pagenr < rbio->stripe_npages; pagenr++) {
struct page *page;
+
+ /* This vertical stripe has no data, skip it. */
+ if (!test_bit(pagenr, rbio->dbitmap))
+ continue;
+
if (stripe < rbio->nr_data) {
page = page_in_rbio(rbio, stripe, pagenr, 1);
if (!page)
@@ -1715,6 +1737,33 @@ static void btrfs_raid_unplug(struct blk
run_plug(plug);
}

+/* Add the original bio into rbio->bio_list, and update rbio::dbitmap. */
+static void rbio_add_bio(struct btrfs_raid_bio *rbio, struct bio *orig_bio)
+{
+ const struct btrfs_fs_info *fs_info = rbio->fs_info;
+ const u64 orig_logical = orig_bio->bi_iter.bi_sector << SECTOR_SHIFT;
+ const u64 full_stripe_start = rbio->bioc->raid_map[0];
+ const u32 orig_len = orig_bio->bi_iter.bi_size;
+ const u32 sectorsize = fs_info->sectorsize;
+ u64 cur_logical;
+
+ ASSERT(orig_logical >= full_stripe_start &&
+ orig_logical + orig_len <= full_stripe_start +
+ rbio->nr_data * rbio->stripe_len);
+
+ bio_list_add(&rbio->bio_list, orig_bio);
+ rbio->bio_list_bytes += orig_bio->bi_iter.bi_size;
+
+ /* Update the dbitmap. */
+ for (cur_logical = orig_logical; cur_logical < orig_logical + orig_len;
+ cur_logical += sectorsize) {
+ int bit = ((u32)(cur_logical - full_stripe_start) >>
+ fs_info->sectorsize_bits) % rbio->stripe_npages;
+
+ set_bit(bit, rbio->dbitmap);
+ }
+}
+
/*
* our main entry point for writes from the rest of the FS.
*/
@@ -1731,9 +1780,8 @@ int raid56_parity_write(struct btrfs_fs_
btrfs_put_bioc(bioc);
return PTR_ERR(rbio);
}
- bio_list_add(&rbio->bio_list, bio);
- rbio->bio_list_bytes = bio->bi_iter.bi_size;
rbio->operation = BTRFS_RBIO_WRITE;
+ rbio_add_bio(rbio, bio);

btrfs_bio_counter_inc_noblocked(fs_info);
rbio->generic_bio_cnt = 1;
@@ -2135,8 +2183,7 @@ int raid56_parity_recover(struct btrfs_f
}

rbio->operation = BTRFS_RBIO_READ_REBUILD;
- bio_list_add(&rbio->bio_list, bio);
- rbio->bio_list_bytes = bio->bi_iter.bi_size;
+ rbio_add_bio(rbio, bio);

rbio->faila = find_logical_bio_stripe(rbio, bio);
if (rbio->faila == -1) {


2022-08-19 17:39:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 08/14] x86/ftrace: Use alternative RET encoding

From: Peter Zijlstra <[email protected]>

commit 1f001e9da6bbf482311e45e48f53c2bd2179e59c upstream.

Use the return thunk in ftrace trampolines, if needed.

Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
[cascardo: use memcpy(text_gen_insn) as there is no __text_gen_insn]
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/ftrace.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -309,7 +309,7 @@ union ftrace_op_code_union {
} __attribute__((packed));
};

-#define RET_SIZE 1 + IS_ENABLED(CONFIG_SLS)
+#define RET_SIZE (IS_ENABLED(CONFIG_RETPOLINE) ? 5 : 1 + IS_ENABLED(CONFIG_SLS))

static unsigned long
create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size)
@@ -365,7 +365,12 @@ create_trampoline(struct ftrace_ops *ops
goto fail;

ip = trampoline + size;
- memcpy(ip, retq, RET_SIZE);
+
+ /* The trampoline ends with ret(q) */
+ if (cpu_feature_enabled(X86_FEATURE_RETHUNK))
+ memcpy(ip, text_gen_insn(JMP32_INSN_OPCODE, ip, &__x86_return_thunk), JMP32_INSN_SIZE);
+ else
+ memcpy(ip, retq, sizeof(retq));

/* No need to test direct calls on created trampolines */
if (ops->flags & FTRACE_OPS_FL_SAVE_REGS) {


2022-08-19 17:39:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 03/14] net_sched: cls_route: disallow handle of 0

From: Jamal Hadi Salim <[email protected]>

commit 02799571714dc5dd6948824b9d080b44a295f695 upstream.

Follows up on:
https://lore.kernel.org/all/[email protected]/

handle of 0 implies from/to of universe realm which is not very
sensible.

Lets see what this patch will do:
$sudo tc qdisc add dev $DEV root handle 1:0 prio

//lets manufacture a way to insert handle of 0
$sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 \
route to 0 from 0 classid 1:10 action ok

//gets rejected...
Error: handle of 0 is not valid.
We have an error talking to the kernel, -1

//lets create a legit entry..
sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 route from 10 \
classid 1:10 action ok

//what did the kernel insert?
$sudo tc filter ls dev $DEV parent 1:0
filter protocol ip pref 100 route chain 0
filter protocol ip pref 100 route chain 0 fh 0x000a8000 flowid 1:10 from 10
action order 1: gact action pass
random type none pass val 0
index 1 ref 1 bind 1

//Lets try to replace that legit entry with a handle of 0
$ sudo tc filter replace dev $DEV parent 1:0 protocol ip prio 100 \
handle 0x000a8000 route to 0 from 0 classid 1:10 action drop

Error: Replacing with handle of 0 is invalid.
We have an error talking to the kernel, -1

And last, lets run Cascardo's POC:
$ ./poc
0
0
-22
-22
-22

Signed-off-by: Jamal Hadi Salim <[email protected]>
Acked-by: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/cls_route.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -424,6 +424,11 @@ static int route4_set_parms(struct net *
return -EINVAL;
}

+ if (!nhandle) {
+ NL_SET_ERR_MSG(extack, "Replacing with handle of 0 is invalid");
+ return -EINVAL;
+ }
+
h1 = to_hash(nhandle);
b = rtnl_dereference(head->table[h1]);
if (!b) {
@@ -477,6 +482,11 @@ static int route4_change(struct net *net
int err;
bool new = true;

+ if (!handle) {
+ NL_SET_ERR_MSG(extack, "Creating with handle of 0 is invalid");
+ return -EINVAL;
+ }
+
if (opt == NULL)
return handle ? -EINVAL : 0;



2022-08-19 17:39:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 02/14] tee: add overflow check in register_shm_helper()

From: Jens Wiklander <[email protected]>

commit 573ae4f13f630d6660008f1974c0a8a29c30e18a upstream.

With special lengths supplied by user space, register_shm_helper() has
an integer overflow when calculating the number of pages covered by a
supplied user space memory region.

This causes internal_get_user_pages_fast() a helper function of
pin_user_pages_fast() to do a NULL pointer dereference:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
Modules linked in:
CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
pc : internal_get_user_pages_fast+0x474/0xa80
Call trace:
internal_get_user_pages_fast+0x474/0xa80
pin_user_pages_fast+0x24/0x4c
register_shm_helper+0x194/0x330
tee_shm_register_user_buf+0x78/0x120
tee_ioctl+0xd0/0x11a0
__arm64_sys_ioctl+0xa8/0xec
invoke_syscall+0x48/0x114

Fix this by adding an an explicit call to access_ok() in
tee_shm_register_user_buf() to catch an invalid user space address
early.

Fixes: 033ddf12bcf5 ("tee: add register user memory")
Cc: [email protected]
Reported-by: Nimish Mishra <[email protected]>
Reported-by: Anirban Chakraborty <[email protected]>
Reported-by: Debdeep Mukhopadhyay <[email protected]>
Suggested-by: Jerome Forissier <[email protected]>
Signed-off-by: Jens Wiklander <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tee/tee_shm.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -222,6 +222,9 @@ struct tee_shm *tee_shm_register(struct
goto err;
}

+ if (!access_ok((void __user *)addr, length))
+ return ERR_PTR(-EFAULT);
+
mutex_lock(&teedev->mutex);
shm->id = idr_alloc(&teedev->idr, shm, 1, 0, GFP_KERNEL);
mutex_unlock(&teedev->mutex);


2022-08-20 01:51:24

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/14] 5.15.62-rc1 review

On 8/19/22 9:40 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.62 release.
> There are 14 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 know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.62-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <[email protected]>

thanks,
-- Shuah

2022-08-20 08:31:44

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/14] 5.15.62-rc1 review

On Fri, 19 Aug 2022 at 21:11, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.15.62 release.
> There are 14 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 know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.62-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro's test farm.
Following regression found on s390.

> Naveen N. Rao <[email protected]>
> kexec_file: drop weak attribute from functions

The s390 defconfig build failed on stable-rc 5.15 with gcc-11 and clang.


arch/s390/kernel/machine_kexec_file.c:336:5: error: redefinition of
'arch_kexec_kernel_image_probe'
int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
^
include/linux/kexec.h:190:1: note: previous definition is here
arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
unsigned long buf_len)
^
1 error generated.


## Build
* kernel: 5.15.62-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: b79f9f8ea7ab2be6f724e8cde6db2a3fb057f62e
* git describe: v5.15.61-15-gb79f9f8ea7ab
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.61-15-gb79f9f8ea7ab

## Test Regressions (compared to v5.15.61)

* s390, build
- clang-13-defconfig
- clang-14-defconfig
- clang-nightly-defconfig
- gcc-10-defconfig
- gcc-11-defconfig
- gcc-9-defconfig

## No metric Regressions (compared to v5.15.61)

## No test Fixes (compared to v5.15.61)

## No metric Fixes (compared to v5.15.61)

## Test result summary
total: 140859, pass: 124026, fail: 701, skip: 15336, xfail: 796

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 314 total, 311 passed, 3 failed
* arm64: 77 total, 75 passed, 2 failed
* i386: 65 total, 59 passed, 6 failed
* mips: 50 total, 47 passed, 3 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 59 total, 56 passed, 3 failed
* riscv: 27 total, 27 passed, 0 failed
* s390: 26 total, 14 passed, 12 failed
* sh: 26 total, 24 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x86_64: 70 total, 68 passed, 2 failed

## Test suites summary
* fwts
* igt-gpu-tools
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* rcutorture
* ssuite
* v4l2-compliance
* vdso

--
Linaro LKFT
https://lkft.linaro.org

2022-08-20 10:07:04

by Bagas Sanjaya

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/14] 5.15.62-rc1 review

On Fri, Aug 19, 2022 at 05:40:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.62 release.
> There are 14 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 know.
>

Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and
powerpc (ps3_defconfig, GCC 12.1.0).

Tested-by: Bagas Sanjaya <[email protected]>

--
An old man doll... just what I always wanted! - Clara


Attachments:
(No filename) (538.00 B)
signature.asc (235.00 B)
Download all attachments

2022-08-20 10:55:01

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/14] 5.15.62-rc1 review

Hi Greg,

On Fri, Aug 19, 2022 at 05:40:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.62 release.
> There are 14 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 know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.

Build test (gcc version 11.3.1 20220819):
mips: 62 configs -> no failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> fails
xtensa allmodconfig -> no failure

Note:

s390 allmodconfig fails with:

arch/s390/kernel/machine_kexec_file.c:336:5: error: redefinition of 'arch_kexec_kernel_image_probe'
336 | int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/s390/kernel/machine_kexec_file.c:12:
./include/linux/kexec.h:190:1: note: previous definition of 'arch_kexec_kernel_image_probe' with type 'int(struct kimage *, void *, long unsigned int)'
190 | arch_kexec_kernel_image_probe(struct kimage *image, void *buf, unsigned long buf_len)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Caused by: 4dc6d49023a0 ("kexec_file: drop weak attribute from functions")


Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
mips: Booted on ci20 board. No regression. [2]

[1]. https://openqa.qa.codethink.co.uk/tests/1659
[2]. https://openqa.qa.codethink.co.uk/tests/1666

Tested-by: Sudip Mukherjee <[email protected]>

--
Regards
Sudip

2022-08-20 22:30:25

by Ron Economos

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/14] 5.15.62-rc1 review

On 8/19/22 8:40 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.62 release.
> There are 14 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 know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.62-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).

Tested-by: Ron Economos <[email protected]>

2022-08-21 01:03:09

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/14] 5.15.62-rc1 review

On Fri, Aug 19, 2022 at 05:40:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.62 release.
> There are 14 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 know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 159 pass: 157 fail: 2
Failed builds:
s390:defconfig
s390:allmodconfig
Qemu test results:
total: 470 pass: 465 fail: 5
Failed tests:
s390:defconfig:nolocktests:smp2:net,default:initrd
s390:defconfig:nolocktests:smp2:virtio-blk-ccw:net,virtio-net-pci:rootfs
s390:defconfig:nolocktests:smp2:scsi[virtio-ccw]:net,default:rootfs
s390:defconfig:nolocktests:virtio-pci:net,virtio-net-pci:rootfs
s390:defconfig:nolocktests:scsi[virtio-pci]:net,default:rootfs

This has been reported already, so I won't go into details.

Note that I did not get this e-mail, even though I am listed in Cc:.
I had to copy it from lore.kernel.org/stable.

Guenter

2022-08-21 07:03:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/14] 5.15.62-rc1 review

On Sat, Aug 20, 2022 at 01:57:05PM +0530, Naresh Kamboju wrote:
> On Fri, 19 Aug 2022 at 21:11, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.15.62 release.
> > There are 14 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 know.
> >
> > Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.62-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro's test farm.
> Following regression found on s390.
>
> > Naveen N. Rao <[email protected]>
> > kexec_file: drop weak attribute from functions
>
> The s390 defconfig build failed on stable-rc 5.15 with gcc-11 and clang.
>
>
> arch/s390/kernel/machine_kexec_file.c:336:5: error: redefinition of
> 'arch_kexec_kernel_image_probe'
> int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> ^
> include/linux/kexec.h:190:1: note: previous definition is here
> arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> unsigned long buf_len)
> ^
> 1 error generated.
>

argh, these kexec patches are such a pain. I'll go drop them from 5.15
now and push out a -rc2 that hopefully will fix this.

thanks,

greg k-h