et been checked in. This commit therefore
> also records the output of "git diff HEAD" to provide the information
> needed to reconstruct the source tree that was tested.
>
> Signed-off-by: Paul E. McKenney
Nit below.
Reviewed-by: Josh Triplett
> ---
> tools/testin
On Mon, Apr 28, 2014 at 05:25:29PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Currently, qemu runs in the foreground, which prevents the script from
> killing it in case the kernel locks up. This commit therefore places
> qemu into the background, allowing the script to recove
T: SCM tree type and location.
> >Type is one of: git, hg, quilt, stgit, topgit
> > S: Status, one of the following:
>
> If this is actually done, I suggest putting this
> "R" entry description immediately after the "M" entry.
Yeah, it does seem
t; maintainers of other subsystems should ask to have the R: tag added for
> something they don't maintain but want to help out in.
That's exactly the idea: this should go along with a change to
get_maintainer.pl to add those folks to the CC list.
- Josh Triplett
--
To unsubscribe fro
>
> > > > I'm not sure of the value of this.
> > > >
> > > > Why not just mark the actual reviewers as maintainers?
> > >
> > > As discussed in the kernel summit discussion, being a regular patch
> > > reviewer isn't the same
an appropriate commit message,
Reviewed-by: Josh Triplett
> ---
> scripts/get_maintainer.pl | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 4198788..d701627 100755
&g
; > > > > >
> > > > > > I'm not sure of the value of this.
> > > > > >
> > > > > > Why not just mark the actual reviewers as maintainers?
> > > > >
> > > > > As discussed in the kernel summ
than 1 or 2, create a mailing list.
>
> Yes, much better on the patch sender(s) to Cc: 1 or 2 people or lists
> than to have to copy/paste 5 or 6 email addresses.
A patch sender should never need to manually copy and paste email
addresses, given get_maintainer.pl.
- Josh Triplett
--
To
t; On Mon, 2014-06-02 at 11:55 -0700, j...@joshtriplett.org wrote:
> > > > > this should go along with a change to
> > > > > get_maintainer.pl to add those folks to the CC list.
> > > >
> > > > Something like this:
> > >
> > >
gt; >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -7321,6 +7321,7 @@ F: kernel/rcu/torture.c
> >>>
> >>> RCUTORTURE TEST FRAMEWORK
> >>> M: "Paul E. McKenney"
> >>> +R: Josh Triplett
>
a commit, I can blame the reviewers just as much as I can
> blame the author :-)
I like it there for the same reason: if there turns out to be an issue
in a commit I reviewed, I'd like to get CCed on the resulting discussion
and fix, so that I can take that into account in future reviews.
wing warning in target_core_spc.c:
> drivers/target/target_core_spc.c:138:6: warning: no previous prototype for
> ‘spc_parse_naa_6h_vendor_specific’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/target/target_core_pr.h
_iblock.c:766:6: warning: no previous prototype for
> ‘iblock_get_write_cache’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/target/target_core_iblock.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
&g
pes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/target/loopback/tcm_loop.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/target/loopback/tcm_loop.c
> b/drivers/target/loopback/tcm_loop.c
> index 1b4
thermal.c:218:5: warning: no previous prototype
> for ‘sys_set_trip_temp’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/thermal/x86_pkg_temp_thermal.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
ivers/target/tcm_fc/tfc_conf.c:602:6: warning: no previous prototype for
> ‘ft_deregister_configfs’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/target/tcm_fc/tfc_conf.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletio
ng in memory.c:
> > drivers/base/memory.c:87:1: warning: no previous prototype for
> > ‘memory_block_size_bytes’ [-Wmissing-prototypes]
> >
> > Signed-off-by: Rashika Kheria
> > Reviewed-by: Josh Triplett
> > ---
> > drivers/base/memory.c |1 +
&
revious prototype for
> > > > ‘memory_block_size_bytes’ [-Wmissing-prototypes]
> > > >
> > > > Signed-off-by: Rashika Kheria
> > > > Reviewed-by: Josh Triplett
> > > > ---
> > > > drivers/base/memory.c |1 +
> > > > 1 file ch
Moving ptp_pch.c elsehwere is not desirable, it's a PTP driver so
> it belongs under drivers/ptp.
For the moment, at least, would it be reasonable to have a proper header
for these functions since pch_gbe is currently calling them? Making
that driver *not* call those functions might well be a s
nd have
> drivers/usb/core/hcd-pci.c include that file. After all, it's
> perfectly reasonable for hcd-pci to want to know about the quirks of
> various PCI-based controllers, but it's not reasonable for pci-quirks.c
> to need to know about the details of HCDs.
Sounds reasonable.
es.
True. I personally prefer the policy of making all headers
self-contained, and then only including headers that define things used
in the source file. That has the advantage of not including any
unnecessary headers if the dependencies shrink, and not requiring
changes to multiple source
someone notices that they're *not*
self-contained (in other words, they include a .h file to get a
definition they need, and get a compile error).
- 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/
On Fri, Aug 08, 2014 at 06:22:20PM -0700, Linus Torvalds wrote:
> On Fri, Aug 8, 2014 at 5:10 PM, Josh Triplett wrote:
> > Since commit 5d2acfc7b974bbd3858b4dd3f2cdc6362dd8843a ("kconfig: make
> > allnoconfig disable options behind EMBEDDED and EXPERT") in 3.15-r
exity would also be that we would have to support new 32bit compat
> environment on 64bit systems. Userspace would be completely rebuilt to
> support the new -llt architecture, and compatibility for legacy
> applications would be done via the same multiarch packaging as is done now
> fo
On Fri, Aug 01, 2014 at 01:45:29PM -0700, Andrew Morton wrote:
> On Thu, 31 Jul 2014 16:47:23 -0700 Josh Triplett
> wrote:
>
> > GCC 4.10 and newer, and Sparse, supports
> > __attribute__((designated_init)), which marks a structure as requiring
> > a designate
and
bcma_host_soc_unregister_driver.)
The following patch seems to mostly do the right thing, though for some
reason some __exit functions remain in the final binary (such as
md_exit and mon_exit):
--->8---
>From 1646d051a4a4c18b9a6163fceabcafa20628c728 Mon Sep 17 00:00:00 2001
From: Jo
ng to figure
out the twisty maze of binaries.
Reviewed-by: Josh Triplett
> arch/x86/boot/compressed/Makefile | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/x86/boot/compressed/Makefile
> b/arch/x86/boot/compressed/Makefile
> index be1e07d4b596..44
without a caller (nor should an artificial caller be
added). What's your use case for adding this?
Also, while I realize __putstr already has this problem, ideally all the
printing functions in this file should go in some separate source file
that gets omitted when !CONFIG_PRINTK (or possibly
!CO
off when vsyscall=none
> x86_64,vsyscall: Rewrite comment and clean up headers in vsyscall code
> x86_64,vsyscall: Make vsyscall emulation configurable
Nice!
For patches 1 and 2:
Reviewed-by: Josh Triplett
For patch 3, I responded with a possible minor improvement, but with or
without th
On Wed, Oct 29, 2014 at 09:59:25AM -0700, Kees Cook wrote:
> On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett wrote:
> > --- a/arch/x86/kernel/process-io.h
> > +++ b/arch/x86/kernel/process-io.h
> > @@ -1,9 +1,17 @@
> > #ifndef _X86_KERNEL_PROCESS_IO_H
> >
ping with the other CONFIG_SYSCALL_*
> >> naming thread? Again, I don't really care strongly beyond really
> >> wanting to use this new feature! :)
> >
> > I don't feel strongly about the naming. Ingo?
>
> It is sort of a special case here, as this reflects
even on a per-directory basis. However,
-Werror=specific-warning is a great idea. We should add that for
high-value warnings that have been entirely eliminated in a directory.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
k behavior for init as
well, standard kernel practice has typically been to use "default y" for
previously built-in features that become configurable. And I'd
certainly prefer a compile-time configuration option like this (even
with default y) over a "strictinit" kernel comm
or two, then switch the default?
Default y for a few releases, get it on the radar of various
distributions so they make an explicit decision about it, then consider
changing the upstream default.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
does this patch gratuitously change the indentation of the
second line of pr_err?
That aside:
Reviewed-by: Josh Triplett
>
> Changes from v4:
> - Switch the default to y
>
> Changes from v3:
> - Get rid of the strictinit option. Now the new behavior is the default
>
> Cc: Eric Paris
> Cc: Hannes Frederic Sowa
> Cc: Jesse Gross
> Cc: Jonathan Corbet
> Cc: Paul Gortmaker
> Cc: Pravin Shelar
> Cc: Alexander Viro
> Cc: Josh Triplett
> Signed-off-by: Aristeu Rozanski
I already have a patch for this sitting in the tiny tree (branc
8 985 3d9 (TOTALS)
>
> and it's used by ext3 and ext4. This patch is useful for situations
> in which memory footprint is a concern and those filesystems aren't
> used.
>
> Cc: Jan Kara
> Cc: Andrew Morton
> Cc: Andreas Dilger
> Cc: Paul Gortmaker
> Cc: David S. Miller
> Cc: Fabian Frederick
> Cc: Geert Uytterhoeven
> Cc: Linus Torvalds
> Cc: Pablo Neira Ayuso
> Cc: Thomas Graf
> Cc: Ying Xue
> Cc: Josh Triplett
> Signed-off-by: Aristeu Rozanski
I already have a patch for this in the tiny tree (tiny/no-rhash
ESA doesn't depend on X86,
even though FB_VESA does? Does v86d run on non-x86 hardware via
emulation? If so, should FB_UVESA have "select X86_IOPORT if X86"?
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
nels were already
> UP. I don't think it makes much sense to have it at that level. Same
> with preemption.
OK. So, would you consider making it possible to compile out SRCU in
that specific case, while depending on SRCU if either SMP or PREEMPT?
Because that's also the case that allow
On Tue, Jul 28, 2015 at 09:51:57PM +0100, Matt Fleming wrote:
> (Pulling in Josh)
Thanks, Matt.
> On Wed, 22 Jul, at 05:32:44PM, Sebastian Andrzej Siewior wrote:
> > I usually see
> > |Ignoring BGRT: failed to allocate memory for image (wanted 264301314 bytes)
> > |
resolve these dependency
> issues and also document why such limitation exists.
>
> Cc: Geert Uytterhoeven
> Cc: James Bottomley
> Cc: Josh Triplett
> Cc: Paul Bolle
> Cc: Herbert Xu
> Cc: Takashi Iwai
> Cc: "Yann E. MORIN"
> Cc: Michal Marek
>
On Mon, Jul 27, 2015 at 01:03:12PM -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett
> wrote:
>
> > > Some mm functionality might very possibly rely on srcu in the future if
> > > we expect any chances of scaling, ie: faults. So I'
On Mon, Jul 27, 2015 at 01:20:02PM -0700, Davidlohr Bueso wrote:
> On Mon, 2015-07-27 at 13:03 -0700, Andrew Morton wrote:
> > On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett
> > wrote:
> >
> > > > Some mm functionality might very possibly rely on srcu in th
particular
instance, and seeing how clean you can make that.
- 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/
;
> Signed-off-by: Darren Hart
> Reviewed-by: Josh Triplett
I've applied this patch to tiny/ksize in the tinification tree
(https://git.kernel.org/cgit/linux/kernel/git/josh/linux.git/), and I
plan to submit it upstream during the next merge window.
If someone would prefer to take
On Thu, Nov 20, 2014 at 09:14:50AM -0600, Eric W. Biederman wrote:
> Josh Triplett writes:
> > Analogous to the supplementary GID list, the supplementary UID list
> > provides a set of additional user credentials that a process can act as.
> > A process with CAP_SETUID
ly throw them out when not used, without emiting a warning.
That should drastically reduce the number of changes, and in particular
eliminate almost all of the ifdefs.
- 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/
ybe_unused, then wrap the initialization of
.splice_write = splice_write_null to make it .splice_write =
splice_p(splice_write_null). That will avoid adding a single ifdef.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
ace-constrained system
(e.g. cluster filesystems); the patch series could likely be narrowed
to just a half-dozen likely filesystems and drivers, all of which could
be done separately from the initial series removing the core splice
code. Would that be more appealing?
- Josh Triplett
--
To unsubs
ecific splice functions
actually call it; you can make it a no-op static inline, though.
- 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/
ne NOPs when splice is compiled out should
> keep me out of the file-systems.
>
> The space savings are scattered over the patch-set. I'll make sure the next
> attempt includes it in the cover-letter.
I'd suggest including the results from scripts/bloat-o-meter in the
co
On Mon, Nov 24, 2014 at 11:34:12AM -0800, Greg KH wrote:
> On Mon, Nov 24, 2014 at 08:05:10AM -0800, Josh Triplett wrote:
> > On Mon, Nov 24, 2014 at 10:49:31AM +0100, Pieter Smith wrote:
> > > On Sun, Nov 23, 2014 at 03:23:02PM -0800, Josh Triplett wrote:
> > > >
ion
would then repeat in very clear terms the warning that if you disable
that option and then disable specific syscalls, you need to know exactly
what your target userspace uses. That would group together this whole
family of options, and make it clearer what the implications are.
- Josh Trip
bytes)
> >
> > fuse_dev_do_read() is definitely going to remain used. So no point in
> > adding
> > __maybe_unused.
>
> Off course, but at least gcc now also is aware that this is intentional and
> nicely refrains from nagging you with a warning.
s we're targeting for the tinification effort, in
a first pass: 512k-2M of storage (often for an *uncompressed* kernel, to
support execute-in-place), and 128k-512k of memory. We've successfully
built useful kernels and userspaces for such environments, and we'd like
to go even smaller.
- J
On Tue, Nov 25, 2014 at 11:10:44AM +0100, Ingo Molnar wrote:
> * Josh Triplett wrote:
> > On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > > * Stephen Rothwell wrote:
> > > > Hi Josh,
> > > >
> > > > Today's linux-next m
ust a matter of using it for whatever
> > purpose we need.
> >
>
> A list of group id ranges that it's permissible to drop would do the
> trick, both for setgroups and for unshare. The downside would be that
> users in those groups (i.e. everyone by default) would
> >>wrote:
> >>> On Mon, Nov 17, 2014 at 10:06 AM, Casey Schaufler
> >>> wrote:
> >>>> On 11/15/2014 1:01 AM, Josh Triplett wrote:
> >>>>> Currently, unprivileged processes (without CAP_SETGID) cannot call
> >>>>>
Reviewed-by: Josh Triplett
> fs/Makefile | 3 +-
> fs/read_write.c | 176 -
> fs/sendfile.c | 200
>
> 3 files changed, 201 insertions(+), 178 deletions(-)
> cr
ment
applies: one nit below, and with that fixed:
Reviewed-by: Josh Triplett
I've explicitly checked that the moved code matches between
fs/read_write.c and fs/sendfile.c, modulo a single whitespace fix (in
the indentation of the continuation line for do_sendfile's definition).
&g
On Mon, Oct 20, 2014 at 03:04:36PM -0700, Andy Lutomirski wrote:
> CONFIG_INIT_FALLBACK adds config bloat without an obvious use case
> that makes it worth keeping around. Delete it.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> Bring on the blame :)
Reviewed-by: Josh Trip
C put fdput
out-of-line, and compiling it out reversed that again.
> Signed-off-by: Pieter Smith
Reviewed-by: Josh Triplett
> ---
> fs/Makefile | 3 ++-
> init/Kconfig| 10 ++
> kernel/sys_ni.c | 4
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
On Tue, Oct 21, 2014 at 06:18:00AM +0800, Greg Kroah-Hartman wrote:
> On Mon, Oct 20, 2014 at 04:55:11AM -0700, Josh Triplett wrote:
> > On Mon, Oct 20, 2014 at 11:42:31AM +0200, Johannes Berg wrote:
> > > On Thu, 2014-10-16 at 11:49 -0400, Aristeu Rozanski wrote:
> >
On Wed, May 20, 2015 at 12:00:13PM +0200, Paul Bolle wrote:
> Hi Josh,
>
> On Thu, 2015-05-14 at 08:36 -0700, Josh Triplett wrote:
> > kconfig implicitly creates a submenu whenever a series of symbols all
> > have dependencies or prompt-visibility expressions that all depen
On Tue, May 19, 2015 at 01:50:24PM -0400, Theodore Ts'o wrote:
> On Tue, May 19, 2015 at 09:37:40AM -0700, Josh Triplett wrote:
> > In particular, I didn't realize this was *only* the data of the
> > delayed-extent-based files. The bug here seems to have struck various
&
On Fri, May 22, 2015 at 09:28:14PM +0200, Luis R. Rodriguez wrote:
> Adding Josh, as I know he seems to be on an EXPERT crusade to tuck
> away system calls for tinyconfig, so likely can chime in for some
> insane EXPERT runtime issue that users can run into.
Thanks.
> On Fri, May 22
On Thu, May 14, 2015 at 01:04:06PM +0200, Paul Bolle wrote:
> [Adding Michal and linux-kbuild.]
>
> Hi Josh,
>
> Could you please resend this series to include Michal and linux-kbuild?
> Don't bother to include Yann. (I almost forwarded the entire series but
> that look
On Thu, May 14, 2015 at 08:35:23AM -0700, Josh Triplett wrote:
> Commit e1abf2cc8d5 ("bpf: Fix the build on BPF_SYSCALL=y &&
> !CONFIG_TRACING kernels, make it more configurable") made BPF_SYSCALL no
> longer hidden with !EXPERT, but left it in the middle of the EXPER
seriously using synchronize_sched() to provide the low-overhead
> membarrier scheme.
> - Check num_online_cpus() == 1, quickly return without doing nothing.
>
> Changes since v3a:
> - Confirm that each CPU indeed runs the current task's ->mm before
> sending an IPI. Ens
On Wed, May 06, 2015 at 08:44:29AM -0700, Josh Triplett wrote:
> On Wed, May 06, 2015 at 05:08:50PM +0800, Fengguang Wu wrote:
> > FYI, the reported bug is still not fixed in linux-next 20150506.
>
> This isn't the same bug. The previous one you mentioned was a userspace
&g
On Wed, May 06, 2015 at 08:39:22PM -0400, Peter Hurley wrote:
> On 05/06/2015 07:59 PM, j...@joshtriplett.org wrote:
> > On Wed, May 06, 2015 at 08:44:29AM -0700, Josh Triplett wrote:
> >> On Wed, May 06, 2015 at 05:08:50PM +0800, Fengguang Wu wrote:
> >>> FYI, the r
On Thu, May 07, 2015 at 12:24:07PM -0400, Peter Hurley wrote:
> On 05/07/2015 11:56 AM, j...@joshtriplett.org wrote:
> > On Wed, May 06, 2015 at 08:39:22PM -0400, Peter Hurley wrote:
> >> On 05/06/2015 07:59 PM, j...@joshtriplett.org wrote:
> >>> On Wed, May 06,
> On 05/06/2015 07:59 PM, j...@joshtriplett.org wrote:
> > >>> On Wed, May 06, 2015 at 08:44:29AM -0700, Josh Triplett wrote:
> > >>>> On Wed, May 06, 2015 at 05:08:50PM +0800, Fengguang Wu wrote:
> > >>>>> FYI, the reported bug is still not fixed
On Thu, May 07, 2015 at 01:52:37PM -0400, Peter Hurley wrote:
> On 05/06/2015 08:35 PM, Josh Triplett wrote:
> > If devpts failed to initialize, it would store an ERR_PTR in the global
> > devpts_mnt. A subsequent open of /dev/ptmx would call devpts_new_index,
> > wh
On Thu, May 07, 2015 at 03:59:19PM -0700, Andrew Morton wrote:
> On Wed, 6 May 2015 17:35:47 -0700 Josh Triplett wrote:
>
> > If devpts failed to initialize, it would store an ERR_PTR in the global
> > devpts_mnt. A subsequent open of /dev/ptmx would call devpts_new_inde
lf into for tracing purposes, or
with general sanity. However, the explanation for those use cases and
how membarrier() improves them needs to go in the commit message, rather
than only in the collective memory and mail archives of people who have
discussed this patch series.
(My apolo
s in 10s, 6 readers, 2 writers:
>
> memory barriers in reader:1701557485 reads, 3129842 writes
> signal-based scheme: 9830061167 reads,6700 writes
> sys_membarrier: 9952759104 reads, 425 writes
> sys_membarrier (dyn. check): 7970328887 reads
On Tue, May 05, 2015 at 08:53:03PM +0200, Thomas Gleixner wrote:
> On Tue, 21 Apr 2015, Josh Triplett wrote:
> >
> > Signed-off-by: Josh Triplett
> > Signed-off-by: Thiago Macieira
>
> Can you please clarify that SOB chain? It does not make any sense.
Co-authored p
with -Wsection, because these variables were declared
> in .data..percpu and defined in .data..percpu..shared_aligned since
> commit 11bbb235c26f ("rcu: Use DEFINE_PER_CPU_SHARED_ALIGNED for
> rcu_data").
>
> Signed-off-by: Nicolas Iooss
Reviewed-by: Josh Triplett
Nice impro
hat system again.
Thanks,
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/
h. I reviewed the Kconfig option and its usage very carefully,
but completely missed that it was in the wrong file.
This needs to go in init/Kconfig or similar.
- 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/
RSE will never be set outside of x86, right? So does
> this change nothing for those other architectures?
See comment on the previous patch; this is not x86-specific, and it
should be a config option for all architectures.
- Josh Triplett
--
To unsubscribe from this list: send the line &quo
On Tue, May 12, 2015 at 02:22:50PM -0700, Andrew Morton wrote:
> On Mon, 11 May 2015 12:29:19 -0700 Josh Triplett
> wrote:
>
> > Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt
> > into, and a new copy_thread_tls that accepts the tls parameter as an
&g
way), so callers have to actually *call* these
empty functions, and the functions themselves would need to be emitted.
Turning them into static inlines tells the callers that they can avoid
emitting any code.
Reviewed-by: Josh Triplett
> include/linux/rcupdate.h | 4
> includ
onsidered an emergency.
>
> Signed-off-by: Paul E. McKenney
> Cc:
Ouch, subtle.
Reviewed-by: Josh Triplett
> kernel/rcu/tiny.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
> index a501b4ab9b1c..591af0cb
On Tue, May 12, 2015 at 03:49:12PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Reported-by: "Ahmed, Iftekhar"
> Signed-off-by: Paul E. McKenney
Could you elaborate a bit more on this patch (ideally in its commit
message)? I see an addition of a command-line parameter to test
On Tue, May 12, 2015 at 03:58:04PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> By default, with rcutorture.nreaders equal to -1, rcutorture provisions
> N-1 reader kthreads, where N is the number of CPUs. This avoids
> rcutorture-induced stalls, but also avoids heavier levels o
On Tue, May 12, 2015 at 03:58:11PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit updates TREE_RCU-kconfig.txt to reflect changes in RCU's
> Kconfig setup. This commit also updates rcutorture's Kconfig fragments
> to account for Kconfig parameters that are now driven d
parameter
> setup.
>
> 12. Make torture scripts display "make oldconfig" errors
>
> 13. Allow repetition factors in Kconfig-fragment lists. Because
> typing 48 repetitions of "TINY02" is getting old.
I replied to patches 4 and 11 with feedback. Fo
The #CHECK# prefix tells the rcutorture scripts to take no action
> to try to set the Kconfig parameter, but to check that it does
> in fact get set. This is useful for verifying that Kconfig
> parameters that are supposed to be automatical
On Wed, May 13, 2015 at 03:56:28PM -0700, Andrew Morton wrote:
> On Mon, 11 May 2015 12:29:19 -0700 Josh Triplett
> wrote:
>
> > clone with CLONE_SETTLS accepts an argument to set the thread-local
> > storage area for the new thread. sys_clone declares an int argume
e invasive
patch for much less gain. On a system that doesn't need non-root users,
there are hopefully very few processes and thus very few copies of
task_struct; likewise for other structures containing credential data.
Iulia and I talked about that one and ended up coming to the conclusion
t
>
> Quick query: does CLONE_AUTOREAP also affect waiting for non-exit
> events (i.e. WUNTRACED / WCONTINUED), by original parent and/or ptracer?
It shouldn't, no. You can't wait on the process to exit (you'll get
-ECHLD after it wakes up), but you can wait on it to continue
On Mon, Mar 23, 2015 at 02:11:45PM +, David Drysdale wrote:
> On Sun, Mar 15, 2015 at 7:59 AM, Josh Triplett wrote:
> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> > index 0286735..ba28306 100644
> > --- a/arch/x86/ia32/ia32entry.S
> > +++
On Mon, Mar 16, 2015 at 02:44:20PM -0700, Kees Cook wrote:
> On Sun, Mar 15, 2015 at 12:59 AM, Josh Triplett wrote:
> > - Make poll on a CLONE_FD for an exited task also return POLLHUP, for
> > compatibility with FreeBSD's pdfork. Thanks to David Drysdale for calling
>
emantics we implemented; you'll *always* get an
exit notification via the clonefd if you have it open, with or without
autoreap and whether or not a wait has occurred yet. And reading from
the clonefd does not serve as a wait; if you don't pass CLONE_AUTOREAP,
you'll still need to wait on
t's fine. There's no semantic meaning attached to reading from the
clonefd; you still have to wait on the process if you don't pass
CLONE_AUTOREAP. (Or you can block SIGCHLD or use SA_NOCLDWAIT, if you
control the calling process's signal handling; AUTOREAP just lets you
avoid in
> non-expedited scheme. I don't need to touch the scheduler
> internals anymore, so should I move the sys_membarrier
> system call implementation into kernel/rcu/update.c ?
If you don't need access to scheduler internals, I'd suggest putting it
in its own file (something
to avoid issuing a barrier
on CPUs not running the current process if it can, while
~MEMBARRIER_PRIVATE may not. (The latter would be useful for
applications such as system-wide tracing.) That they're currently both
implemented the same way doesn't mean they're semantically equivalent.
101 - 200 of 5391 matches
Mail list logo
