On Tue, May 1, 2018 at 1:00 PM, Steven Rostedt wrote:
> On Tue, 1 May 2018 21:48:38 +0200
> Peter Zijlstra wrote:
>
>> On Tue, May 01, 2018 at 03:38:40PM -0400, Steven Rostedt wrote:
>> > On Tue, 1 May 2018 21:19:51 +0200
>> > Peter Zijlstra wrote:
>>
>> > > Now, lockdep only minimally tracks th
McKenney
Cc: Frederic Weisbecker
Cc: Randy Dunlap
Cc: Masami Hiramatsu
Cc: Fenguang Wu
Cc: Baohong Liu
Cc: Vedang Patel
Cc: kernel-t...@android.com
Cc: sta...@vger.kernel.org
Reviewed-by: Steven Rostedt (VMware)
Fixes: d59158162e032 ("tracing: Add support for preempt and irq enable/disab
On Wed, May 2, 2018 at 9:45 PM 'Alistair Strachan' via kernel-team <
kernel-t...@android.com> wrote:
> Map the region shm as write-combining instead of uncachable.
I think more commit message is needed. Why is this done, what does it fix,
etc. Its hard to know what the improvement is without a c
On Mon, May 28, 2018 at 09:17:51AM +0200, Peter Zijlstra wrote:
> On Sun, May 27, 2018 at 10:19:36PM -0700, Joel Fernandes wrote:
>
> > > +static inline void __rt_mutex_lock(struct rt_mutex *lock, unsigned int
> > > subclass)
> > > +{
> > > + might_sl
On Mon, May 28, 2018 at 09:15:08AM +0200, Peter Zijlstra wrote:
> On Sun, May 27, 2018 at 06:24:47PM -0700, Joel Fernandes (Google) wrote:
> > This patch removes the obscure comment which was
> > saying this path can be entered only for wake-balance.
>
> The comment was me
On Mon, May 28, 2018 at 12:12:34PM +0200, Juri Lelli wrote:
[..]
> > +
> > + util = max_t(unsigned long, util, READ_ONCE(rq->avg_dl.util_avg));
> > +
> > + return util;
>
> Anyway, just a quick thought. I guess we should experiment with this a
> bit. Now, I don't unfortunately have a Arm plat
From: "Joel Fernandes (Google)"
In this patch we introduce a test module for simulating a long atomic
section in the kernel which the preemptoff or irqsoff tracers can
detect. This module is to be used only for test purposes and is default
disabled.
Following is the expected ou
From: "Joel Fernandes (Google)"
In the last patch in this series, we are making lockdep register hooks
onto the irq_{disable,enable} tracepoints. These tracepoints use the
_rcuidle tracepoint variant. In this series we switch the _rcuidle
tracepoint callers to use SRCU instead of
From: "Joel Fernandes (Google)"
This patch detaches the preemptirq tracepoints from the tracers and
keeps it separate.
Advantages:
* Lockdep and irqsoff event can now run in parallel since they no longer
have their own calls.
* This unifies the usecase of adding hooks to an irqsoff
stent with rcu-sched.
[Joel: Added commit message]
Reviewed-by: Steven Rostedt (VMware)
Signed-off-by: Paul McKenney
Signed-off-by: Joel Fernandes (Google)
---
include/linux/srcu.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
From: "Joel Fernandes (Google)"
Here we add unit tests for the preemptoff and irqsoff tracer by using a
kernel module introduced previously to trigger atomic sections in the
kernel.
Signed-off-by: Joel Fernandes (Google)
---
tools/testing/selftests/ftrace/config | 3 +
From: "Joel Fernandes (Google)"
The preempt/irq tracepoints exist but not everything in the kernel is
using it during preempt/irq on/off events. This makes things not work
simultaneously (for ex, only either lockdep or irqsoff events can be
used at a time). This series is an attemp
From: "Joel Fernandes (Google)"
In recent tests with IRQ on/off tracepoints, a large performance
overhead ~10% is noticed when running hackbench. This is root caused to
calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the
tracepoint code. Following a long discussion on t
From: "Joel Fernandes (Google)"
Split reset functions into seperate functions in preparation
of future patches that need to do tracer specific reset.
Signed-off-by: Joel Fernandes (Google)
---
kernel/trace/trace_irqsoff.c | 22 +++---
1 file changed, 19 insert
From: "Joel Fernandes (Google)"
I'm able to reproduce a lockdep splat with config options:
CONFIG_PROVE_LOCKING=y,
CONFIG_DEBUG_LOCK_ALLOC=y and
CONFIG_PREEMPTIRQ_EVENTS=y
$ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable
[ 26.112609] DEBUG_LOCKS_WARN_ON(current
additional corresponding benefit is that, at run-time, we pay the
> cost for a additional sum and multiply, while the more expensive
> division is required only at dequeue time.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Vincent Guittot
>
On Tue, Jun 05, 2018 at 04:21:56PM +0100, Patrick Bellasi wrote:
[..]
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index f74441be3f44..5d54d6a4c31f 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -3161,6 +3161,8 @@ accumulate_sum(u64 delta, int
On Tue, Jun 05, 2018 at 12:33:17PM -0700, Joel Fernandes wrote:
> On Tue, Jun 05, 2018 at 04:21:56PM +0100, Patrick Bellasi wrote:
[..]
> > To be more precise, at each ___update_load_avg we should really update
> > running_avg by:
> >
> >u32 divider = LOAD_AVG_MAX
On Tue, Jun 05, 2018 at 05:54:31PM +0100, Patrick Bellasi wrote:
> On 05-Jun 17:31, Juri Lelli wrote:
> > On 05/06/18 16:11, Patrick Bellasi wrote:
> >
> > [...]
> >
> > > If I run an experiment with your example above, while using the
> > > performance governor to rule out any possible scale inv
Hi,
On Tue, May 29, 2018 at 05:04:59PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> In this patch we introduce a test module for simulating a long atomic
> section in the kernel which the preemptoff or irqsoff tracers can
> detect. This module is
(Resending since Andy wasn't on CC - sorry)
Hi,
On Tue, May 29, 2018 at 05:04:59PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> In this patch we introduce a test module for simulating a long atomic
> section in the kernel which the preemp
On Mon, May 14, 2018 at 10:22:05AM -0700, Paul E. McKenney wrote:
> On Mon, May 14, 2018 at 10:54:54AM -0400, Steven Rostedt wrote:
> > On Sun, 13 May 2018 20:15:35 -0700
> > "Joel Fernandes (Google)" wrote:
> >
> > > Recently we had a discu
On Mon, May 14, 2018 at 10:57:39AM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 08:15:37PM -0700, Joel Fernandes (Google) wrote:
> > The 'c' variable was used previously to store the grace period
> > that is being requested. However it is not very meaningful fo
On Mon, May 14, 2018 at 11:00:27AM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 08:15:38PM -0700, Joel Fernandes (Google) wrote:
> > The funnel locking loop in rcu_start_this_gp uses rcu_root as a
> > temporary variable while walking the combining tree. This causes
On Mon, May 14, 2018 at 11:12:27AM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 08:15:36PM -0700, Joel Fernandes (Google) wrote:
> > Commit be4b8beed87d ("rcu: Move RCU's grace-period-change code to ->gp_seq")
> > removed the cpuend grace period tra
On Mon, May 14, 2018 at 11:38:23AM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 08:15:39PM -0700, Joel Fernandes (Google) wrote:
> > In recent discussion [1], the check for whether a leaf believes RCU is
> > not idle, is being added back to funnel locking code
On Mon, May 14, 2018 at 12:20:28PM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 08:15:40PM -0700, Joel Fernandes (Google) wrote:
> > Currently the tree RCU clean up code records a CleanupMore trace event
> > even if the GP was already in progress. This makes Clea
On Mon, May 14, 2018 at 01:33:20PM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 08:15:41PM -0700, Joel Fernandes (Google) wrote:
> > cpustart shows a stale gp_seq. This is because rdp->gp_seq is updated
> > only at the end of the __note_gp_changes function. For this r
On Mon, May 14, 2018 at 10:38:16AM -0700, Paul E. McKenney wrote:
> On Sun, May 13, 2018 at 08:15:34PM -0700, Joel Fernandes (Google) wrote:
> > rcu_seq_snap may be tricky for someone looking at it for the first time.
> > Lets document how it works with an example to
Hi Paul,
Good morning, hope you're having a great Tuesday. I managed to find some
evening hours today to dig into this a bit more.
On Mon, May 14, 2018 at 08:59:52PM -0700, Paul E. McKenney wrote:
> On Mon, May 14, 2018 at 06:51:33PM -0700, Joel Fernandes wrote:
> > On Mon, May 14,
On Tue, May 15, 2018 at 03:53:00PM +0200, Frederic Weisbecker wrote:
> On Mon, May 07, 2018 at 12:46:06AM +0000, Joel Fernandes wrote:
> > On Sun, May 6, 2018 at 12:22 PM Frederic Weisbecker
> > wrote:
> >
> > > arch_validate_hwbkpt_settings() mixes up attribute
On Tue, May 15, 2018 at 05:55:07AM -0700, Paul E. McKenney wrote:
> On Tue, May 15, 2018 at 12:02:43AM -0700, Joel Fernandes wrote:
> > Hi Paul,
> > Good morning, hope you're having a great Tuesday. I managed to find some
> > evening hours today to dig into this a bit mor
On Tue, May 15, 2018 at 12:08:01PM -0700, Paul E. McKenney wrote:
> On Tue, May 15, 2018 at 11:41:15AM -0700, Joel Fernandes wrote:
> > On Tue, May 15, 2018 at 05:55:07AM -0700, Paul E. McKenney wrote:
> > > On Tue, May 15, 2018 at 12:02:43AM -0700, Joel Fernandes wrot
On Mon, May 14, 2018 at 08:46:03PM -0700, Paul E. McKenney wrote:
> On Mon, May 14, 2018 at 05:57:09PM -0700, Joel Fernandes wrote:
> > On Mon, May 14, 2018 at 11:38:23AM -0700, Paul E. McKenney wrote:
> > > On Sun, May 13, 2018 at 08:15:39PM -0700, Joel Fernandes (Google) wrote:
This patch submission got completely screwed up, sorry, please ignore. I'll
repost soon. There's something messed up with my SMTP server too.
On Tue, May 15, 2018 at 03:45:54PM -0700, Joel Fernandes (Google) wrote:
> I'm able to reproduce a lockdep splat w
4226493206-2884214369&rd=1
And its intermittent too.. I am going to spend a bit of time to figure out
why it happened so it doesn't happen again. Sorry about the noise.
Sigh,
- Joel
On Tue, May 15, 2018 at 3:47 PM Joel Fernandes (Google) <
j...@joelfernandes.org> wrote:
> From: Paul
On Wed, May 16, 2018 at 08:48:29AM -0700, Paul E. McKenney wrote:
> On Tue, May 15, 2018 at 04:04:30PM -0700, Joel Fernandes wrote:
> > On Mon, May 14, 2018 at 08:46:03PM -0700, Paul E. McKenney wrote:
> > > On Mon, May 14, 2018 at 05:57:09PM -0700, Joel Fernandes wrote:
>
bottom of the tree, thus
> > > reducing lock contention and even eliminating it in some cases. But
> > > why
> > > not further reduce contention, especially on large systems, by doing
> > > both,
> > > especially given that the cost
Hi Paul,
On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
wrote:
> On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
>> On Tue, Apr 24, 2018 at 10:26:58AM -0700, Paul E. McKenney wrote:
>> > On Tue, Apr 24, 2018 at 09:01:34AM -0700, Joel Fernandes wrote:
>
On Tue, Apr 24, 2018 at 11:59 AM, Joel Fernandes wrote:
[...]
>>> > > By the way is there any limitation on using SRCU too early during
>>> > > boot? I backported Mathieu's srcu tracepoint patches but the kernel
>>> > > hangs pret
On Tue, Apr 24, 2018 at 12:09 PM, Paul E. McKenney
wrote:
> On Tue, Apr 24, 2018 at 11:59:32AM -0700, Joel Fernandes wrote:
>> Hi Paul,
>>
>> On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
>> wrote:
>> > On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E.
On 04/24/2018 04:21 PM, Mathieu Desnoyers wrote:
- On Apr 24, 2018, at 2:59 PM, Joel Fernandes joe...@google.com wrote:
On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
wrote:
On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
On Tue, Apr 24, 2018 at 10:26:58AM -0700
On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney
wrote:
[..]
>> >
>> > Sounds good, thanks.
>> >
>> > Also I found the reason for my boot issue. It was because the
>> > init_srcu_struct in the prototype was being done in an initcall.
>> > Instead if I do it in start_kernel before the tracepoint i
Hi Mathieu,
On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers
wrote:
> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote:
>
>> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney
>> wrote:
>> [..]
>>>> >
>>>> > Soun
On Sun, Apr 22, 2018 at 8:19 PM, Paul E. McKenney
wrote:
> On Sun, Apr 22, 2018 at 06:14:18PM -0700, Joel Fernandes wrote:
[...]
>> I narrowed the performance hit down to the call to
>> rcu_irq_enter_irqson() and rcu_irq_exit_irqson() in __DO_TRACE.
>> Commenting these 2 func
On Thu, Feb 28, 2019 at 11:17:51AM +0900, Masahiro Yamada wrote:
> Hi Joel,
>
>
> On Thu, Feb 28, 2019 at 4:40 AM Joel Fernandes (Google)
> wrote:
> >
> > Introduce in-kernel headers and other artifacts which are made available
> > as an archive through proc (
On Thu, Feb 28, 2019 at 01:53:43PM +, Qais Yousef wrote:
> Hi Joel
>
> On 02/27/19 14:37, Joel Fernandes (Google) wrote:
> > Introduce in-kernel headers and other artifacts which are made available
> > as an archive through proc (/proc/kheaders.tar.xz file). This archive
On Thu, Feb 28, 2019 at 05:34:44PM +0900, Masami Hiramatsu wrote:
> Hi Joel,
>
> On Wed, 27 Feb 2019 14:37:47 -0500
> "Joel Fernandes (Google)" wrote:
>
> > Introduce in-kernel headers and other artifacts which are made available
> > as an archive through pr
On Thu, Feb 28, 2019 at 09:29:13PM +0900, Masami Hiramatsu wrote:
> On Tue, 26 Feb 2019 10:24:47 -0500
> Joel Fernandes wrote:
>
> > On Fri, Feb 22, 2019 at 11:27:05AM -0800, Alexei Starovoitov wrote:
> > > On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
On Thu, Feb 28, 2019 at 04:30:26PM +0100, Greg KH wrote:
> On Thu, Feb 28, 2019 at 10:00:54AM -0500, Joel Fernandes wrote:
> > > Hmm, isn't it easier to add kernel-headers package on Android?
> >
> > I have already been down that road. In the Android ecosystem, the A
On Thu, Feb 28, 2019 at 7:45 AM Greg KH wrote:
>
> On Thu, Feb 28, 2019 at 10:37:41AM -0500, Joel Fernandes wrote:
> > In any case, it is not practical to provide headers for every kernel
> > version on
> > the system image and maintain them, it will take up too much spac
On Thu, Feb 28, 2019 at 05:04:59PM +0100, Dietmar Eggemann wrote:
[...] ^
> kernel/kheaders_data.h:1:1: note: in expansion of macro ‘KH_MAGIC_END’
> KH_MAGIC_END;
> ^~~~
> kernel/kheaders.c: In function ‘ikheaders_read_current’:
> kernel/kheaders.c:38:12: error: ‘kern
On Thu, Feb 28, 2019 at 12:06 AM Vlastimil Babka wrote:
>
> On 2/27/19 10:32 PM, Oscar Salvador wrote:
> > On Tue, Feb 26, 2019 at 02:04:28PM -0800, Andrew Morton wrote:
> >> How is this going to affect existing userspace which is aware of the
> >> current behaviour?
> >
> > Well, current behavior
On Thu, Feb 28, 2019 at 09:43:06AM -0500, Joel Fernandes wrote:
> On Thu, Feb 28, 2019 at 11:17:51AM +0900, Masahiro Yamada wrote:
> > Hi Joel,
> >
> >
> > On Thu, Feb 28, 2019 at 4:40 AM Joel Fernandes (Google)
> > wrote:
> > >
> > > Introd
On Fri, Mar 01, 2019 at 11:28:26AM +0900, Masami Hiramatsu wrote:
> Hi Joel,
Hi Masami,
> On Thu, 28 Feb 2019 10:00:54 -0500
> Joel Fernandes wrote:
>
> > > Hmm, isn't it easier to add kernel-headers package on Android?
> >
> > I have already been down th
On Fri, Mar 01, 2019 at 03:25:05PM +0900, Masahiro Yamada wrote:
[...]
> > > I am guessing the user will run these commands
> > > on the target system.
> > > In other words, external modules are native-compiled.
> > > So,
> > >
> > > target-arch: arm64
> > > host-arch: arm64
> > >
> > >
> > >
On Fri, Mar 01, 2019 at 04:03:09PM +0900, Masami Hiramatsu wrote:
> Hi Joel,
>
> On Thu, 28 Feb 2019 22:26:11 -0500
> Joel Fernandes wrote:
>
> > On Fri, Mar 01, 2019 at 11:28:26AM +0900, Masami Hiramatsu wrote:
[..]
> > There are many usecases for this, I have often
On Sat, Mar 02, 2019 at 11:13:07AM +0900, Masahiro Yamada wrote:
> On Sat, Mar 2, 2019 at 3:03 AM Joel Fernandes wrote:
> >
> > On Fri, Mar 01, 2019 at 03:25:05PM +0900, Masahiro Yamada wrote:
> > [...]
> > > > > I am guessing the user will run these com
On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote:
> On 04/11, Joel Fernandes (Google) wrote:
> >
> > +static unsigned int proc_tgid_base_poll(struct file *file, struct
> > poll_table_struct *pts)
> > +{
> > + int poll_flags = 0;
> > + struc
On Tue, Apr 16, 2019 at 03:20:51PM -0400, Joel Fernandes wrote:
> On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote:
> > On 04/11, Joel Fernandes (Google) wrote:
> > >
> > > +static unsigned int proc_tgid_base_poll(struct file *file, struct
&
On Mon, Mar 11, 2019 at 03:29:03PM -0700, Paul E. McKenney wrote:
> On Mon, Mar 11, 2019 at 09:39:39AM -0400, Joel Fernandes wrote:
> > On Wed, Aug 29, 2018 at 03:20:34PM -0700, Paul E. McKenney wrote:
> > > RCU's dyntick-idle code is written to tolerate half-interrupts, t
On Tue, Mar 12, 2019 at 08:20:34AM -0700, Paul E. McKenney wrote:
[snip]
>
> >Could we be more explicit in the code that this function can only
> > be called from an interrupt, and also we change the code comment to be more
> > clear about it (like the following diff)?
>
> That would
On Wed, Mar 13, 2019 at 11:07:30AM -0700, Paul E. McKenney wrote:
> On Wed, Mar 13, 2019 at 12:51:25PM -0400, Steven Rostedt wrote:
> > On Wed, 13 Mar 2019 08:51:55 -0700
> > "Paul E. McKenney" wrote:
> >
> > > Does this mean that there is a better approach that Joel's suggestion?
> > > I believe
Hi Tim,
Thanks for the detailed and excellent write-up. It will serve as a
good future reference for low memory killer requirements. I made some
comments below on the "how to kill" part.
On Tue, Mar 12, 2019 at 10:17 AM Tim Murray wrote:
>
> On Tue, Mar 12, 2019 at 9:37 AM Sultan Alsawaf wrote:
On Thu, Mar 14, 2019 at 09:37:46AM -0400, Steven Rostedt wrote:
> On Thu, 14 Mar 2019 09:36:57 -0400
> Steven Rostedt wrote:
>
> > On Thu, 14 Mar 2019 08:31:59 -0400
> > Joel Fernandes wrote:
> >
> > > Oh thanks for pointing that out. Yes it does work for me
On Thu, Mar 14, 2019 at 01:49:11PM -0700, Sultan Alsawaf wrote:
> On Thu, Mar 14, 2019 at 10:47:17AM -0700, Joel Fernandes wrote:
> > About the 100ms latency, I wonder whether it is that high because of
> > the way Android's lmkd is observing that a process has died. There
On Thu, Mar 14, 2019 at 09:36:43PM -0700, Daniel Colascione wrote:
[snip]
> > If you can solve this with an ebpf program, I
> > strongly suggest you do that instead.
>
> Regarding process death notification: I will absolutely not support
> putting aBPF and perf trace events on the critical path o
On Fri, Mar 15, 2019 at 04:44:52PM +0900, Byungchul Park wrote:
> On 03/15/2019 04:31 PM, Byungchul Park wrote:
> > On Mon, Mar 11, 2019 at 09:39:39AM -0400, Joel Fernandes wrote:
> > > On Wed, Aug 29, 2018 at 03:20:34PM -0700, Paul E. McKenney wrote:
> > > > RCU
sleeping.
>
> The result is a potential performance gain during freeze, since less
> tasks have to be awaken.
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
>
> Signed-off-by: Hugo Lefeuvre
> ---
> include/linux/wait.h | 6 +++---
> 1 file changed, 3 insertions(+),
off-by: Hugo Lefeuvre
> ---
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> include/linux/wait.h | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index 5f3efabc36f4..c4
On Fri, Jan 25, 2019 at 11:00:25AM -0800, h...@zytor.com wrote:
> On January 24, 2019 12:59:29 PM PST, Joel Fernandes
> wrote:
> >On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote:
> >>
> >> On 1/23/19 11:37 PM, Daniel Colascione wrote:
> >[.
On Fri, Jan 25, 2019 at 12:34:52PM -0800, Daniel Colascione wrote:
> On Fri, Jan 25, 2019 at 12:28 PM wrote:
> >
> > On January 25, 2019 11:15:52 AM PST, Daniel Colascione
> > wrote:
> > >On Fri, Jan 25, 2019 at 11:01 AM wrote:
> > >>
> > >&g
On Sat, Jan 26, 2019 at 01:02:06AM +0900, Tetsuo Handa wrote:
> On 2019/01/24 22:46, Joel Fernandes wrote:
> > On Thu, Jan 24, 2019 at 10:52:30AM +0900, Tetsuo Handa wrote:
> >> Joel Fernandes wrote:
> >>>> Anyway, I need your checks regarding whether this approach
On Mon, Mar 25, 2019 at 07:18:42PM +0100, Jann Horn wrote:
> On Mon, Mar 25, 2019 at 5:21 PM Christian Brauner
> wrote:
> > The pidctl() syscalls builds on, extends, and improves translate_pid() [4].
> > I quote Konstantins original patchset first that has already been acked and
> > picked up by
On Tue, Mar 26, 2019 at 04:55:11PM +0100, Christian Brauner wrote:
> The pidctl() syscalls builds on, extends, and improves translate_pid() [4].
> I quote Konstantins original patchset first that has already been acked and
> picked up by Eric before and whose functionality is preserved in this
> sy
On Tue, Mar 26, 2019 at 06:08:28PM +0100, Christian Brauner wrote:
[snip]
> > > + struct pid *struct_pid;
> > > + pid_t result;
> > > +
> > > + if (flags)
> > > + return -EINVAL;
> > > +
> > > + switch (cmd) {
> > > + case PIDCMD_QUERY_PID:
> > > + break;
> > > + case PIDCMD_QUERY_P
On Tue, Mar 26, 2019 at 1:17 PM Christian Brauner wrote:
>
> On Tue, Mar 26, 2019 at 01:15:25PM -0400, Joel Fernandes wrote:
> > On Tue, Mar 26, 2019 at 06:08:28PM +0100, Christian Brauner wrote:
> > [snip]
> > > >
> > > >
On Tue, Mar 26, 2019 at 06:22:33PM +0100, Christian Brauner wrote:
> On Tue, Mar 26, 2019 at 01:06:01PM -0400, Joel Fernandes wrote:
> > On Tue, Mar 26, 2019 at 04:55:11PM +0100, Christian Brauner wrote:
> > > The pidctl() syscalls builds on, extends, and improves transla
On Tue, Mar 26, 2019 at 09:01:40AM -0700, Paul E. McKenney wrote:
> On Mon, Mar 25, 2019 at 06:40:17PM -0400, Joel Fernandes wrote:
> > On Mon, Mar 25, 2019 at 12:42 PM Paul E. McKenney
> > wrote:
> > >
> > > On Mon, Mar 25, 2019 at 12:33:37PM -0400, Joel Fernan
On Tue, Mar 26, 2019 at 02:35:49PM -0400, Joel Fernandes wrote:
> On Tue, Mar 26, 2019 at 09:01:40AM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 25, 2019 at 06:40:17PM -0400, Joel Fernandes wrote:
> > > On Mon, Mar 25, 2019 at 12:42 PM Paul E. McKenney
> > > wrote:
On Tue, Mar 26, 2019 at 07:19:30PM +0100, Christian Brauner wrote:
[snip]
> > > > I am actually supportive of Daniel's view that by combining too many
> > > > arguments into a single syscall, becomes confusing and sometimes some
> > > > arguments have to be forced to 0 in the single shoe-horned sys
On Tue, Mar 26, 2019 at 08:19:43PM +0100, Christian Brauner wrote:
> On Tue, Mar 26, 2019 at 02:10:12PM -0400, Joel Fernandes wrote:
> > On Tue, Mar 26, 2019 at 06:22:33PM +0100, Christian Brauner wrote:
> > > On Tue, Mar 26, 2019 at 01:06:01PM -0400, Joel Fernandes wrote:
>
On Tue, Mar 26, 2019 at 01:46:13PM -0700, Paul E. McKenney wrote:
[snip]
> > Any way, I will just add back CPU0 forcefully to the cpus list in my
> > testing,
> > without checking for the online file existence, and see what happens :-) If
> > there's no smoke, then I'll roll that into a patch and
On Tue, Mar 26, 2019 at 07:47:51PM -0700, Paul E. McKenney wrote:
> On Tue, Mar 26, 2019 at 03:24:09PM -0400, Joel Fernandes (Google) wrote:
> > In the future we would like to combine the dynticks and dynticks_nesting
> > counters thus leading to simplifying the code. At the m
On Wed, Mar 27, 2019 at 08:53:51AM -0700, Paul E. McKenney wrote:
> On Wed, Mar 27, 2019 at 11:34:01AM -0400, Joel Fernandes wrote:
> > On Tue, Mar 26, 2019 at 07:47:51PM -0700, Paul E. McKenney wrote:
> > > On Tue, Mar 26, 2019 at 03:24:09PM -0400, Joel Fernandes (Google) wro
On Wed, Mar 27, 2019 at 11:44:37AM -0700, Paul E. McKenney wrote:
> On Wed, Mar 27, 2019 at 01:45:45PM -0400, Joel Fernandes wrote:
> > On Wed, Mar 27, 2019 at 08:53:51AM -0700, Paul E. McKenney wrote:
> > > On Wed, Mar 27, 2019 at 11:34:01AM -0400, Joel Fernandes wrote:
>
On Thu, Mar 28, 2019 at 01:59:45AM +0100, Jann Horn wrote:
> On Thu, Mar 28, 2019 at 1:06 AM Kees Cook wrote:
> > On Wed, Mar 27, 2019 at 7:53 AM Joel Fernandes (Google)
> > wrote:
> > >
> > > struct pid's count is an atomic_t field used as a refcount
Thanks a lot Alan and Paul for the replies. I replied inline.
On Sun, Mar 31, 2019 at 02:55:31PM -0700, Paul E. McKenney wrote:
> On Fri, Mar 29, 2019 at 10:36:39PM -0400, Joel Fernandes wrote:
> > On Thu, Mar 28, 2019 at 10:37:07AM -0700, Paul E. McKenney wrote:
> > > On Thu,
On Wed, Apr 03, 2019 at 10:46:01AM -0700, Daniel Colascione wrote:
> On Wed, Apr 3, 2019 at 10:20 AM Joel Fernandes wrote:
> >
> > On Wed, Apr 03, 2019 at 04:48:37PM +0900, Masahiro Yamada wrote:
> > > On Thu, Mar 28, 2019 at 2:32 AM Joel Fernandes
> > > wrot
On Mon, Apr 08, 2019 at 01:25:49PM -0400, Mathieu Desnoyers wrote:
> - On Apr 8, 2019, at 1:10 PM, paulmck paul...@linux.ibm.com wrote:
>
> > On Mon, Apr 08, 2019 at 01:06:56PM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 8, 2019, at 11:21 AM, paulmck paul...@linux.ibm.com wrote:
> >>
>
On Mon, Apr 08, 2019 at 03:47:04PM -0400, Mathieu Desnoyers wrote:
> - On Apr 8, 2019, at 3:35 PM, Joel Fernandes, Google
> j...@joelfernandes.org wrote:
>
> > On Mon, Apr 08, 2019 at 01:25:49PM -0400, Mathieu Desnoyers wrote:
> >> - On Apr 8, 2019,
On Tue, Apr 09, 2019 at 09:14:18PM -0400, Joel Fernandes (Google) wrote:
> Since commit title ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
> modules"), modules that call DEFINE_{STATIC,}SRCU will have a new array
> of srcu_struct pointers which is used by srcu code to ini
On Tue, Apr 09, 2019 at 10:38:20PM -0400, Steven Rostedt wrote:
> On Tue, 9 Apr 2019 21:14:18 -0400
> "Joel Fernandes (Google)" wrote:
>
> > /*
> > - * Mark ro_after_init section with SHF_RO_AFTER_INIT so that
> > + * These are section names marked wi
On Tue, Apr 9, 2019 at 10:48 PM Steven Rostedt wrote:
>
> On Tue, 9 Apr 2019 22:41:03 -0400
> Joel Fernandes wrote:
>
> > > Other than that, the two patches look fine to me.
> >
> > Could I add your Reviewed-by in the respin?
>
> You can add an Acked-by, as
On Wed, Apr 10, 2019 at 09:26:44AM -0700, Kees Cook wrote:
> On Tue, Apr 9, 2019 at 6:14 PM Joel Fernandes (Google)
> wrote:
> >
> > For the purposes of hardening modules by adding sections to
> > ro_after_init sections, prepare for addition of new ro_after_init
> >
On Wed, Apr 10, 2019 at 03:08:21PM -0400, Joel Fernandes (Google) wrote:
> For the purposes of hardening modules by adding sections to
> ro_after_init sections, prepare for addition of new ro_after_init
> entries which we do in future patches. Create a table to which new
> entries co
On Wed, Apr 10, 2019 at 04:11:12PM -0400, Steven Rostedt wrote:
> On Wed, 10 Apr 2019 15:57:08 -0400
> "Joel Fernandes (Google)" wrote:
>
> > This series hardens the tracepoints in modules by making the array of
> > pointers referring to the tracepoints as
On Wed, Apr 10, 2019 at 08:44:01PM -0400, Steven Rostedt wrote:
> On Wed, 10 Apr 2019 16:29:02 -0400
> Joel Fernandes wrote:
>
> > The srcu structure pointer array is modified at module load time because the
> > array is fixed up by the module loader at load-time with the f
On Fri, Feb 22, 2019 at 11:27:05AM -0800, Alexei Starovoitov wrote:
> On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
> >
> > Then we should still probably fix up "__probe_kernel_read()" to not
> > allow user accesses. The easiest way to do that is actually likely to
> > use the "u
On Mon, Feb 25, 2019 at 11:04:42PM +0900, Masami Hiramatsu wrote:
> Hi,
>
> Here is an RFC series of probe-event to support user-space access
> methods, which we discussed in previous thread.
>
> https://lkml.kernel.org/r/20190220171019.5e81a4946b56982f324f7...@kernel.org
>
> So in this thread,
601 - 700 of 2649 matches
Mail list logo
