On Fri, Aug 19, 2016 at 01:23:57PM -0700, Linus Torvalds wrote:
> On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers
> wrote:
> >
> > Benchmarking various approaches for reading the current CPU number:
>
> So I'd like to see the benchmarks of something that actually *does* something.
>
> IOW,
On Mon, Aug 15, 2016 at 12:17:11PM -0600, Simon Glass wrote:
> On 1 August 2016 at 12:37, Josh Triplett <j...@joshtriplett.org> wrote:
> > On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
> >> On 07/29/2016 12:40 AM, Josh Triplett wrote:
> >> >
On Mon, Aug 15, 2016 at 12:17:11PM -0600, Simon Glass wrote:
> On 1 August 2016 at 12:37, Josh Triplett wrote:
> > On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
> >> On 07/29/2016 12:40 AM, Josh Triplett wrote:
> >> > I'd like to announ
On Mon, Aug 15, 2016 at 01:56:43PM +0100, Matt Fleming wrote:
> On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote:
> > Some broken firmwares have a wrongly filled version field in BGRT table.
> > (See http://wiki.osdev.org/Broken_UEFI_implementations )
> >
> > As we know, these firmwares can
On Mon, Aug 15, 2016 at 01:56:43PM +0100, Matt Fleming wrote:
> On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote:
> > Some broken firmwares have a wrongly filled version field in BGRT table.
> > (See http://wiki.osdev.org/Broken_UEFI_implementations )
> >
> > As we know, these firmwares can
On August 9, 2016 11:37:31 PM HST, Richard Ipsum
<richard.ip...@codethink.co.uk> wrote:
>On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
>> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
>> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Tr
On August 9, 2016 11:37:31 PM HST, Richard Ipsum
wrote:
>On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
>> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
>> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
>> > > I'd
On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > I'd welcome any feedback, whether on the interface and workflow, the
> > internals and collaboration, ideas on presenting diffs of patch series,
>
On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > I'd welcome any feedback, whether on the interface and workflow, the
> > internals and collaboration, ideas on presenting diffs of patch series,
>
On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
> On 07/29/2016 12:40 AM, Josh Triplett wrote:
> > I'd like to announce a project I've been working on for a while:
> >
> > git-series provides a tool for managing patch series with git, tracking
> > th
On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
> On 07/29/2016 12:40 AM, Josh Triplett wrote:
> > I'd like to announce a project I've been working on for a while:
> >
> > git-series provides a tool for managing patch series with git, tracking
> > th
On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote:
> Christian Couder <christian.cou...@gmail.com> wrote:
> > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> > <richard.ip...@codethink.co.uk> wrote:
> > > On Thu, Jul 28, 2016 at 11:40:55PM -07
On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote:
> Christian Couder wrote:
> > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> > wrote:
> > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > > [snip]
> > >>
> > &g
On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote:
> On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:
> > I hope to use git notes with git-series in the future, by putting
> > another gitlink under the git-series for notes related to the series.
&
On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote:
> On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:
> > I hope to use git notes with git-series in the future, by putting
> > another gitlink under the git-series for notes related to the series.
&
On Fri, Jul 29, 2016 at 11:10:11AM +0100, Richard Ipsum wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> [snip]
> >
> > I'd welcome any feedback, whether on the interface and workflow, the
> > internals and collaboration, ideas on presenti
On Fri, Jul 29, 2016 at 11:10:11AM +0100, Richard Ipsum wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> [snip]
> >
> > I'd welcome any feedback, whether on the interface and workflow, the
> > internals and collaboration, ideas on presenti
S.md ,
including the details for how git-series ensures git can always reach,
push, and pull a series.
I'd welcome any feedback, whether on the interface and workflow, the
internals and collaboration, ideas on presenting diffs of patch series,
or anything else.
- Josh Triplett
S.md ,
including the details for how git-series ensures git can always reach,
push, and pull a series.
I'd welcome any feedback, whether on the interface and workflow, the
internals and collaboration, ideas on presenting diffs of patch series,
or anything else.
- Josh Triplett
a warning for conflicting 'choice' options, and that we can simply
> make them non-conflicting by listing all other options as disabled.
> This is a trivial patch that we can apply independent of plans for other
> changes.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
other
two choices, to eliminate this warning. (Doing so then introduces a
different form of warning for changing any option at all, but that needs
fixing in the underlying config merge machinery.)
Based on a similar change from Arnd Bergmann for the
architecture-independent tiny.config.
Signed-of
a warning for conflicting 'choice' options, and that we can simply
> make them non-conflicting by listing all other options as disabled.
> This is a trivial patch that we can apply independent of plans for other
> changes.
>
> Signed-off-by: Arnd Bergmann
Reviewed-by: Josh Tripl
other
two choices, to eliminate this warning. (Doing so then introduces a
different form of warning for changing any option at all, but that needs
fixing in the underlying config merge machinery.)
Based on a similar change from Arnd Bergmann for the
architecture-independent tiny.config.
Signed-of
On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote:
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
> return 0;
> }
>
> +int kexec_crash_loaded(void)
> +{
> + return !!kexec_crash_image;
> +}
Nit:
On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote:
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
> return 0;
> }
>
> +int kexec_crash_loaded(void)
> +{
> + return !!kexec_crash_image;
> +}
Nit:
On Wed, Jul 06, 2016 at 03:56:25PM +0200, Arnd Bergmann wrote:
> On Monday, July 4, 2016 12:58:15 PM CEST Josh Triplett wrote:
> > On Mon, Jul 04, 2016 at 12:51:56PM -0700, Josh Triplett wrote:
> > > On Mon, Jul 04, 2016 at 04:25:55PM +0200, Arnd Bergmann wrote:
> > >
On Wed, Jul 06, 2016 at 03:56:25PM +0200, Arnd Bergmann wrote:
> On Monday, July 4, 2016 12:58:15 PM CEST Josh Triplett wrote:
> > On Mon, Jul 04, 2016 at 12:51:56PM -0700, Josh Triplett wrote:
> > > On Mon, Jul 04, 2016 at 04:25:55PM +0200, Arnd Bergmann wrote:
> > >
On Mon, Jul 04, 2016 at 12:51:56PM -0700, Josh Triplett wrote:
> On Mon, Jul 04, 2016 at 04:25:55PM +0200, Arnd Bergmann wrote:
> > The introduction of "make *.config" as a shorthand for merging configuration
> > files unfortunately introduced some build warnings that w
On Mon, Jul 04, 2016 at 12:51:56PM -0700, Josh Triplett wrote:
> On Mon, Jul 04, 2016 at 04:25:55PM +0200, Arnd Bergmann wrote:
> > The introduction of "make *.config" as a shorthand for merging configuration
> > files unfortunately introduced some build warnings that w
/storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log
Thanks for fixing this.
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
As another possibility, which would preserve the ability to use
KCONFIG_ALLCONFIG, what about adding a parameter to mergeconfig to
disable this warning?
nother KCONFIG_ALLCONFIG on
> the command line, that would again have to be done using the mergeconfig
> script afterwards.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 63a91033d52e ("kbuild: add generic mergeconfig target, %.config")
> Link: https://storage.kernelci.org/ma
er stdout is a TTY and automatically suppressing color?
You could check "os.isatty(1)" in main(), and set a global "color =
False". That would automatically handle the cases of redirecting to a
file or piping to another script, without requiring the user to pass
--no-color.
- Josh Triplett
k "os.isatty(1)" in main(), and set a global "color =
False". That would automatically handle the cases of redirecting to a
file or piping to another script, without requiring the user to pass
--no-color.
- Josh Triplett
..@alien8.de>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Dave Young <dyo...@redhat.com>
> Cc: Josh Boyer <jwbo...@fedoraproject.org>
> Cc: Josh Triplett <j...@joshtriplett.org>
> Cc: Andy Lutomirski <l...@amacapital.net>
> Cc: Môshe van der Sterr
services region has the added
> benefit that BGRT images can now be passed across kexec reboot.
>
> Cc: Ard Biesheuvel
> Cc: Leif Lindholm
> Cc: Peter Jones
> Cc: Borislav Petkov
> Cc: Mark Rutland
> Cc: Dave Young
> Cc: Josh Boyer
> Cc: Josh Triplett
>
nd then removing the bucket it
needs.)
- Josh Triplett
nd then removing the bucket it
needs.)
- Josh Triplett
Force float division by using one float and pretty the print to
> two significant decimals:
>
> Total: Before=10515408, After=10604060, chg +0.84%
>
> Signed-off-by: Riku Voipio <riku.voi...@linaro.org>
> Cc: Vineet Gupta <vgu...@synopsys.com>
> Cc: Josh Tr
Force float division by using one float and pretty the print to
> two significant decimals:
>
> Total: Before=10515408, After=10604060, chg +0.84%
>
> Signed-off-by: Riku Voipio
> Cc: Vineet Gupta
> Cc: Josh Triplett
> Cc: Michal Marek
Good idea.
Reviewed-by: Josh
fixes
by others, and based on the signoffs, all of those seem to go through
miscellaneous trees.
Is anyone using m32r? Is anyone willing to maintain it? And if not,
should we consider removing it?
- Josh Triplett
fixes
by others, and based on the signoffs, all of those seem to go through
miscellaneous trees.
Is anyone using m32r? Is anyone willing to maintain it? And if not,
should we consider removing it?
- Josh Triplett
On Tue, May 31, 2016 at 12:18:27PM -0700, Josh Triplett wrote:
> On Tue, May 31, 2016 at 04:07:32PM -0300, Daniel Bristot de Oliveira wrote:
> > It is not always easy to define the cause of an RCU stall just by
> > analysing the RCU stall messages, mainly when the pr
On Tue, May 31, 2016 at 12:18:27PM -0700, Josh Triplett wrote:
> On Tue, May 31, 2016 at 04:07:32PM -0300, Daniel Bristot de Oliveira wrote:
> > It is not always easy to define the cause of an RCU stall just by
> > analysing the RCU stall messages, mainly when the pr
n.
>
> The default value for the sysctl is 0, maintaining the current behavior.
>
> Cc: Ingo Molnar <mi...@redhat.com>
> Cc: Peter Zijlstra <pet...@infradead.org>
> Reviewed-by: Arnaldo Carvalho de Melo <a...@kernel.org>
> Signed-off-by: Daniel Bristot
n.
>
> The default value for the sysctl is 0, maintaining the current behavior.
>
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Reviewed-by: Arnaldo Carvalho de Melo
> Signed-off-by: Daniel Bristot de Oliveira
Reviewed-by: Josh Triplett
> Documentation/sysctl/kernel.txt |
The kerner.panic_on_rcu_stall sysctl is disabled by default.
s/kerner/kernel/ (here and in the previous paragraph).
Also, even though it's only two lines, please consider creating a static
function wrapping the if and panic, to avoid duplication.
With those changes,
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
The kerner.panic_on_rcu_stall sysctl is disabled by default.
s/kerner/kernel/ (here and in the previous paragraph).
Also, even though it's only two lines, please consider creating a static
function wrapping the if and panic, to avoid duplication.
With those changes,
Reviewed-by: Josh Triplett
On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote:
> On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
> > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
> > > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
>
On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote:
> On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
> > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
> > > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
>
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
> On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
> > On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
> > > The option "-soundhw pcspk" gives me a error on PPC as follow:
&g
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
> On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
> > On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
> > > The option "-soundhw pcspk" gives me a error on PPC as follow:
&g
Boqun Feng (4):
> rcutorture/doc: Add a new way to create initrd using dracut
> rcutorture: Use vmlinux as the fallback kernel image
> rcutorture: Make -soundhw a x86 specific option
> rcutorture: Don't specify the cpu type of QEMU on PPC
All four of these seem reasonable to
Boqun Feng (4):
> rcutorture/doc: Add a new way to create initrd using dracut
> rcutorture: Use vmlinux as the fallback kernel image
> rcutorture: Make -soundhw a x86 specific option
> rcutorture: Don't specify the cpu type of QEMU on PPC
All four of these seem reasonable to me:
ttps://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
- Josh Triplett
ug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
- Josh Triplett
On Wed, May 04, 2016 at 11:08:42AM +0100, Djalal Harouni wrote:
> On Tue, May 03, 2016 at 05:41:07PM -0700, Josh Triplett wrote:
> > The main design constraint with a full mapping would be passing that
> > through "mount". There have been discussions on and off for
On Wed, May 04, 2016 at 11:08:42AM +0100, Djalal Harouni wrote:
> On Tue, May 03, 2016 at 05:41:07PM -0700, Josh Triplett wrote:
> > The main design constraint with a full mapping would be passing that
> > through "mount". There have been discussions on and off for
On Wed, May 04, 2016 at 04:26:46PM +0200, Djalal Harouni wrote:
> This is version 2 of the VFS:userns support portable root filesystems
> RFC. Changes since version 1:
>
> * Update documentation and remove some ambiguity about the feature.
> Based on Josh Triplett co
On Wed, May 04, 2016 at 04:26:46PM +0200, Djalal Harouni wrote:
> This is version 2 of the VFS:userns support portable root filesystems
> RFC. Changes since version 1:
>
> * Update documentation and remove some ambiguity about the feature.
> Based on Josh Triplett co
add *two* parameters each for UID and
GID: a base and a max. That would define a range, which doesn't
necessarily need to be exactly 2**16; thus, if you had a big enough
range, that approach would nest as well.
- Josh Triplett
add *two* parameters each for UID and
GID: a base and a max. That would define a range, which doesn't
necessarily need to be exactly 2**16; thus, if you had a big enough
range, that approach would nest as well.
- Josh Triplett
izeof(*bgrt_tab));
On this and other lines with continuations, the continuation line was
indented to match the 'pr_err('; changing that to 'pr_notice(' makes
that continuation indentation no longer make sense. Perhaps it should
change to a single tab, rather than attempting to line up with the start
of the first argument?
- Josh Triplett
d other lines with continuations, the continuation line was
indented to match the 'pr_err('; changing that to 'pr_notice(' makes
that continuation indentation no longer make sense. Perhaps it should
change to a single tab, rather than attempting to line up with the start
of the first argument?
- Josh Triplett
ve their boot process uglified by the kernel reminding
> us that firmware can and often is broken when the 'quiet' kernel
> parameter is specified. Ironic, considering BGRT is supposed to
> make boot pretty to begin with.
>
> Signed-off-by: Josh Boyer <jwbo...@fedoraproject.org>
ve their boot process uglified by the kernel reminding
> us that firmware can and often is broken when the 'quiet' kernel
> parameter is specified. Ironic, considering BGRT is supposed to
> make boot pretty to begin with.
>
> Signed-off-by: Josh Boyer
Thank you for the updated patch.
Revie
nt in going out of the way to optimize this test
for uniprocessor systems.
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
> kernel/torture.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/kernel/torture.c b/kernel/torture.c
> index fb39a06bbef5..
way to optimize this test
for uniprocessor systems.
Reviewed-by: Josh Triplett
> kernel/torture.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/kernel/torture.c b/kernel/torture.c
> index fb39a06bbef5..a85b7d61d9dd 100644
> --- a/kernel/torture.c
> +++ b/
of few firmware developers (relatively) is just not sensible.
>
> Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
> validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
> like a very good place to include these tests since it already has a
> bunch of ACPI table checks.
BITS doesn't, but should; I've added it to the TODO list.
- Josh Triplett
of few firmware developers (relatively) is just not sensible.
>
> Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
> validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
> like a very good place to include these tests since it already has a
> bunch of ACPI table checks.
BITS doesn't, but should; I've added it to the TODO list.
- Josh Triplett
der Sterre <m...@moshe.nl>
> >> wrote:
> >>>
> >>> (additionally CC-ing Josh Triplett)
> >>
> >> Thanks for doing so. I completely forgot.
> >>
> >>> On 04/27/2016 02:50 PM, Josh Boyer wrote:
> >>>>
> >>
On Wed, Apr 27, 2016 at 11:20:26AM -0400, Josh Boyer wrote:
> On Wed, Apr 27, 2016 at 10:57 AM, Môshe van der Sterre wrote:
> >
> > On 04/27/2016 03:56 PM, Josh Boyer wrote:
> >>
> >> On Wed, Apr 27, 2016 at 9:26 AM, Môshe van der Sterre
> >> wr
On Mon, Apr 25, 2016 at 07:36:59AM +0100, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom <e...@engestrom.ch>
Good catch.
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
> ---
> Documentation/RCU/stallwarn.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 del
On Mon, Apr 25, 2016 at 07:36:59AM +0100, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
Good catch.
Reviewed-by: Josh Triplett
> ---
> Documentation/RCU/stallwarn.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/R
On Sun, Apr 17, 2016 at 07:15:31PM -0700, H. Peter Anvin wrote:
> On 04/17/16 19:12, Josh Triplett wrote:
> >>
> >> I really like the 'libinux' idea, did anyone every hack up a first-pass
> >> at this? And I'm guessing we have more syscalls now that would need to
On Sun, Apr 17, 2016 at 07:15:31PM -0700, H. Peter Anvin wrote:
> On 04/17/16 19:12, Josh Triplett wrote:
> >>
> >> I really like the 'libinux' idea, did anyone every hack up a first-pass
> >> at this? And I'm guessing we have more syscalls now that would need to
On Mon, Apr 18, 2016 at 10:09:25AM +0900, Greg KH wrote:
> On Sun, Apr 17, 2016 at 05:38:24PM -0700, H. Peter Anvin wrote:
> > On 04/13/16 19:13, Theodore Ts'o wrote:
> > >
> > > One other reason to suggest using a /proc file is that you're not at
> > > the mercy of the glibc folks to wire up a
On Mon, Apr 18, 2016 at 10:09:25AM +0900, Greg KH wrote:
> On Sun, Apr 17, 2016 at 05:38:24PM -0700, H. Peter Anvin wrote:
> > On 04/13/16 19:13, Theodore Ts'o wrote:
> > >
> > > One other reason to suggest using a /proc file is that you're not at
> > > the mercy of the glibc folks to wire up a
A program
could read its process umask out at startup, handle umask entirely in
userspace (including for threads), and only interact with the system
umask after fork and before exec.
- Josh Triplett
A program
could read its process umask out at startup, handle umask entirely in
userspace (including for threads), and only interact with the system
umask after fork and before exec.
- Josh Triplett
In contrast, with
> tracing enabled, the RCU grace-period kthread goes into "teenager mode",
> refusing to wake up despite repeated attempts. However, this might
> be a side-effect of the ftrace dump.
>
> On line 525,132, we see that the rcu_preempt grace-period kthread has
> been starved for 1,188,154 jiffies, or about 20 minutes. This seems
> unlikely... The kthread is waiting for no more than a three-jiffy
> timeout ("RCU_GP_WAIT_FQS(3)") and is in TASK_INTERRUPTIBLE state
> ("0x1").
We're seeing a similar stall (~60 seconds) on an x86 development system
here. Any luck tracking down the cause of this? If not, any
suggestions for traces that might be helpful?
- Josh Triplett
iod kthread goes into "teenager mode",
> refusing to wake up despite repeated attempts. However, this might
> be a side-effect of the ftrace dump.
>
> On line 525,132, we see that the rcu_preempt grace-period kthread has
> been starved for 1,188,154 jiffies, or about 20 minutes. This seems
> unlikely... The kthread is waiting for no more than a three-jiffy
> timeout ("RCU_GP_WAIT_FQS(3)") and is in TASK_INTERRUPTIBLE state
> ("0x1").
We're seeing a similar stall (~60 seconds) on an x86 development system
here. Any luck tracking down the cause of this? If not, any
suggestions for traces that might be helpful?
- Josh Triplett
om
> linux-next tomorrow unless I hear that it may be useful. It can always
> be easily added back if it proves useful in the future.
Please go ahead. I'll send a note requesting re-addition when it has
new bits.
- Josh Triplett
om
> linux-next tomorrow unless I hear that it may be useful. It can always
> be easily added back if it proves useful in the future.
Please go ahead. I'll send a note requesting re-addition when it has
new bits.
- Josh Triplett
rning_bug':
> >> include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
> return bug->flags & BUGFLAG_WARNING;
>
> Reported-by: kbuild test robot <fengguang...@intel.com>
> Cc: Josh Triplett <j...@joshtriplett.org>
> Signed-off-by: Andre
^
>include/linux/bug.h:91:47: warning: its scope is only this definition or
> declaration, which is probably not what you want
>include/linux/bug.h: In function 'is_warning_bug':
> >> include/linux/bug.h:93:12: error: derefer
ude/linux/srcu.h:78:16: warning:
> > (near initialization for ‘__srcu_key.subkeys’) [-Wmissing-braces]
> > static struct lock_class_key __srcu_key = RCU_KEY; \
> > ^
> > /home/paulmck/public_git/linux-rcu/kernel/notifier.c:526:6: note: in
> > expansion of macro ‘init_srcu_struct’
> > if (init_srcu_struct(>srcu) < 0)
> > ^
> >
> > These have the following in their .config files:
> >
> > CONFIG_DEBUG_LOCK_ALLOC=y
> >
> > However, none of your new Kconfig options are set, which needs to be
> > tested because this will be the common case. Several of them have
> > CONFIG_PROVE_LOCKING=y, but others do not.
> >
>
> Oh.. this is embarrassing ;-(
>
> Hmm.. when CONFIG_RCU_LOCKED_ACCESS=n and CONFIG_DEBUG_LOCK_ALLOC=y,
> this line becomes:
>
> static struct lock_class_key __srcu_key = { 0 };
>
> IIUC, "={ 0 }" is the unverisal zero initializer in C, could be used for
> zero initialising any structure or array, so it's OK here, right?
Compilers seem touchy about that. Sometimes { 0 } works, and sometimes
{} works (that really should *always* work, but it doesn't).
However, for a static struct, you can always just leave off the
initializer.
- Josh Triplett
> > (near initialization for ‘__srcu_key.subkeys’) [-Wmissing-braces]
> > static struct lock_class_key __srcu_key = RCU_KEY; \
> > ^
> > /home/paulmck/public_git/linux-rcu/kernel/notifier.c:526:6: note: in
> > expansion of macro ‘init_srcu_struct’
> > if (init_srcu_struct(>srcu) < 0)
> > ^
> >
> > These have the following in their .config files:
> >
> > CONFIG_DEBUG_LOCK_ALLOC=y
> >
> > However, none of your new Kconfig options are set, which needs to be
> > tested because this will be the common case. Several of them have
> > CONFIG_PROVE_LOCKING=y, but others do not.
> >
>
> Oh.. this is embarrassing ;-(
>
> Hmm.. when CONFIG_RCU_LOCKED_ACCESS=n and CONFIG_DEBUG_LOCK_ALLOC=y,
> this line becomes:
>
> static struct lock_class_key __srcu_key = { 0 };
>
> IIUC, "={ 0 }" is the unverisal zero initializer in C, could be used for
> zero initialising any structure or array, so it's OK here, right?
Compilers seem touchy about that. Sometimes { 0 } works, and sometimes
{} works (that really should *always* work, but it doesn't).
However, for a static struct, you can always just leave off the
initializer.
- Josh Triplett
On Thu, Feb 04, 2016 at 03:05:19PM +0100, Michael Kerrisk (man-pages) wrote:
> Josh Tripplett's commit ea8f8fc8631d9f890580a94d57a18bfeb827fa2e
s/Tripplett/Triplett/
> was well intentioned (I even Acked it), but in practice it has mostly
> generated (a lot of) useless noise on linux-api as
On Thu, Feb 04, 2016 at 03:05:19PM +0100, Michael Kerrisk (man-pages) wrote:
> Josh Tripplett's commit ea8f8fc8631d9f890580a94d57a18bfeb827fa2e
s/Tripplett/Triplett/
> was well intentioned (I even Acked it), but in practice it has mostly
> generated (a lot of) useless noise on linux-api as
On Wed, Jan 27, 2016 at 09:34:35PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 12:37 PM, Thomas Gleixner t...@linutronix.de wrote:
>
> > On Wed, 27 Jan 2016, Thomas Gleixner wrote:
> >
> >> On Wed, 27 Jan 2016, Mathieu Desnoyers wrote:
> >> > - On Jan 27, 2016, at 12:22 PM,
On Wed, Jan 27, 2016 at 09:02:44PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 2:16 PM, Josh Triplett j...@joshtriplett.org wrote:
>
> > On Wed, Jan 27, 2016 at 06:43:36PM +, Mathieu Desnoyers wrote:
> >> - On Jan 27, 2016, at 1:03 PM, Josh Triplett
On Wed, Jan 27, 2016 at 06:43:36PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 1:03 PM, Josh Triplett j...@joshtriplett.org wrote:
>
> > On Wed, Jan 27, 2016 at 05:36:48PM +, Mathieu Desnoyers wrote:
> >> - On Jan 27, 2016, at 12:24 PM, Thomas Gleixn
On Wed, Jan 27, 2016 at 05:36:48PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 12:24 PM, Thomas Gleixner t...@linutronix.de wrote:
> > On Wed, 27 Jan 2016, Josh Triplett wrote:
> >> With the dynamic allocation removed, this seems sensible to me. One
> &g
ns
> - getcpu system call: 51.0 ns
>
> Signed-off-by: Mathieu Desnoyers
> CC: Thomas Gleixner
> CC: Paul Turner
> CC: Andrew Hunter
> CC: Peter Zijlstra
> CC: Andy Lutomirski
> CC: Andi Kleen
> CC: Dave Watson
> CC: Chris Lameter
>
On Wed, Jan 27, 2016 at 09:34:35PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 12:37 PM, Thomas Gleixner t...@linutronix.de wrote:
>
> > On Wed, 27 Jan 2016, Thomas Gleixner wrote:
> >
> >> On Wed, 27 Jan 2016, Mathieu Desnoyers wrote:
> >> > - On Jan 27, 2016, at 12:22 PM,
ijlstra <pet...@infradead.org>
> CC: Andy Lutomirski <l...@amacapital.net>
> CC: Andi Kleen <a...@firstfloor.org>
> CC: Dave Watson <davejwat...@fb.com>
> CC: Chris Lameter <c...@linux.com>
> CC: Ingo Molnar <mi...@redhat.com>
> CC: Ben Mau
On Wed, Jan 27, 2016 at 05:36:48PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 12:24 PM, Thomas Gleixner t...@linutronix.de wrote:
> > On Wed, 27 Jan 2016, Josh Triplett wrote:
> >> With the dynamic allocation removed, this seems sensible to me. One
> &g
On Wed, Jan 27, 2016 at 06:43:36PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 1:03 PM, Josh Triplett j...@joshtriplett.org wrote:
>
> > On Wed, Jan 27, 2016 at 05:36:48PM +, Mathieu Desnoyers wrote:
> >> - On Jan 27, 2016, at 12:24 PM, Thomas Gleixn
On Wed, Jan 27, 2016 at 09:02:44PM +, Mathieu Desnoyers wrote:
> - On Jan 27, 2016, at 2:16 PM, Josh Triplett j...@joshtriplett.org wrote:
>
> > On Wed, Jan 27, 2016 at 06:43:36PM +, Mathieu Desnoyers wrote:
> >> - On Jan 27, 2016, at 1:03 PM, Josh Triplett
On Fri, Dec 25, 2015 at 07:45:41PM +0100, Mickaël Salaün wrote:
>
> On 25/12/2015 02:34, Josh Triplett wrote:
> > On Thu, Dec 24, 2015 at 01:12:11PM +0100, Mickaël Salaün wrote:
> >> Fix build error by generating elfcore.o only when ELF_CORE (depending on
>
301 - 400 of 2693 matches
Mail list logo
