From: Tzvetomir Stoyanov
This patch implements integration with pkg-config framework.
pkg-config can be used by the library users to determine
required CFLAGS and LDFLAGS in order to use the library
Signed-off-by: Tzvetomir Stoyanov
Signed-off-by: Steven Rostedt (VMware)
---
Arnaldo and Jiri,
Here's more patches to get us a step closer to having a legitimate
standalone library for libtraceevent. I'm currently reviewing man
pages, which I want finished before we call it done.
Please pull this tree (based on current tip/perf/core) or apply
the patches.
Thanks!
--
From: Tzvetomir Stoyanov
This patch adds a new API of tracevent library: tep_override_comm()
It registers a pid / command mapping. If a mapping with the same
pid already exists, the entry is updated with the new command.
Signed-off-by: Tzvetomir Stoyanov
Signed-off-by: Steven Rostedt (VMware)
From: Tzvetomir Stoyanov
In order to make libtraceevent into a proper library, its API
should be straightforward. The __tep_data2host*() functions are
going to no longer be available as a libtraceevent API, tep_read_number()
should be used instead. This patch replaces __tep_data2host*() usage
From: Tzvetomir Stoyanov
In order to make libtraceevent into a proper library, its API
should be straightforward. This patch hides few API functions,
intended for internal usage only:
tep_free_event(), tep_free_format_field(), __tep_data2host2(),
__tep_data2host4() and __tep_data2host8().
The
From: Tzvetomir Stoyanov
This patch adds a new API of tracevent library: tep_override_comm()
It registers a pid / command mapping. If a mapping with the same
pid already exists, the entry is updated with the new command.
Signed-off-by: Tzvetomir Stoyanov
Signed-off-by: Steven Rostedt (VMware)
From: Tzvetomir Stoyanov
In order to make libtraceevent into a proper library, its API
should be straightforward. The __tep_data2host*() functions are
going to no longer be available as a libtraceevent API, tep_read_number()
should be used instead. This patch replaces __tep_data2host*() usage
From: Tzvetomir Stoyanov
In order to make libtraceevent into a proper library, its API
should be straightforward. This patch hides few API functions,
intended for internal usage only:
tep_free_event(), tep_free_format_field(), __tep_data2host2(),
__tep_data2host4() and __tep_data2host8().
The
From: Tzvetomir Stoyanov
This patch adds a sanity check to is_timestamp_in_us() input parameter
trace_clock. It avoids a potential segfault in case trace_clock is NULL.
Reported-by: Slavomir Kaslev
Signed-off-by: Tzvetomir Stoyanov
Signed-off-by: Steven Rostedt (VMware)
---
From: Tzvetomir Stoyanov
In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. This renames struct tep_event_format to struct tep_event,
which describes more closely the purpose of the struct.
From: Tzvetomir Stoyanov
This patch adds a sanity check to is_timestamp_in_us() input parameter
trace_clock. It avoids a potential segfault in case trace_clock is NULL.
Reported-by: Slavomir Kaslev
Signed-off-by: Tzvetomir Stoyanov
Signed-off-by: Steven Rostedt (VMware)
---
From: Tzvetomir Stoyanov
In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. This renames struct tep_event_format to struct tep_event,
which describes more closely the purpose of the struct.
From: Tzvetomir Stoyanov
This patch installs trace-seq.h header file on "make install".
Signed-off-by: Tzvetomir Stoyanov
Signed-off-by: Steven Rostedt (VMware)
---
tools/lib/traceevent/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Tzvetomir Stoyanov
This patch installs trace-seq.h header file on "make install".
Signed-off-by: Tzvetomir Stoyanov
Signed-off-by: Steven Rostedt (VMware)
---
tools/lib/traceevent/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
We already have the DEFINE_SHOW_ATTRIBUTE,There is no need to define
such a macro,so remove DBGFS_FUNC_DECL.Also use macro to simplify some
code.
Signed-off-by: Yangtao Li
---
drivers/dma/amba-pl08x.c | 14 ++
drivers/dma/mic_x100_dma.c | 22 +++---
We already have the DEFINE_SHOW_ATTRIBUTE,There is no need to define
such a macro,so remove DBGFS_FUNC_DECL.Also use macro to simplify some
code.
Signed-off-by: Yangtao Li
---
drivers/dma/amba-pl08x.c | 14 ++
drivers/dma/mic_x100_dma.c | 22 +++---
On Tue, Oct 30 2018 at 11:23 -0600, Raju P.L.S.S.S.N wrote:
Add device bindings for cpuidle states for cpu devices.
Cc:
Signed-off-by: Raju P.L.S.S.S.N
---
Changes in v2
- Address comments from Doug
---
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 62
1 file
On Tue, Oct 30 2018 at 11:23 -0600, Raju P.L.S.S.S.N wrote:
Add device bindings for cpuidle states for cpu devices.
Cc:
Signed-off-by: Raju P.L.S.S.S.N
---
Changes in v2
- Address comments from Doug
---
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 62
1 file
On Sat 2018-11-24 16:37:55, Tetsuo Handa wrote:
> Sometimes we want to print a whole line without being disturbed by
> concurrent printk() from interrupts and/or other threads, for printk()
> which does not end with '\n' can be disturbed.
>
> We tried to allow printk() callers to explicitly use
On Sat 2018-11-24 16:37:55, Tetsuo Handa wrote:
> Sometimes we want to print a whole line without being disturbed by
> concurrent printk() from interrupts and/or other threads, for printk()
> which does not end with '\n' can be disturbed.
>
> We tried to allow printk() callers to explicitly use
On 11/30/2018 2:23 AM, Marc Gonzalez wrote:
On 30/11/2018 09:12, Stephen Boyd wrote:
Quoting Bjorn Andersson (2018-11-29 23:24:20)
On Thu 29 Nov 23:05 PST 2018, Stephen Boyd wrote:
Quoting Bjorn Andersson (2018-11-29 22:52:57)
Keep the two clocks enabled, so that the platform passes
On Fri, Nov 30, 2018 at 08:52:42AM -0500, Michael S. Tsirkin wrote:
> On Fri, Nov 30, 2018 at 02:01:06PM +0100, Maxime Coquelin wrote:
> > On 11/30/18 1:47 PM, Michael S. Tsirkin wrote:
> > > On Fri, Nov 30, 2018 at 05:53:40PM +0800, Tiwei Bie wrote:
> > > > On Fri, Nov 30, 2018 at 04:10:55PM
On 11/30/2018 2:23 AM, Marc Gonzalez wrote:
On 30/11/2018 09:12, Stephen Boyd wrote:
Quoting Bjorn Andersson (2018-11-29 23:24:20)
On Thu 29 Nov 23:05 PST 2018, Stephen Boyd wrote:
Quoting Bjorn Andersson (2018-11-29 22:52:57)
Keep the two clocks enabled, so that the platform passes
On Fri, Nov 30, 2018 at 08:52:42AM -0500, Michael S. Tsirkin wrote:
> On Fri, Nov 30, 2018 at 02:01:06PM +0100, Maxime Coquelin wrote:
> > On 11/30/18 1:47 PM, Michael S. Tsirkin wrote:
> > > On Fri, Nov 30, 2018 at 05:53:40PM +0800, Tiwei Bie wrote:
> > > > On Fri, Nov 30, 2018 at 04:10:55PM
Hi,
* Tero Kristo [181130 09:21]:
> On 30/11/2018 09:57, Stephen Boyd wrote:
> > No that is not preferred. Can the omap2_clk_deny_idle() function be
> > integrated closer into the clk framework in some way that allows it to
> > be part of the clk_ops structure? And then have that take a clk_hw
>
Rob/Brian
On 11/30/2018 08:13 AM, Rob Herring wrote:
> +Dan M
>
> On Fri, Nov 30, 2018 at 7:59 AM Brian Masney wrote:
>>
>> On Tue, Nov 27, 2018 at 10:56:42AM +, Daniel Thompson wrote:
>>> On Sat, Nov 24, 2018 at 09:17:02AM -0500, Brian Masney wrote:
Add a trivial binding for the Texas
Hi,
* Tero Kristo [181130 09:21]:
> On 30/11/2018 09:57, Stephen Boyd wrote:
> > No that is not preferred. Can the omap2_clk_deny_idle() function be
> > integrated closer into the clk framework in some way that allows it to
> > be part of the clk_ops structure? And then have that take a clk_hw
>
Rob/Brian
On 11/30/2018 08:13 AM, Rob Herring wrote:
> +Dan M
>
> On Fri, Nov 30, 2018 at 7:59 AM Brian Masney wrote:
>>
>> On Tue, Nov 27, 2018 at 10:56:42AM +, Daniel Thompson wrote:
>>> On Sat, Nov 24, 2018 at 09:17:02AM -0500, Brian Masney wrote:
Add a trivial binding for the Texas
Currently, the core->dev entry is populated only if runtime PM is
enabled. Doing so prevents accessing the device structure in any
case.
Keep the same logic but instead of using the presence of core->dev as
the only condition, also check the status of
pm_runtime_enabled(). Then, we can set the
Hello,
While working on suspend to RAM feature, I ran into troubles multiple
times when clocks where not suspending/resuming at the desired time. I
had a look at the core and I think the same logic as in the
regulator's core may be applied here to (very easily) fix this issue:
using device links.
Currently, the core->dev entry is populated only if runtime PM is
enabled. Doing so prevents accessing the device structure in any
case.
Keep the same logic but instead of using the presence of core->dev as
the only condition, also check the status of
pm_runtime_enabled(). Then, we can set the
Hello,
While working on suspend to RAM feature, I ran into troubles multiple
times when clocks where not suspending/resuming at the desired time. I
had a look at the core and I think the same logic as in the
regulator's core may be applied here to (very easily) fix this issue:
using device links.
So far the clk_hw_register_fixed_factor() call was not providing any
device structure. While doing so is harmless for regular use, the
missing device structure may be a problem for suspend to RAM support.
Since, device links have been added to clocks, links created during
probe will enforce the
So far the clk_hw_register_fixed_factor() call was not providing any
device structure. While doing so is harmless for regular use, the
missing device structure may be a problem for suspend to RAM support.
Since, device links have been added to clocks, links created during
probe will enforce the
So far the clk_hw_register_fixed_factor() calls are not providing any
device structure. While doing so is harmless for regular use, the
missing device structure may be a problem for suspend to RAM support.
Since, device links have been added to clocks, links created during
probe will enforce the
One major concern when, for instance, suspending/resuming a platform
is to never access registers before the underlying clock has been
resumed, otherwise most of the time the kernel will just crash. One
solution is to use syscore operations when registering clock drivers
suspend/resume callbacks.
So far the clk_hw_register_fixed_factor() calls are not providing any
device structure. While doing so is harmless for regular use, the
missing device structure may be a problem for suspend to RAM support.
Since, device links have been added to clocks, links created during
probe will enforce the
One major concern when, for instance, suspending/resuming a platform
is to never access registers before the underlying clock has been
resumed, otherwise most of the time the kernel will just crash. One
solution is to use syscore operations when registering clock drivers
suspend/resume callbacks.
On Fri, Nov 30, 2018 at 10:12 AM Arnd Bergmann wrote:
>
> On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c
On Fri, Nov 30, 2018 at 10:12 AM Arnd Bergmann wrote:
>
> On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c
On Fri, Nov 30, 2018 at 04:23:47PM +0100, Peter Zijlstra wrote:
> Hurm.. no. They apply cleanly to Linus' tree here.
>
> linux-2.6$ git describe
> v4.20-rc4-156-g94f371cb7394
> linux-2.6$ quilt push 4
> Applying patch patches/peterz-cpa-addr.patch
> patching file arch/x86/mm/pageattr.c
>
On Fri, Nov 30, 2018 at 04:23:47PM +0100, Peter Zijlstra wrote:
> Hurm.. no. They apply cleanly to Linus' tree here.
>
> linux-2.6$ git describe
> v4.20-rc4-156-g94f371cb7394
> linux-2.6$ quilt push 4
> Applying patch patches/peterz-cpa-addr.patch
> patching file arch/x86/mm/pageattr.c
>
When a micro SD card is inserted in the PDU001 card cage, the card
detection switch is opened and the corresponding GPIO input is driven
by a pull-up. Hence change the active level of the card detection
input from low to high.
Signed-off-by: Felix Brack
---
arch/arm/boot/dts/am335x-pdu001.dts |
When a micro SD card is inserted in the PDU001 card cage, the card
detection switch is opened and the corresponding GPIO input is driven
by a pull-up. Hence change the active level of the card detection
input from low to high.
Signed-off-by: Felix Brack
---
arch/arm/boot/dts/am335x-pdu001.dts |
On Thu, Nov 29, 2018 at 03:11:30PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.85 release.
> There are 100 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Nov 29, 2018 at 03:11:30PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.85 release.
> There are 100 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Nov 29, 2018 at 03:11:31PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.6 release.
> There are 110 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Nov 29, 2018 at 03:11:31PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.6 release.
> There are 110 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On 2018-11-30 10:23 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote:
>> On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
>>> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
Hi Peter,
Unfortunately I can't apply this on top of
On 2018-11-30 10:23 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote:
>> On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
>>> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
Hi Peter,
Unfortunately I can't apply this on top of
Em Fri, Nov 30, 2018 at 10:21:40PM +0800, leo@linaro.org escreveu:
> On Fri, Nov 30, 2018 at 11:21:54AM +0100, Jiri Olsa wrote:
> > On Fri, Nov 30, 2018 at 06:06:05PM +0800, Leo Yan wrote:
> > > Since commit 0aa802a79469 ("perf stat: Get rid of extra clock display
> > > function"), the cpu and
Em Fri, Nov 30, 2018 at 10:21:40PM +0800, leo@linaro.org escreveu:
> On Fri, Nov 30, 2018 at 11:21:54AM +0100, Jiri Olsa wrote:
> > On Fri, Nov 30, 2018 at 06:06:05PM +0800, Leo Yan wrote:
> > > Since commit 0aa802a79469 ("perf stat: Get rid of extra clock display
> > > function"), the cpu and
On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote:
> On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
> > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
> >> Hi Peter,
> >>
> >> Unfortunately I can't apply this on top of our drm-next the first patch
> >> fails.
> >
> >
On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote:
> On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
> > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
> >> Hi Peter,
> >>
> >> Unfortunately I can't apply this on top of our drm-next the first patch
> >> fails.
> >
> >
On Fri, 30 Nov 2018 16:09:56 +0100
Anders Roxell wrote:
> Both of those functions end up calling ftrace_modify_code(), which is
> expensive because it changes the page tables and flush caches.
> Microseconds add up because this is called in a loop for each dyn_ftrace
> record, and this triggers
On Fri, 30 Nov 2018 16:09:56 +0100
Anders Roxell wrote:
> Both of those functions end up calling ftrace_modify_code(), which is
> expensive because it changes the page tables and flush caches.
> Microseconds add up because this is called in a loop for each dyn_ftrace
> record, and this triggers
On Fri, 30 Nov 2018 16:09:35 +0100
Anders Roxell wrote:
> When we have KCOV enabled and running ftrace startup tests we end up in
> a softlockup. Kcov and ftrace tracing each other makes it really slow:
>
> [ 275.141388] Testing tracer wakeup_dl: PASSED
> [ 304.738345] Testing tracer
On Fri, 30 Nov 2018 16:09:35 +0100
Anders Roxell wrote:
> When we have KCOV enabled and running ftrace startup tests we end up in
> a softlockup. Kcov and ftrace tracing each other makes it really slow:
>
> [ 275.141388] Testing tracer wakeup_dl: PASSED
> [ 304.738345] Testing tracer
On Fri, 30 Nov 2018 16:08:59 +0100
Anders Roxell wrote:
> Function graph tracing recurses into itself when stackleak is enabled,
> causing the ftrace graph selftest to run for up to 90 seconds and
> trigger the softlockup watchdog.
>
> Breakpoint 2, ftrace_graph_caller () at
>
On Fri, 30 Nov 2018 16:08:59 +0100
Anders Roxell wrote:
> Function graph tracing recurses into itself when stackleak is enabled,
> causing the ftrace graph selftest to run for up to 90 seconds and
> trigger the softlockup watchdog.
>
> Breakpoint 2, ftrace_graph_caller () at
>
On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > Hi,
> >
> > As I've already fed back to Sascha about this, this patch on its own
> > does not fix anything, and is not a stable kernel candidate
On Fri, Nov 2, 2018 at 1:50 PM Olof Johansson wrote:
>
> On Thu, Oct 18, 2018 at 05:17:33PM +0800, Chunyan Zhang wrote:
> > Hi Arnd,
> >
> > For 4.20-rc1 there's one patch only for sprd devicetree, please pull from
> > my git tree:
> >
> > https://github.com/lyrazhang/linux.git m-v4.19-rc1
> >
>
Here is the kernel cmdline:
Kernel command line: androidboot.acpio_idx=0
androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03-userdebug
androidboot.diskbus=00.0 androidboot.verifiedbootstate=green
androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb
On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > Hi,
> >
> > As I've already fed back to Sascha about this, this patch on its own
> > does not fix anything, and is not a stable kernel candidate
On Fri, Nov 2, 2018 at 1:50 PM Olof Johansson wrote:
>
> On Thu, Oct 18, 2018 at 05:17:33PM +0800, Chunyan Zhang wrote:
> > Hi Arnd,
> >
> > For 4.20-rc1 there's one patch only for sprd devicetree, please pull from
> > my git tree:
> >
> > https://github.com/lyrazhang/linux.git m-v4.19-rc1
> >
>
Here is the kernel cmdline:
Kernel command line: androidboot.acpio_idx=0
androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03-userdebug
androidboot.diskbus=00.0 androidboot.verifiedbootstate=green
androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb
On Fri, Nov 30, 2018 at 06:20:49AM -0800, Guenter Roeck wrote:
> On 11/29/18 6:11 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.85 release.
> > There are 100 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Fri, Nov 30, 2018 at 06:20:49AM -0800, Guenter Roeck wrote:
> On 11/29/18 6:11 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.85 release.
> > There are 100 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Fri, 30 Nov 2018 15:56:22 +0100
Anders Roxell wrote:
> When building a allmodconfig kernel for arm64 and boot that in qemu,
> CONFIG_FTRACE_STARTUP_TEST gets enabled and that takes time so the
> watchdog expires and prints out a message like this:
> 'watchdog: BUG: soft lockup - CPU#0 stuck
On Fri, 30 Nov 2018 15:56:22 +0100
Anders Roxell wrote:
> When building a allmodconfig kernel for arm64 and boot that in qemu,
> CONFIG_FTRACE_STARTUP_TEST gets enabled and that takes time so the
> watchdog expires and prints out a message like this:
> 'watchdog: BUG: soft lockup - CPU#0 stuck
On Fri, Nov 30, 2018 at 4:10 PM David Howells wrote:
> Ondrej Mosnacek wrote:
>
> > - if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT)
> > + if (fc->purpose == (FS_CONTEXT_FOR_KERNEL_MOUNT|FS_CONTEXT_FOR_SUBMOUNT))
>
> It's not a bitmask, so you can't do that. You'd need to do:
>
> if
On Fri, Nov 30, 2018 at 4:10 PM David Howells wrote:
> Ondrej Mosnacek wrote:
>
> > - if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT)
> > + if (fc->purpose == (FS_CONTEXT_FOR_KERNEL_MOUNT|FS_CONTEXT_FOR_SUBMOUNT))
>
> It's not a bitmask, so you can't do that. You'd need to do:
>
> if
"gre...@linuxfoundation.org" writes:
> Adding Eric as he touched this code last :)
>
> On Thu, Nov 29, 2018 at 07:25:48PM +, Jan Glauber wrote:
>> On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
>> > I spent some more time looking at this today...
>> >
>> > On Fri, Nov 23, 2018
"gre...@linuxfoundation.org" writes:
> Adding Eric as he touched this code last :)
>
> On Thu, Nov 29, 2018 at 07:25:48PM +, Jan Glauber wrote:
>> On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
>> > I spent some more time looking at this today...
>> >
>> > On Fri, Nov 23, 2018
On Fri, 30 Nov 2018 06:43:17 -0800
"Paul E. McKenney" wrote:
> Could you please send me your list of kernel boot parameters? They
> usually appear near the start of your console output.
Or just: cat /proc/cmdline
-- Steve
On Fri, 30 Nov 2018 06:43:17 -0800
"Paul E. McKenney" wrote:
> Could you please send me your list of kernel boot parameters? They
> usually appear near the start of your console output.
Or just: cat /proc/cmdline
-- Steve
This adds the following commits from upstream:
f267e674d145 checks: Fix crash with multiple source annotations
3616b9a811b6 checks: Use source position information for check failures
2bdbd07a1223 checks: Make each message output atomic
a1eff70c02cf util: Add xa{v}sprintf_append functions
The updated version of dtc has a bug fix for simple_bus_reg warnings
and lots of warnings are generated now. So disable this warning by
default.
Signed-off-by: Rob Herring
---
scripts/Makefile.lib | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
This adds the following commits from upstream:
f267e674d145 checks: Fix crash with multiple source annotations
3616b9a811b6 checks: Use source position information for check failures
2bdbd07a1223 checks: Make each message output atomic
a1eff70c02cf util: Add xa{v}sprintf_append functions
The updated version of dtc has a bug fix for simple_bus_reg warnings
and lots of warnings are generated now. So disable this warning by
default.
Signed-off-by: Rob Herring
---
scripts/Makefile.lib | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
All the 'graph_port' warnings have been fixed or have pending fixes, so
we can enable it by default now.
Signed-off-by: Rob Herring
---
scripts/Makefile.lib | 1 -
1 file changed, 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 46342f0198f6..8e10eb7428ab 100644
---
All the 'graph_port' warnings have been fixed or have pending fixes, so
we can enable it by default now.
Signed-off-by: Rob Herring
---
scripts/Makefile.lib | 1 -
1 file changed, 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 46342f0198f6..8e10eb7428ab 100644
---
On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> Hi,
>
> As I've already fed back to Sascha about this, this patch on its own
> does not fix anything, and is not a stable kernel candidate without
> a patch that makes use of it (iow, the spectre fixes.) It is a
>
On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> Hi,
>
> As I've already fed back to Sascha about this, this patch on its own
> does not fix anything, and is not a stable kernel candidate without
> a patch that makes use of it (iow, the spectre fixes.) It is a
>
On 11/30/18 3:46 AM, Christoph Hellwig wrote:
> Al, Jens,
>
> can someone pick this up, please?
>
> On Fri, Nov 30, 2018 at 10:02:22AM +0100, Maximilian Heyne wrote:
>> On 11/8/18 7:58 PM, Maximilian Heyne wrote:
>>> commit e259221763a40403d5bb232209998e8c45804ab8 ("fs: simplify the
>>>
On 11/30/18 3:46 AM, Christoph Hellwig wrote:
> Al, Jens,
>
> can someone pick this up, please?
>
> On Fri, Nov 30, 2018 at 10:02:22AM +0100, Maximilian Heyne wrote:
>> On 11/8/18 7:58 PM, Maximilian Heyne wrote:
>>> commit e259221763a40403d5bb232209998e8c45804ab8 ("fs: simplify the
>>>
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
>> Hi Peter,
>>
>> Unfortunately I can't apply this on top of our drm-next the first patch
>> fails.
>
> Against what tree would you like the patches? rebasing should not be
> hard I
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
>> Hi Peter,
>>
>> Unfortunately I can't apply this on top of our drm-next the first patch
>> fails.
>
> Against what tree would you like the patches? rebasing should not be
> hard I
On Wed, 14 Nov 2018 17:21:07 -0500
Sasha Levin wrote:
> From: Martin Schwidefsky
>
> [ Upstream commit e12e4044aede97974feb7f0ed726a5179a32 ]
>
> In case a fork or a clone system fails in copy_process and the error
> handling does the mmput() at the bad_fork_cleanup_mm label, the
>
On Wed, 14 Nov 2018 17:21:07 -0500
Sasha Levin wrote:
> From: Martin Schwidefsky
>
> [ Upstream commit e12e4044aede97974feb7f0ed726a5179a32 ]
>
> In case a fork or a clone system fails in copy_process and the error
> handling does the mmput() at the bad_fork_cleanup_mm label, the
>
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
>> Hi Peter,
>>
>> Unfortunately I can't apply this on top of our drm-next the first patch
>> fails.
>
> Against what tree would you like the patches? rebasing should not be
> hard I
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
>> Hi Peter,
>>
>> Unfortunately I can't apply this on top of our drm-next the first patch
>> fails.
>
> Against what tree would you like the patches? rebasing should not be
> hard I
In a scenario where cpu_hotplug_lock percpu_rw_semaphore is already
acquired for read operation by P1 using percpu_down_read().
Now we have P1 in the path of releaseing the cpu_hotplug_lock and P2
is in the process of acquiring cpu_hotplug_lock.
P1
In a scenario where cpu_hotplug_lock percpu_rw_semaphore is already
acquired for read operation by P1 using percpu_down_read().
Now we have P1 in the path of releaseing the cpu_hotplug_lock and P2
is in the process of acquiring cpu_hotplug_lock.
P1
Both of those functions end up calling ftrace_modify_code(), which is
expensive because it changes the page tables and flush caches.
Microseconds add up because this is called in a loop for each dyn_ftrace
record, and this triggers the softlockup watchdog unless we let it sleep
occasionally.
Ondrej Mosnacek wrote:
> - if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT)
> + if (fc->purpose == (FS_CONTEXT_FOR_KERNEL_MOUNT|FS_CONTEXT_FOR_SUBMOUNT))
It's not a bitmask, so you can't do that. You'd need to do:
if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT ||
Both of those functions end up calling ftrace_modify_code(), which is
expensive because it changes the page tables and flush caches.
Microseconds add up because this is called in a loop for each dyn_ftrace
record, and this triggers the softlockup watchdog unless we let it sleep
occasionally.
Ondrej Mosnacek wrote:
> - if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT)
> + if (fc->purpose == (FS_CONTEXT_FOR_KERNEL_MOUNT|FS_CONTEXT_FOR_SUBMOUNT))
It's not a bitmask, so you can't do that. You'd need to do:
if (fc->purpose == FS_CONTEXT_FOR_KERNEL_MOUNT ||
Roman Kagan writes:
> On Fri, Nov 30, 2018 at 02:44:54PM +0100, Vitaly Kuznetsov wrote:
>
>> I also checked this patch before sending out, WS2016 guest boots without
>> issues. Any particular places you're worried about?
>
> It's Linux guests on Hyper-V that need to be checked.
>
That's exactly
Roman Kagan writes:
> On Fri, Nov 30, 2018 at 02:44:54PM +0100, Vitaly Kuznetsov wrote:
>
>> I also checked this patch before sending out, WS2016 guest boots without
>> issues. Any particular places you're worried about?
>
> It's Linux guests on Hyper-V that need to be checked.
>
That's exactly
701 - 800 of 1382 matches
Mail list logo
