July 2024 - Linux-stable-mirror

Re: FW: linux-6.6.y: Regression in amd-pstate cpufreq driver since 6.6.34

by Mario Limonciello

In the future, please send this to the regressions M/L and CC people instead of just sending a private message. For now, I've added the @regressions and @stable mailing lists as this is an issue you find exposed specifically in the LTS series. Hi Lars, Can you please test 6.9.7? If this is still failing, can you please check 6.10-rc6? I'd like to understand if we just have a missing commit to backport or it's a problem in the mainline kernel as well. From the below description it's specifically with boost in passive mode, right? If 6.10-rc6 is still affected, can you please see if this commit helps? https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/commit/?h… This is going into 6.11-rc1. Perry, Jassmine, Can you try to repro this using bleeding-edge or linux-next branches? Thanks, On 7/1/2024 4:33, Huang, Ray wrote: > [AMD Official Use Only - AMD Internal Distribution Only] > > Hi all, > > Could you please help for a quick fix? > > -----Original Message----- > From: Lars Wendler <wendler.lars(a)web.de> > Sent: Monday, July 1, 2024 5:30 PM > To: Huang, Ray <Ray.Huang(a)amd.com> > Cc: gregkh(a)linuxfoundation.org > Subject: linux-6.6.y: Regression in amd-pstate cpufreq driver since 6.6.34 > > Hello dear kernel developers, > > I might have found a regression in the amd-pstate driver of linux-6.6 stable series. I haven't checked linux-master nor any other LTS branch. > > > Now here's what I have found: > > Since linux-6.6.34 the following command fails: > > # echo 0 > /sys/devices/system/cpu/cpufreq/boost > -bash: echo: write error: Invalid argument > > and indeed, disabling CPU boost seems to not work: > > # cat /sys/devices/system/cpu/cpufreq/boost > 1 > > I have bisected the issue to commit > 8f893e52b9e030a25ea62e31271bf930b01f2f07: > > cpufreq: amd-pstate: Fix the inconsistency in max frequency units > > commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream. > > Reverting that commit (even on latest linux-6.6 release) gives me back the ability to disable CPU boost again. > > I can only reproduce this bug on my Zen4 machine: > > # lscpu | grep "^Model name:" | sed 's@[[:space:]][[:space:]]\+@ @' > Model name: AMD Ryzen 7 7745HX with Radeon Graphics > > My older Zen3 machines seem not to be affected by this issue. All my Ryzen systems run on latest linux-6.6 kernels and have the following configuration regarding amd-pstate: > > # zgrep -F AMD_PSTATE /proc/config.gz > CONFIG_X86_AMD_PSTATE=y > CONFIG_X86_AMD_PSTATE_DEFAULT_MODE=2 > # CONFIG_X86_AMD_PSTATE_UT is not set > > > If you need more information, please don't hesitate to ask. > > Kind regards > Lars Wendler

9 months, 4 weeks

3
7
0 0

Please backport d8616ee2affc ("bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues") to linux-5.10.y

by Wen Gu

Hi stable team, Could you please backport [1] to linux-5.10.y? I noticed a regression caused by [2], which was merged to linux-5.10.y since v5.10.80. After sock_map_unhash() helper was removed in [2], sock elems added to the bpf sock map via sock_hash_update_common() cannot be removed if they are in the icsk_accept_queue of the listener sock. Since they have not been accept()ed, they cannot be removed via sock_map_close()->sock_map_remove_links() either. It can be reproduced in network test with short-lived connections. If the server is stopped during the test, there is a probability that some sock elems will remain in the bpf sock map. And with [1], the sock_map_destroy() helper is introduced to invoke sock_map_remove_links() when inet_csk_listen_stop()->inet_child_forget()->inet_csk_destroy_sock(), to remove the sock elems from the bpf sock map in such situation. [1] d8616ee2affc ("bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues") (link: https://lore.kernel.org/all/20220524075311.649153-1-wangyufen@huawei.com/) [2] 8b5c98a67c1b ("bpf, sockmap: Remove unhash handler for BPF sockmap usage") (link: https://lore.kernel.org/all/20211103204736.248403-3-john.fastabend@gmail.co…) Thanks! Wen Gu

9 months, 4 weeks

2
4
0 0

[PATCH] Revert "platform/x86: toshiba_acpi: Add quirk for buttons on Z830"

by Armin Wolf

This reverts commit 6239d65b917c29853592a8b417bdcedcbf1fe154. The associated patch depends on the availability of the ACPI quickstart button driver, which will be available starting with kernel 6.10. This means that the patch brings no benifit for older kernels. Even worse, it was found out that the patch is buggy, causing regressions for people using older kernels. Fix this by simply reverting the patch from the 6.1 stable tree. Cc: <stable(a)vger.kernel.org> # 6.1.x Reported-by: kemal <kmal(a)cock.li> Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/platform/x86/toshiba_acpi.c | 36 +++-------------------------- 1 file changed, 3 insertions(+), 33 deletions(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index f10994b94a33..160abd3b3af8 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -57,11 +57,6 @@ module_param(turn_on_panel_on_resume, int, 0644); MODULE_PARM_DESC(turn_on_panel_on_resume, "Call HCI_PANEL_POWER_ON on resume (-1 = auto, 0 = no, 1 = yes"); -static int hci_hotkey_quickstart = -1; -module_param(hci_hotkey_quickstart, int, 0644); -MODULE_PARM_DESC(hci_hotkey_quickstart, - "Call HCI_HOTKEY_EVENT with value 0x5 for quickstart button support (-1 = auto, 0 = no, 1 = yes"); - #define TOSHIBA_WMI_EVENT_GUID "59142400-C6A3-40FA-BADB-8A2652834100" /* Scan code for Fn key on TOS1900 models */ @@ -141,7 +136,6 @@ MODULE_PARM_DESC(hci_hotkey_quickstart, #define HCI_ACCEL_MASK 0x7fff #define HCI_ACCEL_DIRECTION_MASK 0x8000 #define HCI_HOTKEY_DISABLE 0x0b -#define HCI_HOTKEY_ENABLE_QUICKSTART 0x05 #define HCI_HOTKEY_ENABLE 0x09 #define HCI_HOTKEY_SPECIAL_FUNCTIONS 0x10 #define HCI_LCD_BRIGHTNESS_BITS 3 @@ -2736,15 +2730,10 @@ static int toshiba_acpi_enable_hotkeys(struct toshiba_acpi_dev *dev) return -ENODEV; /* - * Enable quickstart buttons if supported. - * * Enable the "Special Functions" mode only if they are * supported and if they are activated. */ - if (hci_hotkey_quickstart) - result = hci_write(dev, HCI_HOTKEY_EVENT, - HCI_HOTKEY_ENABLE_QUICKSTART); - else if (dev->kbd_function_keys_supported && dev->special_functions) + if (dev->kbd_function_keys_supported && dev->special_functions) result = hci_write(dev, HCI_HOTKEY_EVENT, HCI_HOTKEY_SPECIAL_FUNCTIONS); else @@ -3270,14 +3259,7 @@ static const char *find_hci_method(acpi_handle handle) * works. toshiba_acpi_resume() uses HCI_PANEL_POWER_ON to avoid changing * the configured brightness level. */ -#define QUIRK_TURN_ON_PANEL_ON_RESUME BIT(0) -/* - * Some Toshibas use "quickstart" keys. On these, HCI_HOTKEY_EVENT must use - * the value HCI_HOTKEY_ENABLE_QUICKSTART. - */ -#define QUIRK_HCI_HOTKEY_QUICKSTART BIT(1) - -static const struct dmi_system_id toshiba_dmi_quirks[] = { +static const struct dmi_system_id turn_on_panel_on_resume_dmi_ids[] = { { /* Toshiba Portégé R700 */ /* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */ @@ -3285,7 +3267,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R700"), }, - .driver_data = (void *)QUIRK_TURN_ON_PANEL_ON_RESUME, }, { /* Toshiba Satellite/Portégé R830 */ @@ -3295,7 +3276,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "R830"), }, - .driver_data = (void *)QUIRK_TURN_ON_PANEL_ON_RESUME, }, { /* Toshiba Satellite/Portégé Z830 */ @@ -3303,7 +3283,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "Z830"), }, - .driver_data = (void *)(QUIRK_TURN_ON_PANEL_ON_RESUME | QUIRK_HCI_HOTKEY_QUICKSTART), }, }; @@ -3312,8 +3291,6 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) struct toshiba_acpi_dev *dev; const char *hci_method; u32 dummy; - const struct dmi_system_id *dmi_id; - long quirks = 0; int ret = 0; if (toshiba_acpi) @@ -3466,15 +3443,8 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) } #endif - dmi_id = dmi_first_match(toshiba_dmi_quirks); - if (dmi_id) - quirks = (long)dmi_id->driver_data; - if (turn_on_panel_on_resume == -1) - turn_on_panel_on_resume = !!(quirks & QUIRK_TURN_ON_PANEL_ON_RESUME); - - if (hci_hotkey_quickstart == -1) - hci_hotkey_quickstart = !!(quirks & QUIRK_HCI_HOTKEY_QUICKSTART); + turn_on_panel_on_resume = dmi_check_system(turn_on_panel_on_resume_dmi_ids); toshiba_wwan_available(dev); if (dev->wwan_supported) -- 2.39.2

9 months, 4 weeks

1
0
0 0

[PATCH] Revert "platform/x86: toshiba_acpi: Add quirk for buttons on Z830"

by Armin Wolf

This reverts commit a63054e677fd098fbe69fc9a35325a300c14c698. The associated patch depends on the availability of the ACPI quickstart button driver, which will be available starting with kernel 6.10. This means that the patch brings no benifit for older kernels. Even worse, it was found out that the patch is buggy, causing regressions for people using older kernels. Fix this by simply reverting the patch from the 6.6 stable tree. Cc: <stable(a)vger.kernel.org> # 6.6.x Reported-by: kemal <kmal(a)cock.li> Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/platform/x86/toshiba_acpi.c | 36 +++-------------------------- 1 file changed, 3 insertions(+), 33 deletions(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index 2a5a651235fe..291f14ef6702 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -57,11 +57,6 @@ module_param(turn_on_panel_on_resume, int, 0644); MODULE_PARM_DESC(turn_on_panel_on_resume, "Call HCI_PANEL_POWER_ON on resume (-1 = auto, 0 = no, 1 = yes"); -static int hci_hotkey_quickstart = -1; -module_param(hci_hotkey_quickstart, int, 0644); -MODULE_PARM_DESC(hci_hotkey_quickstart, - "Call HCI_HOTKEY_EVENT with value 0x5 for quickstart button support (-1 = auto, 0 = no, 1 = yes"); - #define TOSHIBA_WMI_EVENT_GUID "59142400-C6A3-40FA-BADB-8A2652834100" /* Scan code for Fn key on TOS1900 models */ @@ -141,7 +136,6 @@ MODULE_PARM_DESC(hci_hotkey_quickstart, #define HCI_ACCEL_MASK 0x7fff #define HCI_ACCEL_DIRECTION_MASK 0x8000 #define HCI_HOTKEY_DISABLE 0x0b -#define HCI_HOTKEY_ENABLE_QUICKSTART 0x05 #define HCI_HOTKEY_ENABLE 0x09 #define HCI_HOTKEY_SPECIAL_FUNCTIONS 0x10 #define HCI_LCD_BRIGHTNESS_BITS 3 @@ -2736,15 +2730,10 @@ static int toshiba_acpi_enable_hotkeys(struct toshiba_acpi_dev *dev) return -ENODEV; /* - * Enable quickstart buttons if supported. - * * Enable the "Special Functions" mode only if they are * supported and if they are activated. */ - if (hci_hotkey_quickstart) - result = hci_write(dev, HCI_HOTKEY_EVENT, - HCI_HOTKEY_ENABLE_QUICKSTART); - else if (dev->kbd_function_keys_supported && dev->special_functions) + if (dev->kbd_function_keys_supported && dev->special_functions) result = hci_write(dev, HCI_HOTKEY_EVENT, HCI_HOTKEY_SPECIAL_FUNCTIONS); else @@ -3268,14 +3257,7 @@ static const char *find_hci_method(acpi_handle handle) * works. toshiba_acpi_resume() uses HCI_PANEL_POWER_ON to avoid changing * the configured brightness level. */ -#define QUIRK_TURN_ON_PANEL_ON_RESUME BIT(0) -/* - * Some Toshibas use "quickstart" keys. On these, HCI_HOTKEY_EVENT must use - * the value HCI_HOTKEY_ENABLE_QUICKSTART. - */ -#define QUIRK_HCI_HOTKEY_QUICKSTART BIT(1) - -static const struct dmi_system_id toshiba_dmi_quirks[] = { +static const struct dmi_system_id turn_on_panel_on_resume_dmi_ids[] = { { /* Toshiba Portégé R700 */ /* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */ @@ -3283,7 +3265,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R700"), }, - .driver_data = (void *)QUIRK_TURN_ON_PANEL_ON_RESUME, }, { /* Toshiba Satellite/Portégé R830 */ @@ -3293,7 +3274,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "R830"), }, - .driver_data = (void *)QUIRK_TURN_ON_PANEL_ON_RESUME, }, { /* Toshiba Satellite/Portégé Z830 */ @@ -3301,7 +3281,6 @@ static const struct dmi_system_id toshiba_dmi_quirks[] = { DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), DMI_MATCH(DMI_PRODUCT_NAME, "Z830"), }, - .driver_data = (void *)(QUIRK_TURN_ON_PANEL_ON_RESUME | QUIRK_HCI_HOTKEY_QUICKSTART), }, }; @@ -3310,8 +3289,6 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) struct toshiba_acpi_dev *dev; const char *hci_method; u32 dummy; - const struct dmi_system_id *dmi_id; - long quirks = 0; int ret = 0; if (toshiba_acpi) @@ -3464,15 +3441,8 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) } #endif - dmi_id = dmi_first_match(toshiba_dmi_quirks); - if (dmi_id) - quirks = (long)dmi_id->driver_data; - if (turn_on_panel_on_resume == -1) - turn_on_panel_on_resume = !!(quirks & QUIRK_TURN_ON_PANEL_ON_RESUME); - - if (hci_hotkey_quickstart == -1) - hci_hotkey_quickstart = !!(quirks & QUIRK_HCI_HOTKEY_QUICKSTART); + turn_on_panel_on_resume = dmi_check_system(turn_on_panel_on_resume_dmi_ids); toshiba_wwan_available(dev); if (dev->wwan_supported) -- 2.39.2

9 months, 4 weeks

1
0
0 0

[PATCH 2/2] f2fs: use meta inode for GC of COW file

by Sunmin Jeong

In case of the COW file, new updates and GC writes are already separated to page caches of the atomic file and COW file. As some cases that use the meta inode for GC, there are some race issues between a foreground thread and GC thread. To handle them, we need to take care when to invalidate and wait writeback of GC pages in COW files as the case of using the meta inode. Also, a pointer from the COW inode to the original inode is required to check the state of original pages. For the former, we can solve the problem by using the meta inode for GC of COW files. Then let's get a page from the original inode in move_data_block when GCing the COW file to avoid race condition. Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Cc: stable(a)vger.kernel.org #v5.19+ Reviewed-by: Sungjong Seo <sj1557.seo(a)samsung.com> Reviewed-by: Yeongjin Gil <youngjin.gil(a)samsung.com> Signed-off-by: Sunmin Jeong <s_min.jeong(a)samsung.com> --- fs/f2fs/data.c | 2 +- fs/f2fs/f2fs.h | 7 ++++++- fs/f2fs/file.c | 3 +++ fs/f2fs/gc.c | 12 ++++++++++-- fs/f2fs/inline.c | 2 +- fs/f2fs/inode.c | 3 ++- 6 files changed, 23 insertions(+), 6 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 05158f89ef32..90ff0f6f7f7f 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -2651,7 +2651,7 @@ bool f2fs_should_update_outplace(struct inode *inode, struct f2fs_io_info *fio) return true; if (IS_NOQUOTA(inode)) return true; - if (f2fs_is_atomic_file(inode)) + if (f2fs_used_in_atomic_write(inode)) return true; /* rewrite low ratio compress data w/ OPU mode to avoid fragmentation */ if (f2fs_compressed_file(inode) && diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 59c5117e54b1..4f9fd1c1d024 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -4267,9 +4267,14 @@ static inline bool f2fs_post_read_required(struct inode *inode) f2fs_compressed_file(inode); } +static inline bool f2fs_used_in_atomic_write(struct inode *inode) +{ + return f2fs_is_atomic_file(inode) || f2fs_is_cow_file(inode); +} + static inline bool f2fs_meta_inode_gc_required(struct inode *inode) { - return f2fs_post_read_required(inode) || f2fs_is_atomic_file(inode); + return f2fs_post_read_required(inode) || f2fs_used_in_atomic_write(inode); } /* diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 25b119cf3499..c9f0ba658cfd 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -2116,6 +2116,9 @@ static int f2fs_ioc_start_atomic_write(struct file *filp, bool truncate) set_inode_flag(fi->cow_inode, FI_COW_FILE); clear_inode_flag(fi->cow_inode, FI_INLINE_DATA); + + /* Set the COW inode's cow_inode to the atomic inode */ + F2FS_I(fi->cow_inode)->cow_inode = inode; } else { /* Reuse the already created COW inode */ ret = f2fs_do_truncate_blocks(fi->cow_inode, 0, true); diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index 136b9e8180a3..76854e732b35 100644 --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -1188,7 +1188,11 @@ static int ra_data_block(struct inode *inode, pgoff_t index) }; int err; - page = f2fs_grab_cache_page(mapping, index, true); + if (f2fs_is_cow_file(inode)) + page = f2fs_grab_cache_page(F2FS_I(inode)->cow_inode->i_mapping, + index, true); + else + page = f2fs_grab_cache_page(mapping, index, true); if (!page) return -ENOMEM; @@ -1287,7 +1291,11 @@ static int move_data_block(struct inode *inode, block_t bidx, CURSEG_ALL_DATA_ATGC : CURSEG_COLD_DATA; /* do not read out */ - page = f2fs_grab_cache_page(inode->i_mapping, bidx, false); + if (f2fs_is_cow_file(inode)) + page = f2fs_grab_cache_page(F2FS_I(inode)->cow_inode->i_mapping, + bidx, false); + else + page = f2fs_grab_cache_page(inode->i_mapping, bidx, false); if (!page) return -ENOMEM; diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c index ac00423f117b..0186ec049db6 100644 --- a/fs/f2fs/inline.c +++ b/fs/f2fs/inline.c @@ -16,7 +16,7 @@ static bool support_inline_data(struct inode *inode) { - if (f2fs_is_atomic_file(inode)) + if (f2fs_used_in_atomic_write(inode)) return false; if (!S_ISREG(inode->i_mode) && !S_ISLNK(inode->i_mode)) return false; diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index c26effdce9aa..c810304e2681 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -807,8 +807,9 @@ void f2fs_evict_inode(struct inode *inode) f2fs_abort_atomic_write(inode, true); - if (fi->cow_inode) { + if (fi->cow_inode && f2fs_is_cow_file(fi->cow_inode)) { clear_inode_flag(fi->cow_inode, FI_COW_FILE); + F2FS_I(fi->cow_inode)->cow_inode = NULL; iput(fi->cow_inode); fi->cow_inode = NULL; } -- 2.25.1

9 months, 4 weeks

1
0
0 0

[PATCH 1/2] f2fs: use meta inode for GC of atomic file

by Sunmin Jeong

The page cache of the atomic file keeps new data pages which will be stored in the COW file. It can also keep old data pages when GCing the atomic file. In this case, new data can be overwritten by old data if a GC thread sets the old data page as dirty after new data page was evicted. Also, since all writes to the atomic file are redirected to COW inodes, GC for the atomic file is not working well as below. f2fs_gc(gc_type=FG_GC) - select A as a victim segment do_garbage_collect - iget atomic file's inode for block B move_data_page f2fs_do_write_data_page - use dn of cow inode - set fio->old_blkaddr from cow inode - seg_freed is 0 since block B is still valid - goto gc_more and A is selected as victim again To solve the problem, let's separate GC writes and updates in the atomic file by using the meta inode for GC writes. Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Cc: stable(a)vger.kernel.org #v5.19+ Reviewed-by: Sungjong Seo <sj1557.seo(a)samsung.com> Reviewed-by: Yeongjin Gil <youngjin.gil(a)samsung.com> Signed-off-by: Sunmin Jeong <s_min.jeong(a)samsung.com> --- fs/f2fs/f2fs.h | 5 +++++ fs/f2fs/gc.c | 6 +++--- fs/f2fs/segment.c | 4 ++-- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index a000cb024dbe..59c5117e54b1 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -4267,6 +4267,11 @@ static inline bool f2fs_post_read_required(struct inode *inode) f2fs_compressed_file(inode); } +static inline bool f2fs_meta_inode_gc_required(struct inode *inode) +{ + return f2fs_post_read_required(inode) || f2fs_is_atomic_file(inode); +} + /* * compress.c */ diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index a079eebfb080..136b9e8180a3 100644 --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -1580,7 +1580,7 @@ static int gc_data_segment(struct f2fs_sb_info *sbi, struct f2fs_summary *sum, start_bidx = f2fs_start_bidx_of_node(nofs, inode) + ofs_in_node; - if (f2fs_post_read_required(inode)) { + if (f2fs_meta_inode_gc_required(inode)) { int err = ra_data_block(inode, start_bidx); f2fs_up_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]); @@ -1631,7 +1631,7 @@ static int gc_data_segment(struct f2fs_sb_info *sbi, struct f2fs_summary *sum, start_bidx = f2fs_start_bidx_of_node(nofs, inode) + ofs_in_node; - if (f2fs_post_read_required(inode)) + if (f2fs_meta_inode_gc_required(inode)) err = move_data_block(inode, start_bidx, gc_type, segno, off); else @@ -1639,7 +1639,7 @@ static int gc_data_segment(struct f2fs_sb_info *sbi, struct f2fs_summary *sum, segno, off); if (!err && (gc_type == FG_GC || - f2fs_post_read_required(inode))) + f2fs_meta_inode_gc_required(inode))) submitted++; if (locked) { diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 7e47b8054413..b55fc4bd416a 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -3823,7 +3823,7 @@ void f2fs_wait_on_block_writeback(struct inode *inode, block_t blkaddr) struct f2fs_sb_info *sbi = F2FS_I_SB(inode); struct page *cpage; - if (!f2fs_post_read_required(inode)) + if (!f2fs_meta_inode_gc_required(inode)) return; if (!__is_valid_data_blkaddr(blkaddr)) @@ -3842,7 +3842,7 @@ void f2fs_wait_on_block_writeback_range(struct inode *inode, block_t blkaddr, struct f2fs_sb_info *sbi = F2FS_I_SB(inode); block_t i; - if (!f2fs_post_read_required(inode)) + if (!f2fs_meta_inode_gc_required(inode)) return; for (i = 0; i < len; i++) -- 2.25.1

9 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] ata: libata-core: Fix null pointer dereference on error" failed to apply to 6.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.9-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.9.y git checkout FETCH_HEAD git cherry-pick -x 5d92c7c566dc76d96e0e19e481d926bbe6631c1e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024070105-falsify-surrender-babc@gregkh' --subject-prefix 'PATCH 6.9.y' HEAD^.. Possible dependencies: 5d92c7c566dc ("ata: libata-core: Fix null pointer dereference on error") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5d92c7c566dc76d96e0e19e481d926bbe6631c1e Mon Sep 17 00:00:00 2001 From: Niklas Cassel <cassel(a)kernel.org> Date: Sat, 29 Jun 2024 14:42:11 +0200 Subject: [PATCH] ata: libata-core: Fix null pointer dereference on error If the ata_port_alloc() call in ata_host_alloc() fails, ata_host_release() will get called. However, the code in ata_host_release() tries to free ata_port struct members unconditionally, which can lead to the following: BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? ata_host_release.cold+0x2f/0x6e [libata] ? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Do not access ata_port struct members unconditionally. Fixes: 633273a3ed1c ("libata-pmp: hook PMP support and enable it") Cc: stable(a)vger.kernel.org Reviewed-by: Damien Le Moal <dlemoal(a)kernel.org> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Reviewed-by: John Garry <john.g.garry(a)oracle.com> Link: https://lore.kernel.org/r/20240629124210.181537-7-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel(a)kernel.org> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index efb5195da60c..bdccf4ea251a 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -5517,6 +5517,9 @@ static void ata_host_release(struct kref *kref) for (i = 0; i < host->n_ports; i++) { struct ata_port *ap = host->ports[i]; + if (!ap) + continue; + kfree(ap->pmp_link); kfree(ap->slave_link); kfree(ap->ncq_sense_buf);

9 months, 4 weeks

4
3
0 0

FAILED: patch "[PATCH] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x b321c31c9b7b309dcde5e8854b741c8e6a9a05f0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072323-trident-unturned-7999@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: b321c31c9b7b ("KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption") 0c2f9acf6ae7 ("KVM: arm64: PMU: Don't overwrite PMUSERENR with vcpu loaded") 8681f7175901 ("KVM: arm64: PMU: Restore the host's PMUSERENR_EL0") 009d6dc87a56 ("ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM") 711432770f78 ("perf: pmuv3: Abstract PMU version checks") df29ddf4f04b ("arm64: perf: Abstract system register accesses away") 7755cec63ade ("arm64: perf: Move PMUv3 driver to drivers/perf") cc91b9481605 ("arm64/perf: Replace PMU version number '0' with ID_AA64DFR0_EL1_PMUVer_NI") 4151bb636acf ("KVM: arm64: Fix SMPRI_EL1/TPIDR2_EL0 trapping on VHE") bb0cca240a16 ("Merge branch kvm-arm64/single-step-async-exception into kvmarm-master/next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b321c31c9b7b309dcde5e8854b741c8e6a9a05f0 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Thu, 13 Jul 2023 08:06:57 +0100 Subject: [PATCH] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption Xiang reports that VMs occasionally fail to boot on GICv4.1 systems when running a preemptible kernel, as it is possible that a vCPU is blocked without requesting a doorbell interrupt. The issue is that any preemption that occurs between vgic_v4_put() and schedule() on the block path will mark the vPE as nonresident and *not* request a doorbell irq. This occurs because when the vcpu thread is resumed on its way to block, vcpu_load() will make the vPE resident again. Once the vcpu actually blocks, we don't request a doorbell anymore, and the vcpu won't be woken up on interrupt delivery. Fix it by tracking that we're entering WFI, and key the doorbell request on that flag. This allows us not to make the vPE resident when going through a preempt/schedule cycle, meaning we don't lose any state. Cc: stable(a)vger.kernel.org Fixes: 8e01d9a396e6 ("KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put") Reported-by: Xiang Chen <chenxiang66(a)hisilicon.com> Suggested-by: Zenghui Yu <yuzenghui(a)huawei.com> Tested-by: Xiang Chen <chenxiang66(a)hisilicon.com> Co-developed-by: Oliver Upton <oliver.upton(a)linux.dev> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Acked-by: Zenghui Yu <yuzenghui(a)huawei.com> Link: https://lore.kernel.org/r/20230713070657.3873244-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 8b6096753740..d3dd05bbfe23 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -727,6 +727,8 @@ struct kvm_vcpu_arch { #define DBG_SS_ACTIVE_PENDING __vcpu_single_flag(sflags, BIT(5)) /* PMUSERENR for the guest EL0 is on physical CPU */ #define PMUSERENR_ON_CPU __vcpu_single_flag(sflags, BIT(6)) +/* WFI instruction trapped */ +#define IN_WFI __vcpu_single_flag(sflags, BIT(7)) /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */ diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index a402ea5511f3..72dc53a75d1c 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -718,13 +718,15 @@ void kvm_vcpu_wfi(struct kvm_vcpu *vcpu) */ preempt_disable(); kvm_vgic_vmcr_sync(vcpu); - vgic_v4_put(vcpu, true); + vcpu_set_flag(vcpu, IN_WFI); + vgic_v4_put(vcpu); preempt_enable(); kvm_vcpu_halt(vcpu); vcpu_clear_flag(vcpu, IN_WFIT); preempt_disable(); + vcpu_clear_flag(vcpu, IN_WFI); vgic_v4_load(vcpu); preempt_enable(); } @@ -792,7 +794,7 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu) if (kvm_check_request(KVM_REQ_RELOAD_GICv4, vcpu)) { /* The distributor enable bits were changed */ preempt_disable(); - vgic_v4_put(vcpu, false); + vgic_v4_put(vcpu); vgic_v4_load(vcpu); preempt_enable(); } diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c index c3b8e132d599..3dfc8b84e03e 100644 --- a/arch/arm64/kvm/vgic/vgic-v3.c +++ b/arch/arm64/kvm/vgic/vgic-v3.c @@ -749,7 +749,7 @@ void vgic_v3_put(struct kvm_vcpu *vcpu) { struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3; - WARN_ON(vgic_v4_put(vcpu, false)); + WARN_ON(vgic_v4_put(vcpu)); vgic_v3_vmcr_sync(vcpu); diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c index c1c28fe680ba..339a55194b2c 100644 --- a/arch/arm64/kvm/vgic/vgic-v4.c +++ b/arch/arm64/kvm/vgic/vgic-v4.c @@ -336,14 +336,14 @@ void vgic_v4_teardown(struct kvm *kvm) its_vm->vpes = NULL; } -int vgic_v4_put(struct kvm_vcpu *vcpu, bool need_db) +int vgic_v4_put(struct kvm_vcpu *vcpu) { struct its_vpe *vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe; if (!vgic_supports_direct_msis(vcpu->kvm) || !vpe->resident) return 0; - return its_make_vpe_non_resident(vpe, need_db); + return its_make_vpe_non_resident(vpe, !!vcpu_get_flag(vcpu, IN_WFI)); } int vgic_v4_load(struct kvm_vcpu *vcpu) @@ -354,6 +354,9 @@ int vgic_v4_load(struct kvm_vcpu *vcpu) if (!vgic_supports_direct_msis(vcpu->kvm) || vpe->resident) return 0; + if (vcpu_get_flag(vcpu, IN_WFI)) + return 0; + /* * Before making the VPE resident, make sure the redistributor * corresponding to our current CPU expects us here. See the diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h index 402b545959af..5b27f94d4fad 100644 --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -431,7 +431,7 @@ int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int irq, int vgic_v4_load(struct kvm_vcpu *vcpu); void vgic_v4_commit(struct kvm_vcpu *vcpu); -int vgic_v4_put(struct kvm_vcpu *vcpu, bool need_db); +int vgic_v4_put(struct kvm_vcpu *vcpu); /* CPU HP callbacks */ void kvm_vgic_cpu_up(void);

9 months, 4 weeks

4
3
0 0

FAILED: patch "[PATCH] efi/x86: Free EFI memory map only when installing a new one." failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 75dde792d6f6c2d0af50278bd374bf0c512fe196 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024062455-glazing-flask-cf0c@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 75dde792d6f6 ("efi/x86: Free EFI memory map only when installing a new one.") d85e3e349407 ("efi: xen: Set EFI_PARAVIRT for Xen dom0 boot on all architectures") fdc6d38d64a2 ("efi: memmap: Move manipulation routines into x86 arch tree") 1df4d1724baa ("drivers: fix typo in firmware/efi/memmap.c") db01ea882bf6 ("efi: Correct comment on efi_memmap_alloc") 3ecc68349bba ("memblock: rename memblock_free to memblock_phys_free") fa27717110ae ("memblock: drop memblock_free_early_nid() and memblock_free_early()") 658aafc8139c ("memblock: exclude MEMBLOCK_NOMAP regions from kmemleak") c6460daea23d ("Merge tag 'for-linus-5.15b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 75dde792d6f6c2d0af50278bd374bf0c512fe196 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ardb(a)kernel.org> Date: Mon, 10 Jun 2024 16:02:13 +0200 Subject: [PATCH] efi/x86: Free EFI memory map only when installing a new one. The logic in __efi_memmap_init() is shared between two different execution flows: - mapping the EFI memory map early or late into the kernel VA space, so that its entries can be accessed; - the x86 specific cloning of the EFI memory map in order to insert new entries that are created as a result of making a memory reservation via a call to efi_mem_reserve(). In the former case, the underlying memory containing the kernel's view of the EFI memory map (which may be heavily modified by the kernel itself on x86) is not modified at all, and the only thing that changes is the virtual mapping of this memory, which is different between early and late boot. In the latter case, an entirely new allocation is created that carries a new, updated version of the kernel's view of the EFI memory map. When installing this new version, the old version will no longer be referenced, and if the memory was allocated by the kernel, it will leak unless it gets freed. The logic that implements this freeing currently lives on the code path that is shared between these two use cases, but it should only apply to the latter. So move it to the correct spot. While at it, drop the dummy definition for non-x86 architectures, as that is no longer needed. Cc: <stable(a)vger.kernel.org> Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks") Tested-by: Ashish Kalra <Ashish.Kalra(a)amd.com> Link: https://lore.kernel.org/all/36ad5079-4326-45ed-85f6-928ff76483d3@amd.com Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index 1dc600fa3ba5..481096177500 100644 --- a/arch/x86/include/asm/efi.h +++ b/arch/x86/include/asm/efi.h @@ -401,7 +401,6 @@ extern int __init efi_memmap_alloc(unsigned int num_entries, struct efi_memory_map_data *data); extern void __efi_memmap_free(u64 phys, unsigned long size, unsigned long flags); -#define __efi_memmap_free __efi_memmap_free extern int __init efi_memmap_install(struct efi_memory_map_data *data); extern int __init efi_memmap_split_count(efi_memory_desc_t *md, diff --git a/arch/x86/platform/efi/memmap.c b/arch/x86/platform/efi/memmap.c index 4ef20b49eb5e..6ed1935504b9 100644 --- a/arch/x86/platform/efi/memmap.c +++ b/arch/x86/platform/efi/memmap.c @@ -92,12 +92,22 @@ int __init efi_memmap_alloc(unsigned int num_entries, */ int __init efi_memmap_install(struct efi_memory_map_data *data) { + unsigned long size = efi.memmap.desc_size * efi.memmap.nr_map; + unsigned long flags = efi.memmap.flags; + u64 phys = efi.memmap.phys_map; + int ret; + efi_memmap_unmap(); if (efi_enabled(EFI_PARAVIRT)) return 0; - return __efi_memmap_init(data); + ret = __efi_memmap_init(data); + if (ret) + return ret; + + __efi_memmap_free(phys, size, flags); + return 0; } /** diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c index 3365944f7965..34109fd86c55 100644 --- a/drivers/firmware/efi/memmap.c +++ b/drivers/firmware/efi/memmap.c @@ -15,10 +15,6 @@ #include <asm/early_ioremap.h> #include <asm/efi.h> -#ifndef __efi_memmap_free -#define __efi_memmap_free(phys, size, flags) do { } while (0) -#endif - /** * __efi_memmap_init - Common code for mapping the EFI memory map * @data: EFI memory map data @@ -51,11 +47,6 @@ int __init __efi_memmap_init(struct efi_memory_map_data *data) return -ENOMEM; } - if (efi.memmap.flags & (EFI_MEMMAP_MEMBLOCK | EFI_MEMMAP_SLAB)) - __efi_memmap_free(efi.memmap.phys_map, - efi.memmap.desc_size * efi.memmap.nr_map, - efi.memmap.flags); - map.phys_map = data->phys_map; map.nr_map = data->size / data->desc_size; map.map_end = map.map + data->size;

9 months, 4 weeks

3
6
0 0

FAILED: patch "[PATCH] efi/x86: Free EFI memory map only when installing a new one." failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 75dde792d6f6c2d0af50278bd374bf0c512fe196 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024062442-bonfire-detonator-1b17@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 75dde792d6f6 ("efi/x86: Free EFI memory map only when installing a new one.") d85e3e349407 ("efi: xen: Set EFI_PARAVIRT for Xen dom0 boot on all architectures") fdc6d38d64a2 ("efi: memmap: Move manipulation routines into x86 arch tree") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 75dde792d6f6c2d0af50278bd374bf0c512fe196 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ardb(a)kernel.org> Date: Mon, 10 Jun 2024 16:02:13 +0200 Subject: [PATCH] efi/x86: Free EFI memory map only when installing a new one. The logic in __efi_memmap_init() is shared between two different execution flows: - mapping the EFI memory map early or late into the kernel VA space, so that its entries can be accessed; - the x86 specific cloning of the EFI memory map in order to insert new entries that are created as a result of making a memory reservation via a call to efi_mem_reserve(). In the former case, the underlying memory containing the kernel's view of the EFI memory map (which may be heavily modified by the kernel itself on x86) is not modified at all, and the only thing that changes is the virtual mapping of this memory, which is different between early and late boot. In the latter case, an entirely new allocation is created that carries a new, updated version of the kernel's view of the EFI memory map. When installing this new version, the old version will no longer be referenced, and if the memory was allocated by the kernel, it will leak unless it gets freed. The logic that implements this freeing currently lives on the code path that is shared between these two use cases, but it should only apply to the latter. So move it to the correct spot. While at it, drop the dummy definition for non-x86 architectures, as that is no longer needed. Cc: <stable(a)vger.kernel.org> Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks") Tested-by: Ashish Kalra <Ashish.Kalra(a)amd.com> Link: https://lore.kernel.org/all/36ad5079-4326-45ed-85f6-928ff76483d3@amd.com Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index 1dc600fa3ba5..481096177500 100644 --- a/arch/x86/include/asm/efi.h +++ b/arch/x86/include/asm/efi.h @@ -401,7 +401,6 @@ extern int __init efi_memmap_alloc(unsigned int num_entries, struct efi_memory_map_data *data); extern void __efi_memmap_free(u64 phys, unsigned long size, unsigned long flags); -#define __efi_memmap_free __efi_memmap_free extern int __init efi_memmap_install(struct efi_memory_map_data *data); extern int __init efi_memmap_split_count(efi_memory_desc_t *md, diff --git a/arch/x86/platform/efi/memmap.c b/arch/x86/platform/efi/memmap.c index 4ef20b49eb5e..6ed1935504b9 100644 --- a/arch/x86/platform/efi/memmap.c +++ b/arch/x86/platform/efi/memmap.c @@ -92,12 +92,22 @@ int __init efi_memmap_alloc(unsigned int num_entries, */ int __init efi_memmap_install(struct efi_memory_map_data *data) { + unsigned long size = efi.memmap.desc_size * efi.memmap.nr_map; + unsigned long flags = efi.memmap.flags; + u64 phys = efi.memmap.phys_map; + int ret; + efi_memmap_unmap(); if (efi_enabled(EFI_PARAVIRT)) return 0; - return __efi_memmap_init(data); + ret = __efi_memmap_init(data); + if (ret) + return ret; + + __efi_memmap_free(phys, size, flags); + return 0; } /** diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c index 3365944f7965..34109fd86c55 100644 --- a/drivers/firmware/efi/memmap.c +++ b/drivers/firmware/efi/memmap.c @@ -15,10 +15,6 @@ #include <asm/early_ioremap.h> #include <asm/efi.h> -#ifndef __efi_memmap_free -#define __efi_memmap_free(phys, size, flags) do { } while (0) -#endif - /** * __efi_memmap_init - Common code for mapping the EFI memory map * @data: EFI memory map data @@ -51,11 +47,6 @@ int __init __efi_memmap_init(struct efi_memory_map_data *data) return -ENOMEM; } - if (efi.memmap.flags & (EFI_MEMMAP_MEMBLOCK | EFI_MEMMAP_SLAB)) - __efi_memmap_free(efi.memmap.phys_map, - efi.memmap.desc_size * efi.memmap.nr_map, - efi.memmap.flags); - map.phys_map = data->phys_map; map.nr_map = data->size / data->desc_size; map.map_end = map.map + data->size;

9 months, 4 weeks

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024