* Willy Tarreau wrote:
> On Wed, Jan 10, 2018 at 08:31:28AM +0100, Ingo Molnar wrote:
> >
> > * Borislav Petkov wrote:
> >
> > > Oh, and you've built the kernel with the option to be able to disable
> > > PTI so it's not like you haven't seen it already.
> >
> >
* Willy Tarreau wrote:
> On Wed, Jan 10, 2018 at 08:31:28AM +0100, Ingo Molnar wrote:
> >
> > * Borislav Petkov wrote:
> >
> > > Oh, and you've built the kernel with the option to be able to disable
> > > PTI so it's not like you haven't seen it already.
> >
> > In general in many corporate
On Wed, Jan 10, 2018 at 08:43:54AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 03:38:09PM +0800, Alan Kao wrote:
> > -LDFLAGS_vmlinux :=
> > +ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
> > + LDFLAGS_vmlinux := --no-relax
> > +else
> > + LDFLAGS_vmlinux :=
> > +endif
>
> Why not:
>
>
On Wed, Jan 10, 2018 at 08:43:54AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 03:38:09PM +0800, Alan Kao wrote:
> > -LDFLAGS_vmlinux :=
> > +ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
> > + LDFLAGS_vmlinux := --no-relax
> > +else
> > + LDFLAGS_vmlinux :=
> > +endif
>
> Why not:
>
>
Hi Stephen,
On Wed, Jan 10, 2018 at 3:02 AM, Stephen Boyd wrote:
> On 01/03, Geert Uytterhoeven wrote:
>> Currently the virtual "clk_flags" file in debugfs shows the numeric
>> value of the top-level framework flags for the specified clock.
>> Hence the user must manually
Hi Stephen,
On Wed, Jan 10, 2018 at 3:02 AM, Stephen Boyd wrote:
> On 01/03, Geert Uytterhoeven wrote:
>> Currently the virtual "clk_flags" file in debugfs shows the numeric
>> value of the top-level framework flags for the specified clock.
>> Hence the user must manually interpret these values.
When committing inmem pages is successful, we revoke already committed
blocks in __revoke_inmem_pages() and finally replace the committed
ones with the old blocks using f2fs_replace_block(). However, if
the committed block was newly created one, the address of the old
block is NEW_ADDR and
When committing inmem pages is successful, we revoke already committed
blocks in __revoke_inmem_pages() and finally replace the committed
ones with the old blocks using f2fs_replace_block(). However, if
the committed block was newly created one, the address of the old
block is NEW_ADDR and
g).
>
> Those with time on their hands and interested to test those branches can fetch
> them at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rseq/linux-rseq.git/
>
> tags:
> v4.15-rc7-rseq-20180109
> v4.15-rc7-membarrier-20180109
>
> Feedback is welco
eir hands and interested to test those branches can fetch
> them at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rseq/linux-rseq.git/
>
> tags:
> v4.15-rc7-rseq-20180109
> v4.15-rc7-membarrier-20180109
>
> Feedback is welcome, although I really hope those involved
On Fri, Jan 05, 2018 at 09:47:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> e1915c8195b38393005be9b74bfa6a3a367c83b3
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw
On Fri, Jan 05, 2018 at 09:47:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> e1915c8195b38393005be9b74bfa6a3a367c83b3
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw
On Wed, Jan 10, 2018 at 03:38:09PM +0800, Alan Kao wrote:
> -LDFLAGS_vmlinux :=
> +ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
> + LDFLAGS_vmlinux := --no-relax
> +else
> + LDFLAGS_vmlinux :=
> +endif
Why not:
LDFLAGS_vmlinux :=
ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
LDFLAGS_vmlinux += --no-relax
endif
On Wed, Jan 10, 2018 at 03:38:09PM +0800, Alan Kao wrote:
> -LDFLAGS_vmlinux :=
> +ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
> + LDFLAGS_vmlinux := --no-relax
> +else
> + LDFLAGS_vmlinux :=
> +endif
Why not:
LDFLAGS_vmlinux :=
ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
LDFLAGS_vmlinux += --no-relax
endif
* Mathieu Desnoyers wrote:
> Hi Linus,
>
> Can you pick up this straightforward fix please ? Let me know whether
> I need to re-send the patch if for some reason the original post is
> too far back in your inbox.
The fix looks much more reasonable than previous
* Mathieu Desnoyers wrote:
> Hi Linus,
>
> Can you pick up this straightforward fix please ? Let me know whether
> I need to re-send the patch if for some reason the original post is
> too far back in your inbox.
The fix looks much more reasonable than previous attempts: I'll pick it up into
From: Shawn Lin
Just use the API instead of open-coding it, no functional change
intended.
Signed-off-by: Shawn Lin
Reviewed-by: Brian Norris
Signed-off-by: Caesar Wang
---
Changes in v2:
-
From: Shawn Lin
Just use the API instead of open-coding it, no functional change
intended.
Signed-off-by: Shawn Lin
Reviewed-by: Brian Norris
Signed-off-by: Caesar Wang
---
Changes in v2:
- As Brian commented on https://patchwork.kernel.org/patch/10139891/,
changed the note and added to
On Tue, Jan 09, 2018 at 03:55:43PM +, Colin King wrote:
> From: Colin Ian King
>
> The initial assignment to mdev is redundant as mdev is re-assigned
> later and the first assigned value is never read. Remove this
> redundant assignment.
>
> Cleans up clang warning:
On 2018/1/10 10:04, Laura Abbott wrote:
> On 01/05/2018 05:10 PM, Dan Williams wrote:
>> From: Mark Rutland
>>
>> This patch implements nospec_ptr() for arm, following the recommended
>> architectural sequences for the arm and thumb instruction sets.
>>
> Fedora picked up
On Tue, Jan 09, 2018 at 03:55:43PM +, Colin King wrote:
> From: Colin Ian King
>
> The initial assignment to mdev is redundant as mdev is re-assigned
> later and the first assigned value is never read. Remove this
> redundant assignment.
>
> Cleans up clang warning:
>
On 2018/1/10 10:04, Laura Abbott wrote:
> On 01/05/2018 05:10 PM, Dan Williams wrote:
>> From: Mark Rutland
>>
>> This patch implements nospec_ptr() for arm, following the recommended
>> architectural sequences for the arm and thumb instruction sets.
>>
> Fedora picked up the series and it fails
Once the function_graph tracer is enabled, a filtered function has the
following call sequence:
* ftracer_caller ==> on/off by ftrace_make_call/ftrace_make_nop
* ftrace_graph_caller
* ftrace_graph_call ==> on/off by ftrace_en/disable_ftrace_graph_caller
* prepare_ftrace_return
Once the function_graph tracer is enabled, a filtered function has the
following call sequence:
* ftracer_caller ==> on/off by ftrace_make_call/ftrace_make_nop
* ftrace_graph_caller
* ftrace_graph_call ==> on/off by ftrace_en/disable_ftrace_graph_caller
* prepare_ftrace_return
Now recordmcount.pl recognizes RISC-V object files. For the mechanism to
work, we have to disable the linker relaxation. This is because
relaxation happens after the script records offsets of _mcount call
sites, resulting in a unreliable record.
Cc: Greentime Hu
Now recordmcount.pl recognizes RISC-V object files. For the mechanism to
work, we have to disable the linker relaxation. This is because
relaxation happens after the script records offsets of _mcount call
sites, resulting in a unreliable record.
Cc: Greentime Hu
Signed-off-by: Alan Kao
---
When doing unwinding in the function walk_stackframe, the pc now receives
the address from calling ftrace_graph_ret_addr instead of manual calculation.
Note that the original expression,
pc = frame->ra - 4
is buggy if the instruction at the return address happened to be a
compressed
When doing unwinding in the function walk_stackframe, the pc now receives
the address from calling ftrace_graph_ret_addr instead of manual calculation.
Note that the original expression,
pc = frame->ra - 4
is buggy if the instruction at the return address happened to be a
compressed
We now have dynamic ftrace with the following added items:
* ftrace_make_call, ftrace_make_nop (in kernel/ftrace.c)
The two functions turns any recorded call site of filtered functions
into a call to ftrace_caller or nops
* ftracce_update_ftrace_func (in kernel/ftrace.c)
turns the nops at
Cc: Greentime Hu
Signed-off-by: Alan Kao
---
arch/riscv/include/asm/ftrace.h | 1 +
arch/riscv/kernel/mcount-dyn.S | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
index
Cc: Greentime Hu
Signed-off-by: Alan Kao
---
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/ftrace.c | 17 ++
arch/riscv/kernel/mcount-dyn.S | 124 +
3 files changed, 142 insertions(+)
We now have dynamic ftrace with the following added items:
* ftrace_make_call, ftrace_make_nop (in kernel/ftrace.c)
The two functions turns any recorded call site of filtered functions
into a call to ftrace_caller or nops
* ftracce_update_ftrace_func (in kernel/ftrace.c)
turns the nops at
Cc: Greentime Hu
Signed-off-by: Alan Kao
---
arch/riscv/include/asm/ftrace.h | 1 +
arch/riscv/kernel/mcount-dyn.S | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
index acf0c7d001f3..429a6a156645 100644
---
Cc: Greentime Hu
Signed-off-by: Alan Kao
---
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/ftrace.c | 17 ++
arch/riscv/kernel/mcount-dyn.S | 124 +
3 files changed, 142 insertions(+)
diff --git a/arch/riscv/Kconfig
On Wed, Jan 10, 2018 at 08:31:28AM +0100, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > Oh, and you've built the kernel with the option to be able to disable
> > PTI so it's not like you haven't seen it already.
>
> In general in many corporate environments requiring
This patch set includes the building blocks of dynamic ftraces features
for RISC-V machines.
Alan Kao (6):
riscv/ftrace: Add RECORD_MCOUNT support
riscv/ftrace: Add dynamic function tracer support
riscv/ftrace: Add dynamic function graph tracer support
riscv/ftrace: Add
Hi Kishon,
Since the Shawn isn't available, I take over this series patches for now.
As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[ 2.375333] rockchip_emmc_phy_power: caldone
On Wed, Jan 10, 2018 at 08:31:28AM +0100, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > Oh, and you've built the kernel with the option to be able to disable
> > PTI so it's not like you haven't seen it already.
>
> In general in many corporate environments requiring kernel reboots or
This patch set includes the building blocks of dynamic ftraces features
for RISC-V machines.
Alan Kao (6):
riscv/ftrace: Add RECORD_MCOUNT support
riscv/ftrace: Add dynamic function tracer support
riscv/ftrace: Add dynamic function graph tracer support
riscv/ftrace: Add
Hi Kishon,
Since the Shawn isn't available, I take over this series patches for now.
As the original bug had tracked on https://issuetracker.google.com/71561742.
In some cases, the mmc phy power on failed during booting up.
The log as below:
...
[ 2.375333] rockchip_emmc_phy_power: caldone
From: Shawn Lin
It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.
Signed-off-by: Shawn Lin
Tested-by: Ziyuan Xu
Signed-off-by: Caesar Wang
---
From: Shawn Lin
It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.
Signed-off-by: Shawn Lin
Tested-by: Ziyuan Xu
Signed-off-by: Caesar Wang
---
Changes in v2:
- print the return valut with regmap_read_poll_timeout failing.
On 28/12/17 12:00, ernest.zhang wrote:
> In some case of eMMC used as boot device, the eMMC signaling voltage is
> fixed to 1.8v, bios can set o2 sd host controller register 0x308 bit4 to
> let host controller skip try 3.3.v signaling voltage in eMMC initialize
> process.
> O2 sd host controller
On 28/12/17 12:00, ernest.zhang wrote:
> In some case of eMMC used as boot device, the eMMC signaling voltage is
> fixed to 1.8v, bios can set o2 sd host controller register 0x308 bit4 to
> let host controller skip try 3.3.v signaling voltage in eMMC initialize
> process.
> O2 sd host controller
* Borislav Petkov wrote:
> Oh, and you've built the kernel with the option to be able to disable
> PTI so it's not like you haven't seen it already.
In general in many corporate environments requiring kernel reboots or kernel
rebuilds limits the real-world usability of any
* Borislav Petkov wrote:
> Oh, and you've built the kernel with the option to be able to disable
> PTI so it's not like you haven't seen it already.
In general in many corporate environments requiring kernel reboots or kernel
rebuilds limits the real-world usability of any kernel feature we
Linus,
please pull sound fixes for v4.15-rc8 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.15-rc8
The topmost commit is 900498a34a3ac9c611e9b425094c8106bdd7dc1c
sound fixes for 4.15-rc8
A
On Wed, Jan 10, 2018 at 08:19:51AM +0100, Ingo Molnar wrote:
>
> * Willy Tarreau wrote:
>
> > +#ifdef CONFIG_PAGE_TABLE_ISOLATION
> > + this_cpu_write(pti_disable,
> > + next_p->mm && next_p->mm->context.pti_disable);
> > +#endif
>
> Another pet peeve, please
Linus,
please pull sound fixes for v4.15-rc8 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.15-rc8
The topmost commit is 900498a34a3ac9c611e9b425094c8106bdd7dc1c
sound fixes for 4.15-rc8
A
On Wed, Jan 10, 2018 at 08:19:51AM +0100, Ingo Molnar wrote:
>
> * Willy Tarreau wrote:
>
> > +#ifdef CONFIG_PAGE_TABLE_ISOLATION
> > + this_cpu_write(pti_disable,
> > + next_p->mm && next_p->mm->context.pti_disable);
> > +#endif
>
> Another pet peeve, please write:
>
> > +
On Wed, 2018-01-10 at 10:12 +0800, Yixun Lan wrote:
>
> On 01/08/18 16:52, Jerome Brunet wrote:
> > On Mon, 2018-01-08 at 15:33 +0800, Yixun Lan wrote:
> > > These two patches are general improvement for meson pinctrl driver.
> > > It make the two pinctrl trees (ee/ao) to share one uniform
On Wed, 2018-01-10 at 10:12 +0800, Yixun Lan wrote:
>
> On 01/08/18 16:52, Jerome Brunet wrote:
> > On Mon, 2018-01-08 at 15:33 +0800, Yixun Lan wrote:
> > > These two patches are general improvement for meson pinctrl driver.
> > > It make the two pinctrl trees (ee/ao) to share one uniform
Hi Chao,
> Original intention here is to recover status to the timing before
> committing atomic write. As at that timing blkaddr in dnode should be
> cur->old_addr(NEW_ADDR), so we need to change to call:
> f2fs_update_data_blkaddr(, NEW_ADDR);
Ok, I'll change NULL_ADDR to NEW_ADDR.
Thanks,
Hi Chao,
> Original intention here is to recover status to the timing before
> committing atomic write. As at that timing blkaddr in dnode should be
> cur->old_addr(NEW_ADDR), so we need to change to call:
> f2fs_update_data_blkaddr(, NEW_ADDR);
Ok, I'll change NULL_ADDR to NEW_ADDR.
Thanks,
* Borislav Petkov wrote:
> On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote:
> > 2.Turning off PTI is, in general, a terrible idea. It totally breaks
> > any semblance of a security model on a Meltdown-affected CPU. So I
> > think we should require CAP_SYS_RAWIO
* Borislav Petkov wrote:
> On Tue, Jan 09, 2018 at 01:26:57PM -0800, Andy Lutomirski wrote:
> > 2.Turning off PTI is, in general, a terrible idea. It totally breaks
> > any semblance of a security model on a Meltdown-affected CPU. So I
> > think we should require CAP_SYS_RAWIO *and* that the
On Wed, Jan 10, 2018 at 08:15:10AM +0100, Ingo Molnar wrote:
> > + /* The "pti_disable" mm attribute is mirrored into this per-cpu var */
> > + cmpb$0, PER_CPU_VAR(pti_disable)
> > + jne .Lend_\@
>
> Could you please do this small change for future iterations:
>
> s/per-cpu
>
On Wed, Jan 10, 2018 at 08:15:10AM +0100, Ingo Molnar wrote:
> > + /* The "pti_disable" mm attribute is mirrored into this per-cpu var */
> > + cmpb$0, PER_CPU_VAR(pti_disable)
> > + jne .Lend_\@
>
> Could you please do this small change for future iterations:
>
> s/per-cpu
>
On Wed, 10 Jan 2018 14:45:07 +0900
Namhyung Kim wrote:
> On Thu, Dec 21, 2017 at 10:02:22AM -0600, Tom Zanussi wrote:
> > Hi,
> >
> > This is V8 of the inter-event tracing patchset, addressing input from
> > V7.
> >
> > These changes address Namhyung's most recent comments
On Wed, 10 Jan 2018 14:45:07 +0900
Namhyung Kim wrote:
> On Thu, Dec 21, 2017 at 10:02:22AM -0600, Tom Zanussi wrote:
> > Hi,
> >
> > This is V8 of the inter-event tracing patchset, addressing input from
> > V7.
> >
> > These changes address Namhyung's most recent comments (thanks,
> >
* Willy Tarreau wrote:
> +#ifdef CONFIG_PAGE_TABLE_ISOLATION
> + this_cpu_write(pti_disable,
> +next_p->mm && next_p->mm->context.pti_disable);
> +#endif
Another pet peeve, please write:
> + this_cpu_write(pti_disable, next_p->mm &&
>
* Willy Tarreau wrote:
> +#ifdef CONFIG_PAGE_TABLE_ISOLATION
> + this_cpu_write(pti_disable,
> +next_p->mm && next_p->mm->context.pti_disable);
> +#endif
Another pet peeve, please write:
> + this_cpu_write(pti_disable, next_p->mm &&
>
On Wed, Jan 10, 2018 at 08:16:24AM +0100, Ingo Molnar wrote:
>
> * Willy Tarreau wrote:
>
> > + /* if we're already on the kernel PGD, we don't switch */
> > +* If we're already on the kernel PGD, we don't switch,
> > +* If we saved a kernel context on entry, we didn't
On Tue, 9 Jan 2018 14:53:56 -0800
Tejun Heo wrote:
> Hello, Steven.
>
> On Tue, Jan 09, 2018 at 05:47:50PM -0500, Steven Rostedt wrote:
> > > Maybe it can break out eventually but that can take a really long
> > > time. It's OOM. Most of userland is waiting for reclaim.
2018-01-06 7:21 GMT+09:00 Marc Herbert :
> On 04/01/2018 09:21, Masahiro Yamada wrote:
>> (+CC Michal's new address)
>>
>> 2017-12-19 10:26 GMT+09:00 Marc Herbert :
>>> As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189
>>>
On Wed, Jan 10, 2018 at 08:16:24AM +0100, Ingo Molnar wrote:
>
> * Willy Tarreau wrote:
>
> > + /* if we're already on the kernel PGD, we don't switch */
> > +* If we're already on the kernel PGD, we don't switch,
> > +* If we saved a kernel context on entry, we didn't switch the CR3,
On Tue, 9 Jan 2018 14:53:56 -0800
Tejun Heo wrote:
> Hello, Steven.
>
> On Tue, Jan 09, 2018 at 05:47:50PM -0500, Steven Rostedt wrote:
> > > Maybe it can break out eventually but that can take a really long
> > > time. It's OOM. Most of userland is waiting for reclaim. There
> > > isn't all
2018-01-06 7:21 GMT+09:00 Marc Herbert :
> On 04/01/2018 09:21, Masahiro Yamada wrote:
>> (+CC Michal's new address)
>>
>> 2017-12-19 10:26 GMT+09:00 Marc Herbert :
>>> As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189
>>> silentoldconfig has become a misnomer. It has become an
* Willy Tarreau wrote:
> + /* if we're already on the kernel PGD, we don't switch */
> + * If we're already on the kernel PGD, we don't switch,
> + * If we saved a kernel context on entry, we didn't switch the CR3,
It's hard enough to read assembly code, please use
* Willy Tarreau wrote:
> + /* if we're already on the kernel PGD, we don't switch */
> + * If we're already on the kernel PGD, we don't switch,
> + * If we saved a kernel context on entry, we didn't switch the CR3,
It's hard enough to read assembly code, please use consistent
* Willy Tarreau wrote:
> When a syscall returns to userspace with pti_disable set, it means the
> current mm is configured to disable page table isolation (PTI). In this
> case, returns from kernel to user will not switch the CR3, leaving it
> to the kernel one which already maps
* Willy Tarreau wrote:
> When a syscall returns to userspace with pti_disable set, it means the
> current mm is configured to disable page table isolation (PTI). In this
> case, returns from kernel to user will not switch the CR3, leaving it
> to the kernel one which already maps both user and
On Tue, 2018-01-09 at 16:39 -0800, Linus Torvalds wrote:
> On Tue, Jan 9, 2018 at 4:31 PM, Andi Kleen
> wrote:
> >
> >
> > The following patch fixes it for me. Something doesn't
> > seem to work with ALTERNATIVE_2. It adds only a few bytes
> > more code, so seems
On Tue, 2018-01-09 at 16:39 -0800, Linus Torvalds wrote:
> On Tue, Jan 9, 2018 at 4:31 PM, Andi Kleen
> wrote:
> >
> >
> > The following patch fixes it for me. Something doesn't
> > seem to work with ALTERNATIVE_2. It adds only a few bytes
> > more code, so seems acceptable.
> Ugh. It's kind of
* Andy Lutomirski wrote:
> On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau wrote:
> > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote:
> >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote:
> >> > I see and am not particularly against
Hi Vadim,
I love your patch! Yet something to improve:
[auto build test ERROR on platform-drivers-x86/for-next]
[cannot apply to linus/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
* Andy Lutomirski wrote:
> On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau wrote:
> > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote:
> >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote:
> >> > I see and am not particularly against this, but what use case do you
>
Hi Vadim,
I love your patch! Yet something to improve:
[auto build test ERROR on platform-drivers-x86/for-next]
[cannot apply to linus/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Previously we use a magic number 10 to limit the number of
time slices. It's not very good.
This patch creates a new function perf_time__range_alloc()
to allocate time slices buffer. The number of buffer entries is
determined by the number of comma in string but at least it will
allocate one
Previously we use a magic number 10 to limit the number of
time slices. It's not very good.
This patch creates a new function perf_time__range_alloc()
to allocate time slices buffer. The number of buffer entries is
determined by the number of comma in string but at least it will
allocate one
Previously, the time percent slice needs an index to specify
which one the user wants.
While it may be easy for using if the index can be omitted.
So with this patch, for example,
perf report --stdio --time 10%/1 should be equivalent to
perf report --stdio --time 10%
Signed-off-by: Jin Yao
The following message will be returned to user when executing
'perf script --time' if perf data file doesn't contain the
first/last sample time.
"HINT: no first/last sample time found in perf data.
Please use latest perf binary to execute 'perf record'
(if '--buildid-all' is enabled, needs to
Previously, the time percent slice needs an index to specify
which one the user wants.
While it may be easy for using if the index can be omitted.
So with this patch, for example,
perf report --stdio --time 10%/1 should be equivalent to
perf report --stdio --time 10%
Signed-off-by: Jin Yao
---
The following message will be returned to user when executing
'perf script --time' if perf data file doesn't contain the
first/last sample time.
"HINT: no first/last sample time found in perf data.
Please use latest perf binary to execute 'perf record'
(if '--buildid-all' is enabled, needs to
Previously it was only allowed to use at most 10 time slices
in 'perf script --time'.
This patch removes this limitation.
For example, following command line is OK (12 time slices)
perf script --time
1%/1,1%/2,1%/3,1%/4,1%/5,1%/6,1%/7,1%/8,1%/9,1%/10,1%/11,1%/12
Signed-off-by: Jin Yao
Previously it was only allowed to use at most 10 time slices
in 'perf script --time'.
This patch removes this limitation.
For example, following command line is OK (12 time slices)
perf script --time
1%/1,1%/2,1%/3,1%/4,1%/5,1%/6,1%/7,1%/8,1%/9,1%/10,1%/11,1%/12
Signed-off-by: Jin Yao
---
Previously it was only allowed to use at most 10 time slices
in 'perf report --time'.
This patch removes this limitation.
For example, following command line is OK (12 time slices)
perf report --stdio --time
1%/1,1%/2,1%/3,1%/4,1%/5,1%/6,1%/7,1%/8,1%/9,1%/10,1%/11,1%/12
Signed-off-by: Jin Yao
The command line like 'perf report --stdio --time 1abc%/1' could be
accepted by perf. It looks not very good.
This patch uses strtod() to replace original atof() and check the
entire string. Now for the same command line, it would return error
message "Invalid time string".
root@skl:/tmp# perf
Previously it was only allowed to use at most 10 time slices
in 'perf report --time'.
This patch removes this limitation.
For example, following command line is OK (12 time slices)
perf report --stdio --time
1%/1,1%/2,1%/3,1%/4,1%/5,1%/6,1%/7,1%/8,1%/9,1%/10,1%/11,1%/12
Signed-off-by: Jin Yao
The command line like 'perf report --stdio --time 1abc%/1' could be
accepted by perf. It looks not very good.
This patch uses strtod() to replace original atof() and check the
entire string. Now for the same command line, it would return error
message "Invalid time string".
root@skl:/tmp# perf
Add a time slices indication to the perf report header.
For example,
# perf report --stdio --time 10%
# Total Lost Samples: 0
#
# Samples: 9K of event 'cycles:ppp' (time slices: 10%)
# Event count (approx.): 8951288803
Signed-off-by: Jin Yao
---
Add a time slices indication to the perf report header.
For example,
# perf report --stdio --time 10%
# Total Lost Samples: 0
#
# Samples: 9K of event 'cycles:ppp' (time slices: 10%)
# Event count (approx.): 8951288803
Signed-off-by: Jin Yao
---
tools/perf/builtin-report.c | 3 +++
The following message will be returned to user when executing
'perf report --time' if perf data file doesn't contain the
first/last sample time.
"HINT: no first/last sample time found in perf data.
Please use latest perf binary to execute 'perf record'
(if '--buildid-all' is enabled, needs to
The following message will be returned to user when executing
'perf report --time' if perf data file doesn't contain the
first/last sample time.
"HINT: no first/last sample time found in perf data.
Please use latest perf binary to execute 'perf record'
(if '--buildid-all' is enabled, needs to
It's follow-up patches to improve the perf time slice feature
(perf report/script --time xxx)
1. Improve the error message
perf report: Improve error msg when no first/last sample time found
perf script: Improve error msg when no first/last sample time found
2. Fix an issue that illegal
It's follow-up patches to improve the perf time slice feature
(perf report/script --time xxx)
1. Improve the error message
perf report: Improve error msg when no first/last sample time found
perf script: Improve error msg when no first/last sample time found
2. Fix an issue that illegal
On 2018-01-09 11:18, Simo Sorce wrote:
> On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote:
> > Containers are a userspace concept. The kernel knows nothing of them.
> >
> > The Linux audit system needs a way to be able to track the container
> > provenance of events and actions.
On 2018-01-09 11:18, Simo Sorce wrote:
> On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote:
> > Containers are a userspace concept. The kernel knows nothing of them.
> >
> > The Linux audit system needs a way to be able to track the container
> > provenance of events and actions.
check_conf() never increments conf_cnt for listnewconfig, so conf_cnt
is always zero.
In other words, conf_cnt is not zero, "input_mode != listnewconfig"
is met.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/conf.c | 2 +-
1 file changed, 1 insertion(+), 1
check_conf() never increments conf_cnt for listnewconfig, so conf_cnt
is always zero.
In other words, conf_cnt is not zero, "input_mode != listnewconfig"
is met.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
1 - 100 of 2714 matches
Mail list logo