2021-05-05 12:09:03

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 00/15] 4.19.190-rc1 review

This is the start of the stable review cycle for the 4.19.190 release.
There are 15 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 Fri, 07 May 2021 12:04:54 +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.19.190-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.19.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Miklos Szeredi <[email protected]>
ovl: allow upperdir inside lowerdir

Mark Pearson <[email protected]>
platform/x86: thinkpad_acpi: Correct thermal sensor allocation

Shengjiu Wang <[email protected]>
ASoC: ak5558: Add MODULE_DEVICE_TABLE

Shengjiu Wang <[email protected]>
ASoC: ak4458: Add MODULE_DEVICE_TABLE

Chris Chiu <[email protected]>
USB: Add reset-resume quirk for WD19's Realtek Hub

Kai-Heng Feng <[email protected]>
USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet

Takashi Iwai <[email protected]>
ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX

Jiri Kosina <[email protected]>
iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_gen2_enqueue_hcmd()

Daniel Borkmann <[email protected]>
bpf: Fix masking negation logic upon negative dst register

Romain Naour <[email protected]>
mips: Do not include hi and lo in clobber list for R6

Jiri Kosina <[email protected]>
iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()

Phillip Potter <[email protected]>
net: usb: ax88179_178a: initialize local variables before use

Rafael J. Wysocki <[email protected]>
ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade()

Rafael J. Wysocki <[email protected]>
ACPI: tables: x86: Reserve memory occupied by ACPI tables

Gao Xiang <[email protected]>
erofs: fix extended inode could cross boundary


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

Diffstat:

Makefile | 4 +-
arch/mips/vdso/gettimeofday.c | 14 ++-
arch/x86/kernel/acpi/boot.c | 25 ++--
arch/x86/kernel/setup.c | 7 +-
drivers/acpi/tables.c | 42 ++++++-
drivers/net/usb/ax88179_178a.c | 4 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 7 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 7 +-
drivers/platform/x86/thinkpad_acpi.c | 31 +++--
drivers/staging/erofs/inode.c | 135 ++++++++++++++--------
drivers/usb/core/quirks.c | 4 +
fs/overlayfs/super.c | 12 +-
include/linux/acpi.h | 9 +-
kernel/bpf/verifier.c | 12 +-
sound/soc/codecs/ak4458.c | 1 +
sound/soc/codecs/ak5558.c | 1 +
sound/usb/quirks-table.h | 10 ++
17 files changed, 224 insertions(+), 101 deletions(-)



2021-05-05 12:09:20

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 04/15] net: usb: ax88179_178a: initialize local variables before use

From: Phillip Potter <[email protected]>

commit bd78980be1a68d14524c51c4b4170782fada622b upstream.

Use memset to initialize local array in drivers/net/usb/ax88179_178a.c, and
also set a local u16 and u32 variable to 0. Fixes a KMSAN found uninit-value bug
reported by syzbot at:
https://syzkaller.appspot.com/bug?id=00371c73c72f72487c1d0bfe0cc9d00de339d5aa

Reported-by: [email protected]
Signed-off-by: Phillip Potter <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/ax88179_178a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -307,12 +307,12 @@ static int ax88179_read_cmd(struct usbne
int ret;

if (2 == size) {
- u16 buf;
+ u16 buf = 0;
ret = __ax88179_read_cmd(dev, cmd, value, index, size, &buf, 0);
le16_to_cpus(&buf);
*((u16 *)data) = buf;
} else if (4 == size) {
- u32 buf;
+ u32 buf = 0;
ret = __ax88179_read_cmd(dev, cmd, value, index, size, &buf, 0);
le32_to_cpus(&buf);
*((u32 *)data) = buf;


2021-05-05 12:09:34

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 07/15] bpf: Fix masking negation logic upon negative dst register

From: Daniel Borkmann <[email protected]>

commit b9b34ddbe2076ade359cd5ce7537d5ed019e9807 upstream.

The negation logic for the case where the off_reg is sitting in the
dst register is not correct given then we cannot just invert the add
to a sub or vice versa. As a fix, perform the final bitwise and-op
unconditionally into AX from the off_reg, then move the pointer from
the src to dst and finally use AX as the source for the original
pointer arithmetic operation such that the inversion yields a correct
result. The single non-AX mov in between is possible given constant
blinding is retaining it as it's not an immediate based operation.

Fixes: 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic")
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Piotr Krysiuk <[email protected]>
Reviewed-by: Piotr Krysiuk <[email protected]>
Reviewed-by: John Fastabend <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/bpf/verifier.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)

--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -6099,14 +6099,10 @@ static int fixup_bpf_calls(struct bpf_ve
*patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg);
*patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0);
*patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63);
- if (issrc) {
- *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX,
- off_reg);
- insn->src_reg = BPF_REG_AX;
- } else {
- *patch++ = BPF_ALU64_REG(BPF_AND, off_reg,
- BPF_REG_AX);
- }
+ *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, off_reg);
+ if (!issrc)
+ *patch++ = BPF_MOV64_REG(insn->dst_reg, insn->src_reg);
+ insn->src_reg = BPF_REG_AX;
if (isneg)
insn->code = insn->code == code_add ?
code_sub : code_add;


2021-05-05 12:09:42

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 11/15] USB: Add reset-resume quirk for WD19s Realtek Hub

From: Chris Chiu <[email protected]>

commit ca91fd8c7643d93bfc18a6fec1a0d3972a46a18a upstream.

Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

Information of this hub:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5
D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=5487 Rev= 1.47
S: Manufacturer=Dell Inc.
S: Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms

The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the specified port of the hub. The port
seems to be in an unknown state so the hub_activate during resume
fails the hub_port_status, then the hub will fail to work.

The quirky hub needs the reset-resume quirk to function correctly.

Acked-by: Alan Stern <[email protected]>
Signed-off-by: Chris Chiu <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/quirks.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -406,6 +406,7 @@ static const struct usb_device_id usb_qu

/* Realtek hub in Dell WD19 (Type-C) */
{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+ { USB_DEVICE(0x0bda, 0x5487), .driver_info = USB_QUIRK_RESET_RESUME },

/* Generic RTL8153 based ethernet adapters */
{ USB_DEVICE(0x0bda, 0x8153), .driver_info = USB_QUIRK_NO_LPM },


2021-05-05 14:11:54

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 03/15] ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade()

From: Rafael J. Wysocki <[email protected]>

commit 6998a8800d73116187aad542391ce3b2dd0f9e30 upstream.

Commit 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by
ACPI tables") attempted to address an issue with reserving the memory
occupied by ACPI tables, but it broke the initrd-based table override
mechanism relied on by multiple users.

To restore the initrd-based ACPI table override functionality, move
the acpi_boot_table_init() invocation in setup_arch() on x86 after
the acpi_table_upgrade() one.

Fixes: 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by ACPI tables")
Reported-by: Hans de Goede <[email protected]>
Tested-by: Hans de Goede <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Cc: George Kennedy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/setup.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1097,9 +1097,6 @@ void __init setup_arch(char **cmdline_p)

cleanup_highmap();

- /* Look for ACPI tables and reserve memory occupied by them. */
- acpi_boot_table_init();
-
memblock_set_current_limit(ISA_END_ADDRESS);
e820__memblock_setup();

@@ -1179,6 +1176,8 @@ void __init setup_arch(char **cmdline_p)
reserve_initrd();

acpi_table_upgrade();
+ /* Look for ACPI tables and reserve memory occupied by them. */
+ acpi_boot_table_init();

vsmp_init();



2021-05-05 14:11:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 02/15] ACPI: tables: x86: Reserve memory occupied by ACPI tables

From: Rafael J. Wysocki <[email protected]>

commit 1a1c130ab7575498eed5bcf7220037ae09cd1f8a upstream.

The following problem has been reported by George Kennedy:

Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail
in __free_pages_core()") the following use after free occurs
intermittently when ACPI tables are accessed.

BUG: KASAN: use-after-free in ibft_init+0x134/0xc49
Read of size 4 at addr ffff8880be453004 by task swapper/0/1
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1-7a7fd0d #1
Call Trace:
dump_stack+0xf6/0x158
print_address_description.constprop.9+0x41/0x60
kasan_report.cold.14+0x7b/0xd4
__asan_report_load_n_noabort+0xf/0x20
ibft_init+0x134/0xc49
do_one_initcall+0xc4/0x3e0
kernel_init_freeable+0x5af/0x66b
kernel_init+0x16/0x1d0
ret_from_fork+0x22/0x30

ACPI tables mapped via kmap() do not have their mapped pages
reserved and the pages can be "stolen" by the buddy allocator.

Apparently, on the affected system, the ACPI table in question is
not located in "reserved" memory, like ACPI NVS or ACPI Data, that
will not be used by the buddy allocator, so the memory occupied by
that table has to be explicitly reserved to prevent the buddy
allocator from using it.

In order to address this problem, rearrange the initialization of the
ACPI tables on x86 to locate the initial tables earlier and reserve
the memory occupied by them.

The other architectures using ACPI should not be affected by this
change.

Link: https://lore.kernel.org/linux-acpi/[email protected]/
Reported-by: George Kennedy <[email protected]>
Tested-by: George Kennedy <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Mike Rapoport <[email protected]>
Cc: 5.10+ <[email protected]> # 5.10+
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/acpi/boot.c | 25 ++++++++++++-------------
arch/x86/kernel/setup.c | 8 +++-----
drivers/acpi/tables.c | 42 +++++++++++++++++++++++++++++++++++++++---
include/linux/acpi.h | 9 ++++++++-
4 files changed, 62 insertions(+), 22 deletions(-)

--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1565,10 +1565,18 @@ void __init acpi_boot_table_init(void)
/*
* Initialize the ACPI boot-time table parser.
*/
- if (acpi_table_init()) {
+ if (acpi_locate_initial_tables())
disable_acpi();
- return;
- }
+ else
+ acpi_reserve_initial_tables();
+}
+
+int __init early_acpi_boot_init(void)
+{
+ if (acpi_disabled)
+ return 1;
+
+ acpi_table_init_complete();

acpi_table_parse(ACPI_SIG_BOOT, acpi_parse_sbf);

@@ -1581,18 +1589,9 @@ void __init acpi_boot_table_init(void)
} else {
printk(KERN_WARNING PREFIX "Disabling ACPI support\n");
disable_acpi();
- return;
+ return 1;
}
}
-}
-
-int __init early_acpi_boot_init(void)
-{
- /*
- * If acpi_disabled, bail out
- */
- if (acpi_disabled)
- return 1;

/*
* Process the Multiple APIC Description Table (MADT), if present
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1097,6 +1097,9 @@ void __init setup_arch(char **cmdline_p)

cleanup_highmap();

+ /* Look for ACPI tables and reserve memory occupied by them. */
+ acpi_boot_table_init();
+
memblock_set_current_limit(ISA_END_ADDRESS);
e820__memblock_setup();

@@ -1183,11 +1186,6 @@ void __init setup_arch(char **cmdline_p)

early_platform_quirks();

- /*
- * Parse the ACPI tables for possible boot-time SMP configuration.
- */
- acpi_boot_table_init();
-
early_acpi_boot_init();

initmem_init();
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -732,7 +732,7 @@ acpi_os_table_override(struct acpi_table
}

/*
- * acpi_table_init()
+ * acpi_locate_initial_tables()
*
* find RSDP, find and checksum SDT/XSDT.
* checksum all tables, print SDT/XSDT
@@ -740,7 +740,7 @@ acpi_os_table_override(struct acpi_table
* result: sdt_entry[] is initialized
*/

-int __init acpi_table_init(void)
+int __init acpi_locate_initial_tables(void)
{
acpi_status status;

@@ -755,9 +755,45 @@ int __init acpi_table_init(void)
status = acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
if (ACPI_FAILURE(status))
return -EINVAL;
- acpi_table_initrd_scan();

+ return 0;
+}
+
+void __init acpi_reserve_initial_tables(void)
+{
+ int i;
+
+ for (i = 0; i < ACPI_MAX_TABLES; i++) {
+ struct acpi_table_desc *table_desc = &initial_tables[i];
+ u64 start = table_desc->address;
+ u64 size = table_desc->length;
+
+ if (!start || !size)
+ break;
+
+ pr_info("Reserving %4s table memory at [mem 0x%llx-0x%llx]\n",
+ table_desc->signature.ascii, start, start + size - 1);
+
+ memblock_reserve(start, size);
+ }
+}
+
+void __init acpi_table_init_complete(void)
+{
+ acpi_table_initrd_scan();
check_multiple_madt();
+}
+
+int __init acpi_table_init(void)
+{
+ int ret;
+
+ ret = acpi_locate_initial_tables();
+ if (ret)
+ return ret;
+
+ acpi_table_init_complete();
+
return 0;
}

--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -230,10 +230,14 @@ void __iomem *__acpi_map_table(unsigned
void __acpi_unmap_table(void __iomem *map, unsigned long size);
int early_acpi_boot_init(void);
int acpi_boot_init (void);
+void acpi_boot_table_prepare (void);
void acpi_boot_table_init (void);
int acpi_mps_check (void);
int acpi_numa_init (void);

+int acpi_locate_initial_tables (void);
+void acpi_reserve_initial_tables (void);
+void acpi_table_init_complete (void);
int acpi_table_init (void);
int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
int __init acpi_table_parse_entries(char *id, unsigned long table_size,
@@ -734,9 +738,12 @@ static inline int acpi_boot_init(void)
return 0;
}

+static inline void acpi_boot_table_prepare(void)
+{
+}
+
static inline void acpi_boot_table_init(void)
{
- return;
}

static inline int acpi_mps_check(void)


2021-05-05 14:11:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 01/15] erofs: fix extended inode could cross boundary

From: Gao Xiang <[email protected]>

commit 0dcd3c94e02438f4a571690e26f4ee997524102a upstream.

Each ondisk inode should be aligned with inode slot boundary
(32-byte alignment) because of nid calculation formula, so all
compact inodes (32 byte) cannot across page boundary. However,
extended inode is now 64-byte form, which can across page boundary
in principle if the location is specified on purpose, although
it's hard to be generated by mkfs due to the allocation policy
and rarely used by Android use case now mainly for > 4GiB files.

For now, only two fields `i_ctime_nsec` and `i_nlink' couldn't
be read from disk properly and cause out-of-bound memory read
with random value.

Let's fix now.

Fixes: 431339ba9042 ("staging: erofs: add inode operations")
Cc: <[email protected]> # 4.19+
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Chao Yu <[email protected]>
Signed-off-by: Gao Xiang <[email protected]>
[ Gao Xiang: resolve non-trivial conflicts for latest 4.19.y. ]
Signed-off-by: Gao Xiang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/erofs/inode.c | 135 ++++++++++++++++++++++++++++--------------
1 file changed, 90 insertions(+), 45 deletions(-)

--- a/drivers/staging/erofs/inode.c
+++ b/drivers/staging/erofs/inode.c
@@ -14,26 +14,78 @@

#include <trace/events/erofs.h>

-/* no locking */
-static int read_inode(struct inode *inode, void *data)
+/*
+ * if inode is successfully read, return its inode page (or sometimes
+ * the inode payload page if it's an extended inode) in order to fill
+ * inline data if possible.
+ */
+static struct page *read_inode(struct inode *inode, unsigned int *ofs)
{
+ struct super_block *sb = inode->i_sb;
+ struct erofs_sb_info *sbi = EROFS_SB(sb);
struct erofs_vnode *vi = EROFS_V(inode);
- struct erofs_inode_v1 *v1 = data;
- const unsigned advise = le16_to_cpu(v1->i_advise);
+ const erofs_off_t inode_loc = iloc(sbi, vi->nid);
+ erofs_blk_t blkaddr;
+ struct page *page;
+ struct erofs_inode_v1 *v1;
+ struct erofs_inode_v2 *v2, *copied = NULL;
+ unsigned int ifmt;
+ int err;
+
+ blkaddr = erofs_blknr(inode_loc);
+ *ofs = erofs_blkoff(inode_loc);
+
+ debugln("%s, reading inode nid %llu at %u of blkaddr %u",
+ __func__, vi->nid, *ofs, blkaddr);

- vi->data_mapping_mode = __inode_data_mapping(advise);
+ page = erofs_get_meta_page(sb, blkaddr, false);
+ if (IS_ERR(page)) {
+ errln("failed to get inode (nid: %llu) page, err %ld",
+ vi->nid, PTR_ERR(page));
+ return page;
+ }
+
+ v1 = page_address(page) + *ofs;
+ ifmt = le16_to_cpu(v1->i_advise);

+ vi->data_mapping_mode = __inode_data_mapping(ifmt);
if (unlikely(vi->data_mapping_mode >= EROFS_INODE_LAYOUT_MAX)) {
errln("unknown data mapping mode %u of nid %llu",
vi->data_mapping_mode, vi->nid);
- DBG_BUGON(1);
- return -EIO;
+ err = -EOPNOTSUPP;
+ goto err_out;
}

- if (__inode_version(advise) == EROFS_INODE_LAYOUT_V2) {
- struct erofs_inode_v2 *v2 = data;
-
+ switch (__inode_version(ifmt)) {
+ case EROFS_INODE_LAYOUT_V2:
vi->inode_isize = sizeof(struct erofs_inode_v2);
+ /* check if the inode acrosses page boundary */
+ if (*ofs + vi->inode_isize <= PAGE_SIZE) {
+ *ofs += vi->inode_isize;
+ v2 = (struct erofs_inode_v2 *)v1;
+ } else {
+ const unsigned int gotten = PAGE_SIZE - *ofs;
+
+ copied = kmalloc(vi->inode_isize, GFP_NOFS);
+ if (!copied) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+ memcpy(copied, v1, gotten);
+ unlock_page(page);
+ put_page(page);
+
+ page = erofs_get_meta_page(sb, blkaddr + 1, false);
+ if (IS_ERR(page)) {
+ errln("failed to get inode payload page (nid: %llu), err %ld",
+ vi->nid, PTR_ERR(page));
+ kfree(copied);
+ return page;
+ }
+ *ofs = vi->inode_isize - gotten;
+ memcpy((u8 *)copied + gotten, page_address(page), *ofs);
+ v2 = copied;
+ }
vi->xattr_isize = ondisk_xattr_ibody_size(v2->i_xattr_icount);

inode->i_mode = le16_to_cpu(v2->i_mode);
@@ -46,7 +98,7 @@ static int read_inode(struct inode *inod
} else if (S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) {
inode->i_rdev = 0;
} else {
- return -EIO;
+ goto bogusimode;
}

i_uid_write(inode, le32_to_cpu(v2->i_uid));
@@ -58,10 +110,11 @@ static int read_inode(struct inode *inod
inode->i_ctime.tv_nsec = le32_to_cpu(v2->i_ctime_nsec);

inode->i_size = le64_to_cpu(v2->i_size);
- } else if (__inode_version(advise) == EROFS_INODE_LAYOUT_V1) {
- struct erofs_sb_info *sbi = EROFS_SB(inode->i_sb);
-
+ kfree(copied);
+ break;
+ case EROFS_INODE_LAYOUT_V1:
vi->inode_isize = sizeof(struct erofs_inode_v1);
+ *ofs += vi->inode_isize;
vi->xattr_isize = ondisk_xattr_ibody_size(v1->i_xattr_icount);

inode->i_mode = le16_to_cpu(v1->i_mode);
@@ -74,7 +127,7 @@ static int read_inode(struct inode *inod
} else if (S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) {
inode->i_rdev = 0;
} else {
- return -EIO;
+ goto bogusimode;
}

i_uid_write(inode, le16_to_cpu(v1->i_uid));
@@ -86,11 +139,12 @@ static int read_inode(struct inode *inod
inode->i_ctime.tv_nsec = sbi->build_time_nsec;

inode->i_size = le32_to_cpu(v1->i_size);
- } else {
+ break;
+ default:
errln("unsupported on-disk inode version %u of nid %llu",
- __inode_version(advise), vi->nid);
- DBG_BUGON(1);
- return -EIO;
+ __inode_version(ifmt), vi->nid);
+ err = -EOPNOTSUPP;
+ goto err_out;
}

inode->i_mtime.tv_sec = inode->i_ctime.tv_sec;
@@ -100,7 +154,16 @@ static int read_inode(struct inode *inod

/* measure inode.i_blocks as the generic filesystem */
inode->i_blocks = ((inode->i_size - 1) >> 9) + 1;
- return 0;
+ return page;
+bogusimode:
+ errln("bogus i_mode (%o) @ nid %llu", inode->i_mode, vi->nid);
+ err = -EIO;
+err_out:
+ DBG_BUGON(1);
+ kfree(copied);
+ unlock_page(page);
+ put_page(page);
+ return ERR_PTR(err);
}

/*
@@ -132,7 +195,7 @@ static int fill_inline_data(struct inode
if (unlikely(lnk == NULL))
return -ENOMEM;

- m_pofs += vi->inode_isize + vi->xattr_isize;
+ m_pofs += vi->xattr_isize;

/* inline symlink data shouldn't across page boundary as well */
if (unlikely(m_pofs + inode->i_size > PAGE_SIZE)) {
@@ -153,35 +216,17 @@ static int fill_inline_data(struct inode

static int fill_inode(struct inode *inode, int isdir)
{
- struct erofs_sb_info *sbi = EROFS_SB(inode->i_sb);
- struct erofs_vnode *vi = EROFS_V(inode);
struct page *page;
- void *data;
- int err;
- erofs_blk_t blkaddr;
- unsigned ofs;
+ unsigned int ofs;
+ int err = 0;

trace_erofs_fill_inode(inode, isdir);

- blkaddr = erofs_blknr(iloc(sbi, vi->nid));
- ofs = erofs_blkoff(iloc(sbi, vi->nid));
-
- debugln("%s, reading inode nid %llu at %u of blkaddr %u",
- __func__, vi->nid, ofs, blkaddr);
-
- page = erofs_get_meta_page(inode->i_sb, blkaddr, isdir);
-
+ /* read inode base data from disk */
+ page = read_inode(inode, &ofs);
if (IS_ERR(page)) {
- errln("failed to get inode (nid: %llu) page, err %ld",
- vi->nid, PTR_ERR(page));
return PTR_ERR(page);
- }
-
- DBG_BUGON(!PageUptodate(page));
- data = page_address(page);
-
- err = read_inode(inode, data + ofs);
- if (!err) {
+ } else {
/* setup the new inode */
if (S_ISREG(inode->i_mode)) {
#ifdef CONFIG_EROFS_FS_XATTR
@@ -229,7 +274,7 @@ static int fill_inode(struct inode *inod
inode->i_mapping->a_ops = &erofs_raw_access_aops;

/* fill last page if inline data is available */
- fill_inline_data(inode, data, ofs);
+ fill_inline_data(inode, page_address(page), ofs);
}

out_unlock:


2021-05-05 21:24:23

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review

On 5/5/21 8:05 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.190 release.
> There are 15 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 Fri, 07 May 2021 12:04:54 +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.19.190-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.19.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

2021-05-06 01:49:24

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review

On Wed, May 05, 2021 at 02:05:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.190 release.
> There are 15 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 Fri, 07 May 2021 12:04:54 +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.19.190-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 4.19.190-rc1
>
> Miklos Szeredi <[email protected]>
> ovl: allow upperdir inside lowerdir
>
> Mark Pearson <[email protected]>
> platform/x86: thinkpad_acpi: Correct thermal sensor allocation
>
> Shengjiu Wang <[email protected]>
> ASoC: ak5558: Add MODULE_DEVICE_TABLE
>
> Shengjiu Wang <[email protected]>
> ASoC: ak4458: Add MODULE_DEVICE_TABLE
>
Wait, this also has the double commit. Can you please remove the bad one ?

Thanks,
Guenter

2021-05-06 02:04:21

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review

On Wed, May 05, 2021 at 06:47:43PM -0700, Guenter Roeck wrote:
> On Wed, May 05, 2021 at 02:05:05PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.190 release.
> > There are 15 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 Fri, 07 May 2021 12:04:54 +0000.
> > Anything received after that time might be too late.
> >
[ ... ]
> >
> > Shengjiu Wang <[email protected]>
> > ASoC: ak5558: Add MODULE_DEVICE_TABLE
> >
> > Shengjiu Wang <[email protected]>
> > ASoC: ak4458: Add MODULE_DEVICE_TABLE
> >
> Wait, this also has the double commit. Can you please remove the bad one ?
>
Actually, both need to be removed because they are already in the tree:

$ git describe
v4.19.189-16-g5a3ba2f90f87
$ git log --oneline v4.19.. sound/soc/codecs/ak4458.c sound/soc/codecs/ak5558.c
e32ee6f6fbcd ASoC: ak5558: Add MODULE_DEVICE_TABLE
5d0fe4839d63 ASoC: ak4458: Add MODULE_DEVICE_TABLE
04bb225a4824 ASoC: ak5558: Add MODULE_DEVICE_TABLE
25a09f4aad56 ASoC: ak4458: Add MODULE_DEVICE_TABLE
3f8d3c9506a5 ASoC: ak4458: rstn_control - return a non-zero on error only
4c31b4b4ba65 ASoC: ak4458: add return value for ak4458_probe

This applies to all branches.

Thanks,
Guenter

2021-05-06 02:11:12

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review

On Wed, May 05, 2021 at 02:05:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.190 release.
> There are 15 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 Fri, 07 May 2021 12:04:54 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 423 pass: 423 fail: 0

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

Guenter

2021-05-06 10:11:16

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review

Hi Greg,

On Wed, May 05, 2021 at 02:05:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.190 release.
> There are 15 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 Fri, 07 May 2021 12:04:54 +0000.
> Anything received after that time might be too late.

Build test:
mips (gcc version 11.1.1 20210430): 63 configs -> no failure
arm (gcc version 11.1.1 20210430): 116 configs -> no new failure
x86_64 (gcc version 10.2.1 20210110): 2 configs -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression.


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

--
Regards
Sudip

2021-05-06 11:46:59

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review

On Wed, 5 May 2021 at 17:35, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.190 release.
> There are 15 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 Fri, 07 May 2021 12:04:54 +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.19.190-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.19.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]>

## Build
* kernel: 4.19.190-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.19.y
* git commit: 5a3ba2f90f8789162a03e07a37224bab4c643d1d
* git describe: v4.19.189-16-g5a3ba2f90f87
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.189-16-g5a3ba2f90f87

## No regressions (compared to v4.19.189-2-g1bd8f1c8ad2f)

## No fixes (compared to v4.19.189-2-g1bd8f1c8ad2f)

## Test result summary
total: 68631, pass: 54812, fail: 2758, skip: 10808, xfail: 253,

## Build Summary
* arm: 96 total, 96 passed, 0 failed
* arm64: 24 total, 24 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 13 total, 13 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 39 total, 39 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 14 total, 14 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-
* 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-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-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-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance

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

2021-05-06 21:48:15

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review

Hi!

> This is the start of the stable review cycle for the 4.19.190 release.
> There are 15 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 Fri, 07 May 2021 12:04:54 +0000.
> Anything received after that time might be too late.

CIP testing did not find any kernel problems here: (testing
infrastructure has some problems)

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.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) (836.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-05-07 01:53:34

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/15] 4.19.190-rc1 review



On 2021/5/5 20:05, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.190 release.
> There are 15 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 Fri, 07 May 2021 12:04:54 +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.19.190-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Tested on arm64 and x86 for 4.19.190-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.19.y
Version: 4.19.190-rc1
Commit: 5a3ba2f90f8789162a03e07a37224bab4c643d1d
Compiler: gcc version 7.3.0 (GCC)

arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8435
passed: 8435
failed: 0
timeout: 0
--------------------------------------------------------------------

x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8435
passed: 8435
failed: 0
timeout: 0
--------------------------------------------------------------------

Tested-by: Hulk Robot <[email protected]>