Re: [PATCH v3] um: Fix build error and kconfig for i386

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 >

Re: [PATCH v3] um: Fix build error and kconfig for i386

mit' > arch/x86/um/built-in.o: In function `elf_core_write_extra_data': > (.text+0x3eef): undefined reference to `dump_emit' > > Fixes: 5d2acfc7b974 ("kconfig: make allnoconfig disable options behind > EMBEDDED and EXPERT") > Signed-off-by: Mickaël Salaün > Cc: J

Re: [PATCH v2] um: Fix build error and kconfig for i386

On Thu, Dec 24, 2015 at 01:09:45PM +0100, Mickaël Salaün wrote: > > On 23/12/2015 22:42, Josh Triplett wrote: > > On Wed, Dec 23, 2015 at 01:59:13PM +0100, Mickaël Salaün wrote: > >> Fix build error by selecting COREDUMP when X86_32 is selected: > >> > >&

Re: [PATCH v3] um: Fix build error and kconfig for i386

igikod.net> > Cc: Jeff Dike <jd...@addtoit.com> > Cc: Richard Weinberger <rich...@nod.at> > Cc: Josh Triplett <j...@joshtriplett.org> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> > Cc: Michal Marek <mma...@suse.cz> > Cc: Andrew Morton <a..

Re: [PATCH v2] um: Fix build error and kconfig for i386

On Thu, Dec 24, 2015 at 01:09:45PM +0100, Mickaël Salaün wrote: > > On 23/12/2015 22:42, Josh Triplett wrote: > > On Wed, Dec 23, 2015 at 01:59:13PM +0100, Mickaël Salaün wrote: > >> Fix build error by selecting COREDUMP when X86_32 is selected: > >> > >&

Re: [RFC PATCH v2 2/3] thread_local_abi: wire up x86 32/64 system call

>CC: Andrew Hunter >CC: Peter Zijlstra >CC: Andy Lutomirski >CC: Andi Kleen >CC: Dave Watson >CC: Chris Lameter >CC: Ingo Molnar >CC: Ben Maurer >CC: Steven Rostedt >CC: "Paul E. McKenney" >CC: Josh Triplett >CC: Linus Torvalds >C

Re: [PATCH v2] um: Fix build error and kconfig for i386

.o: In function `elf_core_write_extra_data': > (.text+0x3eef): undefined reference to `dump_emit' > > Fixes: 5d2acfc7b974 ("kconfig: make allnoconfig disable options behind > EMBEDDED and EXPERT") > Signed-off-by: Mickaël Salaün > Cc: Jeff Dike > Cc: Richard Weinberge

Re: [RFC PATCH v2 2/3] thread_local_abi: wire up x86 32/64 system call

radead.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 Maurer <bmau...@fb.com> >CC:

Re: [PATCH v2] um: Fix build error and kconfig for i386

lt;jd...@addtoit.com> > Cc: Richard Weinberger <rich...@nod.at> > Cc: Josh Triplett <j...@joshtriplett.org> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> > Cc: Michal Marek <mma...@suse.cz> > Cc: Andrew Morton <a...@linux-foundation.org> >

Re: [PATCH] x86/efi-bgrt: Replace early_memremap() with memremap()

e version allows mappings of arbitrary size. > > Reported-by: Môshe van der Sterre > Tested-by: Môshe van der Sterre > Cc: Josh Triplett > Cc: Sai Praneeth Prakhya > Cc: Borislav Petkov > Signed-off-by: Matt Fleming Reviewed-by: Josh Triplett > arch/x86/platform/efi/ef

Re: [PATCH] x86/efi-bgrt: Replace early_memremap() with memremap()

ion allows mappings of arbitrary size. > > Reported-by: Môshe van der Sterre <m...@moshe.nl> > Tested-by: Môshe van der Sterre <m...@moshe.nl> > Cc: Josh Triplett <j...@joshtriplett.org> > Cc: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Cc: Bori

Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

On Fri, Dec 11, 2015 at 06:46:02PM +, Jason Cooper wrote: > On Fri, Dec 11, 2015 at 10:27:30AM -0800, Josh Triplett wrote: > > On Fri, Dec 11, 2015 at 01:36:01PM +, Jason Cooper wrote: > > > +Josh > > > > > > Hey Arnd, Detlef, > > > > &g

Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

On Fri, Dec 11, 2015 at 01:36:01PM +, Jason Cooper wrote: > +Josh > > Hey Arnd, Detlef, > > On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote: > > On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote: > > > On 12/10/15 22:29, Arnd Bergmann wrote: > > > > On Thursday 10

Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

On Fri, Dec 11, 2015 at 06:46:02PM +, Jason Cooper wrote: > On Fri, Dec 11, 2015 at 10:27:30AM -0800, Josh Triplett wrote: > > On Fri, Dec 11, 2015 at 01:36:01PM +, Jason Cooper wrote: > > > +Josh > > > > > > Hey Arnd, Detlef, > > > > &g

Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

On Fri, Dec 11, 2015 at 01:36:01PM +, Jason Cooper wrote: > +Josh > > Hey Arnd, Detlef, > > On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote: > > On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote: > > > On 12/10/15 22:29, Arnd Bergmann wrote: > > > > On Thursday 10

Re: [PATCH] x86/efi-bgrt: Fix kernel panic when mapping BGRT data

iginal motivation for efi_lookup_mapped_addr came from early_ioremap printing a warning if used on an address range already mapped as RAM. Does early_mem* handle that case correctly without a warning? Because not all firmware places the BGRT image in boot services memory; some firmware pla

Re: [PATCH] x86/efi-bgrt: Fix kernel panic when mapping BGRT data

ing the page table switch to efi_pgd. The original motivation for efi_lookup_mapped_addr came from early_ioremap printing a warning if used on an address range already mapped as RAM. Does early_mem* handle that case correctly without a warning? Because not all firmware places the BGRT image in boot serv

Re: [lkp] [rcu] 52b265325b: WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:61 internal_create_group+0x252/0x300()

On Tue, Dec 08, 2015 at 09:18:16PM -0800, Paul E. McKenney wrote: > On Wed, Dec 09, 2015 at 11:23:05AM +0800, kernel test robot wrote: > > FYI, we noticed the below changes on > > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > > rcu/dev > > commit

Re: [lkp] [rcu] 52b265325b: WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:61 internal_create_group+0x252/0x300()

On Tue, Dec 08, 2015 at 09:18:16PM -0800, Paul E. McKenney wrote: > On Wed, Dec 09, 2015 at 11:23:05AM +0800, kernel test robot wrote: > > FYI, we noticed the below changes on > > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > > rcu/dev > > commit

Re: [PATCH tip/core/rcu 6/8] rcutorture: Print symbolic name for ->gp_state

On Sat, Dec 05, 2015 at 05:54:36PM -0800, Paul E. McKenney wrote: > On Fri, Dec 04, 2015 at 05:04:21PM -0800, Josh Triplett wrote: > > On Fri, Dec 04, 2015 at 04:23:50PM -0800, Paul E. McKenney wrote: > > > Currently, ->gp_state is printed as an integer, which slows debuggi

Re: [PATCH tip/core/rcu 6/8] rcutorture: Print symbolic name for ->gp_state

On Sat, Dec 05, 2015 at 05:54:36PM -0800, Paul E. McKenney wrote: > On Fri, Dec 04, 2015 at 05:04:21PM -0800, Josh Triplett wrote: > > On Fri, Dec 04, 2015 at 04:23:50PM -0800, Paul E. McKenney wrote: > > > Currently, ->gp_state is printed as an integer, which slows debuggi

Re: [PATCH tip/core/rcu 0/10] Expedited-grace-period changes for 4.5

On Fri, Dec 04, 2015 at 03:58:51PM -0800, Paul E. McKenney wrote: > Hello! > > This series contains follow-on cleanup changes to RCU's expedited > grace-period functionality. The patches in this series are as follows: > > 1.Short-circuit synchronize_sched_expedited() if there is only one

Re: [PATCH tip/core/rcu 0/8] Torture-test updates for 4.5

outputting to the same file. I sent comments on patches 2, 5, and 6; for the rest: Reviewed-by: Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH tip/core/rcu 6/8] rcutorture: Print symbolic name for ->gp_state

On Fri, Dec 04, 2015 at 04:23:50PM -0800, Paul E. McKenney wrote: > Currently, ->gp_state is printed as an integer, which slows debugging. > This commit therefore prints a symbolic name in addition to the integer. > > Signed-off-by: Paul E. McKenney > [ Updated to fix relational operator called

Re: [PATCH tip/core/rcu 5/8] rcutorture: Print symbolic name for rcu_torture_writer_state

On Fri, Dec 04, 2015 at 04:23:49PM -0800, Paul E. McKenney wrote: > Currently, rcu_torture_writer_state is printed as an integer, which slows > debugging. This commit therefore prints a symbolic name in addition to > the integer. > > Signed-off-by: Paul E. McKenney > --- >

Re: [PATCH tip/core/rcu 2/8] rcutorture: Dump stack when GP kthread stalls

On Fri, Dec 04, 2015 at 04:23:46PM -0800, Paul E. McKenney wrote: > This commit increases debug information in the case where the grace-period > kthread is being prevented from running by dumping that kthread's stack. That's not everything this patch does; see below. > Signed-off-by: Paul E.

Re: [PATCH tip/core/rcu 0/8] Documentation updates for 4.5

feedback to patch 1 that effectively apply to the whole series; one covers the checkin of a generated file, and the other covers various mechanical issues in the document. With those two fixed: Reviewed-by: Josh Triplett for the whole series -- To unsubscribe from this list: send the line &q

Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements

On Fri, Dec 04, 2015 at 04:33:32PM -0800, Paul E. McKenney wrote: > On Fri, Dec 04, 2015 at 04:07:19PM -0800, Josh Triplett wrote: > > On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > > > This commit adds RCU requirements as published in a 2015 LWN seri

Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements

.net/Articles/453002/;>complete surprise. s/http/https/ > +This requirement made its presence known after users made it > +clear that an earlier > +http://lwn.net/Articles/107930/;>real-time patch s/http/https/ > +did not meet their needs, in conjunction with some > +https://lk

Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements

On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > This commit adds RCU requirements as published in a 2015 LWN series. > Bringing these requirements in-tree allows them to be updated as changes > are discovered. > > Signed-off-by: Paul E. McKenney > --- >

Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements

On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > This commit adds RCU requirements as published in a 2015 LWN series. > Bringing these requirements in-tree allows them to be updated as changes > are discovered. > > Signed-off-by: Paul E. McKenney >

Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements

.net/Articles/453002/;>complete surprise. s/http/https/ > +This requirement made its presence known after users made it > +clear that an earlier > +http://lwn.net/Articles/107930/;>real-time patch s/http/https/ > +did not meet their needs, in conjunction with some > +https://lk

Re: [PATCH tip/core/rcu 0/8] Documentation updates for 4.5

feedback to patch 1 that effectively apply to the whole series; one covers the checkin of a generated file, and the other covers various mechanical issues in the document. With those two fixed: Reviewed-by: Josh Triplett <j...@joshtriplett.org> for the whole series -- To unsubscribe from t

Re: [PATCH tip/core/rcu 2/8] rcutorture: Dump stack when GP kthread stalls

On Fri, Dec 04, 2015 at 04:23:46PM -0800, Paul E. McKenney wrote: > This commit increases debug information in the case where the grace-period > kthread is being prevented from running by dumping that kthread's stack. That's not everything this patch does; see below. > Signed-off-by: Paul E.

Re: [PATCH tip/core/rcu 5/8] rcutorture: Print symbolic name for rcu_torture_writer_state

On Fri, Dec 04, 2015 at 04:23:49PM -0800, Paul E. McKenney wrote: > Currently, rcu_torture_writer_state is printed as an integer, which slows > debugging. This commit therefore prints a symbolic name in addition to > the integer. > > Signed-off-by: Paul E. McKenney >

Re: [PATCH tip/core/rcu 0/10] Expedited-grace-period changes for 4.5

On Fri, Dec 04, 2015 at 03:58:51PM -0800, Paul E. McKenney wrote: > Hello! > > This series contains follow-on cleanup changes to RCU's expedited > grace-period functionality. The patches in this series are as follows: > > 1.Short-circuit synchronize_sched_expedited() if there is only one

Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements

On Fri, Dec 04, 2015 at 04:33:32PM -0800, Paul E. McKenney wrote: > On Fri, Dec 04, 2015 at 04:07:19PM -0800, Josh Triplett wrote: > > On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > > > This commit adds RCU requirements as published in a 2015 LWN seri

Re: [PATCH tip/core/rcu 6/8] rcutorture: Print symbolic name for ->gp_state

On Fri, Dec 04, 2015 at 04:23:50PM -0800, Paul E. McKenney wrote: > Currently, ->gp_state is printed as an integer, which slows debugging. > This commit therefore prints a symbolic name in addition to the integer. > > Signed-off-by: Paul E. McKenney > [ Updated to fix

Re: [PATCH tip/core/rcu 0/8] Torture-test updates for 4.5

outputting to the same file. I sent comments on patches 2, 5, and 6; for the rest: Reviewed-by: Josh Triplett <j...@joshtriplett.org> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 4/4] x86/cpu: Provide a config option to disable static_cpu_has

y: Borislav Petkov > Cc: Josh Triplett Assuming this passes the kernel build robot, then: Reviewed-by: Josh Triplett > arch/x86/Kconfig | 11 +++ > arch/x86/include/asm/cpufeature.h | 2 +- > 2 files changed, 12 insertions(+), 1 deletion(-) > >

Re: [PATCH v3] uselib: default depending if libc5 was used

20 - -20 > padzero 216 192 -24 > sys_uselib 380 --380 > load_elf_library 964 --964 > > Signed-off-by: Riku Voipio > Cc: Josh Triplett Reviewed-by:

Re: [PATCH v2] uselib: default depending if libc5 was used

On Tue, Dec 01, 2015 at 02:35:24PM +0200, Riku Voipio wrote: > On 1 December 2015 at 10:46, Geert Uytterhoeven wrote: > > On Tue, Dec 1, 2015 at 1:31 AM, Andrew Morton > > wrote: > >> On Fri, 27 Nov 2015 12:07:10 -0800 Josh Triplett > >> wrote: > >

Re: [PATCH v2] uselib: default depending if libc5 was used

On Tue, Dec 01, 2015 at 02:35:24PM +0200, Riku Voipio wrote: > On 1 December 2015 at 10:46, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > > On Tue, Dec 1, 2015 at 1:31 AM, Andrew Morton <a...@linux-foundation.org> > > wrote: > >> On Fri, 27 Nov

Re: [PATCH v3] uselib: default depending if libc5 was used

20 - -20 > padzero 216 192 -24 > sys_uselib 380 --380 > load_elf_library 964 --964 > > Signed-off-by: Riku Voipio <riku.voi...@linaro.org> > Cc:

Re: [PATCH 4/4] x86/cpu: Provide a config option to disable static_cpu_has

om Josh. > > Signed-off-by: Borislav Petkov <b...@suse.de> > Cc: Josh Triplett <j...@joshtriplett.org> Assuming this passes the kernel build robot, then: Reviewed-by: Josh Triplett <j...@joshtriplett.org> > arch/x86/Kconfig | 11 +++ > arch/x8

Re: [PATCH v2] uselib: default depending if libc5 was used

On Mon, Nov 30, 2015 at 04:31:29PM -0800, Andrew Morton wrote: > On Fri, 27 Nov 2015 12:07:10 -0800 Josh Triplett > wrote: > > > On Fri, Nov 27, 2015 at 01:14:20PM +0200, Riku Voipio wrote: > > > uselib hasn't been used since libc5; glibc does not use it. > >

Re: [PATCH v2] uselib: default depending if libc5 was used

On Mon, Nov 30, 2015 at 04:31:29PM -0800, Andrew Morton wrote: > On Fri, 27 Nov 2015 12:07:10 -0800 Josh Triplett <j...@joshtriplett.org> > wrote: > > > On Fri, Nov 27, 2015 at 01:14:20PM +0200, Riku Voipio wrote: > > > uselib hasn't been used since libc5; glibc do

Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

On Fri, Nov 27, 2015 at 07:04:33PM +0100, Borislav Petkov wrote: > On Fri, Nov 27, 2015 at 02:52:57PM +0100, Borislav Petkov wrote: > > commit .TEXT .DATA .BSS > > rc2+650055 127948 > >

Re: [PATCH v2] uselib: default depending if libc5 was used

On Fri, Nov 27, 2015 at 01:14:20PM +0200, Riku Voipio wrote: > uselib hasn't been used since libc5; glibc does not use it. > Deprecate uselib a bit more, by making the default y only > if libc5 was widely used on the plaform. > > This makes arm64 kernel built with defconfig slighly smaller > >

Re: [PATCH] uselib: default depending if libc5 was used

On Fri, Nov 27, 2015 at 12:48:29PM +0200, Riku Voipio wrote: > On 27 November 2015 at 11:33, Josh Triplett wrote: > > On Fri, Nov 27, 2015 at 11:11:26AM +0200, Riku Voipio wrote: > >> uselib hasn't been used since libc5; glibc does not use it. > >> Deprecate u

Re: [PATCH] uselib: default depending if libc5 was used

20 - -20 > padzero 216 192 -24 > sys_uselib 380 --380 > load_elf_library 964 --964 > > Signed-off-by: Riku Voipio > Cc: Josh Triplett Seems sensible.

Re: [PATCH] uselib: default depending if libc5 was used

On Fri, Nov 27, 2015 at 12:48:29PM +0200, Riku Voipio wrote: > On 27 November 2015 at 11:33, Josh Triplett <j...@joshtriplett.org> wrote: > > On Fri, Nov 27, 2015 at 11:11:26AM +0200, Riku Voipio wrote: > >> uselib hasn't been used since libc5; glibc does not use it. >

Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

On Fri, Nov 27, 2015 at 07:04:33PM +0100, Borislav Petkov wrote: > On Fri, Nov 27, 2015 at 02:52:57PM +0100, Borislav Petkov wrote: > > commit .TEXT .DATA .BSS > > rc2+650055 127948 > >

Re: [PATCH v2] uselib: default depending if libc5 was used

On Fri, Nov 27, 2015 at 01:14:20PM +0200, Riku Voipio wrote: > uselib hasn't been used since libc5; glibc does not use it. > Deprecate uselib a bit more, by making the default y only > if libc5 was widely used on the plaform. > > This makes arm64 kernel built with defconfig slighly smaller > >

Re: [PATCH] uselib: default depending if libc5 was used

20 - -20 > padzero 216 192 -24 > sys_uselib 380 --380 > load_elf_library 964 --964 > > Signed-off-by: Riku Voipio <riku.voi...@linaro.org> > Cc: Jo

Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

On November 24, 2015 4:10:48 PM PST, Andy Lutomirski wrote: >On Tue, Nov 24, 2015 at 2:42 PM, Josh Triplett >wrote: >>> textdata bss dec hex filename >>> before:644896 127436 1189384 1961716 1deef4 >vmlinux >&g

Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

; static_cpu_has* macros to boot_cpu_has()? That should slim down > the kernel even more but it won't benefit from the speedup of the > static_cpu_has* stuff. > > Josh, thoughts? Seems like a good idea to me: that would sacrifice a small amount of runtime performance in favor of cod

Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

0 4096 > after:[ 7] .data PROGBITSc1093000 094000 0142a0 > 00 WA 0 0 4096 > > So I'm wondering if we should make a config option which converts > static_cpu_has* macros to boot_cpu_has()? That should slim down > the kernel even more but it won't be

Re: [RFC PATCH 3/3] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

On November 24, 2015 4:10:48 PM PST, Andy Lutomirski <l...@amacapital.net> wrote: >On Tue, Nov 24, 2015 at 2:42 PM, Josh Triplett <j...@joshtriplett.org> >wrote: >>> textdata bss dec hex filename >>> before:64

Re: [RFC] asm-generic: default BUG_ON(x) to "if(x) BUG()"

On Mon, Nov 23, 2015 at 09:58:22PM +0100, Arnd Bergmann wrote: > On Monday 23 November 2015 12:16:36 Josh Triplett wrote: > > Two comments inline below. > > > > On Mon, Nov 23, 2015 at 05:25:28PM +0100, Arnd Bergmann wrote: > > > When CONFIG_BUG is disable

Re: [RFC] asm-generic: default BUG_ON(x) to "if(x) BUG()"

_ON in the !CONFIG_BUG case almost identical to the CONFIG_BUG=y case, except for the use of unlikely(condition), which this ought to do as well. Given that, could you pull the definition *out* of the #ifdef/#else for CONFIG_BUG entirely, and define it the same way in both cases? - Josh Triplett

Re: [RFC] asm-generic: default BUG_ON(x) to "if(x) BUG()"

e (0) This makes BUG_ON in the !CONFIG_BUG case almost identical to the CONFIG_BUG=y case, except for the use of unlikely(condition), which this ought to do as well. Given that, could you pull the definition *out* of the #ifdef/#else for CONFIG_BUG entirely, and define it the same way in both cases

Re: [RFC] asm-generic: default BUG_ON(x) to "if(x) BUG()"

On Mon, Nov 23, 2015 at 09:58:22PM +0100, Arnd Bergmann wrote: > On Monday 23 November 2015 12:16:36 Josh Triplett wrote: > > Two comments inline below. > > > > On Mon, Nov 23, 2015 at 05:25:28PM +0100, Arnd Bergmann wrote: > > > When CONFIG_BUG is disable

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On Mon, Nov 16, 2015 at 03:26:40PM -0800, Paul E. McKenney wrote: > On Mon, Nov 16, 2015 at 02:32:11PM -0800, Josh Triplett wrote: > > On Mon, Nov 16, 2015 at 01:51:26PM -0800, Jacob Pan wrote: > > > On Mon, 16 Nov 2015 16:06:57 +0100 (CET) > >

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On Mon, Nov 16, 2015 at 01:51:26PM -0800, Jacob Pan wrote: > On Mon, 16 Nov 2015 16:06:57 +0100 (CET) > Thomas Gleixner wrote: > > > > -0 [000]30.093474: bprint: > > > __tick_nohz_idle_enter: JPAN: tick_nohz_stop_sched_tick 609 delta > > > 100 [JP] but sees delta is exactly

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On Mon, Nov 16, 2015 at 01:51:26PM -0800, Jacob Pan wrote: > On Mon, 16 Nov 2015 16:06:57 +0100 (CET) > Thomas Gleixner wrote: > > > > -0 [000]30.093474: bprint: > > > __tick_nohz_idle_enter: JPAN: tick_nohz_stop_sched_tick 609 delta > > > 100 [JP] but

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On Mon, Nov 16, 2015 at 03:26:40PM -0800, Paul E. McKenney wrote: > On Mon, Nov 16, 2015 at 02:32:11PM -0800, Josh Triplett wrote: > > On Mon, Nov 16, 2015 at 01:51:26PM -0800, Jacob Pan wrote: > > > On Mon, 16 Nov 2015 16:06:57 +0100 (CET) > > > Thomas Gleixner

Re: kdbus refactoring?

mplementation will be done. Any information you can > provide can help the development community provide useful input on the > project. And I've seen you specifically recommend having such conversations early and often. That same document also warns about the discouraging possibility of receiving

Re: kdbus refactoring?

made on how the implementation will be done. Any information you can > provide can help the development community provide useful input on the > project. And I've seen you specifically recommend having such conversations early and often. That same document also warns about the discoura

Re: [PATCH] x86/efi: Preface all print statements with efi* tag

!\n", pa_memmap); > > Cc: Borislav Petkov > Cc: Josh Triplett > Signed-off-by: Matt Fleming Good call. Reviewed-by: Josh Triplett > --- > arch/x86/platform/efi/efi-bgrt.c | 3 +++ > arch/x86/platform/efi/efi_64.c | 2 ++ > arch/x86/platform/efi/quirks.c | 4 +

Re: [PATCH] x86/efi: Preface all print statements with efi* tag

!\n", pa_memmap); > > Cc: Borislav Petkov <b...@suse.de> > Cc: Josh Triplett <j...@joshtriplett.org> > Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> Good call. Reviewed-by: Josh Triplett <j...@joshtriplett.org> > --- > arch/x86/platform/efi/

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

On Thu, Oct 22, 2015 at 08:00:20PM -0700, Kristen Accardi wrote: > On Oct 22, 2015 7:04 PM, "Neil Brown" wrote: > > > > Darren Hart writes: > > > > > > > > Is there a good description of what is expected of a TAB member? How > much time > > > is involved? What makes a great TAB member? > > > > >

Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

On Thu, Oct 22, 2015 at 08:00:20PM -0700, Kristen Accardi wrote: > On Oct 22, 2015 7:04 PM, "Neil Brown" wrote: > > > > Darren Hart writes: > > > > > > > > Is there a good description of what is expected of a TAB member? How > much time > > > is involved?

Re: [PATCH v2] x86/mm: warn on W+x mappings

On Wed, Oct 14, 2015 at 05:19:40PM +0200, Ingo Molnar wrote: > > * Josh Triplett wrote: > > > On Mon, Oct 12, 2015 at 04:17:54PM +0200, Ingo Molnar wrote: > > > * Matt Fleming wrote: > > > > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote: > >

Re: [PATCH v2] x86/mm: warn on W+x mappings

On Wed, Oct 14, 2015 at 05:19:40PM +0200, Ingo Molnar wrote: > > * Josh Triplett <j...@joshtriplett.org> wrote: > > > On Mon, Oct 12, 2015 at 04:17:54PM +0200, Ingo Molnar wrote: > > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > >

Re: [PATCH v2] x86/mm: warn on W+x mappings

ring bootup and saved on the Linux side. That wouldn't support writing to EFI variables. Or using the EFI capsule update system to update firmware. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.k

Re: [PATCH v2] x86/mm: warn on W+x mappings

t; > So EFI variables could be queried during bootup and saved on the Linux side. That wouldn't support writing to EFI variables. Or using the EFI capsule update system to update firmware. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for synchronize_sched_expedited()

On Thu, Oct 08, 2015 at 05:11:11PM -0700, Paul E. McKenney wrote: > On Thu, Oct 08, 2015 at 11:01:14AM -0700, Josh Triplett wrote: > > On Thu, Oct 08, 2015 at 08:19:03AM -0700, Paul E. McKenney wrote: > > > On Thu, Oct 08, 2015 at 05:12:42PM +0200, Peter Zijlstra wrote: >

Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for synchronize_sched_expedited()

en it won't fit. I suppose I could use IRQs instead. ;-) In this particular case, "IRQs" works just as well; however, in general, this seems like an excellent example of when to ignore the 80-column guideline. :) - Josh Triplett -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for synchronize_sched_expedited()

en it won't fit. I suppose I could use IRQs instead. ;-) In this particular case, "IRQs" works just as well; however, in general, this seems like an excellent example of when to ignore the 80-column guideline. :) - Josh Triplett -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for synchronize_sched_expedited()

On Thu, Oct 08, 2015 at 05:11:11PM -0700, Paul E. McKenney wrote: > On Thu, Oct 08, 2015 at 11:01:14AM -0700, Josh Triplett wrote: > > On Thu, Oct 08, 2015 at 08:19:03AM -0700, Paul E. McKenney wrote: > > > On Thu, Oct 08, 2015 at 05:12:42PM +0200, Peter Zijlstra wrote: >

Re: [PATCH tip/core/rcu 0/13] percpu-rwsem patches for 4.4

On Tue, Oct 06, 2015 at 12:33:11PM -0700, Paul E. McKenney wrote: > On Tue, Oct 06, 2015 at 08:50:56PM +0200, Oleg Nesterov wrote: > > On 10/06, Josh Triplett wrote: > > > > > > For all 13: > > > Reviewed-by: Josh Triplett > > > > Thanks! >

Re: [PATCH tip/core/rcu 04/13] rcu: Don't disable preemption for Tiny and Tree RCU readers

On Tue, Oct 06, 2015 at 10:42:04AM -0700, Paul E. McKenney wrote: > On Tue, Oct 06, 2015 at 10:16:30AM -0700, Josh Triplett wrote: > > On Tue, Oct 06, 2015 at 10:01:01AM -0700, Paul E. McKenney wrote: > > > On Tue, Oct 06, 2015 at 09:44:45AM -0700, Josh Triplett wrote: > >

Re: [PATCH tip/core/rcu 07/13] rcu: Move preemption disabling out of __srcu_read_lock()

On Tue, Oct 06, 2015 at 10:36:46AM -0700, Paul E. McKenney wrote: > On Tue, Oct 06, 2015 at 10:18:39AM -0700, Josh Triplett wrote: > > On Tue, Oct 06, 2015 at 09:13:42AM -0700, Paul E. McKenney wrote: > > > Currently, __srcu_read_lock() cannot be invoked from restricted > >

Re: [PATCH tip/core/rcu 0/13] percpu-rwsem patches for 4.4

terov. > > 13. Cleanup the CONFIG_PROVE_RCU checks, courtesy of Oleg Nesterov. For all 13: Reviewed-by: Josh Triplett Regarding the rcu_sync infrastructure: odd that an atomic read on the reader proves ligher weight than rcu_read_lock()/rcu_read_unlock(). -- To unsubscribe from this l

Re: [PATCH tip/core/rcu 10/13] rcu: Add rcu_pointer_handoff()

On Tue, Oct 06, 2015 at 10:31:52AM -0700, Paul E. McKenney wrote: > On Tue, Oct 06, 2015 at 10:21:28AM -0700, Josh Triplett wrote: > > On Tue, Oct 06, 2015 at 09:13:45AM -0700, Paul E. McKenney wrote: > > > This commit adds an rcu_pointer_handoff() that is intended to mark >

Re: [PATCH tip/core/rcu 0/5] Documentation changes for 4.4

> 3.Update whatisRCU() to show rcu_dereference_protected(), > courtesy of Jason A. Donenfeld. > > 4.Catch up list of torture_type options. > > 5.Add lockless_dereference() to memory-barriers.txt. For all five: Reviewed-by: Josh Triplett -- To unsubscribe

Re: [PATCH tip/core/rcu 0/4] torture-test changes for 4.4

t; 3.Forgive non-plural arguments. > > 4.Fix module unwind when bad torture_type specified to locktorture. For all four: Reviewed-by: Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org Mor

Re: [PATCH tip/core/rcu 1/4] rcutorture: Fix module unwind when bad torture_type specified

e comment about not using "goto unwind" doesn't actually apply (rcu_torture_cleanup *seems* to handle lack of init), this seems fine. Reviewed-by: Josh Triplett > kernel/rcu/rcutorture.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/kernel/rcu/rcut

Re: [PATCH tip/core/rcu 0/13] Miscellaneous fixes for 4.4

.edu/amatveev/RLU_SOSP2015.pdf > > 12. Remove deprecated rcu_lockdep_assert(). (And a patch 13 not mentioned here.) I responded to patches 4, 6, and 10 with feedback; for the rest (and for those with the issues addressed): Reviewed-by: Josh Triplett -- To unsubscribe from this list: sen

Re: [PATCH tip/core/rcu 10/13] rcu: Add rcu_pointer_handoff()

On Tue, Oct 06, 2015 at 09:13:45AM -0700, Paul E. McKenney wrote: > This commit adds an rcu_pointer_handoff() that is intended to mark > situations where a structure's protection transitions from RCU to some > other mechanism (locking, reference counting, whatever). These markings > should allow

Re: [PATCH tip/core/rcu 07/13] rcu: Move preemption disabling out of __srcu_read_lock()

On Tue, Oct 06, 2015 at 09:13:42AM -0700, Paul E. McKenney wrote: > Currently, __srcu_read_lock() cannot be invoked from restricted > environments because it contains calls to preempt_disable() and > preempt_enable(), both of which can invoke lockdep, which is a bad > idea in some restricted

Re: [PATCH tip/core/rcu 04/13] rcu: Don't disable preemption for Tiny and Tree RCU readers

On Tue, Oct 06, 2015 at 10:01:01AM -0700, Paul E. McKenney wrote: > On Tue, Oct 06, 2015 at 09:44:45AM -0700, Josh Triplett wrote: > > On Tue, Oct 06, 2015 at 09:13:39AM -0700, Paul E. McKenney wrote: > > > From: Boqun Feng > > > > > > Because preempt_disab

Re: [PATCH tip/core/rcu 06/13] rcu: Add online/offline info to stall warning message

On Tue, Oct 06, 2015 at 09:13:41AM -0700, Paul E. McKenney wrote: > This commit makes the RCU CPU stall warning message print online/offline > indications immediately after the CPU number. A "?" indicates global > offline, a "," global online, and a "!" indicates RCU believes that the > CPU is

Re: [PATCH tip/core/rcu 04/13] rcu: Don't disable preemption for Tiny and Tree RCU readers

On Tue, Oct 06, 2015 at 09:13:39AM -0700, Paul E. McKenney wrote: > From: Boqun Feng > > Because preempt_disable() maps to barrier() for non-debug builds, > it forces the compiler to spill and reload registers. Because Tree > RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these >

Re: [Tech-board-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

I'll be present in-person at Kernel Summit for the election. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH tip/core/rcu 04/13] rcu: Don't disable preemption for Tiny and Tree RCU readers

On Tue, Oct 06, 2015 at 10:42:04AM -0700, Paul E. McKenney wrote: > On Tue, Oct 06, 2015 at 10:16:30AM -0700, Josh Triplett wrote: > > On Tue, Oct 06, 2015 at 10:01:01AM -0700, Paul E. McKenney wrote: > > > On Tue, Oct 06, 2015 at 09:44:45AM -0700, Josh Triplett wrote: > >

Re: [PATCH tip/core/rcu 0/13] percpu-rwsem patches for 4.4

On Tue, Oct 06, 2015 at 12:33:11PM -0700, Paul E. McKenney wrote: > On Tue, Oct 06, 2015 at 08:50:56PM +0200, Oleg Nesterov wrote: > > On 10/06, Josh Triplett wrote: > > > > > > For all 13: > > > Reviewed-by: Josh Triplett <j...@joshtriplett.org> > >

Re: [PATCH tip/core/rcu 04/13] rcu: Don't disable preemption for Tiny and Tree RCU readers

On Tue, Oct 06, 2015 at 09:13:39AM -0700, Paul E. McKenney wrote: > From: Boqun Feng > > Because preempt_disable() maps to barrier() for non-debug builds, > it forces the compiler to spill and reload registers. Because Tree > RCU and Tiny RCU now only appear in

Re: [PATCH tip/core/rcu 10/13] rcu: Add rcu_pointer_handoff()

On Tue, Oct 06, 2015 at 09:13:45AM -0700, Paul E. McKenney wrote: > This commit adds an rcu_pointer_handoff() that is intended to mark > situations where a structure's protection transitions from RCU to some > other mechanism (locking, reference counting, whatever). These markings > should allow

<    1   2   3   4   5   6   7   8   9   10   >