October 2024 - Linux-stable-mirror

[PATCH v2] serial: 8250: omap: Move pm_runtime_get_sync

by Judith Mendez

From: Bin Liu <b-liu(a)ti.com> Currently in omap_8250_shutdown, the dma->rx_running flag is set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync is called, which is a runtime resume call stack which can re-set the flag. When the call omap_8250_shutdown returns, the flag is expected to be UN-SET, but this is not the case. This is causing issues the next time UART is re-opened and omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync before the omap_8250_rx_dma_flush. cc: stable(a)vger.kernel.org Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback") Signed-off-by: Bin Liu <b-liu(a)ti.com> [Judith: Add commit message] Signed-off-by: Judith Mendez <jm(a)ti.com> Reviewed-by: Kevin Hilman <khilman(a)baylibre.com> Tested-by: Kevin Hilman <khilman(a)baylibre.com> --- Issue seen on am335x devices so far [0]. The patch has been tested with sanity boot test on am335x EVM, am335x-boneblack and am57xx-beagle-x15. Changes since v1 RESEND: - Fix email header and commit description length - Add fixes tag, add link [0], cc stable, add kevin's reviewed-by/tested-by's - Separate patch from patch series [1] [0] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1… Link to v1 RESEND: [1] https://lore.kernel.org/linux-omap/20241011173356.870883-1-jm@ti.com/ --- drivers/tty/serial/8250/8250_omap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index 88b58f44e4e97..0dd68bdbfbcf7 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -776,12 +776,12 @@ static void omap_8250_shutdown(struct uart_port *port) struct uart_8250_port *up = up_to_u8250p(port); struct omap8250_priv *priv = port->private_data; + pm_runtime_get_sync(port->dev); + flush_work(&priv->qos_work); if (up->dma) omap_8250_rx_dma_flush(up); - pm_runtime_get_sync(port->dev); - serial_out(up, UART_OMAP_WER, 0); if (priv->habit & UART_HAS_EFR2) serial_out(up, UART_OMAP_EFR2, 0x0); -- 2.47.0

2 days, 21 hours

1
0
0 0

[PATCH 0/2] leds: max5970: fix unreleased fwnode_handle in probe function

by Javier Carrasco

This series fixes the wrong management of the 'led_node' fwnode_handle, which is not released after it is no longer required. This affects both the normal path of execution and the existing error paths (currently two) in max5970_led_probe(). First, the missing callst to fwnode_handle_put() in the different code paths are added, to make the patch available for stable kernels. Then, the code gets updated to a more robust approach by means of the __free() macro to automatically release the node when it goes out of scope, removing the need for explicit calls to fwnode_handle_put(). Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- Javier Carrasco (2): leds: max5970: fix unreleased fwnode_handle in probe function leds: max5970: use cleanup facility for fwnode_handle led_node drivers/leds/leds-max5970.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- base-commit: f2493655d2d3d5c6958ed996b043c821c23ae8d3 change-id: 20241019-max5970-of_node_put-939b004f57d2 Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

2 days, 22 hours

2
3
0 0

[PATCH] mm/damon/core: avoid overflow in damon_feed_loop_next_input()

by SeongJae Park

damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation. Reported-by: Guenter Roeck <linux(a)roeck-us.net> Closes: https://lore.kernel.org/944f3d5b-9177-48e7-8ec9-7f1331a3fea3@roeck-us.net Fixes: 9294a037c015 ("mm/damon/core: implement goal-oriented feedback-driven quota auto-tuning") Cc: <stable(a)vger.kernel.org> # 6.8.x Signed-off-by: SeongJae Park <sj(a)kernel.org> Tested-by: Guenter Roeck <linux(a)roeck-us.net> --- Changes from RFC (https://lore.kernel.org/20240905172405.46995-1-sj@kernel.org) - Rebase on latest mm-unstable and cleanup code mm/damon/core.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index a83f3b736d51..27745dcf855f 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -1456,17 +1456,31 @@ static unsigned long damon_feed_loop_next_input(unsigned long last_input, unsigned long score) { const unsigned long goal = 10000; - unsigned long score_goal_diff = max(goal, score) - min(goal, score); - unsigned long score_goal_diff_bp = score_goal_diff * 10000 / goal; - unsigned long compensation = last_input * score_goal_diff_bp / 10000; /* Set minimum input as 10000 to avoid compensation be zero */ const unsigned long min_input = 10000; + unsigned long score_goal_diff, compensation; + bool over_achieving = score > goal; - if (goal > score) + if (score == goal) + return last_input; + if (score >= goal * 2) + return min_input; + + if (over_achieving) + score_goal_diff = score - goal; + else + score_goal_diff = goal - score; + + if (last_input < ULONG_MAX / score_goal_diff) + compensation = last_input * score_goal_diff / goal; + else + compensation = last_input / goal * score_goal_diff; + + if (over_achieving) + return max(last_input - compensation, min_input); + if (last_input < ULONG_MAX - compensation) return last_input + compensation; - if (last_input > compensation + min_input) - return last_input - compensation; - return min_input; + return ULONG_MAX; } #ifdef CONFIG_PSI -- 2.39.5

2 days, 22 hours

1
0
0 0

[PATCH] tpm: set TPM_CHIP_FLAG_SUSPENDED early

by Jarkko Sakkinen

Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according to the bug report, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. Move setting of the flag into the beginning. Cc: stable(a)vger.kernel.org # v6.4+ Fixes: 99d464506255 ("tpm: Prevent hwrng from activating during resume") Reported-by: Mike Seo <mikeseohyungjin(a)gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219383 Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- drivers/char/tpm/tpm-interface.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 8134f002b121..3f96bc8b95df 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -370,6 +370,8 @@ int tpm_pm_suspend(struct device *dev) if (!chip) return -ENODEV; + chip->flags |= TPM_CHIP_FLAG_SUSPENDED; + if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED) goto suspended; @@ -390,8 +392,6 @@ int tpm_pm_suspend(struct device *dev) } suspended: - chip->flags |= TPM_CHIP_FLAG_SUSPENDED; - if (rc) dev_err(dev, "Ignoring error %d while suspending\n", rc); return 0; -- 2.47.0

2 days, 22 hours

2
6
0 0

[PATCH V2] wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures

by Guilherme G. Piccoli

Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got responsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries (at every I/O read) in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race"). [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000. Cc: stable(a)vger.kernel.org # v6.1+ Reported-by: syzbot+edd9fe0d3a65b14588d5(a)syzkaller.appspotmail.com Tested-by: Bitterblue Smith <rtl8821cerfe2(a)gmail.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com> --- V2: - Restrict the change to USB device only (thanks Ping-Ke Shih). - Tested in 2 USB devices by Bitterblue Smith - thanks a lot! V1: https://lore.kernel.org/lkml/20241025150226.896613-1-gpiccoli@igalia.com/ drivers/net/wireless/realtek/rtlwifi/efuse.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c index 82cf5fb5175f..f741066c06de 100644 --- a/drivers/net/wireless/realtek/rtlwifi/efuse.c +++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c @@ -164,7 +164,17 @@ void read_efuse_byte(struct ieee80211_hw *hw, u16 _offset, u8 *pbuf) struct rtl_priv *rtlpriv = rtl_priv(hw); u32 value32; u8 readbyte; - u16 retry; + u16 retry, max_attempts; + + /* + * In case of USB devices, transfer speeds are limited, hence + * efuse I/O reads could be (way) slower. So, decrease (a lot) + * the read attempts in case of failures. + */ + if (rtlpriv->rtlhal.interface == INTF_PCI) + max_attempts = 10000; + else + max_attempts = 10; rtl_write_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL] + 1, (_offset & 0xff)); @@ -178,7 +188,7 @@ void read_efuse_byte(struct ieee80211_hw *hw, u16 _offset, u8 *pbuf) retry = 0; value32 = rtl_read_dword(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL]); - while (!(((value32 >> 24) & 0xff) & 0x80) && (retry < 10000)) { + while (!(((value32 >> 24) & 0xff) & 0x80) && (retry < max_attempts)) { value32 = rtl_read_dword(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL]); retry++; -- 2.46.2

2 days, 22 hours

2
2
0 0

[PATCH v2] leds: lp55xx: Remove redundant test for invalid channel number

by Michal Vokáč

Since commit 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") there are two subsequent tests if the chan_nr (reg property) is in valid range. One in the lp55xx_init_led() function and one in the lp55xx_parse_common_child() function that was added with the mentioned commit. There are two issues with that. First is in the lp55xx_parse_common_child() function where the reg property is tested right after it is read from the device tree. Test for the upper range is not correct though. Valid reg values are 0 to (max_channel - 1) so it should be >=. Second issue is that in case the parsed value is out of the range the probe just fails and no error message is shown as the code never reaches the second test that prints and error message. Remove the test form lp55xx_parse_common_child() function completely and keep the one in lp55xx_init_led() function to deal with it. Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Cc: <stable(a)vger.kernel.org> Signed-off-by: Michal Vokáč <michal.vokac(a)ysoft.com> --- v2: - Complete change of the approach to the problem. In v1 I removed the test from lp55xx_init_led() but I failed to test that solution properly. It could not work. In v2 I removed the test for chan_nr being out of range from the lp55xx_parse_common_child() function. - Re-worded the subject and commit message to fit the changes. It was: "leds: lp55xx: Fix check for invalid channel number" drivers/leds/leds-lp55xx-common.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c index 5a2e259679cf..e71456a56ab8 100644 --- a/drivers/leds/leds-lp55xx-common.c +++ b/drivers/leds/leds-lp55xx-common.c @@ -1132,9 +1132,6 @@ static int lp55xx_parse_common_child(struct device_node *np, if (ret) return ret; - if (*chan_nr < 0 || *chan_nr > cfg->max_channel) - return -EINVAL; - return 0; } -- 2.1.4

2 days, 23 hours

2
1
0 0

[PATCH v3 12/14] scsi: ufs: exynos: fix hibern8 notify callbacks

by Peter Griffin

v1 of the patch which introduced the ufshcd_vops_hibern8_notify() callback used a bool instead of an enum. In v2 this was updated to an enum based on the review feedback in [1]. ufs-exynos hibernate calls have always been broken upstream as it follows the v1 bool implementation. Link: https://patchwork.kernel.org/project/linux-scsi/patch/001f01d23994$719997c0… [1] Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> Reviewed-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> Cc: stable(a)vger.kernel.org --- v3: Added Link tag, and CC stable, and Reviewed-by (Tudor) --- drivers/ufs/host/ufs-exynos.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c index 5078210b2a5c..9b6c4cfd7665 100644 --- a/drivers/ufs/host/ufs-exynos.c +++ b/drivers/ufs/host/ufs-exynos.c @@ -1526,12 +1526,12 @@ static void exynos_ufs_dev_hw_reset(struct ufs_hba *hba) hci_writel(ufs, 1 << 0, HCI_GPIO_OUT); } -static void exynos_ufs_pre_hibern8(struct ufs_hba *hba, u8 enter) +static void exynos_ufs_pre_hibern8(struct ufs_hba *hba, enum uic_cmd_dme cmd) { struct exynos_ufs *ufs = ufshcd_get_variant(hba); struct exynos_ufs_uic_attr *attr = ufs->drv_data->uic_attr; - if (!enter) { + if (cmd == UIC_CMD_DME_HIBER_EXIT) { if (ufs->opts & EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL) exynos_ufs_disable_auto_ctrl_hcc(ufs); exynos_ufs_ungate_clks(ufs); @@ -1559,11 +1559,11 @@ static void exynos_ufs_pre_hibern8(struct ufs_hba *hba, u8 enter) } } -static void exynos_ufs_post_hibern8(struct ufs_hba *hba, u8 enter) +static void exynos_ufs_post_hibern8(struct ufs_hba *hba, enum uic_cmd_dme cmd) { struct exynos_ufs *ufs = ufshcd_get_variant(hba); - if (!enter) { + if (cmd == UIC_CMD_DME_HIBER_EXIT) { u32 cur_mode = 0; u32 pwrmode; @@ -1582,7 +1582,7 @@ static void exynos_ufs_post_hibern8(struct ufs_hba *hba, u8 enter) if (!(ufs->opts & EXYNOS_UFS_OPT_SKIP_CONNECTION_ESTAB)) exynos_ufs_establish_connt(ufs); - } else { + } else if (cmd == UIC_CMD_DME_HIBER_ENTER) { ufs->entry_hibern8_t = ktime_get(); exynos_ufs_gate_clks(ufs); if (ufs->opts & EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL) @@ -1669,15 +1669,15 @@ static int exynos_ufs_pwr_change_notify(struct ufs_hba *hba, } static void exynos_ufs_hibern8_notify(struct ufs_hba *hba, - enum uic_cmd_dme enter, + enum uic_cmd_dme cmd, enum ufs_notify_change_status notify) { switch ((u8)notify) { case PRE_CHANGE: - exynos_ufs_pre_hibern8(hba, enter); + exynos_ufs_pre_hibern8(hba, cmd); break; case POST_CHANGE: - exynos_ufs_post_hibern8(hba, enter); + exynos_ufs_post_hibern8(hba, cmd); break; } } -- 2.47.0.163.g1226f6d8fa-goog

2 days, 23 hours

1
0
0 0

[PATCH v3 04/14] scsi: ufs: exynos: add check inside exynos_ufs_config_smu()

by Peter Griffin

Move the EXYNOS_UFS_OPT_UFSPR_SECURE check inside exynos_ufs_config_smu(). This way all call sites will benefit from the check. This fixes a bug currently in the exynos_ufs_resume() path on gs101 as it calls exynos_ufs_config_smu() and we end up accessing registers that can only be accessed from secure world which results in a serror. Fixes: d11e0a318df8 ("scsi: ufs: exynos: Add support for Tensor gs101 SoC") Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> Reviewed-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> Cc: stable(a)vger.kernel.org --- v3: CC stable and be more verbose in commit message (Tudor) --- drivers/ufs/host/ufs-exynos.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c index 33de7ff747a2..f4454e89040f 100644 --- a/drivers/ufs/host/ufs-exynos.c +++ b/drivers/ufs/host/ufs-exynos.c @@ -719,6 +719,9 @@ static void exynos_ufs_config_smu(struct exynos_ufs *ufs) { u32 reg, val; + if (ufs->opts & EXYNOS_UFS_OPT_UFSPR_SECURE) + return; + exynos_ufs_disable_auto_ctrl_hcc_save(ufs, &val); /* make encryption disabled by default */ @@ -1454,8 +1457,8 @@ static int exynos_ufs_init(struct ufs_hba *hba) if (ret) goto out; exynos_ufs_specify_phy_time_attr(ufs); - if (!(ufs->opts & EXYNOS_UFS_OPT_UFSPR_SECURE)) - exynos_ufs_config_smu(ufs); + + exynos_ufs_config_smu(ufs); hba->host->dma_alignment = DATA_UNIT_SIZE - 1; return 0; -- 2.47.0.163.g1226f6d8fa-goog

2 days, 23 hours

1
0
0 0

[PATCH net] wifi: brcmfmac: release 'root' node in all execution paths

by Javier Carrasco

The fixed patch introduced an additional condition to enter the scope where the 'root' device_node is released (!settings->board_type, currently 'err'), which avoid decrementing the refcount with a call to of_node_put() if that second condition is not satisfied. Move the call to of_node_put() to the point where 'root' is no longer required to avoid leaking the resource if err is not zero. Cc: stable(a)vger.kernel.org Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- Note that a call to of_node_put() on a NULL device_node has no effect, which simplifies this patch as there is no need to refactor the or add more conditions. --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c index fe4f65756105..af930e34c21f 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c @@ -110,9 +110,8 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type, } strreplace(board_type, '/', '-'); settings->board_type = board_type; - - of_node_put(root); } + of_node_put(root); if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac")) return; --- base-commit: c05c62850a8f035a267151dd86ea3daf887e28b8 change-id: 20241030-brcmfmac-of-cleanup-000fe98821df Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

2 days, 23 hours

2
2
0 0

[PATCH v3] ext4: prevent data-race that occur when read/write ext4_group_desc structure members

by Jeongjun Park

Currently, data-race like [1] occur in fs/ext4/ialloc.c find_group_other() and find_group_orlov() read *_lo, *_hi with ext4_free_inodes_count without additional locking. This can cause data-race, but since the lock is held for most writes and free inodes value is generally not a problem even if it is incorrect, it is more appropriate to use READ_ONCE()/WRITE_ONCE() than to add locking. [1] ================================================================== BUG: KCSAN: data-race in ext4_free_inodes_count / ext4_free_inodes_set write to 0xffff88810404300e of 2 bytes by task 6254 on cpu 1: ext4_free_inodes_set+0x1f/0x80 fs/ext4/super.c:405 __ext4_new_inode+0x15ca/0x2200 fs/ext4/ialloc.c:1216 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff88810404300e of 2 bytes by task 6257 on cpu 0: ext4_free_inodes_count+0x1c/0x80 fs/ext4/super.c:349 find_group_other fs/ext4/ialloc.c:594 [inline] __ext4_new_inode+0x6ec/0x2200 fs/ext4/ialloc.c:1017 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e value changed: 0x185c -> 0x185b Cc: <stable(a)vger.kernel.org> Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- fs/ext4/super.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 16a4ce704460..8337c4999f90 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -346,9 +346,9 @@ __u32 ext4_free_group_clusters(struct super_block *sb, __u32 ext4_free_inodes_count(struct super_block *sb, struct ext4_group_desc *bg) { - return le16_to_cpu(bg->bg_free_inodes_count_lo) | + return le16_to_cpu(READ_ONCE(bg->bg_free_inodes_count_lo)) | (EXT4_DESC_SIZE(sb) >= EXT4_MIN_DESC_SIZE_64BIT ? - (__u32)le16_to_cpu(bg->bg_free_inodes_count_hi) << 16 : 0); + (__u32)le16_to_cpu(READ_ONCE(bg->bg_free_inodes_count_hi)) << 16 : 0); } __u32 ext4_used_dirs_count(struct super_block *sb, @@ -402,9 +402,9 @@ void ext4_free_group_clusters_set(struct super_block *sb, void ext4_free_inodes_set(struct super_block *sb, struct ext4_group_desc *bg, __u32 count) { - bg->bg_free_inodes_count_lo = cpu_to_le16((__u16)count); + WRITE_ONCE(bg->bg_free_inodes_count_lo, cpu_to_le16((__u16)count)); if (EXT4_DESC_SIZE(sb) >= EXT4_MIN_DESC_SIZE_64BIT) - bg->bg_free_inodes_count_hi = cpu_to_le16(count >> 16); + WRITE_ONCE(bg->bg_free_inodes_count_hi, cpu_to_le16(count >> 16)); } void ext4_used_dirs_set(struct super_block *sb, --

3 days

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024