June 2022 - Linux-stable-mirror

[REGRESSION] VGA output with AST 2600 graphics.

by Jocelyn Falempe

Hi, I've found a regression in the ast driver, for AST2600 hardware. before the upstream commit f9bd00e0ea9d https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… The ast driver handled AST 2600 chip like an AST 2500. After this commit, it uses some default values, more like the older AST chip. There are a lot of places in the driver like this: https://elixir.bootlin.com/linux/v5.18.1/source/drivers/gpu/drm/ast/ast_pos… where it checks for (AST2300 || AST2400 || AST2500) but not for AST2600. This makes the VGA output, to be blurred and flickered with whites lines on AST2600. The issue is present since v5.11 For v5.11~v5.17 I propose a simple workaround (as there are no other reference to AST2600 in the driver): --- a/drivers/gpu/drm/ast/ast_main.c +++ b/drivers/gpu/drm/ast/ast_main.c @@ -146,7 +146,8 @@ static int ast_detect_chip(struct drm_device *dev, bool *need_post) /* Identify chipset */ if (pdev->revision >= 0x50) { - ast->chip = AST2600; + /* Workaround to use the same codepath for AST2600 */ + ast->chip = AST2500; drm_info(dev, "AST 2600 detected\n"); } else if (pdev->revision >= 0x40) { ast->chip = AST2500; starting from v5.18, there is another reference to AST2600 in the code https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ast/ast_main.… So I think someone with good aspeed knowledge should review all locations where there is a test for AST2500, and figure out what should be done for AST2600 Thanks, -- Jocelyn

3 years

3
4
0 0

[PATCH] net-sysfs: allow changing sysfs carrier when interface is down

by Joakim Tjernlund

UP/DOWN and carrier are async events and it makes sense one can adjust carrier in sysfs before bringing the interface up. Signed-off-by: Joakim Tjernlund <joakim.tjernlund(a)infinera.com> Cc: stable(a)vger.kernel.org --- net/core/net-sysfs.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c index a4ae65263384..3418ef7ef2d8 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -167,8 +167,6 @@ static DEVICE_ATTR_RO(broadcast); static int change_carrier(struct net_device *dev, unsigned long new_carrier) { - if (!netif_running(dev)) - return -EINVAL; return dev_change_carrier(dev, (bool)new_carrier); } @@ -191,10 +189,7 @@ static ssize_t carrier_show(struct device *dev, { struct net_device *netdev = to_net_dev(dev); - if (netif_running(netdev)) - return sprintf(buf, fmt_dec, !!netif_carrier_ok(netdev)); - - return -EINVAL; + return sprintf(buf, fmt_dec, !!netif_carrier_ok(netdev)); } static DEVICE_ATTR_RW(carrier); -- 2.35.1

3 years

5
14
0 0

[PATCH] btrfs: correctly populate btrfs_super_block::log_root_transid

by Qu Wenruo

[BUG] After creating a dirty log tree, although btrfs_super_block::log_root and log_root_level is correctly populated, its generation is still left 0: log_root 30474240 log_root_transid 0 <<< log_root_level 0 [CAUSE] We just forgot to update btrfs_super_block::log_root_transid completely. Thus it's always the original value (0) from the initial super block. Thankfully this old behavior won't break log replay, as in btrfs_read_tree(), parent generation 0 means we just skip the generation check. And per-root log tree is still done properly using the root generation, so here we really only missed the generation check for log tree root, and even we fixed it, it should not cause any compatible problem. [FIX] Just update btrfs_super_block::log_root_transid properly. Cc: stable(a)vger.kernel.org #4.9+ Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/tree-log.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 370388fadf96..27a76d6fef8c 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -3083,7 +3083,8 @@ int btrfs_sync_log(struct btrfs_trans_handle *trans, struct btrfs_log_ctx root_log_ctx; struct blk_plug plug; u64 log_root_start; - u64 log_root_level; + u64 log_root_transid; + u8 log_root_level; mutex_lock(&root->log_mutex); log_transid = ctx->log_transid; @@ -3297,6 +3298,7 @@ int btrfs_sync_log(struct btrfs_trans_handle *trans, log_root_start = log_root_tree->node->start; log_root_level = btrfs_header_level(log_root_tree->node); + log_root_transid = btrfs_header_generation(log_root_tree->node); log_root_tree->log_transid++; mutex_unlock(&log_root_tree->log_mutex); @@ -3334,6 +3336,7 @@ int btrfs_sync_log(struct btrfs_trans_handle *trans, btrfs_set_super_log_root(fs_info->super_for_commit, log_root_start); btrfs_set_super_log_root_level(fs_info->super_for_commit, log_root_level); + btrfs_set_super_log_root_transid(fs_info->super_for_commit, log_root_transid); ret = write_all_supers(fs_info, 1); mutex_unlock(&fs_info->tree_log_mutex); if (ret) { -- 2.36.1

3 years

3
4
0 0

FAILED: patch "[PATCH] exportfs: support idmapped mounts" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3a761d72fa62eec8913e45d29375344f61706541 Mon Sep 17 00:00:00 2001 From: Christian Brauner <brauner(a)kernel.org> Date: Mon, 4 Apr 2022 12:51:41 +0200 Subject: [PATCH] exportfs: support idmapped mounts Make the two locations where exportfs helpers check permission to lookup a given inode idmapped mount aware by switching it to the lookup_one() helper. This is a bugfix for the open_by_handle_at() system call which doesn't take idmapped mounts into account currently. It's not tied to a specific commit so we'll just Cc stable. In addition this is required to support idmapped base layers in overlay. The overlay filesystem uses exportfs to encode and decode file handles for its index=on mount option and when nfs_export=on. Cc: <stable(a)vger.kernel.org> Cc: <linux-fsdevel(a)vger.kernel.org> Tested-by: Giuseppe Scrivano <gscrivan(a)redhat.com> Reviewed-by: Amir Goldstein <amir73il(a)gmail.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner(a)kernel.org> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c index 0106eba46d5a..3ef80d000e13 100644 --- a/fs/exportfs/expfs.c +++ b/fs/exportfs/expfs.c @@ -145,7 +145,7 @@ static struct dentry *reconnect_one(struct vfsmount *mnt, if (err) goto out_err; dprintk("%s: found name: %s\n", __func__, nbuf); - tmp = lookup_one_len_unlocked(nbuf, parent, strlen(nbuf)); + tmp = lookup_one_unlocked(mnt_user_ns(mnt), nbuf, parent, strlen(nbuf)); if (IS_ERR(tmp)) { dprintk("%s: lookup failed: %d\n", __func__, PTR_ERR(tmp)); err = PTR_ERR(tmp); @@ -525,7 +525,8 @@ exportfs_decode_fh_raw(struct vfsmount *mnt, struct fid *fid, int fh_len, } inode_lock(target_dir->d_inode); - nresult = lookup_one_len(nbuf, target_dir, strlen(nbuf)); + nresult = lookup_one(mnt_user_ns(mnt), nbuf, + target_dir, strlen(nbuf)); if (!IS_ERR(nresult)) { if (unlikely(nresult->d_inode != result->d_inode)) { dput(nresult);

3 years

3
3
0 0

Dear Child of God

by Mrs Lila Haber

Dear Child of God, Calvary Greetings in the name of the LORD Almighty and Our LORD JESUS CHRIST the giver of every good thing. Good day and compliments of the seasons, i know this letter will definitely come to you as a huge surprise, but I implore you to take the time to go through it carefully as the decision you make will go off a long way to determine my future and continued existence. I am Mrs Lila Haber aging widow of 57 years old suffering from long time illness.I have some funds I inherited from my late husband, the sum of (7.2Million Dollars) and I needed a very honest and God fearing who can withdraw this money then use the funds for Charity works. I WISH TO GIVE THIS FUNDS TO YOU FOR CHARITY WORKS. I found your email address from the internet after honest prayers to the LORD to bring me a helper and i decided to contact you if you may be willing and interested to handle these trust funds in good faith before anything happens to me. I accept this decision because I do not have any child who will inherit this money after I die. I want your urgent reply to me so that I will give you the deposit receipt which the SECURITY COMPANY issued to me as next of kin for immediate transfer of the money to your account in your country, to start the good work of God, I want you to use the 25/percent of the total amount to help yourself in doing the project. I am desperately in keen need of assistance and I have summoned up courage to contact you for this task, you must not fail me and the millions of the poor people in our todays WORLD. This is no stolen money and there are no dangers involved,100% RISK FREE with full legal proof. Please if you would be able to use the funds for the Charity works kindly let me know immediately.I will appreciate your utmost confidentiality and trust in this matter to accomplish my heart desire, as I don't want anything that will jeopardize my last wish. Please kindly respond quickly for further details. Warmest Regards, Mrs Lila Haber

3 years

1
0
0 0

[PATCH] mtd: phram: Map RAM using memremap instead of ioremap

by Petr Malat

One can't use memcpy on memory obtained by ioremap, because IO memory may have different alignment and size access restriction than the system memory. Use memremap as phram driver operates on RAM. This fixes an unaligned access on ARM64, which could be triggered with e.g. dd if=/dev/phram/by-name/testdev bs=8190 count=1 Unable to handle kernel paging request at virtual address ffffffc01208bfbf Mem abort info: ESR = 0x96000021 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000021 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000000cd5000 [ffffffc01208bfbf] pgd=00000002fffff003, p4d=00000002fffff003, pud=00000002fffff003, pmd=0000000100b43003, pte=0068000022221717 Internal error: Oops: 96000021 [#1] PREEMPT SMP CPU: 2 PID: 14768 Comm: dd Tainted: G O 5.10.116-f13ddced70 #1 Hardware name: AXM56xx Victoria (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x168/0x230 lr : phram_read+0x68/0xb0 [phram] sp : ffffffc0138f3bd0 x29: ffffffc0138f3bd0 x28: 0000000034a50090 x27: 0000000000000000 x26: ffffff81176ce000 x25: 0000000000000000 x24: 0000000000000000 x23: ffffffc0138f3cb8 x22: ffffff8109475000 x21: 0000000000000000 x20: ffffff81176ce000 x19: 0000000000001fff x18: 0000000000000020 x17: 0000000000000000 x16: 0000000000000000 x15: ffffff8125861410 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff81176cffff x4 : ffffffc01208bfff x3 : ffffff81176cff80 x2 : ffffffffffffffef x1 : ffffffc01208bfc0 x0 : ffffff81176ce000 Call trace: __memcpy+0x168/0x230 mtd_read_oob_std+0x80/0x90 mtd_read_oob+0x8c/0x150 mtd_read+0x54/0x80 mtdchar_read+0xdc/0x2c0 vfs_read+0xb8/0x1e4 ksys_read+0x78/0x10c __arm64_sys_read+0x28/0x34 do_el0_svc+0x94/0x1f0 el0_svc+0x20/0x30 el0_sync_handler+0x1a4/0x1c0 el0_sync+0x180/0x1c0 Code: a984346c a9c4342c f1010042 54fffee8 (a97c3c8e) ---[ end trace 5707221d643416b6 ]--- Signed-off-by: Petr Malat <oss(a)malat.biz> --- drivers/mtd/devices/phram.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c index d503821a3e60..25d3674b4e51 100644 --- a/drivers/mtd/devices/phram.c +++ b/drivers/mtd/devices/phram.c @@ -83,7 +83,7 @@ static void unregister_devices(void) list_for_each_entry_safe(this, safe, &phram_list, list) { mtd_device_unregister(&this->mtd); - iounmap(this->mtd.priv); + memunmap(this->mtd.priv); kfree(this->mtd.name); kfree(this); } @@ -99,9 +99,9 @@ static int register_device(char *name, phys_addr_t start, size_t len, uint32_t e goto out0; ret = -EIO; - new->mtd.priv = ioremap(start, len); + new->mtd.priv = memremap(start, len, MEMREMAP_WB); if (!new->mtd.priv) { - pr_err("ioremap failed\n"); + pr_err("memremap failed\n"); goto out1; } @@ -129,7 +129,7 @@ static int register_device(char *name, phys_addr_t start, size_t len, uint32_t e return 0; out2: - iounmap(new->mtd.priv); + memunmap(new->mtd.priv); out1: kfree(new); out0: -- 2.30.2

3 years

3
6
0 0

[PATCH] btrfs: reject log replay if there is unsupported RO flag

by Qu Wenruo

[BUG] If we have a btrfs image with dirty log, along with an unsupported RO compatible flag: log_root 30474240 ... compat_flags 0x0 compat_ro_flags 0x40000003 ( FREE_SPACE_TREE | FREE_SPACE_TREE_VALID | unknown flag: 0x40000000 ) Then even if we can only mount it RO, we will still cause metadata update for log replay: BTRFS info (device dm-1): flagging fs with big metadata feature BTRFS info (device dm-1): using free space tree BTRFS info (device dm-1): has skinny extents BTRFS info (device dm-1): start tree-log replay This is definitely against RO compact flag requirement. [CAUSE] RO compact flag only forces us to do RO mount, but we will still do log replay for plain RO mount. Thus this will result us to do log replay and update metadata. This can be very problematic for new RO compat flag, for example older kernel can not understand v2 cache, and if we allow metadata update on RO mount and invalidate/corrupt v2 cache. [FIX] Just set the nologreplay flag if there is any unsupported RO compact flag. This will reject log replay no matter if we have dirty log or not, with the following message: BTRFS info (device dm-1): disabling log replay due to unsupported ro compat features Cc: stable(a)vger.kernel.org #4.9+ Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/disk-io.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index fe309db9f5ff..d06f1a176b5b 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3655,6 +3655,14 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device err = -EINVAL; goto fail_alloc; } + /* + * We have unsupported RO compat features, although RO mounted, we + * should any metadata write, including the log replay. + * Or we can screw up whatever the new feature requires. + */ + if (features) + btrfs_set_and_info(fs_info, NOLOGREPLAY, + "disabling log replay due to unsupported ro compat features"); if (sectorsize < PAGE_SIZE) { struct btrfs_subpage_info *subpage_info; -- 2.36.1

3 years

3
2
0 0

[PATCH stable 5.10 5.15 5.17 5.18] arm64: Initialize jump labels before setup_machine_fdt()

by Jason A. Donenfeld

From: Stephen Boyd <swboyd(a)chromium.org> commit 73e2d827a501d48dceeb5b9b267a4cd283d6b1ae upstream. A static key warning splat appears during early boot on arm64 systems that credit randomness from devicetrees that contain an "rng-seed" property. This is because setup_machine_fdt() is called before jump_label_init() during setup_arch(). Let's swap the order of these two calls so that jump labels are initialized before the devicetree is unflattened and the rng seed is credited. static_key_enable_cpuslocked(): static key '0xffffffe51c6fcfc0' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xb0/0xb8 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0+ #224 44b43e377bfc84bc99bb5ab885ff694984ee09ff pstate: 600001c9 (nZCv dAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : static_key_enable_cpuslocked+0xb0/0xb8 lr : static_key_enable_cpuslocked+0xb0/0xb8 sp : ffffffe51c393cf0 x29: ffffffe51c393cf0 x28: 000000008185054c x27: 00000000f1042f10 x26: 0000000000000000 x25: 00000000f10302b2 x24: 0000002513200000 x23: 0000002513200000 x22: ffffffe51c1c9000 x21: fffffffdfdc00000 x20: ffffffe51c2f0831 x19: ffffffe51c6fcfc0 x18: 00000000ffff1020 x17: 00000000e1e2ac90 x16: 00000000000000e0 x15: ffffffe51b710708 x14: 0000000000000066 x13: 0000000000000018 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000ffffffff x9 : 0000000000000000 x8 : 0000000000000000 x7 : 61632065726f6665 x6 : 6220646573752027 x5 : ffffffe51c641d25 x4 : ffffffe51c13142c x3 : ffff0a00ffffff05 x2 : 40000000ffffe003 x1 : 00000000000001c0 x0 : 0000000000000065 Call trace: static_key_enable_cpuslocked+0xb0/0xb8 static_key_enable+0x2c/0x40 crng_set_ready+0x24/0x30 execute_in_process_context+0x80/0x90 _credit_init_bits+0x100/0x154 add_bootloader_randomness+0x64/0x78 early_init_dt_scan_chosen+0x140/0x184 early_init_dt_scan_nodes+0x28/0x4c early_init_dt_scan+0x40/0x44 setup_machine_fdt+0x7c/0x120 setup_arch+0x74/0x1d8 start_kernel+0x84/0x44c __primary_switched+0xc0/0xc8 ---[ end trace 0000000000000000 ]--- random: crng init done Machine model: Google Lazor (rev1 - 2) with LTE Cc: Hsin-Yi Wang <hsinyi(a)chromium.org> Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Jason A. Donenfeld <Jason(a)zx2c4.com> Cc: Dominik Brodowski <linux(a)dominikbrodowski.net> Fixes: f5bda35fba61 ("random: use static branch for crng_ready()") Signed-off-by: Stephen Boyd <swboyd(a)chromium.org> Reviewed-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Link: https://lore.kernel.org/r/20220602022109.780348-1-swboyd@chromium.org Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- This got a "Fixes:" tag, but didn't have a corresponding Cc to stable. Presumably AUTOSEL will eventually find this too, but sending it onward proactively anyway. arch/arm64/kernel/setup.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index eb4b24652c10..2360ff765979 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -300,13 +300,14 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p) early_fixmap_init(); early_ioremap_init(); - setup_machine_fdt(__fdt_pointer); - /* * Initialise the static keys early as they may be enabled by the - * cpufeature code and early parameters. + * cpufeature code, early parameters, and DT setup. */ jump_label_init(); + + setup_machine_fdt(__fdt_pointer); + parse_early_param(); /* -- 2.35.1

3 years

2
5
0 0

[PATCH 0/6] bfq: cgroup fixes for 5.4 stable

by Jan Kara

Hello, In this series are BFQ upstream fixes that didn't apply to 5.4 stable tree cleanly and needed some massaging before they apply. The result did pass some cgroup testing with bfq and the backport is based on the one we have in our SLES kernel so I'm reasonably confident things are fine. Honza

3 years

2
7
0 0

[PATCH 5.15 0/2] Fix suspend on qcom sc7180 SoCs

by Stephen Boyd

These two patches fix suspend on sc7180 boards, i.e. Trogdor, on 5.15 stable kernels. Without these two patches the IP0 interconnect is kept on forever, and suspend fails because XO shutdown can't be achieved. Mike Tipton (1): interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate Stephen Boyd (1): interconnect: qcom: sc7180: Drop IP0 interconnects drivers/interconnect/qcom/icc-rpmh.c | 10 +++++----- drivers/interconnect/qcom/sc7180.c | 21 --------------------- drivers/interconnect/qcom/sm8150.c | 1 - drivers/interconnect/qcom/sm8250.c | 1 - drivers/interconnect/qcom/sm8350.c | 1 - 5 files changed, 5 insertions(+), 29 deletions(-) -- https://chromeos.dev

3 years

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2022