- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "coda: fix 'kernel memory exposure attempt' in fsync" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coda: fix 'kernel memory exposure attempt' in fsync to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: coda-fix-kernel-memory-exposure-attempt-in-fsync.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d337b66a4c52c7b04eec661d86c2ef6e168965a2 Mon Sep 17 00:00:00 2001 From: Jan Harkes <jaharkes(a)cs.cmu.edu> Date: Wed, 27 Sep 2017 15:52:12 -0400 Subject: coda: fix 'kernel memory exposure attempt' in fsync From: Jan Harkes <jaharkes(a)cs.cmu.edu> commit d337b66a4c52c7b04eec661d86c2ef6e168965a2 upstream. When an application called fsync on a file in Coda a small request with just the file identifier was allocated, but the declared length was set to the size of union of all possible upcall requests. This bug has been around for a very long time and is now caught by the extra checking in usercopy that was introduced in Linux-4.8. The exposure happens when the Coda cache manager process reads the fsync upcall request at which point it is killed. As a result there is nobody servicing any further upcalls, trapping any processes that try to access the mounted Coda filesystem. Signed-off-by: Jan Harkes <jaharkes(a)cs.cmu.edu> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/coda/upcall.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/coda/upcall.c +++ b/fs/coda/upcall.c @@ -446,8 +446,7 @@ int venus_fsync(struct super_block *sb, UPARG(CODA_FSYNC); inp->coda_fsync.VFid = *fid; - error = coda_upcall(coda_vcp(sb), sizeof(union inputArgs), - &outsize, inp); + error = coda_upcall(coda_vcp(sb), insize, &outsize, inp); CODA_FREE(inp, insize); return error; Patches currently in stable-queue which might be from jaharkes(a)cs.cmu.edu are queue-4.9/coda-fix-kernel-memory-exposure-attempt-in-fsync.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "coda: fix 'kernel memory exposure attempt' in fsync" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coda: fix 'kernel memory exposure attempt' in fsync to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: coda-fix-kernel-memory-exposure-attempt-in-fsync.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d337b66a4c52c7b04eec661d86c2ef6e168965a2 Mon Sep 17 00:00:00 2001 From: Jan Harkes <jaharkes(a)cs.cmu.edu> Date: Wed, 27 Sep 2017 15:52:12 -0400 Subject: coda: fix 'kernel memory exposure attempt' in fsync From: Jan Harkes <jaharkes(a)cs.cmu.edu> commit d337b66a4c52c7b04eec661d86c2ef6e168965a2 upstream. When an application called fsync on a file in Coda a small request with just the file identifier was allocated, but the declared length was set to the size of union of all possible upcall requests. This bug has been around for a very long time and is now caught by the extra checking in usercopy that was introduced in Linux-4.8. The exposure happens when the Coda cache manager process reads the fsync upcall request at which point it is killed. As a result there is nobody servicing any further upcalls, trapping any processes that try to access the mounted Coda filesystem. Signed-off-by: Jan Harkes <jaharkes(a)cs.cmu.edu> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/coda/upcall.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/coda/upcall.c +++ b/fs/coda/upcall.c @@ -446,8 +446,7 @@ int venus_fsync(struct super_block *sb, UPARG(CODA_FSYNC); inp->coda_fsync.VFid = *fid; - error = coda_upcall(coda_vcp(sb), sizeof(union inputArgs), - &outsize, inp); + error = coda_upcall(coda_vcp(sb), insize, &outsize, inp); CODA_FREE(inp, insize); return error; Patches currently in stable-queue which might be from jaharkes(a)cs.cmu.edu are queue-4.4/coda-fix-kernel-memory-exposure-attempt-in-fsync.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "coda: fix 'kernel memory exposure attempt' in fsync" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coda: fix 'kernel memory exposure attempt' in fsync to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: coda-fix-kernel-memory-exposure-attempt-in-fsync.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d337b66a4c52c7b04eec661d86c2ef6e168965a2 Mon Sep 17 00:00:00 2001 From: Jan Harkes <jaharkes(a)cs.cmu.edu> Date: Wed, 27 Sep 2017 15:52:12 -0400 Subject: coda: fix 'kernel memory exposure attempt' in fsync From: Jan Harkes <jaharkes(a)cs.cmu.edu> commit d337b66a4c52c7b04eec661d86c2ef6e168965a2 upstream. When an application called fsync on a file in Coda a small request with just the file identifier was allocated, but the declared length was set to the size of union of all possible upcall requests. This bug has been around for a very long time and is now caught by the extra checking in usercopy that was introduced in Linux-4.8. The exposure happens when the Coda cache manager process reads the fsync upcall request at which point it is killed. As a result there is nobody servicing any further upcalls, trapping any processes that try to access the mounted Coda filesystem. Signed-off-by: Jan Harkes <jaharkes(a)cs.cmu.edu> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/coda/upcall.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/coda/upcall.c +++ b/fs/coda/upcall.c @@ -447,8 +447,7 @@ int venus_fsync(struct super_block *sb, UPARG(CODA_FSYNC); inp->coda_fsync.VFid = *fid; - error = coda_upcall(coda_vcp(sb), sizeof(union inputArgs), - &outsize, inp); + error = coda_upcall(coda_vcp(sb), insize, &outsize, inp); CODA_FREE(inp, insize); return error; Patches currently in stable-queue which might be from jaharkes(a)cs.cmu.edu are queue-4.14/coda-fix-kernel-memory-exposure-attempt-in-fsync.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "coda: fix 'kernel memory exposure attempt' in fsync" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coda: fix 'kernel memory exposure attempt' in fsync to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: coda-fix-kernel-memory-exposure-attempt-in-fsync.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d337b66a4c52c7b04eec661d86c2ef6e168965a2 Mon Sep 17 00:00:00 2001 From: Jan Harkes <jaharkes(a)cs.cmu.edu> Date: Wed, 27 Sep 2017 15:52:12 -0400 Subject: coda: fix 'kernel memory exposure attempt' in fsync From: Jan Harkes <jaharkes(a)cs.cmu.edu> commit d337b66a4c52c7b04eec661d86c2ef6e168965a2 upstream. When an application called fsync on a file in Coda a small request with just the file identifier was allocated, but the declared length was set to the size of union of all possible upcall requests. This bug has been around for a very long time and is now caught by the extra checking in usercopy that was introduced in Linux-4.8. The exposure happens when the Coda cache manager process reads the fsync upcall request at which point it is killed. As a result there is nobody servicing any further upcalls, trapping any processes that try to access the mounted Coda filesystem. Signed-off-by: Jan Harkes <jaharkes(a)cs.cmu.edu> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/coda/upcall.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/coda/upcall.c +++ b/fs/coda/upcall.c @@ -446,8 +446,7 @@ int venus_fsync(struct super_block *sb, UPARG(CODA_FSYNC); inp->coda_fsync.VFid = *fid; - error = coda_upcall(coda_vcp(sb), sizeof(union inputArgs), - &outsize, inp); + error = coda_upcall(coda_vcp(sb), insize, &outsize, inp); CODA_FREE(inp, insize); return error; Patches currently in stable-queue which might be from jaharkes(a)cs.cmu.edu are queue-4.13/coda-fix-kernel-memory-exposure-attempt-in-fsync.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "coda: fix 'kernel memory exposure attempt' in fsync" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coda: fix 'kernel memory exposure attempt' in fsync to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: coda-fix-kernel-memory-exposure-attempt-in-fsync.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d337b66a4c52c7b04eec661d86c2ef6e168965a2 Mon Sep 17 00:00:00 2001 From: Jan Harkes <jaharkes(a)cs.cmu.edu> Date: Wed, 27 Sep 2017 15:52:12 -0400 Subject: coda: fix 'kernel memory exposure attempt' in fsync From: Jan Harkes <jaharkes(a)cs.cmu.edu> commit d337b66a4c52c7b04eec661d86c2ef6e168965a2 upstream. When an application called fsync on a file in Coda a small request with just the file identifier was allocated, but the declared length was set to the size of union of all possible upcall requests. This bug has been around for a very long time and is now caught by the extra checking in usercopy that was introduced in Linux-4.8. The exposure happens when the Coda cache manager process reads the fsync upcall request at which point it is killed. As a result there is nobody servicing any further upcalls, trapping any processes that try to access the mounted Coda filesystem. Signed-off-by: Jan Harkes <jaharkes(a)cs.cmu.edu> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/coda/upcall.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/coda/upcall.c +++ b/fs/coda/upcall.c @@ -446,8 +446,7 @@ int venus_fsync(struct super_block *sb, UPARG(CODA_FSYNC); inp->coda_fsync.VFid = *fid; - error = coda_upcall(coda_vcp(sb), sizeof(union inputArgs), - &outsize, inp); + error = coda_upcall(coda_vcp(sb), insize, &outsize, inp); CODA_FREE(inp, insize); return error; Patches currently in stable-queue which might be from jaharkes(a)cs.cmu.edu are queue-3.18/coda-fix-kernel-memory-exposure-attempt-in-fsync.patch

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] mm, swap: fix false error message in __swp_swapcount()" failed to apply to 4.13-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.13-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 e9a6effa500526e2a19d5ad042cb758b55b1ef93 Mon Sep 17 00:00:00 2001 From: Huang Ying <huang.ying.caritas(a)gmail.com> Date: Wed, 15 Nov 2017 17:33:15 -0800 Subject: [PATCH] mm, swap: fix false error message in __swp_swapcount() When a page fault occurs for a swap entry, the physical swap readahead (not the VMA base swap readahead) may readahead several swap entries after the fault swap entry. The readahead algorithm calculates some of the swap entries to readahead via increasing the offset of the fault swap entry without checking whether they are beyond the end of the swap device and it relys on the __swp_swapcount() and swapcache_prepare() to check it. Although __swp_swapcount() checks for the swap entry passed in, it will complain with the error message as follow for the expected invalid swap entry. This may make the end users confused. swap_info_get: Bad swap offset entry 0200f8a7 To fix the false error message, the swap entry checking is added in swapin_readahead() to avoid to pass the out-of-bound swap entries and the swap entry reserved for the swap header to __swp_swapcount() and swapcache_prepare(). Link: http://lkml.kernel.org/r/20171102054225.22897-1-ying.huang@intel.com Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots") Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com> Reported-by: Christian Kujau <lists(a)nerdbynature.de> Acked-by: Minchan Kim <minchan(a)kernel.org> Suggested-by: Minchan Kim <minchan(a)kernel.org> Cc: Tim Chen <tim.c.chen(a)linux.intel.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> [4.11+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/swap_state.c b/mm/swap_state.c index 326439428daf..f2face8b889e 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -559,6 +559,7 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t gfp_mask, unsigned long offset = entry_offset; unsigned long start_offset, end_offset; unsigned long mask; + struct swap_info_struct *si = swp_swap_info(entry); struct blk_plug plug; bool do_poll = true, page_allocated; @@ -572,6 +573,8 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t gfp_mask, end_offset = offset | mask; if (!start_offset) /* First page is swap header. */ start_offset++; + if (end_offset >= si->max) + end_offset = si->max - 1; blk_start_plug(&plug); for (offset = start_offset; offset <= end_offset ; offset++) {

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] mm, swap: fix false error message in __swp_swapcount()" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-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 e9a6effa500526e2a19d5ad042cb758b55b1ef93 Mon Sep 17 00:00:00 2001 From: Huang Ying <huang.ying.caritas(a)gmail.com> Date: Wed, 15 Nov 2017 17:33:15 -0800 Subject: [PATCH] mm, swap: fix false error message in __swp_swapcount() When a page fault occurs for a swap entry, the physical swap readahead (not the VMA base swap readahead) may readahead several swap entries after the fault swap entry. The readahead algorithm calculates some of the swap entries to readahead via increasing the offset of the fault swap entry without checking whether they are beyond the end of the swap device and it relys on the __swp_swapcount() and swapcache_prepare() to check it. Although __swp_swapcount() checks for the swap entry passed in, it will complain with the error message as follow for the expected invalid swap entry. This may make the end users confused. swap_info_get: Bad swap offset entry 0200f8a7 To fix the false error message, the swap entry checking is added in swapin_readahead() to avoid to pass the out-of-bound swap entries and the swap entry reserved for the swap header to __swp_swapcount() and swapcache_prepare(). Link: http://lkml.kernel.org/r/20171102054225.22897-1-ying.huang@intel.com Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots") Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com> Reported-by: Christian Kujau <lists(a)nerdbynature.de> Acked-by: Minchan Kim <minchan(a)kernel.org> Suggested-by: Minchan Kim <minchan(a)kernel.org> Cc: Tim Chen <tim.c.chen(a)linux.intel.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> [4.11+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/swap_state.c b/mm/swap_state.c index 326439428daf..f2face8b889e 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -559,6 +559,7 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t gfp_mask, unsigned long offset = entry_offset; unsigned long start_offset, end_offset; unsigned long mask; + struct swap_info_struct *si = swp_swap_info(entry); struct blk_plug plug; bool do_poll = true, page_allocated; @@ -572,6 +573,8 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t gfp_mask, end_offset = offset | mask; if (!start_offset) /* First page is swap header. */ start_offset++; + if (end_offset >= si->max) + end_offset = si->max - 1; blk_start_plug(&plug); for (offset = start_offset; offset <= end_offset ; offset++) {

7 years, 2 months

1
0
0 0

[Linux-stable-mirror] Patch "mm, swap: fix false error message in __swp_swapcount()" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm, swap: fix false error message in __swp_swapcount() to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-swap-fix-false-error-message-in-__swp_swapcount.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e9a6effa500526e2a19d5ad042cb758b55b1ef93 Mon Sep 17 00:00:00 2001 From: Huang Ying <huang.ying.caritas(a)gmail.com> Date: Wed, 15 Nov 2017 17:33:15 -0800 Subject: mm, swap: fix false error message in __swp_swapcount() From: Huang Ying <huang.ying.caritas(a)gmail.com> commit e9a6effa500526e2a19d5ad042cb758b55b1ef93 upstream. When a page fault occurs for a swap entry, the physical swap readahead (not the VMA base swap readahead) may readahead several swap entries after the fault swap entry. The readahead algorithm calculates some of the swap entries to readahead via increasing the offset of the fault swap entry without checking whether they are beyond the end of the swap device and it relys on the __swp_swapcount() and swapcache_prepare() to check it. Although __swp_swapcount() checks for the swap entry passed in, it will complain with the error message as follow for the expected invalid swap entry. This may make the end users confused. swap_info_get: Bad swap offset entry 0200f8a7 To fix the false error message, the swap entry checking is added in swapin_readahead() to avoid to pass the out-of-bound swap entries and the swap entry reserved for the swap header to __swp_swapcount() and swapcache_prepare(). Link: http://lkml.kernel.org/r/20171102054225.22897-1-ying.huang@intel.com Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots") Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com> Reported-by: Christian Kujau <lists(a)nerdbynature.de> Acked-by: Minchan Kim <minchan(a)kernel.org> Suggested-by: Minchan Kim <minchan(a)kernel.org> Cc: Tim Chen <tim.c.chen(a)linux.intel.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Hugh Dickins <hughd(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/swap_state.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -506,6 +506,7 @@ struct page *swapin_readahead(swp_entry_ unsigned long offset = entry_offset; unsigned long start_offset, end_offset; unsigned long mask; + struct swap_info_struct *si = swp_swap_info(entry); struct blk_plug plug; bool do_poll = true; @@ -519,6 +520,8 @@ struct page *swapin_readahead(swp_entry_ end_offset = offset | mask; if (!start_offset) /* First page is swap header. */ start_offset++; + if (end_offset >= si->max) + end_offset = si->max - 1; blk_start_plug(&plug); for (offset = start_offset; offset <= end_offset ; offset++) { Patches currently in stable-queue which might be from huang.ying.caritas(a)gmail.com are queue-4.13/mm-swap-fix-false-error-message-in-__swp_swapcount.patch

7 years, 2 months

2
1
0 0

[Linux-stable-mirror] Please add lkft-triage@lists.linaro.org to your announcement e-mails

by Anmar Oueja

Hello Greg, Can you please add lkft-triage(a)lists.linaro.org ML to your CC when sending your announcement e-mails. Thanks, anmar

7 years, 2 months

2
1
0 0

[Linux-stable-mirror] Patch "x86/cpu/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/cpu/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-cpu-amd-derive-l3-shared_cpu_map-from-cpu_llc_shared_mask.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2b83809a5e6d619a780876fcaf68cdc42b50d28c Mon Sep 17 00:00:00 2001 From: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com> Date: Mon, 31 Jul 2017 10:51:59 +0200 Subject: x86/cpu/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask From: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com> commit 2b83809a5e6d619a780876fcaf68cdc42b50d28c upstream. For systems with X86_FEATURE_TOPOEXT, current logic uses the APIC ID to calculate shared_cpu_map. However, APIC IDs are not guaranteed to be contiguous for cores across different L3s (e.g. family17h system w/ downcore configuration). This breaks the logic, and results in an incorrect L3 shared_cpu_map. Instead, always use the previously calculated cpu_llc_shared_mask of each CPU to derive the L3 shared_cpu_map. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20170731085159.9455-3-bp@alien8.de Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/intel_cacheinfo.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) --- a/arch/x86/kernel/cpu/intel_cacheinfo.c +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c @@ -811,7 +811,24 @@ static int __cache_amd_cpumap_setup(unsi struct cacheinfo *this_leaf; int i, sibling; - if (boot_cpu_has(X86_FEATURE_TOPOEXT)) { + /* + * For L3, always use the pre-calculated cpu_llc_shared_mask + * to derive shared_cpu_map. + */ + if (index == 3) { + for_each_cpu(i, cpu_llc_shared_mask(cpu)) { + this_cpu_ci = get_cpu_cacheinfo(i); + if (!this_cpu_ci->info_list) + continue; + this_leaf = this_cpu_ci->info_list + index; + for_each_cpu(sibling, cpu_llc_shared_mask(cpu)) { + if (!cpu_online(sibling)) + continue; + cpumask_set_cpu(sibling, + &this_leaf->shared_cpu_map); + } + } + } else if (boot_cpu_has(X86_FEATURE_TOPOEXT)) { unsigned int apicid, nshared, first, last; this_leaf = this_cpu_ci->info_list + index; @@ -837,19 +854,6 @@ static int __cache_amd_cpumap_setup(unsi continue; cpumask_set_cpu(sibling, &this_leaf->shared_cpu_map); - } - } - } else if (index == 3) { - for_each_cpu(i, cpu_llc_shared_mask(cpu)) { - this_cpu_ci = get_cpu_cacheinfo(i); - if (!this_cpu_ci->info_list) - continue; - this_leaf = this_cpu_ci->info_list + index; - for_each_cpu(sibling, cpu_llc_shared_mask(cpu)) { - if (!cpu_online(sibling)) - continue; - cpumask_set_cpu(sibling, - &this_leaf->shared_cpu_map); } } } else Patches currently in stable-queue which might be from suravee.suthikulpanit(a)amd.com are queue-4.13/x86-cpu-amd-derive-l3-shared_cpu_map-from-cpu_llc_shared_mask.patch

7 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror