2021-03-22 13:10:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 00/14] 4.4.263-rc1 review

This is the start of the stable review cycle for the 4.4.263 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 Wed, 24 Mar 2021 12:19:09 +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/v4.x/stable-review/patch-4.4.263-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-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Thomas Gleixner <[email protected]>
genirq: Disable interrupts for force threaded handlers

Shijie Luo <[email protected]>
ext4: fix potential error in ext4_do_update_inode

zhangyi (F) <[email protected]>
ext4: find old entry again if failed to rename whiteout

Thomas Gleixner <[email protected]>
x86/ioapic: Ignore IRQ2 again

Tyrel Datwyler <[email protected]>
PCI: rpadlpar: Fix potential drc_name corruption in store functions

Jim Lin <[email protected]>
usb: gadget: configfs: Fix KASAN use-after-free

Macpaul Lin <[email protected]>
USB: replace hardcode maximum usb string length by definition

Dan Carpenter <[email protected]>
scsi: lpfc: Fix some error codes in debugfs

Joe Korty <[email protected]>
NFSD: Repair misuse of sv_lock in 5.10.16-rt30.

Filipe Manana <[email protected]>
btrfs: fix race when cloning extent buffer during rewind of an old root

Gwendal Grignou <[email protected]>
platform/chrome: cros_ec_dev - Fix security issue

Jan Kara <[email protected]>
ext4: check journal inode extents more carefully

Jan Kara <[email protected]>
ext4: don't allow overlapping system zones

Jan Kara <[email protected]>
ext4: handle error of ext4_setup_system_zone() on remount


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

Diffstat:

Makefile | 4 +-
arch/x86/kernel/apic/io_apic.c | 10 +++++
drivers/pci/hotplug/rpadlpar_sysfs.c | 14 +++----
drivers/platform/chrome/cros_ec_dev.c | 4 ++
drivers/platform/chrome/cros_ec_proto.c | 4 +-
drivers/scsi/lpfc/lpfc_debugfs.c | 4 +-
drivers/usb/gadget/composite.c | 4 +-
drivers/usb/gadget/configfs.c | 16 +++++---
drivers/usb/gadget/usbstring.c | 4 +-
fs/btrfs/ctree.c | 2 +
fs/ext4/block_validity.c | 71 +++++++++++++++------------------
fs/ext4/ext4.h | 6 +--
fs/ext4/extents.c | 16 +++-----
fs/ext4/indirect.c | 6 +--
fs/ext4/inode.c | 13 +++---
fs/ext4/mballoc.c | 4 +-
fs/ext4/namei.c | 29 +++++++++++++-
fs/ext4/super.c | 5 ++-
include/linux/mfd/cros_ec.h | 6 ++-
include/uapi/linux/usb/ch9.h | 3 ++
kernel/irq/manage.c | 4 ++
net/sunrpc/svc_xprt.c | 4 +-
22 files changed, 139 insertions(+), 94 deletions(-)



2021-03-22 13:10:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 12/14] ext4: find old entry again if failed to rename whiteout

From: zhangyi (F) <[email protected]>

commit b7ff91fd030dc9d72ed91b1aab36e445a003af4f upstream.

If we failed to add new entry on rename whiteout, we cannot reset the
old->de entry directly, because the old->de could have moved from under
us during make indexed dir. So find the old entry again before reset is
needed, otherwise it may corrupt the filesystem as below.

/dev/sda: Entry '00000001' in ??? (12) has deleted/unused inode 15. CLEARED.
/dev/sda: Unattached inode 75
/dev/sda: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

Fixes: 6b4b8e6b4ad ("ext4: fix bug for rename with RENAME_WHITEOUT")
Cc: [email protected]
Signed-off-by: zhangyi (F) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext4/namei.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)

--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3375,6 +3375,31 @@ static int ext4_setent(handle_t *handle,
return 0;
}

+static void ext4_resetent(handle_t *handle, struct ext4_renament *ent,
+ unsigned ino, unsigned file_type)
+{
+ struct ext4_renament old = *ent;
+ int retval = 0;
+
+ /*
+ * old->de could have moved from under us during make indexed dir,
+ * so the old->de may no longer valid and need to find it again
+ * before reset old inode info.
+ */
+ old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL);
+ if (IS_ERR(old.bh))
+ retval = PTR_ERR(old.bh);
+ if (!old.bh)
+ retval = -ENOENT;
+ if (retval) {
+ ext4_std_error(old.dir->i_sb, retval);
+ return;
+ }
+
+ ext4_setent(handle, &old, ino, file_type);
+ brelse(old.bh);
+}
+
static int ext4_find_delete_entry(handle_t *handle, struct inode *dir,
const struct qstr *d_name)
{
@@ -3674,8 +3699,8 @@ static int ext4_rename(struct inode *old
end_rename:
if (whiteout) {
if (retval) {
- ext4_setent(handle, &old,
- old.inode->i_ino, old_file_type);
+ ext4_resetent(handle, &old,
+ old.inode->i_ino, old_file_type);
drop_nlink(whiteout);
}
unlock_new_inode(whiteout);


2021-03-22 13:15:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 01/14] ext4: handle error of ext4_setup_system_zone() on remount

From: Jan Kara <[email protected]>

commit d176b1f62f242ab259ff665a26fbac69db1aecba upstream.

ext4_setup_system_zone() can fail. Handle the failure in ext4_remount().

Reviewed-by: Lukas Czerner <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext4/super.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4968,7 +4968,10 @@ static int ext4_remount(struct super_blo
ext4_register_li_request(sb, first_not_zeroed);
}

- ext4_setup_system_zone(sb);
+ err = ext4_setup_system_zone(sb);
+ if (err)
+ goto restore_opts;
+
if (sbi->s_journal == NULL && !(old_sb_flags & MS_RDONLY))
ext4_commit_super(sb, 1);



2021-03-22 13:15:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 02/14] ext4: dont allow overlapping system zones

From: Jan Kara <[email protected]>

commit bf9a379d0980e7413d94cb18dac73db2bfc5f470 upstream.

Currently, add_system_zone() just silently merges two added system zones
that overlap. However the overlap should not happen and it generally
suggests that some unrelated metadata overlap which indicates the fs is
corrupted. We should have caught such problems earlier (e.g. in
ext4_check_descriptors()) but add this check as another line of defense.
In later patch we also use this for stricter checking of journal inode
extent tree.

Reviewed-by: Lukas Czerner <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext4/block_validity.c | 34 ++++++++++++----------------------
1 file changed, 12 insertions(+), 22 deletions(-)

--- a/fs/ext4/block_validity.c
+++ b/fs/ext4/block_validity.c
@@ -57,7 +57,7 @@ static int add_system_zone(struct ext4_s
ext4_fsblk_t start_blk,
unsigned int count)
{
- struct ext4_system_zone *new_entry = NULL, *entry;
+ struct ext4_system_zone *new_entry, *entry;
struct rb_node **n = &sbi->system_blks.rb_node, *node;
struct rb_node *parent = NULL, *new_node = NULL;

@@ -68,30 +68,20 @@ static int add_system_zone(struct ext4_s
n = &(*n)->rb_left;
else if (start_blk >= (entry->start_blk + entry->count))
n = &(*n)->rb_right;
- else {
- if (start_blk + count > (entry->start_blk +
- entry->count))
- entry->count = (start_blk + count -
- entry->start_blk);
- new_node = *n;
- new_entry = rb_entry(new_node, struct ext4_system_zone,
- node);
- break;
- }
+ else /* Unexpected overlap of system zones. */
+ return -EFSCORRUPTED;
}

- if (!new_entry) {
- new_entry = kmem_cache_alloc(ext4_system_zone_cachep,
- GFP_KERNEL);
- if (!new_entry)
- return -ENOMEM;
- new_entry->start_blk = start_blk;
- new_entry->count = count;
- new_node = &new_entry->node;
+ new_entry = kmem_cache_alloc(ext4_system_zone_cachep,
+ GFP_KERNEL);
+ if (!new_entry)
+ return -ENOMEM;
+ new_entry->start_blk = start_blk;
+ new_entry->count = count;
+ new_node = &new_entry->node;

- rb_link_node(new_node, parent, n);
- rb_insert_color(new_node, &sbi->system_blks);
- }
+ rb_link_node(new_node, parent, n);
+ rb_insert_color(new_node, &sbi->system_blks);

/* Can we merge to the left? */
node = rb_prev(new_node);


2021-03-22 20:18:54

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/14] 4.4.263-rc1 review

Hi!

> This is the start of the stable review cycle for the 4.4.263 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.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel


--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (671.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-03-22 21:59:51

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/14] 4.4.263-rc1 review

On Mon, Mar 22, 2021 at 01:28:54PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.263 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 Wed, 24 Mar 2021 12:19:09 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 163 pass: 163 fail: 0
Qemu test results:
total: 329 pass: 329 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter

2021-03-23 13:42:41

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/14] 4.4.263-rc1 review

On Mon, 22 Mar 2021 at 18:24, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.4.263 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 Wed, 24 Mar 2021 12:19:09 +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/v4.x/stable-review/patch-4.4.263-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-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

Summary
------------------------------------------------------------------------

kernel: 4.4.263-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 769f344ebed2d7d9adc324015195b8c3fda886da
git describe: v4.4.262-15-g769f344ebed2
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.262-15-g769f344ebed2

No regressions (compared to build v4.4.262)

No fixes (compared to build v4.4.262)


Ran 36066 total tests in the following environments and test suites.

Environments
--------------
- arm
- arm64
- i386
- juno-64k_page_size
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- qemu-arm64-kasan
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- sparc
- x15 - arm
- x86_64
- x86-kasan
- x86_64

Test Suites
-----------
* build
* linux-log-parser
* libhugetlbfs
* ltp-commands-tests
* ltp-containers-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-tracing-tests
* network-basic-tests
* ltp-cap_bounds-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-sched-tests
* ltp-syscalls-tests
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* kvm-unit-tests
* ltp-open-posix-tests
* perf
* v4l2-compliance
* install-android-platform-tools-r2600
* kselftest-kvm
* kselftest-vm
* fwts

Summary
------------------------------------------------------------------------

kernel: 4.4.263-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.263-rc1-hikey-20210322-970
git commit: cdbe5973893696eb29efb23b75953efd2f7edf4d
git describe: 4.4.263-rc1-hikey-20210322-970
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.263-rc1-hikey-20210322-970

No regressions (compared to 4.4.263-rc1-hikey-20210319-968)

No fixes (compared to 4.4.263-rc1-hikey-20210319-968)

Ran 1863 total tests in the following environments and test suites.

Environments
--------------
- hi6220-hikey - arm64

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance

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