eep 1':
9,325 ftrace:function
1.004088470 seconds time elapsed
root#
The warning only appears the first time above perf command being triggered. You
won't see this until a fresh boot.
3.8 doesn't have this issue. Still exists on 3.9-rc3.
--
Thanks,
WANG Chao
--
To u
ommended
reserved memory here. Though I have to say crashkernel=128M is good choice.
I think it would be better to leave this to user or distribution itself to
determine how much memory should be reserved for crash kernel, then export
this value to kernel in some ways.
Thanks,
WANG C
also its memory consuming can vary very much from
>> each other. You just can't list all these generators and their recommended
>> reserved memory here. Though I have to say crashkernel=128M is good choice.
>>
>> I think it would be better
this a new ftrace_ops flag is added that denotes the ftrace_list_end
> ftrace_ops stub as just that, a stub. This flag is now checked in the
> control loop and the function is not called if the flag is set.
>
> Thanks to Jovi for not just reporting the bug, but also pointing out
&
:
Maps only in kallsyms:
end
vmlinux symtab matches kallsyms: FAILED!
The end addr of aesni_gcm_dec/aesni_gcm_enc in vmlinux symtab and
kallsyms is wrong beyond 4K.
I think that's a problem or am I missing some changes for these days?
--
Thanks,
WANG Chao
--
To unsubscribe from this
_events+0x2ea/0x910
[3.088981] [] ? __schedule+0x3de/0x7e0
[3.094451] [] hub_thread+0x35/0x1e0
[3.099661] [] ? wake_up_bit+0x40/0x40
[3.105045] [] ? hub_events+0x910/0x910
[3.110514] [] kthread+0xc0/0xd0
[3.115378] [] ? kthread_create_on_node+0x120/0x120
[ 3.121887] [] ret_fro
us and out of range while 3.8 reservation
>>> looks within the range.
>>>
>>> [0.00] Reserving 128MB of memory at 5216MB for crashkernel
>>> (System RAM: 3977MB)
>>>
>>> Wondering if anything to do with memblock again...
>>
>> that
On 03/08/2013 03:27 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao wrote:
>>>
>>> looks like your system DO have DMAR table, please enable dmar
>>> remapping in your kernel config.
>>
>> I've already got following config:
On 03/09/2013 03:39 AM, Yinghai Lu wrote:
> [ Add more to To list ]
>
> On Fri, Mar 8, 2013 at 10:24 AM, Yinghai Lu wrote:
>> On Fri, Mar 8, 2013 at 4:12 AM, WANG Chao wrote:
>>
>>>> what is 00:02.0 in your system?
>>> This IOMMU issue is related to ht
x86_64 kvm guest, it was booting
successfully and the issue mentioned is gone.
-WANG Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pl
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
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
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
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 support&q
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-
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
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
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 inser
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/driv
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
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/dr
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?
>
>
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 c
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: W
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
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")
On 10/28/13 at 11:12am, Vivek Goyal wrote:
> On Thu, Oct 24, 2013 at 10:48:29PM -0700, Yinghai Lu wrote:
> > On Thu, Oct 24, 2013 at 12:27 PM, Vivek Goyal wrote:
> > > On Thu, Oct 24, 2013 at 12:24:57PM -0700, Yinghai Lu wrote:
> > >> On Thu, Oct 24, 2013 at 12:18 PM, Vivek Goyal wrote:
> > >> >
helping push this change, to all of you.
WANG Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
y=xxx cmdline to 2nd kernel.
What do you think of this problem?
BTW MAINTAINERS file still uses your old email, please update
accordingly.
Thanks
WANG Chao
On 02/19/14 at 02:18pm, WANG Chao wrote:
> Hi, All
>
> arch/x86/kernel/pci-calgary.c is the only user of saved_max_pfn today:
&
t the empty PT_NOTE and continue to initialise vmcore.
And ultimately the multiple PT_NOTE are merged into a single one, all
empty PT_NOTE are discarded naturally during the merge. So empty PT_NOTE
is not visible to user space and vmcore is as good as expected.
Signed-off-by: WANG Chao
---
fs
Because it needs two conditions: first kernel's E820 map and
memmap=exactmap cmdline.
So I'm wondering if it's possible to get rid of saved_max_pfn totally in
calgary code. Or we can get saved_max_pfn using a different way, for
example calculated in 1st kernel and passed in to 2nd kernel
Remove m...@il.ibm.com from CC, this email isn't valid now.
On 02/19/14 at 09:36pm, Vivek Goyal wrote:
> On Wed, Feb 19, 2014 at 05:04:22PM -0700, Jon Mason wrote:
> > On Tue, Feb 18, 2014 at 11:18 PM, WANG Chao wrote:
> > > Hi, All
> > >
> > > arch/x86
gt; >
> > Reported-by: Matthew Whitehead
> > Reported-by: Dave Young
> > Tested-by: WANG Chao
> > Signed-off-by: Baoquan He
>
> Hi Bao,
>
> This patch fixes the issue for me too. I noticed that we have generic
> function migrate_to_reboot_cpu() to achiev
y to reserve a large crash kernel area. So the
failure of old kexec is consistent between old kernel and new kernel.
Signed-off-by: WANG Chao
---
arch/x86/kernel/setup.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f0d
On 10/14/13 at 11:54am, Yinghai Lu wrote:
> On Mon, Oct 14, 2013 at 4:46 AM, WANG Chao wrote:
> > Now crashkernel=X will fail out if there's not enough memory at
> > low (below 896M). What makes sense for crashkernel=X would be:
> >
> > - First try to reserve X
On 10/24/13 at 12:04pm, Yinghai Lu wrote:
> On Mon, Oct 14, 2013 at 4:46 AM, WANG Chao wrote:
> > Now crashkernel=X will fail out if there's not enough memory at
> > low (below 896M). What makes sense for crashkernel=X would be:
> >
> > - First try to reserve X
e name it in a unified prefix as others.
>
> And name of the default dummy function in kernel/kexec.c is not consistent
> with the arch specific one, so currently
> arch_image_file_post_load_cleanup of x86 arch is not called. Please
> consider wihch one nee
ed_max_pfn to kdump kernel in any way.
Signed-off-by: WANG Chao
---
arch/x86/kernel/pci-calgary_64.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 299d493..b26ab94 100644
---
Hi, Vivek
On 03/07/14 at 09:14am, Vivek Goyal wrote:
> On Fri, Mar 07, 2014 at 04:10:16PM +0800, WANG Chao wrote:
>
> [..]
> > }
> >
> > - specified_table_size = determine_tce_table_size((is_kdump_kernel() ?
> > - sav
On 03/07/14 at 11:09am, Vivek Goyal wrote:
> On Fri, Mar 07, 2014 at 11:52:04PM +0800, WANG Chao wrote:
> > Hi, Vivek
> >
> > On 03/07/14 at 09:14am, Vivek Goyal wrote:
> > > On Fri, Mar 07, 2014 at 04:
id of saved_max_pfn this time, for backward compatibility
with old first kernel and new second kernel. However new first kernel
and old second kernel can not work unfortunately.
v2->v1:
- retain saved_max_pfn so new 2nd kernel can work with old 1st kernel
from Vivek
Signed-off-by: WANG Chao
-
nd updates
its callers accordingly.
v2: Fix arch/tile/kernel/module.c::module_alloc().
Signed-off-by: WANG Chao
---
arch/tile/kernel/module.c| 2 +-
drivers/lguest/core.c| 7 ++-
drivers/staging/android/binder.c | 4 +---
include/linux/vmalloc.h | 2 +-
mm
nd updates
its callers accordingly.
Signed-off-by: WANG Chao
---
drivers/lguest/core.c| 7 ++-
drivers/staging/android/binder.c | 4 +---
include/linux/vmalloc.h | 2 +-
mm/vmalloc.c | 14 +-
mm/zsmalloc.c| 2 +
h loaded case.
I'm not quite familiar with this. But I'm wondering if it makes sense to
skip handle_relocation() if kaslr doesn't take effects (nokaslr or
kaslr failed to find suitable area).
Thanks
WANG Chao
--
To unsubscribe from this list: send the line "unsubscribe
On 04/21/14 at 11:01am, Kees Cook wrote:
> On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu wrote:
> > On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao wrote:
> >> Hi, Kees
> >>
> >> When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded
> &g
On 04/21/14 at 09:58pm, Yinghai Lu wrote:
> On Mon, Apr 21, 2014 at 8:16 PM, WANG Chao wrote:
> > On 04/21/14 at 11:01am, Kees Cook wrote:
> >> On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu wrote:
> >> > On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao wrote:
> >&g
Fix checkpatch warning of missing a blank line after declarations,
found under drivers/staging/android/ion/.
Signed-off-by: WANG Chao
---
drivers/staging/android/ion/ion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
On 07/24/14 at 02:26am, WANG Chao wrote:
> Fix checkpatch warning of missing a blank line after declarations,
> found under drivers/staging/android/ion/.
Sorry I forgot to mention this is for linux-next.
>
> Signed-off-by: WANG Chao
> ---
> drivers/staging/android/ion/ion
Fix checkpatch warning of prefer kcalloc over kzalloc with multiply,
found under drivers/staging/android/ion/.
Signed-off-by: WANG Chao
---
drivers/staging/android/ion/ion_dummy_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion
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
On 06/05/14 at 11:22am, Vivek Goyal wrote:
> On Thu, Jun 05, 2014 at 11:16:39AM -0400, Vivek Goyal wrote:
> > On Thu, Jun 05, 2014 at 05:56:03PM +0800, WANG Chao wrote:
> >
> > [..]
> > > > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > > > index
t;
> + }
> +
> + image->cmdline_buf_len = cmdline_len;
> +
> + /* command line should be a string with last byte null */
> + if (image->cmdline_buf[cmdline_len - 1] != '\0') {
> + ret = -EINVAL;
> + goto out;
> +
On 06/09/14 at 10:11am, Dave Young wrote:
> On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> > On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > > Previous patch provided the interface def
On 06/13/14 at 09:50am, Borislav Petkov wrote:
> On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote:
> > IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does
> > not tell us anything about command line size supported by kernel being
> > loaded.
>
> Whatever you do, you d
On 06/13/14 at 10:10am, Borislav Petkov wrote:
> On Fri, Jun 13, 2014 at 04:00:28PM +0800, WANG Chao wrote:
> > By greping for COMMAND_LINE_SIZE for different arch, I think 8K being
> > the fallback, in general, is good for now and the future:
>
> Why - we could simply use
{ "mem-min",1, 0, OPT_MEM_MIN }, \
> { "mem-max",1, 0, OPT_MEM_MAX }, \
> { "reuseinitrd",0, 0, OPT_REUSE_INITRD }, \
> + { "use-kexec2-syscall", 0, 0, OPT_USE_KEXEC2_SYSCALL }, \
> { "
int *initrd_fd as the argument? Then
if I don't need initrd, in userspace I can do this:
kexec_file_load(&kernel_fd, NULL, ...)
And even you can remove KEXEC_FILE_UNLOAD flag, because you could tell
that one wants to unload if the following is invoked:
kexec_file_load(NULL, NULL, ...)
: Kernel code
0167b6a6-01d06cbf : Kernel data
01e6d000-01feafff : Kernel bss
bb00-bf7f : Crash kernel
bfdffc00-bfe53bff : ACPI Non-volatile Storage
I apply your patch on top of 3.13-rc3. And makedumpfile can successfully
extract dump with mmap().
Thanks,
WANG Chao
> ---
> fs/
ption if it is large memory system.
>
> ",high" will work smaller or large memory system after you install new
> kexec tools.
>
> Again, for distribution, when new kernel is added, new kernel will all
> have ",high"
> and new kexec-tools get installed.
>
ernel/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
---
mm/slub.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/mm/slub.c b/mm
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
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
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 w
n_warn, 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
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'
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/arc
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 --
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.
&
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
in
ult 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 increa
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
> >
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
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:
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
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
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
: 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
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
been identified 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/f
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 support&q
re
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..797ca1975
> 在 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
> 在 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
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 1006
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
tch patch module.
Add extra-y 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 1006
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/
nc 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 APERF and MPERF reads to 10
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
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
.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
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:
&
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,
>
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
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
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
Commit-ID: 936329de1e6bf3dfa8c056074e6fc6b673e7b1d0
Gitweb: http://git.kernel.org/tip/936329de1e6bf3dfa8c056074e6fc6b673e7b1d0
Author: WANG Chao
AuthorDate: Mon, 10 Mar 2014 22:52:00 +0800
Committer: H. Peter Anvin
CommitDate: Thu, 20 Mar 2014 14:51:39 -0700
x86, calgary: Use 8M TCE
Commit-ID: 0534af01cca338193abbfdb53650af91e65dbf10
Gitweb: http://git.kernel.org/tip/0534af01cca338193abbfdb53650af91e65dbf10
Author: WANG Chao
AuthorDate: Mon, 10 Mar 2014 22:52:00 +0800
Committer: H. Peter Anvin
CommitDate: Thu, 10 Apr 2014 19:51:32 -0700
x86, calgary: Use 8M TCE
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
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
1 - 100 of 103 matches
Mail list logo
