Re: [PATCH] kbuild: add extra-y to targets-for-modules

Sorry for the late reply. On 11/25/20 at 10:42P, Masahiro Yamada wrote: > On Tue, Nov 24, 2020 at 12:05 AM WANG Chao wrote: > > > > On 11/23/20 at 02:23P, Masahiro Yamada wrote: > > > On Tue, Nov 3, 2020 at 3:23 PM WANG Chao wrote: > > > > > > &g

Re: [PATCH] kbuild: add extra-y to targets-for-modules

On 11/23/20 at 02:23P, Masahiro Yamada wrote: > On Tue, Nov 3, 2020 at 3:23 PM WANG Chao wrote: > > > > extra-y target doesn't build for 'make M=...' since commit 6212804f2d78 > > ("kbuild: do not create built-in objects for external module builds"). > > >

[PATCH] kbuild: add extra-y to targets-for-modules

to targets-for-modules so that such kind of build works properly. Signed-off-by: WANG Chao --- scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index ae647379b579..0113a042d643 100644 --- a/scripts/Makefile.build +++

Re: [PATCH 1/3] RAS/CEC: fix __find_elem

On 04/25/19 at 03:56P, WANG Chao wrote: > On 04/18/19 at 11:41P, WANG Chao wrote: > > A left over pfn (because we don't clear) at ca->array[n] can be a match > > in __find_elem. Later it'd cause a memmove size overflow in del_elem. > > > > Signed-off-by: WANG Chao

Re: [PATCH 1/3] RAS/CEC: fix __find_elem

On 04/18/19 at 11:41P, WANG Chao wrote: > A left over pfn (because we don't clear) at ca->array[n] can be a match > in __find_elem. Later it'd cause a memmove size overflow in del_elem. > > Signed-off-by: WANG Chao > --- > drivers/ras/cec.c | 2 +- > 1 file changed, 1

Re: [PATCH 3/3] RAS/CEC: immediate soft-offline page when count_threshold == 1

On 04/20/19 at 01:57P, Borislav Petkov wrote: > On Thu, Apr 18, 2019 at 11:41:15AM +0800, WANG Chao wrote: > > count_threshol == 1 isn't working as expected. CEC only does soft > > offline the second time the same pfn is hit by a correctable error. > > So this? > > ---

[tip:ras/core] RAS/CEC: Increment cec_entered under the mutex lock

Commit-ID: 09cbd2197e9291d6a3d3f42873f06ca1f388c1a4 Gitweb: https://git.kernel.org/tip/09cbd2197e9291d6a3d3f42873f06ca1f388c1a4 Author: WANG Chao AuthorDate: Thu, 18 Apr 2019 03:41:14 + Committer: Borislav Petkov CommitDate: Sat, 20 Apr 2019 12:16:52 +0200 RAS/CEC: Increment

[tip:ras/core] RAS/CEC: Increment cec_entered under the mutex lock

Commit-ID: 06e0fe2d8e9178bda874a75083bc13647fbf983f Gitweb: https://git.kernel.org/tip/06e0fe2d8e9178bda874a75083bc13647fbf983f Author: WANG Chao AuthorDate: Thu, 18 Apr 2019 03:41:14 + Committer: Borislav Petkov CommitDate: Sat, 20 Apr 2019 12:13:13 +0200 RAS/CEC: Increment

[PATCH 3/3] RAS/CEC: immediate soft-offline page when count_threshold == 1

count_threshol == 1 isn't working as expected. CEC only does soft offline the second time the same pfn is hit by a correctable error. Signed-off-by: WANG Chao --- drivers/ras/cec.c | 36 +--- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/drivers

[PATCH 2/3] RAS/CEC: make ces_entered smp safe

ces_entered should be put in a critical section to avoid race condition. Signed-off-by: WANG Chao --- drivers/ras/cec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c index 2e0bf1269c31..702e4c02c713 100644 --- a/drivers/ras/cec.c

[PATCH 1/3] RAS/CEC: fix __find_elem

A left over pfn (because we don't clear) at ca->array[n] can be a match in __find_elem. Later it'd cause a memmove size overflow in del_elem. Signed-off-by: WANG Chao --- drivers/ras/cec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ras/cec.c b/drivers/ras/ce

[PATCH] x86/kvm: move kvm_load/put_guest_xcr0 into atomic context

V[i] == 1 and xcr0[i] == 0, XRSTORS will generate #GP (In this case, bit 9). Then ex_handler_fprestore kicks in and tries to reinitialize fpu by restoring init fpu state. Same story as last #GP, except we get DOUBLE FAULT this time. Cc: sta...@vger.kernel.org Signed-off-by: WANG Chao --- arch/x86/

[tip:x86/urgent] x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE

Commit-ID: e4f358916d528d479c3c12bd2fd03f2d5a576380 Gitweb: https://git.kernel.org/tip/e4f358916d528d479c3c12bd2fd03f2d5a576380 Author: WANG Chao AuthorDate: Tue, 11 Dec 2018 00:37:25 +0800 Committer: Borislav Petkov CommitDate: Wed, 9 Jan 2019 10:35:56 +0100 x86, modpost: Replace

Re: [PATCH] treewide: replace RETPOLINE with CONFIG_RETPOLINE

On 12/21/18 at 11:47P, Borislav Petkov wrote: > On Fri, Dec 21, 2018 at 05:33:47PM +0800, WANG Chao wrote: > > On 12/11/18 at 12:37P, WANG Chao wrote: > > > Since commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend > > > on compiler suppor

Re: [PATCH] treewide: replace RETPOLINE with CONFIG_RETPOLINE

On 12/21/18 at 11:47P, Borislav Petkov wrote: > On Fri, Dec 21, 2018 at 05:33:47PM +0800, WANG Chao wrote: > > On 12/11/18 at 12:37P, WANG Chao wrote: > > > Since commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend > > > on compiler suppor

Re: [PATCH] treewide: replace RETPOLINE with CONFIG_RETPOLINE

On 12/11/18 at 12:37P, WANG Chao wrote: > Since commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend > on compiler support"), RETPOLINE has been replaced by CONFIG_RETPOLINE. > > Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compile

[PATCH] treewide: replace RETPOLINE with CONFIG_RETPOLINE

Since commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support"), RETPOLINE has been replaced by CONFIG_RETPOLINE. Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support") Signed-off-by: WANG Chao --- arch/x86/ker

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

On 11/16/17 at 02:54P, Rafael J. Wysocki wrote: > On Thursday, November 16, 2017 10:50:36 AM CET WANG Chao wrote: > > On 11/16/17 at 01:24P, Rafael J. Wysocki wrote: > > > On Wednesday, November 15, 2017 10:33:47 AM CET WANG Chao wrote: > > > > On 11/15/17 at 0

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

On 11/16/17 at 02:54P, Rafael J. Wysocki wrote: > On Thursday, November 16, 2017 10:50:36 AM CET WANG Chao wrote: > > On 11/16/17 at 01:24P, Rafael J. Wysocki wrote: > > > On Wednesday, November 15, 2017 10:33:47 AM CET WANG Chao wrote: > > > > On 11/15/17 at 0

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

On 11/16/17 at 01:24P, Rafael J. Wysocki wrote: > On Wednesday, November 15, 2017 10:33:47 AM CET WANG Chao wrote: > > On 11/15/17 at 02:13P, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > > > > > > After co

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

On 11/16/17 at 01:24P, Rafael J. Wysocki wrote: > On Wednesday, November 15, 2017 10:33:47 AM CET WANG Chao wrote: > > On 11/15/17 at 02:13P, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > > > After commit 890da9cf0983 (Revert "x86: do no

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

.000s sys 0m0.002s - sync aperfmperf_snapshot_khz() w/o any sleep: # time cat /proc/cpuinfo > /dev/null real0m0.002s user0m0.000s sys 0m0.002s Thanks, WANG Chao > > Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce > the default delay between consecutive

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

erf_snapshot_khz() w/o any sleep: # time cat /proc/cpuinfo > /dev/null real0m0.002s user0m0.000s sys 0m0.002s Thanks, WANG Chao > > Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce > the default delay between consecutive APERF and MPERF reads to 10 ms, > w

Re: [PATCH] x86 / CPU: Avoid unnecessary IPIs in arch_freq_get_on_cpu()

t_on_cpu(). > > Fixes: 4815d3c56d1e (cpufreq: x86: Make scaling_cur_freq behave more as > expected) > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Looks good to me. Reviewed-by: WANG Chao <chao.w...@ucloud.cn> > --- > > This change was part

Re: [PATCH] x86 / CPU: Avoid unnecessary IPIs in arch_freq_get_on_cpu()

es: 4815d3c56d1e (cpufreq: x86: Make scaling_cur_freq behave more as > expected) > Signed-off-by: Rafael J. Wysocki Looks good to me. Reviewed-by: WANG Chao > --- > > This change was part of commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in > /proc/cpuinfo), but

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

On 11/10/17 at 08:25P, Ingo Molnar wrote: > > * Rafael J. Wysocki <rafael.j.wyso...@intel.com> wrote: > > > Hi Linus, > > > > On 11/9/2017 11:38 AM, WANG Chao wrote: > > > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) c

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

On 11/10/17 at 08:25P, Ingo Molnar wrote: > > * Rafael J. Wysocki wrote: > > > Hi Linus, > > > > On 11/9/2017 11:38 AM, WANG Chao wrote: > > > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused > > > a serious perf

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

On 11/10/17 at 12:04P, WANG Chao wrote: > On 11/10/17 at 01:06P, Rafael J. Wysocki wrote: > > On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote: > > > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki > > > <rafael.j.wyso...@inte

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

On 11/10/17 at 12:04P, WANG Chao wrote: > On 11/10/17 at 01:06P, Rafael J. Wysocki wrote: > > On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote: > > > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki > > > wrote: > > > > Hi Linus, >

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

On 11/10/17 at 01:06P, Rafael J. Wysocki wrote: > On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote: > > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki > > <rafael.j.wyso...@intel.com> wrote: > > > Hi Linus, > > > >

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

On 11/10/17 at 01:06P, Rafael J. Wysocki wrote: > On Thursday, November 9, 2017 11:30:54 PM CET Rafael J. Wysocki wrote: > > On Thu, Nov 9, 2017 at 5:06 PM, Rafael J. Wysocki > > wrote: > > > Hi Linus, > > > > > > On 11/9/2017 11:38 AM, WANG Chao wrote: &

[PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

.org # 4.13 Signed-off-by: WANG Chao <chao.w...@ucloud.cn> --- arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/proc.c | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 236999c54edc..c60922a6

[PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

.org # 4.13 Signed-off-by: WANG Chao --- arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/proc.c | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 236999c54edc..c60922a66385 100644 --- a/arch/x86

[PATCH v3] sched: unlikely corrupted stack end

e at it, it's better and cleaner to add unlikely() to task_stack_end_corrupted() macro. Signed-off-by: WANG Chao <wcw...@gmail.com> --- include/linux/sched.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 6e42ada26345..74a02bf

[PATCH v3] sched: unlikely corrupted stack end

e at it, it's better and cleaner to add unlikely() to task_stack_end_corrupted() macro. Signed-off-by: WANG Chao --- include/linux/sched.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 6e42ada26345..74a02bf30827 100644 --- a/i

Re: [PATCH v2] sched: unlikely corrupted stack end

> 在 2016年6月14日，下午6:26，Ingo Molnar <mi...@kernel.org> 写道： > > > * WANG Chao <wcw...@gmail.com> wrote: > >> >>> 在 2016年6月14日，下午4:56，Ingo Molnar <mi...@kernel.org> 写道： >>> >>> >>> * WANG Chao <wcw...@gmail.com>

Re: [PATCH v2] sched: unlikely corrupted stack end

> 在 2016年6月14日，下午6:26，Ingo Molnar 写道： > > > * WANG Chao wrote: > >> >>> 在 2016年6月14日，下午4:56，Ingo Molnar 写道： >>> >>> >>> * WANG Chao wrote: >>> >>>> unlikely() was dropped in commit ce03e4137bb2 ("sched

Re: [PATCH v2] sched: unlikely corrupted stack end

> 在 2016年6月14日，下午4:56，Ingo Molnar <mi...@kernel.org> 写道： > > > * WANG Chao <wcw...@gmail.com> wrote: > >> unlikely() was dropped in commit ce03e4137bb2 ("sched/core: Drop >> unlikely behind BUG_ON()"), but commit 29d6455178a0 ("s

Re: [PATCH v2] sched: unlikely corrupted stack end

> 在 2016年6月14日，下午4:56，Ingo Molnar 写道： > > > * WANG Chao wrote: > >> unlikely() was dropped in commit ce03e4137bb2 ("sched/core: Drop >> unlikely behind BUG_ON()"), but commit 29d6455178a0 ("sched: panic on >> corrupted stack end") drop

[PATCH v2] sched: unlikely corrupted stack end

e at it, it's better and cleaner to turn task_stack_end_corrupted() into inline function. Signed-off-by: WANG Chao <wcw...@gmail.com> --- include/linux/sched.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 6e42ada

[PATCH v2] sched: unlikely corrupted stack end

e at it, it's better and cleaner to turn task_stack_end_corrupted() into inline function. Signed-off-by: WANG Chao --- include/linux/sched.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 6e42ada26345..797ca1975431 100644

[PATCH] sched: unlikely corrupted stack end

unlikely() was dropped in commit ce03e41 ("sched/core: Drop unlikely behind BUG_ON()"), but commit 29d6455 ("sched: panic on corrupted stack end") dropped BUG_ON() and called panic directly. Now we should bring unlikely() back for branch prediction. Signed-off-by: WANG Ch

[PATCH] sched: unlikely corrupted stack end

unlikely() was dropped in commit ce03e41 ("sched/core: Drop unlikely behind BUG_ON()"), but commit 29d6455 ("sched: panic on corrupted stack end") dropped BUG_ON() and called panic directly. Now we should bring unlikely() back for branch prediction. Signed-off-by: WANG Cha

[tip:x86/mm] x86, e820: Clean up sanitize_e820_map() users

Commit-ID: d574ffa1066003569ed5cdaeabf44597564ce975 Gitweb: http://git.kernel.org/tip/d574ffa1066003569ed5cdaeabf44597564ce975 Author: WANG Chao AuthorDate: Wed, 7 Jan 2015 11:37:38 +0800 Committer: Thomas Gleixner CommitDate: Fri, 23 Jan 2015 16:14:27 +0100 x86, e820: Clean up

[tip:x86/mm] x86, setup: Let early_memremap() handle page alignment

Commit-ID: 7389882c81474d635a208726edb22938645ff9ad Gitweb: http://git.kernel.org/tip/7389882c81474d635a208726edb22938645ff9ad Author: WANG Chao AuthorDate: Wed, 7 Jan 2015 18:55:48 +0800 Committer: Thomas Gleixner CommitDate: Fri, 23 Jan 2015 16:14:26 +0100 x86, setup: Let

[tip:x86/mm] x86, e820: Clean up sanitize_e820_map() users

Commit-ID: d574ffa1066003569ed5cdaeabf44597564ce975 Gitweb: http://git.kernel.org/tip/d574ffa1066003569ed5cdaeabf44597564ce975 Author: WANG Chao chaow...@redhat.com AuthorDate: Wed, 7 Jan 2015 11:37:38 +0800 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Fri, 23 Jan 2015 16:14

[tip:x86/mm] x86, setup: Let early_memremap() handle page alignment

Commit-ID: 7389882c81474d635a208726edb22938645ff9ad Gitweb: http://git.kernel.org/tip/7389882c81474d635a208726edb22938645ff9ad Author: WANG Chao chaow...@redhat.com AuthorDate: Wed, 7 Jan 2015 18:55:48 +0800 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Fri, 23 Jan 2015 16:14

Re: [PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT

On 01/22/15 at 11:22am, Rik van Riel wrote: > On 01/22/2015 11:19 AM, Davidlohr Bueso wrote: > > On Thu, 2015-01-22 at 15:57 +0800, WANG Chao wrote: > >> Hi, Davidlohr > >> > >> On 01/21/15 at 11:46pm, Davidlohr Bueso wrote: > >>> On Thu, 2015-0

Re: [PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT

On 01/22/15 at 11:22am, Rik van Riel wrote: On 01/22/2015 11:19 AM, Davidlohr Bueso wrote: On Thu, 2015-01-22 at 15:57 +0800, WANG Chao wrote: Hi, Davidlohr On 01/21/15 at 11:46pm, Davidlohr Bueso wrote: On Thu, 2015-01-22 at 14:29 +0800, WANG Chao wrote: Add a new kconfig option

Re: [PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT

Hi, Davidlohr On 01/21/15 at 11:46pm, Davidlohr Bueso wrote: > On Thu, 2015-01-22 at 14:29 +0800, WANG Chao wrote: > > Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the > > number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 > > sl

[PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT

-by: WANG Chao --- include/linux/sched.h | 2 +- mm/Kconfig| 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 8db31ef..56fd96d 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -134,7 +134,7

Re: [PATCH] x86, e820: clean up around sanitize_e820_map()

Hi, David On 01/21/15 at 02:51pm, David Rientjes wrote: > On Wed, 7 Jan 2015, WANG Chao wrote: > > > The argument 3 of sanitize_e820_map() will only update upon a successful > > sanitization. Some of the callers may not be aware of this in the past. > > No

[PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT

-by: WANG Chao chaow...@redhat.com --- include/linux/sched.h | 2 +- mm/Kconfig| 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 8db31ef..56fd96d 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h

Re: [PATCH] x86, e820: clean up around sanitize_e820_map()

Hi, David On 01/21/15 at 02:51pm, David Rientjes wrote: On Wed, 7 Jan 2015, WANG Chao wrote: The argument 3 of sanitize_e820_map() will only update upon a successful sanitization. Some of the callers may not be aware of this in the past. Now clean up these callers. Signed-off

Re: [PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT

Hi, Davidlohr On 01/21/15 at 11:46pm, Davidlohr Bueso wrote: On Thu, 2015-01-22 at 14:29 +0800, WANG Chao wrote: Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both

[PATCH 1/2] x86: early_memremap exact size of struct setup_data

When early remapping setup_data, we can remap the structure alone, use sizeof(struct setup_data). No need to remap a larger area, we never access setup_data->data at that point. Signed-off-by: WANG Chao --- arch/x86/kernel/setup.c | 8 +++- 1 file changed, 3 insertions(+), 5 deleti

[PATCH 2/2] x86: add macro for_each_setup_data()

A common task for parsing setup_data is to iterate over setup_data's linked list, remap and do something and unmap. Now add macro for_each_setup_data() to do that. Signed-off-by: WANG Chao --- arch/x86/kernel/setup.c | 37 - 1 file changed, 12 insertions

[PATCH 1/2] x86: early_memremap exact size of struct setup_data

When early remapping setup_data, we can remap the structure alone, use sizeof(struct setup_data). No need to remap a larger area, we never access setup_data-data at that point. Signed-off-by: WANG Chao chaow...@redhat.com --- arch/x86/kernel/setup.c | 8 +++- 1 file changed, 3 insertions

[PATCH 2/2] x86: add macro for_each_setup_data()

A common task for parsing setup_data is to iterate over setup_data's linked list, remap and do something and unmap. Now add macro for_each_setup_data() to do that. Signed-off-by: WANG Chao chaow...@redhat.com --- arch/x86/kernel/setup.c | 37 - 1 file changed

[PATCH] x86, e820: clean up around sanitize_e820_map()

The argument 3 of sanitize_e820_map() will only update upon a successful sanitization. Some of the callers may not be aware of this in the past. Now clean up these callers. Signed-off-by: WANG Chao --- arch/x86/kernel/e820.c | 22 ++ 1 file changed, 6 insertions(+), 16

[PATCH] x86, e820: clean up around sanitize_e820_map()

The argument 3 of sanitize_e820_map() will only update upon a successful sanitization. Some of the callers may not be aware of this in the past. Now clean up these callers. Signed-off-by: WANG Chao chaow...@redhat.com --- arch/x86/kernel/e820.c | 22 ++ 1 file changed, 6

[PATCH] vmcore: fix PT_NOTE n_namesz, n_descsz overflow issue

yet. At least we could drop the bogus note so user space wouldn't be surprised. Signed-off-by: WANG Chao --- fs/proc/vmcore.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c index a90d6d35..4e61388 100644 --- a/fs/proc/vmcore.c +++

[PATCH] vmcore: fix PT_NOTE n_namesz, n_descsz overflow issue

. At least we could drop the bogus note so user space wouldn't be surprised. Signed-off-by: WANG Chao chaow...@redhat.com --- fs/proc/vmcore.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c index a90d6d35..4e61388 100644 --- a/fs/proc

Re: [PATCH 0/3] Fix kdump failures with crashkernel=high

Hi, On 12/03/14 at 11:35am, Joerg Roedel wrote: > Hi, > > On Wed, Dec 03, 2014 at 12:01:23PM +0800, WANG Chao wrote: > >From your experience It seems like swiotlb isn't working well with > > crashkernel=X,high alone. What about using crashkernel=X,low with > > crash

Re: [PATCH 0/3] Fix kdump failures with crashkernel=high

Hi, On 12/03/14 at 11:35am, Joerg Roedel wrote: Hi, On Wed, Dec 03, 2014 at 12:01:23PM +0800, WANG Chao wrote: From your experience It seems like swiotlb isn't working well with crashkernel=X,high alone. What about using crashkernel=X,low with crashkernel=X,high? Is there any reason you

Re: [PATCH 0/3] Fix kdump failures with crashkernel=high

t of low-memory allocated for the > crash-kernel is increase from 72MB to 256MB (only changing > the defaults, can still be overwritten by crashkernel=X,low). crashkernel=X,high shouldn't automatically reserve 72M low at the first place. Now it's going insane if you increase it to 256M b

Re: [PATCH 0/3] Fix kdump failures with crashkernel=high

to 256MB (only changing the defaults, can still be overwritten by crashkernel=X,low). crashkernel=X,high shouldn't automatically reserve 72M low at the first place. Now it's going insane if you increase it to 256M by default. Thanks WANG Chao This number comes from experiments on the affected

[tip:perf/core] perf test: fix typo in python test

Commit-ID: 887e73d7f42c6a146b572a0577e9875ccca66f37 Gitweb: http://git.kernel.org/tip/887e73d7f42c6a146b572a0577e9875ccca66f37 Author: WANG Chao AuthorDate: Wed, 12 Nov 2014 16:27:05 +0800 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 19 Nov 2014 12:33:47 -0300 perf test: fix

[tip:perf/core] perf test: fix typo in python test

Commit-ID: 887e73d7f42c6a146b572a0577e9875ccca66f37 Gitweb: http://git.kernel.org/tip/887e73d7f42c6a146b572a0577e9875ccca66f37 Author: WANG Chao chaow...@redhat.com AuthorDate: Wed, 12 Nov 2014 16:27:05 +0800 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Wed, 19 Nov

[PATCH] perf test: fix typo in python test

Library loading in python syntax should be 'import perf', not 'use perf'. Signed-off-by: WANG Chao --- tools/perf/tests/builtin-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c index 162c978..4b7d9ab

[PATCH] perf test: fix typo in python test

Library loading in python syntax should be 'import perf', not 'use perf'. Signed-off-by: WANG Chao chaow...@redhat.com --- tools/perf/tests/builtin-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c index

Re: [PATCH] kernel, add panic_on_warn

n, additional documentation, modify > !slowpath cases > [v3]: use proc_dointvec_minmax() in sysctl handler > [v4]: remove !slowpath cases, and add __read_mostly > [v5]: change to panic_on_warn, re-alphabetize Documentation/sysctl/kernel.txt > [v6]: disable on kdump kernel to avoid

Re: [PATCH] kernel, add panic_on_warn

, re-alphabetize Documentation/sysctl/kernel.txt [v6]: disable on kdump kernel to avoid bogus panicks. [v7]: swithch to core param, and remove change from v6 This looks good to me. Acked-by: WANG Chao chaow...@redhat.com --- Documentation/kdump/kdump.txt |7 ++ Documentation

[PATCH] iscsi_ibft: convert printk() to pr_foo()

Switch to pr_foo() and a common prefix ("iscsi_ibft: ") to each printk message it generates. The printk message used to break down into multiple lines, now squash these into a single string. Along with this patch, use multiple MODULE_AUTHOR() marco as recommended. Signed-off-by:

[PATCH] Documentation/ABI/testing/sysfs-ibft: fix a typo

Correct a sentence in Documentation/ABI/testing/sysfs-ibft. Signed-off-by: WANG Chao --- Documentation/ABI/testing/sysfs-ibft | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/sysfs-ibft b/Documentation/ABI/testing/sysfs-ibft index c2b7d11..cac3930

[PATCH] Documentation/ABI/testing/sysfs-ibft: fix a typo

Correct a sentence in Documentation/ABI/testing/sysfs-ibft. Signed-off-by: WANG Chao chaow...@redhat.com --- Documentation/ABI/testing/sysfs-ibft | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/sysfs-ibft b/Documentation/ABI/testing/sysfs-ibft index

[PATCH] iscsi_ibft: convert printk() to pr_foo()

Switch to pr_foo() and a common prefix (iscsi_ibft: ) to each printk message it generates. The printk message used to break down into multiple lines, now squash these into a single string. Along with this patch, use multiple MODULE_AUTHOR() marco as recommended. Signed-off-by: WANG Chao chaow

[tip:x86/build] x86/purgatory, build: Suppress kexec-purgatory.c is up to date message

Commit-ID: 3ea4b8ee2419e21295cabab66c317612c5a55d26 Gitweb: http://git.kernel.org/tip/3ea4b8ee2419e21295cabab66c317612c5a55d26 Author: WANG Chao AuthorDate: Tue, 14 Oct 2014 12:46:58 +0800 Committer: H. Peter Anvin CommitDate: Wed, 15 Oct 2014 08:31:21 -0700 x86/purgatory, build

[tip:x86/build] x86/purgatory, build: Suppress kexec-purgatory.c is up to date message

Commit-ID: 3ea4b8ee2419e21295cabab66c317612c5a55d26 Gitweb: http://git.kernel.org/tip/3ea4b8ee2419e21295cabab66c317612c5a55d26 Author: WANG Chao chaow...@redhat.com AuthorDate: Tue, 14 Oct 2014 12:46:58 +0800 Committer: H. Peter Anvin h...@zytor.com CommitDate: Wed, 15 Oct 2014 08:31:21

Re: [PATCH] arch/x86/purgatory/Makefile: supress kexec-purgatory.c is up to date message

On 10/14/14 at 05:52pm, Vivek Goyal wrote: > On Tue, Oct 14, 2014 at 12:46:58PM +0800, WANG Chao wrote: > > Supress this unnecessary message during kernel re-build > > (CONFIG_KEXEC_FILE=y): > > > > make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date. > &

[PATCH] staging, unisys: remove leftover function kmalloc_kernel()

kmalloc_kernel() previously declared in timskmodutils.h which recently got removed. Now also remove kmalloc_kernel(), because it's not used anywhere. Signed-off-by: WANG Chao --- drivers/staging/unisys/visorutil/visorkmodutils.c | 10 -- 1 file changed, 10 deletions(-) diff --git

Re: [PATCH] arch/x86/purgatory/Makefile: supress kexec-purgatory.c is up to date message

On 10/14/14 at 05:52pm, Vivek Goyal wrote: On Tue, Oct 14, 2014 at 12:46:58PM +0800, WANG Chao wrote: Supress this unnecessary message during kernel re-build (CONFIG_KEXEC_FILE=y): make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date. Signed-off-by: WANG Chao chaow

[PATCH] staging, unisys: remove leftover function kmalloc_kernel()

kmalloc_kernel() previously declared in timskmodutils.h which recently got removed. Now also remove kmalloc_kernel(), because it's not used anywhere. Signed-off-by: WANG Chao wangchao19890...@gmail.com --- drivers/staging/unisys/visorutil/visorkmodutils.c | 10 -- 1 file changed, 10

[PATCH] arch/x86/purgatory/Makefile: supress kexec-purgatory.c is up to date message

Supress this unnecessary message during kernel re-build (CONFIG_KEXEC_FILE=y): make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date. Signed-off-by: WANG Chao --- arch/x86/purgatory/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/purgatory/Makefile b/arch/x86

[PATCH] arch/x86/purgatory/Makefile: supress kexec-purgatory.c is up to date message

Supress this unnecessary message during kernel re-build (CONFIG_KEXEC_FILE=y): make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date. Signed-off-by: WANG Chao chaow...@redhat.com --- arch/x86/purgatory/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/purgatory

Re: [PATCH resend] staging, lustre: fix a sparse error

On 10/12/14 at 08:17pm, Al Viro wrote: > On Fri, Oct 10, 2014 at 11:21:16AM +0800, WANG Chao wrote: > > > I think __user annotation is for no dereferencing in kernel space. In > > this case, I think it's fine to override this error by __force. Because > > they're pointe

Re: [PATCH resend] staging, lustre: fix a sparse error

On 10/12/14 at 08:17pm, Al Viro wrote: On Fri, Oct 10, 2014 at 11:21:16AM +0800, WANG Chao wrote: I think __user annotation is for no dereferencing in kernel space. In this case, I think it's fine to override this error by __force. Because they're pointers with identical target types

Re: [PATCH resend] staging, lustre: fix a sparse error

On 10/09/14 at 05:58pm, Sudip Mukherjee wrote: > On Thu, Oct 09, 2014 at 06:25:10PM +0800, WANG Chao wrote: > > This fixes the following sparse error: > > > > drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c:393:9: error: > > incompatible types in compa

[PATCH resend] staging, lustre: fix a sparse error

This fixes the following sparse error: drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c:393:9: error: incompatible types in comparison expression (different address spaces) Signed-off-by: WANG Chao --- drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c | 2 +- 1 file

[PATCH resend] staging, lustre: fix a sparse error

This fixes the following sparse error: drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c:393:9: error: incompatible types in comparison expression (different address spaces) Signed-off-by: WANG Chao wangchao19890...@gmail.com --- drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib

Re: [PATCH resend] staging, lustre: fix a sparse error

On 10/09/14 at 05:58pm, Sudip Mukherjee wrote: On Thu, Oct 09, 2014 at 06:25:10PM +0800, WANG Chao wrote: This fixes the following sparse error: drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c:393:9: error: incompatible types in comparison expression (different address

Re: [PATCH] mm, slub: do not add duplicate sysfs

On 08/28/14 at 09:47am, Christoph Lameter wrote: > On Thu, 28 Aug 2014, WANG Chao wrote: > > > What about failslab_store()? SLAB_FAILSLAB is also a nomerge flag. > > > Subject: slub: Disable tracing and failslab for merged slabs > > Tracing of mergeable slabs

Re: [PATCH] mm, slub: do not add duplicate sysfs

On 08/28/14 at 09:47am, Christoph Lameter wrote: On Thu, 28 Aug 2014, WANG Chao wrote: What about failslab_store()? SLAB_FAILSLAB is also a nomerge flag. Subject: slub: Disable tracing and failslab for merged slabs Tracing of mergeable slabs as well as uses of failslab are confusing

Re: [PATCH] mm, slub: do not add duplicate sysfs

On 08/27/14 at 10:32am, Christoph Lameter wrote: > Maybe something like this may be a proper fix: > > Subject: slub: Disable tracing of mergeable slabs > > Tracing of mergeable slabs is confusing since the objects > of multiple slab caches will be traced. Moreover this creates > a situation

Re: [PATCH] mm, slub: do not add duplicate sysfs

On 08/27/14 at 10:25am, Christoph Lameter wrote: > On Wed, 27 Aug 2014, WANG Chao wrote: > > > Mergeable slab can be changed to unmergeable after tuning its sysfs > > interface, for example echo 1 > trace. But the sysfs kobject with the unique > > name will be still

[PATCH] mm, slub: do not add duplicate sysfs

/:t-048-1, if this one is taken too, we increase the index value each time, :t-048-2, :t-048-3 ... until we find one. Signed-off-by: WANG Chao --- mm/slub.c | 34 -- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c in

[PATCH] mm, slub: do not add duplicate sysfs

/kernel/slab/:t-048 is already there, but not mergeable. We create another unique name with index suffix, /sys/kernel/slab/:t-048-1, if this one is taken too, we increase the index value each time, :t-048-2, :t-048-3 ... until we find one. Signed-off-by: WANG Chao chaow...@redhat.com

Re: [PATCH] mm, slub: do not add duplicate sysfs

On 08/27/14 at 10:25am, Christoph Lameter wrote: On Wed, 27 Aug 2014, WANG Chao wrote: Mergeable slab can be changed to unmergeable after tuning its sysfs interface, for example echo 1 trace. But the sysfs kobject with the unique name will be still there. Hmmm... Merging should

Re: [PATCH] mm, slub: do not add duplicate sysfs

On 08/27/14 at 10:32am, Christoph Lameter wrote: Maybe something like this may be a proper fix: Subject: slub: Disable tracing of mergeable slabs Tracing of mergeable slabs is confusing since the objects of multiple slab caches will be traced. Moreover this creates a situation where a

[linux-next PATCH] staging: android: ion: fix void function return statements

Fix checkpatch warning of void function return statements, found under drivers/staging/android/ion. Signed-off-by: WANG Chao --- drivers/staging/android/ion/ion.c | 1 - drivers/staging/android/ion/ion_carveout_heap.c | 1 - drivers/staging/android/ion/ion_chunk_heap.c| 1

  1   2   >