: Paul E. McKenney
Co-developed-by: Vineeth Pillai
Signed-off-by: Vineeth Pillai
Signed-off-by: Joel Fernandes (Google)
---
If you like some pictures of the cases handled by this patch, please
see the OSPM slide deck (the below link jumps straight to relevant
slides - about 6-7 of them in total
-tagged, allow the CGroup interface to override
the task's tag.
ChromeOS will use core-scheduling to securely enable hyperthreading.
This cuts down the keypress latency in Google docs from 150ms to 50ms
while improving the camera streaming frame rate by ~3%.
Signed-off-by: Joel Fernandes (Google
On Wed, May 20, 2020 at 08:28:00PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-05-20 13:42:59 [-0400], Joel Fernandes wrote:
> > Hi Sebastian,
> Hi Joel,
>
> > For pointer stability, can we just use get_local_ptr() and put_local_ptr()
> > instead of addin
On Wed, May 20, 2020 at 08:35:29PM +0200, Peter Zijlstra wrote:
> On Wed, May 20, 2020 at 08:28:00PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-05-20 13:42:59 [-0400], Joel Fernandes wrote:
> > > Hi Sebastian,
> > Hi Joel,
> >
> > > For pointer s
Hi Sebastian,
On Wed, May 20, 2020 at 02:06:08PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-05-20 12:24:07 [+0200], Peter Zijlstra wrote:
> > On Tue, May 19, 2020 at 10:19:07PM +0200, Sebastian Andrzej Siewior wrote:
> >
> > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> >
her to directly
acquire lock or call rcu_nocb_lock_irqsave()).
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
>
> Signed-off-by: Frederic Weisbecker
> Cc: Paul E. McKenney
> Cc: Josh Triplett
> Cc: Steven Rostedt
> Cc: Mathieu Desnoyers
> Cc: Lai Jiangshan
>
always_inline void rcu_nmi_ente
> /**
> * rcu_nmi_enter - inform RCU of entry to NMI context
> */
> -void rcu_nmi_enter(void)
> +noinstr void rcu_nmi_enter(void)
> {
> rcu_nmi_enter_common(false);
> }
> -NOKPROBE_SYMBOL(rcu_nmi_enter);
>
> /**
> * rc
On Sat, May 16, 2020 at 10:18:45AM -0700, Paul E. McKenney wrote:
> On Sat, May 16, 2020 at 01:45:47AM +0200, Thomas Gleixner wrote:
>
> [ . . . ]
>
> > - noinstr-rcu-nmi-2020-05-15
> >
> > Based on the core/rcu branch in the tip tree. It has merged in
> > noinstr-lds-2020-05-15 and
On Thu, May 14, 2020 at 04:43:31PM +0200, Thomas Gleixner wrote:
[...]
> > Or, if [1] is merged, then we could just combine the checks into one check.
> > RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nesting) != 1,
> > "Bad RCU dynticks_nmi_nesting counter\n");
> >
On Wed, May 13, 2020 at 10:41:16PM -0400, Joel Fernandes wrote:
> Hi Thomas,
>
> On Tue, May 05, 2020 at 03:44:05PM +0200, Thomas Gleixner wrote:
>
> Thank you for CC'ing me.
>
> > Interrupts and exceptions invoke rcu_irq_enter() on entry and need to
> > invoke rcu
okes rcu_irq_exit() and contains a few sanity checks in case that
> CONFIG_PROVE_RCU is enabled to catch such issues directly.
Could you let me know which patch or part in the multi-part series is using it?
>
> Signed-off-by: Thomas Gleixner
> Cc: "Paul E. McKenney"
> Cc
On Tue, May 12, 2020 at 5:49 PM Akira Yokosawa wrote:
>
> On Tue, 12 May 2020 17:43:42 -0400, Joel Fernandes wrote:
> > On Tue, May 12, 2020 at 09:30:22AM -0700, Paul E. McKenney wrote:
> >> On Tue, May 12, 2020 at 11:41:01AM -0400, Joel Fernandes wrote:
> >>>
On Tue, May 12, 2020 at 09:30:22AM -0700, Paul E. McKenney wrote:
> On Tue, May 12, 2020 at 11:41:01AM -0400, Joel Fernandes wrote:
> > On Tue, May 12, 2020 at 11:07 AM Akira Yokosawa wrote:
> > >
> > > From 7bb979aacd8788d174df8a56e9803ba9e5b7a381 Mon Sep 17 00:
On Tue, May 12, 2020 at 11:30 AM Rafael J. Wysocki wrote:
[...]
> > The end goal with GKI is the following: Google will release a single
> > binary kernel image (signed, etc etc) that all devices using a given
> > Android version will be required to use. That image is however going to
> > be only
On Tue, May 12, 2020 at 11:07 AM Akira Yokosawa wrote:
>
> From 7bb979aacd8788d174df8a56e9803ba9e5b7a381 Mon Sep 17 00:00:00 2001
> From: Joel Fernandes (Google)
> Date: Mon, 11 May 2020 22:06:46 -0400
> Subject: [PATCH 4/3] docs: litmus-tests: Clarify about the RCU
> pre-i
On Tue, May 12, 2020 at 10:39 AM Akira Yokosawa wrote:
>
> On Tue, 12 May 2020 07:19:44 -0700, Paul E. McKenney wrote:
> > On Tue, May 12, 2020 at 08:19:36AM -0400, Joel Fernandes wrote:
> >> On Tue, May 12, 2020 at 08:50:45PM +0900, Akira Yokosawa wrote:
> >&g
came up.
> >
> > For Akira's series,
> > Acked-by: Joel Fernandes (Google)
>
> Thank you!
>
> >
> > And could we add the following patch on top of Akira's series so we still
> > maintain a reference to the moved RCU test?>
> > ---8<---
ponse but I've noticed some glitches.
> > >
> > > On Sun, 22 Mar 2020 21:57:32 -0400, Joel Fernandes (Google) wrote:
> > >> Move MP+onceassign+derefonce to the new Documentation/litmus-tests/rcu/
> > >> directory.
> > >
> > > MP+onceassign+derefonce.litmus
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: a6a82ce18ba443186545d3fefbee8b9419a859dc
Gitweb:
https://git.kernel.org/tip/a6a82ce18ba443186545d3fefbee8b9419a859dc
Author:Joel Fernandes (Google)
AuthorDate:Mon, 16 Mar 2020 12:32:28 -04:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 9154244c1ab6c9db4f1f25ac8f73bd46dba64287
Gitweb:
https://git.kernel.org/tip/9154244c1ab6c9db4f1f25ac8f73bd46dba64287
Author:Joel Fernandes (Google)
AuthorDate:Mon, 16 Mar 2020 12:32:27 -04:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: f87dc808009ac86c790031627698ef1a34c31e25
Gitweb:
https://git.kernel.org/tip/f87dc808009ac86c790031627698ef1a34c31e25
Author:Joel Fernandes (Google)
AuthorDate:Mon, 16 Mar 2020 12:32:26 -04:00
t; Cc: sta...@vger.kernel.org
> Fixes: d16a8c31077e ("tracing: Wait for preempt irq delay thread to finish")
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> Signed-off-by: Steven Rostedt (VMware)
> ---
> kernel/trace/preemptirq_delay_test.c | 12 ++--
On Mon, May 11, 2020 at 9:49 AM Peter Zijlstra wrote:
>
> On Sun, May 10, 2020 at 07:46:52PM -0400, Joel Fernandes (Google) wrote:
> > With current core scheduling patchset, non-threaded IRQ and softirq
> > victims can leak data from its hyperthread to a sibling hyper
Signed-off-by: Joel Fernandes (Google)
---
If you like some pictures of the cases handled by this patch, please
see the OSPM slide deck (the below link jumps straight to relevant
slides - about 6-7 of them in total): https://bit.ly/2zvzxWk
TODO:
1. Any optimziations for VM usecases (can we do
On Wed, May 6, 2020 at 9:11 PM Brian Geffon wrote:
>
> > > - mremap_userfaultfd_complete(, addr, new_addr, old_len);
> > > + mremap_userfaultfd_complete(, addr, ret, old_len);
> >
> > Not super familiar with this code, but thought I'd ask, does ret
> > to be checked for -ENOMEM before
On Wed, May 6, 2020 at 1:22 PM Brian Geffon wrote:
>
> A user is not required to set a new address when using
> MREMAP_DONTUNMAP as it can be used without MREMAP_FIXED.
> When doing so the remap event will use new_addr which may not
> have been set and we didn't propagate it back other then
> in
t;)
I'd also avoid top-posting and send inline replies:
https://web.archive.org/web/20080722025748/http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt
https://lkml.org/lkml/2019/12/4/267
Thanks!
- Joel
>
> Brian
>
>
> On Wed, May 6, 2020 at 10:28 AM Joel Fernandes wrote
On Wed, May 6, 2020 at 1:22 PM Brian Geffon wrote:
>
> A user is not required to set a new address when using
> MREMAP_DONTUNMAP as it can be used without MREMAP_FIXED.
> When doing so the remap event will use new_addr which may not
> have been set and we didn't propagate it back other then
> in
Hi Paul,
On Mon, May 4, 2020 at 3:01 PM Paul E. McKenney wrote:
>
> On Mon, May 04, 2020 at 02:08:05PM -0400, Joel Fernandes wrote:
> > On Mon, May 04, 2020 at 07:48:22PM +0200, Uladzislau Rezki wrote:
> > > On Mon, May 04, 2020 at 08:24:37AM -0700, P
On Mon, May 4, 2020 at 1:44 PM Paul E. McKenney wrote:
>
> On Mon, May 04, 2020 at 10:15:32AM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2020 at 08:05:00AM -0400, Joel Fernandes (Google) wrote:
> > > These patches clean up the usage of dynticks nesting
On Mon, May 04, 2020 at 07:48:22PM +0200, Uladzislau Rezki wrote:
> On Mon, May 04, 2020 at 08:24:37AM -0700, Paul E. McKenney wrote:
[..]
> > > > Presumably the list can also be accessed without holding this lock,
> > > > because otherwise we shouldn't need llist...
> > > >
> > > Hm... We
On Mon, May 4, 2020 at 1:15 PM Paul E. McKenney wrote:
>
> On Mon, May 04, 2020 at 08:05:00AM -0400, Joel Fernandes (Google) wrote:
> > These patches clean up the usage of dynticks nesting counters simplifying
> > the
> > code, while preserving the usecases.
>
do cheaper
comparisons with zero instead for the code that keeps the tick on in
rcu_nmi_enter_common().
In the next patch, both of the concerns of (2) will be addressed and
then we can get rid of dynticks_nmi_nesting, however one step at a time.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/r
for
rcu_dyntick.
Similarly, USER, IDLE and IRQ are used for describing context in
the rcu_dyntick tracepoints. Since, "KERNEL" is not used for any
of the rcu_dyntick tracepoints, remove it from the description.
Signed-off-by: Madhuparna Bhowmik
Signed-off-by: Joel Fernandes (Google)
--
" or "IRQ".
(2) Remove the "++=" and "--=" strings and replace them with
"StillNonIdle". This is much easier on the eyes, and the -- and ++
are easily apparent in the dynticks_nesting counters we are printing
anyway.
Signed-off-by: J
have been set to true in the outermost interrupt, so the nested/NMI
interrupts will check forced_tick anyway, and bail.
Signed-off-by: Joel Fernandes (Google)
---
.../Data-Structures/Data-Structures.rst | 31 ---
Documentation/RCU/stallwarn.rst | 6 +--
kernel/rcu/tree.c
This code is unused and can be removed now. Revert was straightforward.
Tested with rcutorture on all TREE configurations.
Link:
http://lore.kernel.org/r/CALCETrWNPOOdTrFabTDd=h7+wc6xj9rjceg6ol1s0rtv5pf...@mail.gmail.com
Suggested-by: Andy Lutomirski
Signed-off-by: Joel Fernandes (Google
is not a simple counter and can be "crowbarred" in
common situations.
rcutorture testing with all TREE RCU configurations succeed with
CONFIG_RCU_EQS_DEBUG=y and CONFIG_PROVE_LOCKING=y.
v1->v2:
- Rebase on v5.6-rc6
v2->v3:
- Rebase on rcu/dev with adjustments for tasks-RCU.
Joel Ferna
On Sun, May 03, 2020 at 05:20:32PM -0700, Paul E. McKenney wrote:
> On Sun, May 03, 2020 at 07:42:50PM -0400, Joel Fernandes wrote:
> > On Fri, May 01, 2020 at 02:37:53PM -0700, Paul E. McKenney wrote:
> > [...]
> > > > @@ -2993,41 +2994,73 @@ put_cached_bnode
On Sun, May 03, 2020 at 05:23:09PM -0700, Paul E. McKenney wrote:
> On Sun, May 03, 2020 at 07:44:00PM -0400, Joel Fernandes wrote:
> > On Fri, May 01, 2020 at 01:52:46PM -0700, Joe Perches wrote:
> > > On Fri, 2020-05-01 at 12:05 -0700, Paul E. McKenney wrote:
> > > &
On Sun, May 03, 2020 at 05:26:56PM -0700, Paul E. McKenney wrote:
> On Sun, May 03, 2020 at 07:52:13PM -0400, Joel Fernandes wrote:
> > On Fri, May 01, 2020 at 12:05:55PM -0700, Paul E. McKenney wrote:
> > > On Tue, Apr 28, 2020 at 10:58:42PM +0200, Uladzislau Rezki (Sony) w
On Sun, May 03, 2020 at 05:28:55PM -0700, Paul E. McKenney wrote:
> On Sun, May 03, 2020 at 08:12:58PM -0400, Joel Fernandes wrote:
> > On Fri, May 01, 2020 at 03:39:09PM -0700, Paul E. McKenney wrote:
> > > On Tue, Apr 28, 2020 at 10:58:58PM +0200, Uladzislau Rezki (Sony) wro
On Sun, May 03, 2020 at 05:29:47PM -0700, Paul E. McKenney wrote:
> On Sun, May 03, 2020 at 08:24:37PM -0400, Joel Fernandes wrote:
> > On Fri, May 01, 2020 at 04:00:52PM -0700, Paul E. McKenney wrote:
> > > On Tue, Apr 28, 2020 at 10:58:59PM +0200, Uladzislau Rezki (Sony) w
ay simpler and probably way faster as well. And given that Tiny RCU
> runs only on uniprocessor systems, the complexity probably is buying
> you very little, if anything.
Agreed.
thanks,
- Joel
>
> Thanx
On Fri, May 01, 2020 at 04:00:52PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 28, 2020 at 10:58:59PM +0200, Uladzislau Rezki (Sony) wrote:
> > From: "Joel Fernandes (Google)"
> >
> > Handle cases where the the object being kvfree_rcu()'d is not aligned by
> &g
t; rcu_head and queuing get failed, the current context has
> > to follow might_sleep() annotation, thus below steps could
> > be applied:
> >a) wait until a grace period has elapsed;
> >b) direct inlining of the kvfree() call.
> >
> > Reviewed-by:
On Fri, May 01, 2020 at 12:05:55PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 28, 2020 at 10:58:42PM +0200, Uladzislau Rezki (Sony) wrote:
> > From: "Joel Fernandes (Google)"
> >
> > Simple clean up of comments in kfree_rcu() code to keep it consistent
> &g
On Fri, May 01, 2020 at 01:52:46PM -0700, Joe Perches wrote:
> On Fri, 2020-05-01 at 12:05 -0700, Paul E. McKenney wrote:
> > On Tue, Apr 28, 2020 at 10:58:42PM +0200, Uladzislau Rezki (Sony) wrote:
> > > Simple clean up of comments in kfree_rcu() code to keep it consistent
> > > with majority of
On Fri, May 01, 2020 at 02:37:53PM -0700, Paul E. McKenney wrote:
[...]
> > @@ -2993,41 +2994,73 @@ put_cached_bnode(struct kfree_rcu_cpu *krcp,
> > static void kfree_rcu_work(struct work_struct *work)
> > {
> > unsigned long flags;
> > + struct kvfree_rcu_bulk_data *bkhead, *bvhead,
On Wed, Apr 29, 2020 at 12:31:41PM -0400, Steven Rostedt wrote:
> On Wed, 29 Apr 2020 19:54:16 +0800
> Xiao Yang wrote:
>
> > On 2020/4/28 22:45, Steven Rostedt wrote:
> > > diff --git a/kernel/trace/preemptirq_delay_test.c
> > > b/kernel/trace/preemptirq_delay_test.c
> > >> index
On Tue, Apr 28, 2020 at 06:19:05PM +0800, Xiao Yang wrote:
> Hi Joel,
>
> Thanks for your quick fix.
>
> Unfortunately, it fixes my original panic but introduces other
> issues(two wanings and one panic) on my arm64 vm, as below:
>
The following commit has been merged into the perf/core branch of tip:
Commit-ID: da97e18458fb42d7c00fac5fd1c56a3896ec666e
Gitweb:
https://git.kernel.org/tip/da97e18458fb42d7c00fac5fd1c56a3896ec666e
Author:Joel Fernandes (Google)
AuthorDate:Mon, 14 Oct 2019 13:03:08 -04
On Tue, Oct 15, 2019 at 01:19:07PM +0200, Viktor Rosendahl (BMW) wrote:
> This patch implements the feature that the tracing_max_latency file,
> e.g. /sys/kernel/debug/tracing/tracing_max_latency will receive
> notifications through the fsnotify framework when a new latency is
> available.
>
>
> > diff --git a/include/uapi/linux/perf_event.h
> > b/include/uapi/linux/perf_event.h
> > index bb7b271397a6..2af95f937a5b 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -427,6 +427,15 @@ struct perf_event_attr {
> > __u16 __reserved_2;
On Tue, Oct 15, 2019 at 10:30:08AM +0200, Peter Zijlstra wrote:
> On Mon, Oct 14, 2019 at 01:03:08PM -0400, Joel Fernandes (Google) wrote:
> > In current mainline, the degree of access to perf_event_open(2) system
> > call depends on the perf_event_paranoid sysctl. Th
RCU to be a decorative option of TREE_RCU.
>
Looks like a nice simplification and so far I could not poke any holes in the
code...
I am in support of this patch for further review and testing. Thanks!
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> Signed-off-by: Lai Jiangshan
&g
=
>
> Signed-off-by: Marco Elver
I believe Paul has already queued this, but anyway I have reviewed it as well
and it LGTM.
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> ---
> include/trace/events/rcu.h | 4 ++--
> ker
can be marked static.
> I made this change as shown below with your Reported-by.
>
> Seem reasonable?
>
LGTM.
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> Thanx, Paul
>
> ---
...@google.com
Cc: kernel-t...@android.com
Acked-by: James Morris
Co-developed-by: Peter Zijlstra
Suggested-by: Peter Zijlstra
Signed-off-by: Joel Fernandes (Google)
---
Changes since v1:
o Fixes from Peter Ziljstra.
o Added Ack from James Morris and Co-developed-by tag for Peter.
Changes since RFC
On Mon, Oct 14, 2019 at 11:35:44AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 11, 2019 at 12:03:30PM -0400, Joel Fernandes (Google) wrote:
>
> > @@ -4761,6 +4762,7 @@ int perf_event_release_kernel(struct perf_event
> > *event)
> > }
> >
> > no_ctx:
&g
: rsavit...@google.com
Cc: je...@google.com
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google)
---
Changes since RFC:
o Small nits, style changes (James Morris).
o Consolidation of code (Peter Zijlstra).
arch/x86/events/intel/bts.c | 8 ++--
arch/x86/events/intel/core.c
On Fri, Oct 11, 2019 at 09:05:43AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 02:31:14PM -0400, Joel Fernandes wrote:
> > On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
>
> > > Yes, I did notice, I found it weird.
> > >
> > &g
On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 11:13:33AM -0400, Joel Fernandes wrote:
> > On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> > > +static inline int perf_allow_tracepoint(struct perf_event_attr *attr)
>
On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2019 at 04:36:57PM -0400, Joel Fernandes (Google) wrote:
> > In currentl mainline, the degree of access to perf_event_open(2) system
> > call depends on the perf_event_paranoid sysctl. Th
On Thu, Oct 10, 2019 at 09:11:39AM +1100, James Morris wrote:
> On Wed, 9 Oct 2019, Joel Fernandes (Google) wrote:
>
> >
> > +#ifdef CONFIG_SECURITY
> > + err = security_perf_event_alloc(event);
> > + if (err)
> > + goto err_security;
On Wed, Oct 09, 2019 at 03:41:56PM -0700, Casey Schaufler wrote:
> On 10/9/2019 3:14 PM, James Morris wrote:
> > On Wed, 9 Oct 2019, Casey Schaufler wrote:
> >
> >> Please consider making the perf_alloc security blob maintained
> >> by the infrastructure rather than the individual modules. This
>
: rsavit...@google.com
Cc: je...@google.com
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google)
---
arch/x86/events/intel/bts.c | 5 +++
arch/x86/events/intel/core.c| 5 +++
arch/x86/events/intel/p4.c | 5 +++
include/linux/lsm_hooks.h | 15
On Wed, Oct 09, 2019 at 05:10:45PM +0200, Christian Brauner wrote:
> On Wed, Oct 09, 2019 at 10:55:58AM -0400, Joel Fernandes wrote:
> > On Wed, Oct 09, 2019 at 04:29:11PM +0200, Christian Brauner wrote:
> > > On Wed, Oct 09, 2019 at 10:21:29AM -0400, Joel Fernandes wrote:
>
On Wed, Oct 09, 2019 at 04:29:11PM +0200, Christian Brauner wrote:
> On Wed, Oct 09, 2019 at 10:21:29AM -0400, Joel Fernandes wrote:
> > On Wed, Oct 09, 2019 at 12:40:12PM +0200, Christian Brauner wrote:
> > > On Tue, Oct 08, 2019 at 02:05:16PM -0400, Joel Fernandes wrote:
>
On Wed, Oct 09, 2019 at 10:20:17AM +0800, Boqun Feng wrote:
[snip]
> > Boqun, are you going to be posting another patch which just uses
> > mask_ofl_ipi
> > in the for_each(..) loop? (without using _snap) as Paul suggested?
> >
>
> IIUC, Paul already has this fix along with other ->expmask
On Wed, Oct 09, 2019 at 12:40:12PM +0200, Christian Brauner wrote:
> On Tue, Oct 08, 2019 at 02:05:16PM -0400, Joel Fernandes wrote:
> > On Tue, Oct 08, 2019 at 03:01:59PM +0200, Christian Brauner wrote:
> > > When a binder transaction is initiated on a binder device coming fro
On Wed, Oct 09, 2019 at 12:08:24AM +0200, Viktor Rosendahl (BMW) wrote:
> This new trace option "console-latency" will enable the latency
> tracers to trace the console latencies. Previously this has always been
> implicitely disabled. I guess this is because they are considered
> to be well known
by copying
> the name of the binder device instead of stashing a pointer to it.
>
> Reported-by: Jann Horn
> Fixes: 03e2e07e3814 ("binder: Make transaction_log available in binderfs")
> Link:
> https://lore.kernel.org/r/cag48ez14q0-f8lqsvcnbyr2o6gpw8shxsm4u5jmd9mpstem...@mail.gmai
On Tue, Oct 08, 2019 at 06:35:45PM +0200, Marco Elver wrote:
> On Tue, 8 Oct 2019 at 18:30, Joel Fernandes wrote:
> >
> > On Tue, Oct 08, 2019 at 01:01:40PM +0800, Boqun Feng wrote:
> > > "mask_ofl_ipi" is used for iterate CPUs which IPIs are needed to send
&g
iteration. This would improve the readibility of the
> IPI sending loop in sync_rcu_exp_select_node_cpus().
>
> Signed-off-by: Boqun Feng
> ---
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> kernel/rcu/tree_exp.h | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletion
On Fri, Oct 04, 2019 at 03:24:39PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 04, 2019 at 11:54:02PM +0200, Jonathan Neuschäfer wrote:
> > Without this patch, Sphinx shows "variable arguments" as the description
> > of the cond argument, rather than the intended description, and prints
> > the
rwise falls back to the
> default behaviour.
>
> In commit f7b101d33046 ("kheaders: Move from proc to sysfs") it was
> modified to use sysfs and the script for generation of the archive was
> renamed to what is being patched.
>
> Signed-off-by: Dmitry Goldin
Reviewed-by: Jo
On Fri, Oct 04, 2019 at 07:01:37PM +0200, Dmitry Vyukov wrote:
> On Fri, Oct 4, 2019 at 6:57 PM Joel Fernandes wrote:
> >
> > On Fri, Oct 04, 2019 at 06:52:49PM +0200, Dmitry Vyukov wrote:
> > > On Fri, Oct 4, 2019 at 6:49 PM Joel Fernandes
> > > wrote:
>
On Tue, Oct 01, 2019 at 01:27:02PM +0200, Uladzislau Rezki wrote:
[snip]
> > > I have just a small question related to workloads and performance
> > > evaluation.
> > > Are you aware of any specific workloads which benefit from it for example
> > > mobile area, etc? I am asking because i think
On Fri, Oct 04, 2019 at 06:52:49PM +0200, Dmitry Vyukov wrote:
> On Fri, Oct 4, 2019 at 6:49 PM Joel Fernandes wrote:
> >
> > On Wed, Oct 02, 2019 at 09:51:58PM +0200, Marco Elver wrote:
> > > Hi Joel,
> > >
> > > On Tue, 1 Oct 2019 at 23:19, Joel Ferna
On Wed, Oct 02, 2019 at 09:51:58PM +0200, Marco Elver wrote:
> Hi Joel,
>
> On Tue, 1 Oct 2019 at 23:19, Joel Fernandes wrote:
> >
> > On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote:
> > > Hi all,
> > >
> > > We would like to sha
Hi Oleg,
On Fri, Oct 04, 2019 at 05:41:03PM +0200, Oleg Nesterov wrote:
> On 10/04, Joel Fernandes (Google) wrote:
> >
> > But this is not always true if you consider the following events:
>
> I'm afraid I missed your point, but...
>
> > ---
On Fri, Oct 04, 2019 at 10:57:41AM -0400, Joel Fernandes (Google) wrote:
> From: Joel Fernandes
>
> Please consider this is an RFC for discussion only. Just want to discuss
> why the GP_REPLAY state is needed at all.
And I messed up the subject prefix, but this is
From: Joel Fernandes
Please consider this is an RFC for discussion only. Just want to discuss
why the GP_REPLAY state is needed at all.
Here's the intention AFAICS:
When rcu_sync_exit() has happened, the gp_state changes to GP_EXIT while
we wait for a grace period before transitioning
46 ("kheaders: Move from proc to sysfs") it was
> > modified to use sysfs and the script for generation of the archive was
> > renamed to what is being patched.
> >
> > Signed-off-by: Dmitry Goldin
> > ---
> > kernel/gen_kheaders.sh | 5 -
> >
On Thu, Oct 03, 2019 at 06:33:15AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 03, 2019 at 09:08:50AM -0400, Steven Rostedt wrote:
> > On Thu, 03 Oct 2019 09:39:17 +0100
> > David Howells wrote:
> >
> > > paul...@kernel.org wrote:
> > >
> > > > +#define rcu_replace(rcu_ptr, ptr, c)
On Thu, Oct 03, 2019 at 12:44:09AM +0200, Viktor Rosendahl wrote:
> On 10/2/19 2:52 AM, Joel Fernandes wrote:
> > On Fri, Sep 20, 2019 at 05:22:19PM +0200, Viktor Rosendahl (BMW) wrote:
> > > This new trace option "console-latency" will enable the latency
> &
On Thu, Oct 03, 2019 at 01:57:27PM +0200, Andrea Parri wrote:
> On Wed, Oct 02, 2019 at 11:28:37AM -0400, Joel Fernandes (Google) wrote:
> > Quite interested in the LKMM, I have submitted patches before and used
> > it a lot. I would like to be a part of the maintainers f
Quite interested in the LKMM, I have submitted patches before and used
it a lot. I would like to be a part of the maintainers for this project.
Cc: Paul McKenney
Suggested-by: Alan Stern
Signed-off-by: Joel Fernandes (Google)
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git
On Wed, Oct 02, 2019 at 10:13:43AM -0400, Alan Stern wrote:
> On Tue, 1 Oct 2019, Joel Fernandes wrote:
>
> > On Tue, Oct 01, 2019 at 01:39:47PM -0400, Alan Stern wrote:
> > > This patch fixes a few minor typos and improves word usage in a few
> > > places in t
On Fri, Sep 20, 2019 at 05:22:19PM +0200, Viktor Rosendahl (BMW) wrote:
> This new trace option "console-latency" will enable the latency
> tracers to trace the console latencies. Previously this has always been
> implicitely disabled. I guess this is because they are considered
> to be well known
tween which latency in a burst was captured by the tracer.
>
> In addition, there is a sysfs trigger, so that it's not necessary to
> reload the module to repeat the test. The trigger will appear as
> /sys/kernel/preemptirq_delay_test/trigger in sysfs.
>
> Signed-off-by: Viktor Rosen
f CONFIG_FSNOTIFY
> + struct dentry *d_max_latency;
> + struct work_struct fsnotify_work;
> + struct irq_work fsnotify_irqwork;
> +#endif
> #endif
> struct trace_pid_list __rcu *filtered_pids;
> /*
> @@ -785,6 +792,17 @@ void update_max_tr_single(struct trace_array *tr,
> struct task_struct *tsk, int cpu);
> #endif /* CONFIG_TRACER_MAX_TRACE */
>
> +#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
> + defined(CONFIG_FSNOTIFY)
> +
> +void latency_fsnotify(struct trace_array *tr);
> +
> +#else
> +
> +#define latency_fsnotify(tr) do { } while (0)
Please define the NOOP as a function so that compiler checks the arguments.
So:
static void latency_fsnotify(struct trace_array *tr) { }
Other than these nits, the patch looks fine to me.
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote:
> Hi all,
>
> We would like to share a new data-race detector for the Linux kernel:
> Kernel Concurrency Sanitizer (KCSAN) --
> https://github.com/google/ktsan/wiki/KCSAN (Details:
>
On Tue, Oct 01, 2019 at 01:39:47PM -0400, Alan Stern wrote:
> This patch fixes a few minor typos and improves word usage in a few
> places in the Linux Kernel Memory Model's explanation.txt file.
>
> Signed-off-by: Alan Stern
>
Reviewed-by: Joel Fernandes (Google)
t
- rcu_read_lock();
> > p = rcu_dereference(cpu_rq(cpu)->curr);
> > if (p && p->mm == mm)
> > __cpumask_set_cpu(cpu, tmpmask);
>
>
> Yep. Looks like that solves it!
> Tested-by: John Stultz
Makes sense.
And here
plete type
struct trace_entry ent;\
Link: http://lore.kernel.org/r/20190903200905.198642-1-j...@joelfernandes.org
Acked-by: Michal Hocko
Co-developed-by: Tim Murray
Signed-off-by: Tim Murray
Signed-off-by: Joel Fernandes (Google)
---
v2->v3: Removed optimization for rate limitting and we c
binder_alloc_buffer_lookup() doesn't exist and is named
"binder_alloc_prepare_to_free()". Correct the code comments to reflect
this.
Signed-off-by: Joel Fernandes (Google)
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
On Wed, Sep 18, 2019 at 11:58:11AM +0200, Uladzislau Rezki wrote:
> > Recently a discussion about stability and performance of a system
> > involving a high rate of kfree_rcu() calls surfaced on the list [1]
> > which led to another discussion how to prepare for this situation.
> >
> > This patch
On Thu, Sep 12, 2019 at 05:38:43PM -0400, Joel Fernandes wrote:
> Hi Scott,
>
> Would you mind CC'ing r...@vger.kernel.org on RCU related patches? I added it
> for this time.
>
> On Wed, Sep 11, 2019 at 05:57:28PM +0100, Scott Wood wrote:
> > Besides restoring behavior
501 - 600 of 4053 matches
Mail list logo
