>/dev/null; \
make clean >/dev/null 2>&1; \
sync'\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
233.574187771 seconds time ela
/include/asm-generic/fixmap.h:31: undefined
reference to `__compiletime_assert_31'
Makefile:1051: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Signed-off-by: Du Changbin
Acked-by: Steven Rostedt (VMware)
---
arch/arm/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+
will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.
Signed-off-by: Du Changbin
Acked-by: Steven Rostedt (VMware)
---
Makefile | 6 ++
lib/Kconfig.debug | 17 +
2 files changed, 23 insertions(+)
di
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
233.574187771 seconds time elapsed ( +- 0.19% )
Du Changbin (4):
x86/mm: surround level4_kernel_pgt with #ifdef
CONFIG_X86_5LEVEL...#endif
kernel hacking
The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.
Signed-off-by: Du Changbin
Acked-by: Steven Rostedt (VMware)
---
arch/x86/include/asm/pgtable_64.h | 2 ++
arch/x86/kernel/head64.c
On Thu, Oct 18, 2018 at 12:59:48PM -0400, Steven Rostedt wrote:
> On Thu, 18 Oct 2018 16:25:46 +
> Du Changbin wrote:
>
> > From: Changbin Du
> >
> > This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
> > this option will prevent the compi
On Thu, Oct 18, 2018 at 05:57:56PM +0100, Robin Murphy wrote:
> On 18/10/18 17:25, Du Changbin wrote:
> > From: Changbin Du
> >
> > This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
> > this option will prevent the compiler from optimizing the
From: Changbin Du
With '-Og' optimization level, GCC would not optimize a count for a loop
as a constant value. But BUILD_BUG_ON() only accept compile-time constant
values. Let's use __fix_to_virt() to avoid the error.
arch/arm/mm/mmu.o: In function `fix_to_virt':
/home/changbin/work/linux/./inc
From: Changbin Du
This will apply GCC '-Og' optimization level which is supported
since GCC 4.8. This optimization level offers a reasonable level
of optimization while maintaining fast compilation and a good
debugging experience. It is similar to '-O1' while perferring
to keep debug ability over
From: Changbin Du
The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.
Signed-off-by: Changbin Du
Acked-by: Steven Rostedt (VMware)
---
arch/x86/include/asm/pgtable_64.h | 2 ++
arch/x86/k
From: Changbin Du
This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
this option will prevent the compiler from optimizing the kernel by
auto-inlining functions not marked with the inline keyword.
With this option, only functions explicitly marked with "inline" will
be inlined.
Hi all,
I have posted this series several months ago but interrupted by personal
affairs. Now I get time to complete this task. Thanks for all of the
reviewers.
I know some kernel developers was searching for a method to dissable GCC
optimizations, probably they want to apply GCC '-O0' option. But
u3)) #21 SMP Sat Sep 1 21:43:30 CST 2018
Signed-off-by: Du Changbin
---
scripts/gdb/linux/proc.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gdb/linux/proc.py b/scripts/gdb/linux/proc.py
index 086d27223c0c..0aebd7565b03 100644
--- a/scripts/gdb/linux/proc.py
+++
Hi Bjorn. Have you checked this little improvment? The idea here is that
this is not a hotspot, so readbility matters than trick. Thanks!
On Sat, Oct 13, 2018 at 08:49:19AM +0800, changbin...@gmail.com wrote:
> From: Du Changbin
>
> Currently, the pci_size() function actually retur
2018
gdb 7.4 seems to be no such issue.
Signed-off-by: Du Changbin
---
scripts/gdb/linux/proc.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gdb/linux/proc.py b/scripts/gdb/linux/proc.py
index 086d27223c0c..0aebd7565b03 100644
--- a/scripts/gdb/linux/proc.py
+++
8
gdb 7.4 seems to be no such issue.
Signed-off-by: Du Changbin
---
scripts/gdb/linux/proc.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gdb/linux/proc.py b/scripts/gdb/linux/proc.py
index 086d27223c0c..0aebd7565b03 100644
--- a/scripts/gdb/linux/proc.py
+++ b/scripts
000 DR6: fffe0ff0 DR7: 0400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this bug report. See:
https://go
Hi,
On Thu, Jun 07, 2018 at 09:47:18AM +0530, Viresh Kumar wrote:
> +Greg/Alex,
>
> @Fegguang/build-bot: I do see mention of Greg and /me in your initial email's
> body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in
> your
> email. Bug ?
>
> On 06-06-18, 14:26, Steven Ros
On Tue, May 29, 2018 at 06:03:32PM +0200, Peter Zijlstra wrote:
> On Mon, Mar 19, 2018 at 03:23:25PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > Inspired by gdb command 'list', show the code context of target lines.
> > Here is a example:
> >
> > $ scripts/faddr2line vmlinu
On Wed, May 30, 2018 at 08:01:48AM +1000, NeilBrown wrote:
> On Tue, May 29 2018, Peter Zijlstra wrote:
>
> > On Tue, May 29, 2018 at 12:07:10PM -0500, Josh Poimboeuf wrote:
> >> Yeah, this change really should have been an optional arg. It hurt the
> >> readability and compactness of the output.
On Wed, May 09, 2018 at 08:52:24AM -0400, Steven Rostedt wrote:
> On Wed, 9 May 2018 16:43:16 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > With '-Og' optimization level, GCC would not optimize a count for a loop
> > as a constant value. But BUILD_BUG_ON() only accept com
On Wed, May 09, 2018 at 05:21:14PM +0900, Mark Brown wrote:
> On Sun, May 06, 2018 at 08:20:13AM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > If device tree is not enabled, of_find_regulator_by_node() should have
> > a dummy function since the function call is still there.
>
On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote:
> On Thu, 3 May 2018 21:45:46 +0800
> "Du, Changbin" wrote:
>
> > > With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more
> > > inline with what it is and understandable than
> &g
On Wed, May 02, 2018 at 03:56:31PM +0100, Daniel Thompson wrote:
> On Wed, May 02, 2018 at 09:44:55PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > Hi all,
> > I know some kernel developers was searching for a method to dissable GCC
> > optimizations, probably they want to app
On Wed, May 02, 2018 at 09:19:56PM -0400, Steven Rostedt wrote:
> On Wed, 2 May 2018 13:45:58 -0700
> Andrew Morton wrote:
>
> > On Wed, 2 May 2018 10:17:07 -0400 Steven Rostedt
> > wrote:
> >
> > > > Comparison of vmlinux size: a bit smaller.
> > > >
> > > > w/o CONFIG_DEBUG_EXPERIENCE
On Wed, May 02, 2018 at 10:19:30AM -0400, Steven Rostedt wrote:
> On Wed, 2 May 2018 21:45:00 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > With '-Og' optimization level, GCC would not optimize a count for a loop
> > as a constant value. But BUILD_BUG_ON() only accept com
On Wed, May 02, 2018 at 04:27:47PM -0400, Arnd Bergmann wrote:
> On Wed, May 2, 2018 at 9:44 AM, wrote:
> > From: Changbin Du
> >
> > This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
> > this option will prevent the compiler from optimizing the kernel by
> > auto-inlining fun
On Tue, May 01, 2018 at 10:54:20AM -0400, Steven Rostedt wrote:
> On Tue, 1 May 2018 21:00:12 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
> > this option will make compiler not auto-inline kernel funct
On Tue, May 01, 2018 at 08:25:27AM -0700, Randy Dunlap wrote:
> Good morning.
>
> On 05/01/2018 06:00 AM, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> >
> > Signed-off-by: Changbin Du
> > ---
> > Makefile | 4
> > include/linux/compiler-gcc.h | 2 +-
> >
On Wed, May 02, 2018 at 05:40:36AM +0900, Mark Brown wrote:
> On Tue, May 01, 2018 at 09:00:11PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > If device tree is not enabled, of_find_regulator_by_node() should have
> > a dummy function since the function call is still there.
>
On Wed, May 02, 2018 at 09:33:15AM +0200, Ingo Molnar wrote:
>
> * changbin...@intel.com wrote:
>
> > Comparison of system performance: a bit drop.
> >
> > w/o CONFIG_DEBUG_EXPERIENCE
> > $ time make -j4
> > real6m43.619s
> > user19m5.160s
> > sys 2m20.287s
> >
Hello, any reviewer? Thanks!
On Fri, Apr 20, 2018 at 01:29:55PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> It allows to flush more than 4GB of device TLBs. So the mask should be
> 64bit wide. UBSAN captured this fault as below.
>
> [3.760024]
>
On Sun, Apr 08, 2018 at 09:19:58AM +0200, Greg KH wrote:
> On Sun, Apr 08, 2018 at 10:47:12AM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > There is an format error in driver-api/usb/typec.rst that breaks sphinx
> > docs building.
> >
> > reST markup error:
> > /home/changbin
On Tue, Apr 03, 2018 at 04:19:07PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 28, 2018 at 03:26:31PM +0800, Du, Changbin escreveu:
> > Hi Arnaldo,
> > Just a kind reminder. Hope you didn't forget this.
>
> Ok, applied.
>
> - Arnaldo
>
Got it, thanks!
Hi Arnaldo,
Just a kind reminder. Hope you didn't forget this.
On Fri, Mar 16, 2018 at 09:50:45AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 16, 2018 at 03:51:09PM +0800, Du, Changbin escreveu:
> > Hi Arnaldo, How about this simple one? Thanks.
> >
> > On
On Tue, Mar 27, 2018 at 03:19:26PM -0600, Shuah Khan wrote:
> On 03/26/2018 09:11 PM, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > The tools/build/Makefile.build use 'OUTPUT' variable as below example:
> > objprefix:= $(subst ./,,$(OUTPUT)$(dir)/)
> >
> > So it requires the 'OU
On Tue, Mar 27, 2018 at 11:52:27AM +0200, Daniel Borkmann wrote:
> On 03/27/2018 11:00 AM, Du, Changbin wrote:
> > On Tue, Mar 27, 2018 at 10:52:57AM +0200, Daniel Borkmann wrote:
> >> On 03/27/2018 05:06 AM, Du, Changbin wrote:
> >>> On Mon, Mar 26, 2018 at 08:02:
On Tue, Mar 27, 2018 at 10:52:57AM +0200, Daniel Borkmann wrote:
> On 03/27/2018 05:06 AM, Du, Changbin wrote:
> > On Mon, Mar 26, 2018 at 08:02:30PM -0700, Alexei Starovoitov wrote:
> >> On Tue, Mar 27, 2018 at 10:20:10AM +0800, Du, Changbin wrote:
> >>> On Mon, Ma
On Mon, Mar 26, 2018 at 08:02:30PM -0700, Alexei Starovoitov wrote:
> On Tue, Mar 27, 2018 at 10:20:10AM +0800, Du, Changbin wrote:
> > On Mon, Mar 26, 2018 at 07:55:13AM -0700, Alexei Starovoitov wrote:
> > > On Mon, Mar 26, 2018 at 05:23:28PM +0800, changbin...@intel.com wro
Hi Starovoitov,
This one does have the issue you mentioned.
[PATCH 2/4] selftests/gpio: fix paths in Makefile
And can be fixed by:
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
+OUTPUT ?= $(shell pwd)
On Mon, Mar 26, 2018 at 07:55:13AM -0700, Alexei Starovoitov wrote:
> On Mon, Mar 26, 2018 at 05:23:28PM +0800, changbin...@intel.com wrote:
> > Signed-off-by: Changbin Du
> > ---
> > tools/testing/selftests/bpf/Makefile | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff
Hi Arnaldo, How about this simple one? Thanks.
On Tue, Mar 13, 2018 at 06:40:01PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> There is a redundant ')' at the tail of each event. So remove it.
> $ sudo perf trace --no-syscalls -e 'kmem:*' -a
>899.342 kmem:kfree:(vfs_writev+0xb
Hello everyone,
I got a warning as below which is a AB-BA deadlock issue. But I don't understand
how the 'existing dependency' happened.
It looks like: kvm_read_guest() held (&mm->mmap_sem), then reading userspace
memory
(which is not ready yet) caused page_fault() invoked, then in i915_gem_faul
On Wed, Mar 07, 2018 at 10:46:49AM -0700, Jonathan Corbet wrote:
> On Tue, 27 Feb 2018 17:43:37 -0500
> Steven Rostedt wrote:
>
> > On Tue, 27 Feb 2018 17:34:22 +0800
> > "Du, Changbin" wrote:
> >
> > > Ten days past, will you accept this
On Tue, Mar 06, 2018 at 11:17:07AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 06, 2018 at 08:53:02AM +0100, Jiri Olsa escreveu:
> > On Tue, Mar 06, 2018 at 11:37:35AM +0800, changbin...@intel.com wrote:
> > > From: Changbin Du
> > >
> > > v2:
> > > o add a patch to move thread::shortn
I just done final version, please check v2. Thanks for your comments!
On Mon, Mar 05, 2018 at 11:37:54PM +0100, Jiri Olsa wrote:
> On Mon, Mar 05, 2018 at 03:11:36PM +0800, Du, Changbin wrote:
>
> SNIP
>
> > > > on the other hand it's simple enough and looks
> &
On Fri, Mar 02, 2018 at 11:43:12AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Feb 23, 2018 at 07:40:40PM +0800, changbin...@intel.com escreveu:
> > From: Changbin Du
> >
> > This is to show the real name of thread that created via fork-exec.
> > See below example for shortname *A0*.
>
> Ca
Hi,
On Fri, Mar 02, 2018 at 11:47:32PM +0900, Namhyung Kim wrote:
> Hi,
>
> On Fri, Mar 02, 2018 at 12:38:45PM +0100, Jiri Olsa wrote:
> > On Fri, Mar 02, 2018 at 06:52:54PM +0800, Du, Changbin wrote:
> > > Hello, any comment?
> >
> > sry, overlooked this
Hello, any comment?
On Fri, Feb 23, 2018 at 07:40:40PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> This is to show the real name of thread that created via fork-exec.
> See below example for shortname *A0*.
>
> $ sudo ./perf sched map
> *A0 80393.050639 secs A0 =
On Fri, Mar 02, 2018 at 11:39:16AM +0100, Rafael J. Wysocki wrote:
> On 3/2/2018 11:15 AM, Du, Changbin wrote:
> > On Fri, Mar 02, 2018 at 11:18:10AM +0100, Rafael J. Wysocki wrote:
> > > On Fri, Mar 2, 2018 at 10:41 AM, Du, Changbin
> > > wrote:
> > > &
On Fri, Mar 02, 2018 at 11:18:10AM +0100, Rafael J. Wysocki wrote:
> On Fri, Mar 2, 2018 at 10:41 AM, Du, Changbin wrote:
> >> >> That rather isn't the case if negative values are ever passed to the
> >> >> tracepoint, right?
> >> >>
> >
> >> That rather isn't the case if negative values are ever passed to the
> >> tracepoint, right?
> >>
> > yes.
> >> Which seems to be the reason why you want to make this change, isn't it?
> >>
> > yes, to improve readability.
> >
> >> So maybe fix the code using the tracepoint(s) to avoid passing
On Wed, Feb 28, 2018 at 10:14:41AM +0100, Rafael J. Wysocki wrote:
> On 2/28/2018 3:45 AM, Du, Changbin wrote:
> > On Tue, Feb 27, 2018 at 05:39:38PM -0500, Steven Rostedt wrote:
> > > On Tue, 27 Feb 2018 17:35:27 +0800
> > > "Du, Changbin" wrote:
> >
On Tue, Feb 27, 2018 at 05:39:38PM -0500, Steven Rostedt wrote:
> On Tue, 27 Feb 2018 17:35:27 +0800
> "Du, Changbin" wrote:
>
> > > From the tracing perspective:
> > >
> > > Acked-by: Steven Rostedt (VMware)
> > >
> > > -- Steve
Hello Steven and Corbet,
Ten days past, will you accept this serias? Thank you!
On Sat, Feb 17, 2018 at 01:39:33PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> Hi All,
> The linux tracers are so useful that I want to make the docs better. The
> kernel
> now uses Sphinx to generat
Hi,
On Tue, Feb 20, 2018 at 08:28:24AM +0100, Philippe Ombredanne wrote:
> Changbin, Steven,
>
> On Sat, Feb 17, 2018 at 6:39 AM, wrote:
> > From: Changbin Du
> >
> > This converts the plain text documentation to reStructuredText format and
> > add it into Sphinx TOC tree. No essential content
On Mon, Feb 19, 2018 at 10:21:34AM +0900, Namhyung Kim wrote:
> Hello,
>
> On Wed, Feb 14, 2018 at 10:44:24AM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > Before this change, the '--graph-funcs', '--nograph-funcs' and
> > '--trace-funcs' options didn't work as expected when
On Fri, Feb 16, 2018 at 12:36:29PM -0500, Steven Rostedt wrote:
> On Fri, 16 Feb 2018 05:49:52 -0700
> Jonathan Corbet wrote:
>
> > On Thu, 15 Feb 2018 22:57:05 -0500
> > Steven Rostedt wrote:
> >
> > > This document is out of date, and I rather have it updated before we
> > > make it more "ava
On Thu, Feb 15, 2018 at 10:57:05PM -0500, Steven Rostedt wrote:
> On Fri, 16 Feb 2018 11:12:18 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > Signed-off-by: Changbin Du
> > ---
> > .../trace/{ftrace-design.txt => ftrace-design.rst} | 248
> > +++--
> > Do
Thanks, I will improve this change in v2. And also update related docs.
On Mon, Feb 12, 2018 at 12:04:52PM -0500, Steven Rostedt wrote:
> On Sun, 11 Feb 2018 18:50:04 +0800
> "Du, Changbin" wrote:
>
> > Steve, How abount DEFINE_EVENT_PRINT as below?
>
> Ye
On Sun, Feb 11, 2018 at 10:15:10PM -0800, Namhyung Kim wrote:
> On Mon, Feb 12, 2018 at 12:48:15PM +0800, Du, Changbin wrote:
> > Hi,
> >
> > On Mon, Feb 12, 2018 at 10:55:27AM +0900, Namhyung Kim wrote:
> > > Hello,
> > >
> > > On Thu, Feb 08,
Hi,
On Mon, Feb 12, 2018 at 10:55:27AM +0900, Namhyung Kim wrote:
> Hello,
>
> On Thu, Feb 08, 2018 at 04:13:20PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > The terminal character '\0' should take into account into size of the
> > string buffer. Without this fix, the '--g
Hi Rostedt,
What abount this fix? Thanks!
On Wed, Jan 31, 2018 at 11:48:49PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> The fgraph forget to print irq return mark for leaf entry. Then we can see
> unbalanced irq mark in the trace. This patch fix this.
>
> Before:
> 1)
On Fri, Feb 09, 2018 at 09:44:58PM -0500, Steven Rostedt wrote:
> On Sat, 10 Feb 2018 09:37:04 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The type of state is signed int, convert it to unsigned int looks weird.
> > (-1 become 4294967295)
> >932.123 power:cpu_idle:st
On Thu, Feb 08, 2018 at 09:57:24AM +0900, Namhyung Kim wrote:
> Hello,
>
[snip]
> > Does anyone know why? Thank you! :)
>
> It seems your data doesn't have wakeup event which is required by the
> 'perf sched latency'.
>
> Thanks,
> Namhyung
>
Hi Kim,
Thanks for your reply. I thought the 'Swicth
Hello all,
I am using perf sched tool to analyzer sched data on my machine. But it seems
that
'perf sched latency' report incorrect 'Switches'. What I did is as below.
First, record...
$ sudo perf sched record time pi 200 > /dev/null
Then check statistics. It says 'pi' only sched-in 1 time.
On Wed, Jan 17, 2018 at 02:45:24PM +0900, Namhyung Kim wrote:
> Hello,
>
> On Wed, Jan 17, 2018 at 12:54:34PM +0800, Du, Changbin wrote:
> > On Tue, Jan 16, 2018 at 12:42:26PM -0500, Steven Rostedt wrote:
> > > On Tue, 16 Jan 2018 17:02:27 +0800
> >
On Tue, Jan 16, 2018 at 12:42:26PM -0500, Steven Rostedt wrote:
> On Tue, 16 Jan 2018 17:02:27 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > I found there are some problems in the tracing parser when I investiage the
> > root
> > cause of issues mentioned in below patch.
Hi Rostedt,
Thanks for your polish, let me update commit msg with your words.
On Mon, Jan 15, 2018 at 06:20:00PM -0500, Steven Rostedt wrote:
> On Mon, 15 Jan 2018 19:41:12 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The usersapce can give a '\0' terminated C string in
On Tue, Jan 09, 2018 at 11:10:22PM -0500, Steven Rostedt wrote:
> On Wed, 10 Jan 2018 11:02:06 +0800
> "Du, Changbin" wrote:
>
> > On Tue, Jan 09, 2018 at 06:02:58PM -0500, Steven Rostedt wrote:
> > > On Tue, 9 Jan 2018 17:55:47 +0800
> > > changbi
On Fri, Jan 12, 2018 at 10:31:08AM -0500, Steven Rostedt wrote:
[...]
> > Thanks, so now I unstand why below corner case. The userspace try to set the
> > filter with a unrecognized symbole name (e.g "abcdefg").
> > open("/sys/kernel/debug/tracing/set_ftrace_filter", O_WRONLY|O_TRUNC) = 3
> > write
Hi Rostedt,
On Tue, Jan 09, 2018 at 11:19:36PM -0500, Steven Rostedt wrote:
> On Wed, 10 Jan 2018 11:18:23 +0800
> "Du, Changbin" wrote:
>
> > write(3, "abcdefg", 7)
> > >
> > > From my point of view, the above isn't done writing the
On Tue, Jan 09, 2018 at 06:12:41PM -0500, Steven Rostedt wrote:
> On Tue, 9 Jan 2018 17:55:48 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > We should not set parser->cont if it has reached the end of input buffer.
> > And since some callers (like ftrace_graph_write()) tre
On Tue, Jan 09, 2018 at 06:02:58PM -0500, Steven Rostedt wrote:
> On Tue, 9 Jan 2018 17:55:47 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The parser parse every string into parser.buffer. And some of the callers
> > assume that parser.buffer contains a C string. So it i
hi Rostedt,
On Tue, Jan 09, 2018 at 05:54:34PM -0500, Steven Rostedt wrote:
> On Tue, 9 Jan 2018 17:55:46 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The usersapce can give a '\0' terminated C string or even has '\0' at the
> > middle of input buffer. We need handle bo
On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote:
> On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote:
> > Hi Olsa,
> > What about this fix now? Thanks!
> >
> > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote:
> > >
Hi Olsa,
What about this fix now? Thanks!
On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> The terminal character '\0' should take into account as size of the string
> buffer. Without this fix, the '--graph-funcs', '--nograph-funcs' and
> '--trace-fu
On Tue, Jan 02, 2018 at 11:18:31AM +0100, Rafael J. Wysocki wrote:
> On Tue, Jan 2, 2018 at 7:36 AM, Du, Changbin wrote:
> > Hi Wysocki and Brown,
> > May I know wether you have checked this? Thanks!
>
> There's a commit changing this queued up already, see
> https
Hi Wysocki and Brown,
May I know wether you have checked this? Thanks!
On Fri, Dec 22, 2017 at 11:11:10PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> The ACPI_MASKABLE_GPE_MAX is larger than the number of bits that u64 can
> represent. This result in shift-overflow. So actually w
On Wed, Dec 13, 2017 at 03:17:24PM -0500, Steven Rostedt wrote:
> On Tue, 12 Dec 2017 19:15:53 +0800
> "Du, Changbin" wrote:
>
> > Hi Rostedt, How about this version?
> >
>
> I've pulled it, but due to traveling, I haven't been able to pus
Hi Rostedt, How about this version?
On Thu, Nov 30, 2017 at 11:39:43AM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> The default NR_CPUS can be very large, but actual possible nr_cpu_ids
> usually is very small. For my x86 distribution, the NR_CPUS is 8192 and
> nr_cpu_ids is 4. A
On Fri, Dec 08, 2017 at 09:27:37AM +0100, Michal Hocko wrote:
> On Fri 08-12-17 12:42:55, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > This patch introduced 4 new interfaces to allocate a prepared transparent
> > huge page. These interfaces merge distributed two-step allocation as s
Hi Andrew,
On Thu, Dec 07, 2017 at 03:45:19PM -0800, Andrew Morton wrote:
> On Thu, 7 Dec 2017 18:54:19 +0800 changbin...@intel.com wrote:
>
> > From: Changbin Du
[snip]
> -static inline void prep_transhuge_page(struct page *page) {}
> > +#define alloc_transhuge_page_vma(gfp_mask, vma, addr) N
Hi Cherian,
Your patch 'ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs'
introduced a out-of-bounds BUG in kernel. The code need to check
cpu_pcc_subspace_idx before use it since it can be -1. Thanks.
[ 15.113449]
==
[
On Wed, Nov 29, 2017 at 10:12:09PM -0500, Steven Rostedt wrote:
> On Wed, 29 Nov 2017 12:42:45 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The default NR_CPUS can be very large, but actual possible nr_cpu_ids
> > usually is very small. For my x86 distribution, the NR_CPU
Hi Steven,
Have you picked up this patch or need more polish? Thanks.
On Wed, Nov 01, 2017 at 11:28:08AM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> The default NR_CPUS can be very large, but actual possible nr_cpu_ids
> usually is very small. For my x86 distribution, the NR_CPUS
On Wed, Nov 08, 2017 at 10:01:37AM +0100, Ingo Molnar wrote:
>
> * changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > This change suppresses the 'dd' output and adds '-quite' parameter
> > to mkisofs tool. None of the messages matter to the user. Now:
> >
> > $ make isoimage
> > ...
On Tue, Nov 07, 2017 at 11:20:29AM +0100, Ingo Molnar wrote:
>
> * changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The build message for fdimage/isoimage are pretty unstructured. The raw
> > shell command blocks are printed. We can improve them as regular build
> > system messages
Hi Ingo,
On Sun, Nov 05, 2017 at 10:33:53AM +0100, Ingo Molnar wrote:
>
> * changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > Recently I failed to build isoimage target, because the path of isolinux.bin
> > changed to /usr/xxx/ISOLINUX/isolinux.bin, as well as ldlinux.c32 which
> >
On Sun, Nov 05, 2017 at 10:32:08AM +0100, Ingo Molnar wrote:
>
> A few spelling fixes:
>
> in the title:
>
> s/Fact out
> /Factor out
>
> * changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The build message for fdimage/isoimage are pretty unstructured. The raw
> > shell command
Hi Ingo and Yamada,
Thanks for your suggestions. I'll have a try though I am not familiar with
kbuild system.
On Wed, Nov 01, 2017 at 12:17:50PM +0900, Masahiro Yamada wrote:
> 2017-10-31 18:39 GMT+09:00 Ingo Molnar :
> >
> > * changbin...@intel.com wrote:
> >
> >> From: Changbin Du
> >>
> >> R
Hi Rostedt,
On Tue, Oct 31, 2017 at 12:19:58PM -0400, Steven Rostedt wrote:
> On Thu, 26 Oct 2017 00:20:28 +0800
> changbin...@intel.com wrote:
>
> > From: Changbin Du
> >
> > The default NR_CPUS can be very large, but actual possible nr_cpu_ids
> > usually is very small. For my x86 distribution
On Wed, Oct 25, 2017 at 07:24:36PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> The default NR_CPUS can be very large, but actual possible nr_cpu_ids
> usually is very small. For my x86 distribution, the NR_CPUS is 8192 and
> nr_cpu_ids is 4. About 2 pages are wasted.
>
> Most mac
Hi Lameter,
On Fri, Oct 20, 2017 at 06:35:44AM -0500, Christopher Lameter wrote:
> On Fri, 20 Oct 2017, changbin...@intel.com wrote:
>
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 269b5df..2a960fc 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -501,6 +501,43
Hi Hocko,
On Thu, Oct 19, 2017 at 02:49:31PM +0200, Michal Hocko wrote:
> On Wed 18-10-17 19:00:26, Du, Changbin wrote:
> > Hi Hocko,
> >
> > On Tue, Oct 17, 2017 at 12:20:52PM +0200, Michal Hocko wrote:
> > > [CC Kirill]
> > >
> > > On Mo
Hi Morton,
On Tue, Oct 17, 2017 at 04:28:16PM -0700, Andrew Morton wrote:
> On Mon, 16 Oct 2017 17:19:15 +0800 changbin...@intel.com wrote:
>
> > The first one introduce new interfaces, the second one kills naming
> > confusion.
> > The aim is to remove duplicated code and simplify transparent hu
On Tue, Oct 17, 2017 at 02:12:46PM +0300, Kirill A. Shutemov wrote:
> On Mon, Oct 16, 2017 at 05:19:16PM +0800, changbin...@intel.com wrote:
> > @@ -501,6 +501,45 @@ void prep_transhuge_page(struct page *page)
> > set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR);
> > }
> >
> > +struct page
Hi Hocko,
On Tue, Oct 17, 2017 at 12:20:52PM +0200, Michal Hocko wrote:
> [CC Kirill]
>
> On Mon 16-10-17 17:19:16, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > This patch introduced 4 new interfaces to allocate a prepared
> > transparent huge page.
> > - alloc_transhuge_page_vm
Hi Khandual,
> > long freed);
> > bool isolate_huge_page(struct page *page, struct list_head *list);
> > void putback_active_hugepage(struct page *page);
> > -void free_huge_page(struct page *page);
> > +void huge_page_dtor(struct page *page);
> > void
Hi Khandual,
Thanks for your review.
On Tue, Oct 17, 2017 at 01:38:07PM +0530, Anshuman Khandual wrote:
> On 10/16/2017 02:49 PM, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > This patch introduced 4 new interfaces to allocate a prepared
> > transparent huge page.
> > - alloc_tran
1 - 100 of 211 matches
Mail list logo
