Re: [PATCH 2/8] pstore: Do not use crash buffer for decompression

2018-11-29 Thread Joel Fernandes
On Thu, Nov 29, 2018 at 02:06:39PM -0800, Kees Cook wrote: > On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote: > > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes > > wrote: > > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote: > > >> + works

Re: [RFC][PATCH 11/14] function_graph: Convert ret_stack to a series of longs

2018-11-27 Thread Joel Fernandes
On Mon, Nov 26, 2018 at 11:26:03AM -0500, Steven Rostedt wrote: > On Tue, 27 Nov 2018 01:07:55 +0900 > Masami Hiramatsu wrote: > > > > > --- a/include/linux/sched.h > > > > +++ b/include/linux/sched.h > > > > @@ -1119,7 +1119,7 @@ struct task_struct { > > > > int

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-26 Thread Joel Fernandes
On Sat, Nov 24, 2018 at 04:47:36PM -0800, Matthew Wilcox wrote: > On Sat, Nov 24, 2018 at 04:42:29PM -0800, Andrew Morton wrote: > > This changelog doesn't have the nifty test case code which was in > > earlier versions? > > Why do we put regression tests in the changelogs anyway? We have >

Re: [RFC][PATCH 11/14] function_graph: Convert ret_stack to a series of longs

2018-11-23 Thread Joel Fernandes
bit wasteful especially if there was only one or 2 function graph callbacks registered and most of the callback array in the stack isn't used. Could we make the array size configurable at compile time and start it with a small number like 4 or 6? Also for patches 1 through 10: Reviewed-by: Joel Fernandes (Google) thanks, - Joel

Re: [RFC][PATCH 06/14] fgraph: Move function graph specific code into fgraph.c

2018-11-23 Thread Joel Fernandes
On Fri, Nov 23, 2018 at 01:11:38PM -0500, Steven Rostedt wrote: > On Fri, 23 Nov 2018 12:58:34 -0500 > Steven Rostedt wrote: > > > I think the better answer is to move it into trace_functions_graph.c. > > I take that back. I think the better answer is to not call that > function if the profiler

Re: [RFC][PATCH 06/14] fgraph: Move function graph specific code into fgraph.c

2018-11-22 Thread Joel Fernandes
On Wed, Nov 21, 2018 at 08:27:14PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > To make the function graph infrastructure more managable, the code needs to > be in its own file (fgraph.c). Move the code that is specific for managing > the function graph infrastructure out

Re: [RFC][PATCH 09/14] function_graph: Move ftrace_graph_get_addr() to fgraph.c

2018-11-22 Thread Joel Fernandes
On Wed, Nov 21, 2018 at 08:27:17PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Move the function function_graph_get_addr() to fgraph.c, as the management > of the curr_ret_stack is going to change, and all the accesses to ret_stack > needs to be done in fgraph.c.

Re: [RFC][PATCH 07/14] fgraph: Add new fgraph_ops structure to enable function graph hooks

2018-11-22 Thread Joel Fernandes
On Wed, Nov 21, 2018 at 08:27:15PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Currently the registering of function graph is to pass in a entry and return > function. We need to have a way to associate those functions together where > the entry can determine to run the

Re: [PATCH -next 2/2] selftests/memfd: modify tests for F_SEAL_FUTURE_WRITE seal

2018-11-22 Thread Joel Fernandes
On Mon, Nov 19, 2018 at 09:21:37PM -0800, Joel Fernandes (Google) wrote: > Modify the tests for F_SEAL_FUTURE_WRITE based on the changes > introduced in previous patch. > > Also add a test to make sure the reopen issue pointed by Jann Horn [1] > is fixed. > > [1] > http

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-22 Thread Joel Fernandes
On Wed, Nov 21, 2018 at 07:25:26PM -0800, Andy Lutomirski wrote: > On Wed, Nov 21, 2018 at 6:27 PM Andrew Morton > wrote: > > > > On Tue, 20 Nov 2018 13:13:35 -0800 Joel Fernandes > > wrote: > > > > > > > I am Ok with whatever

Re: dyntick-idle CPU and node's qsmask

2018-11-20 Thread Joel Fernandes
On Tue, Nov 20, 2018 at 06:41:07PM -0800, Paul E. McKenney wrote: [...] > > > > I was thinking if we could simplify rcu_note_context_switch (the parts > > > > that > > > > call rcu_momentary_dyntick_idle), if we did the following in > > > > rcu_implicit_dynticks_qs. > > > > > > > > Since we

Re: dyntick-idle CPU and node's qsmask

2018-11-20 Thread Joel Fernandes
On Tue, Nov 20, 2018 at 02:28:14PM -0800, Paul E. McKenney wrote: > On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote: > > On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote: > > > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote: >

Re: [PATCH 2/8] pstore: Do not use crash buffer for decompression

2018-11-20 Thread Joel Fernandes
On Wed, Nov 14, 2018 at 01:56:09AM -0600, Kees Cook wrote: > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote: > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote: > >> static void decompress_record(struct pstore_record *record) > >> { > &g

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-20 Thread Joel Fernandes
On Tue, Nov 20, 2018 at 02:02:49PM -0700, Andy Lutomirski wrote: > > > On Nov 20, 2018, at 1:47 PM, Joel Fernandes wrote: > > > >> On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote: > >> > >>> On Nov 20, 2018, at 1:07 PM, Stephen

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-20 Thread Joel Fernandes
On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote: > > > On Nov 20, 2018, at 1:07 PM, Stephen Rothwell wrote: > > > > Hi Joel, > > > >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes > >> wrote: > >> > >>&g

Re: dyntick-idle CPU and node's qsmask

2018-11-20 Thread Joel Fernandes
On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote: > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote: > > On Sat, Nov 10, 2018 at 08:22:10PM -0800, Paul E. McKenney wrote: > > > On Sat, Nov 10, 2018 at 07:09:25PM -0800, Joel Fernandes wrote: >

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-20 Thread Joel Fernandes
On Tue, Nov 20, 2018 at 07:13:17AM -0800, Andy Lutomirski wrote: > On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google) > wrote: > > > > A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week > > where we don't need to modify core VFS structures to g

[PATCH -manpage 2/2] memfd_create.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal

2018-11-19 Thread Joel Fernandes (Google)
More details of the seal can be found in the LKML patch: https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t Signed-off-by: Joel Fernandes (Google) --- man2/memfd_create.2 | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/man2

[PATCH -manpage 1/2] fcntl.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal

2018-11-19 Thread Joel Fernandes (Google)
More details of the seal can be found in the LKML patch: https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t Signed-off-by: Joel Fernandes (Google) --- man2/fcntl.2 | 15 +++ 1 file changed, 15 insertions(+) diff --git a/man2/fcntl.2 b/man2/fcntl.2 index

[PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-19 Thread Joel Fernandes (Google)
://lore.kernel.org/lkml/69ce06cc-e47c-4992-848a-66eb23ee6...@amacapital.net/ Suggested-by: Andy Lutomirski Fixes: 5e653c2923fd ("mm: Add an F_SEAL_FUTURE_WRITE seal to memfd") Signed-off-by: Joel Fernandes (Google) --- fs/hugetlbfs/inode.c | 2 +- mm/memfd.c

[PATCH -next 2/2] selftests/memfd: modify tests for F_SEAL_FUTURE_WRITE seal

2018-11-19 Thread Joel Fernandes (Google)
Signed-off-by: Joel Fernandes (Google) --- tools/testing/selftests/memfd/memfd_test.c | 88 +++--- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/tools/testing/selftests/memfd/memfd_test.c b/tools/testing/selftests/memfd/memfd_test.c index 32b207ca7372..c67d32eeb668

Re: [PATCH RFC v2 0/3] cleanups for pstore and ramoops

2018-11-14 Thread Joel Fernandes
On Wed, Nov 14, 2018 at 01:14:57AM -0600, Kees Cook wrote: > On Sat, Nov 3, 2018 at 6:38 PM, Joel Fernandes (Google) > wrote: > > Here are some simple cleanups and fixes for ramoops in pstore. Let me know > > what you think, thanks. > > I took these and slightl

Re: dyntick-idle CPU and node's qsmask

2018-11-11 Thread Joel Fernandes
On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote: [..] > > > > > CPU will with high probability report its own quiescent state before > > > > > three > > > > > jiffies pass, in which case the cache misses on the rcu_data > > > > > structures > > > > > would be wasted motion. > >

Re: dyntick-idle CPU and node's qsmask

2018-11-11 Thread Joel Fernandes
On Sat, Nov 10, 2018 at 08:22:10PM -0800, Paul E. McKenney wrote: > On Sat, Nov 10, 2018 at 07:09:25PM -0800, Joel Fernandes wrote: > > On Sat, Nov 10, 2018 at 03:04:36PM -0800, Paul E. McKenney wrote: > > > On Sat, Nov 10, 2018 at 01:46:59PM -0800, Joel Fernandes wrot

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-11 Thread Joel Fernandes
structures.. and if it works (which I will > >>>> test > >>>> to be sure it will), then we should be good. > >>> > >>> I agree it’s complicated, but the code is already written. You should > >>> just > >>> need to a

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-11 Thread Joel Fernandes
t; > > It seems a fair idea what you're saying. But I don't see how its less > > complex.. IMO its far more simple to have VFS do the denial of the > > operations > > based on the flags of its datastructures.. and if it works (which I will > > test > > to be sure it

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-10 Thread Joel Fernandes
On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote: > > > > On Nov 10, 2018, at 6:38 PM, Joel Fernandes wrote: > > > >> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote: > >> > >>>> On Nov 10, 2018, at 2:09 PM, Jo

Re: dyntick-idle CPU and node's qsmask

2018-11-10 Thread Joel Fernandes
On Sat, Nov 10, 2018 at 03:04:36PM -0800, Paul E. McKenney wrote: > On Sat, Nov 10, 2018 at 01:46:59PM -0800, Joel Fernandes wrote: > > Hi Paul and everyone, > > > > I was tracing/studying the RCU code today in paul/dev branch and noticed > > that > > for dyn

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-10 Thread Joel Fernandes
On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote: > > > On Nov 10, 2018, at 2:09 PM, Joel Fernandes wrote: > > > >> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote: > >>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-10 Thread Joel Fernandes
On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote: > On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione wrote: > > On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes > > wrote: > >> Thanks Andy for your thoughts, my comments below: > [snip] > >>

dyntick-idle CPU and node's qsmask

2018-11-10 Thread Joel Fernandes
Hi Paul and everyone, I was tracing/studying the RCU code today in paul/dev branch and noticed that for dyntick-idle CPUs, the RCU GP thread is clearing the rnp->qsmask corresponding to the leaf node for the idle CPU, and reporting a QS on their behalf. rcu_sched-10[003]40.008039:

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-10 Thread Joel Fernandes
Thanks Andy for your thoughts, my comments below: On Fri, Nov 09, 2018 at 10:05:14PM -0800, Andy Lutomirski wrote: > > > > On Nov 9, 2018, at 7:20 PM, Joel Fernandes wrote: > > > >> On Fri, Nov 09, 2018 at 10:19:03PM +0100, Jann Horn wrote: > >>> On

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-10 Thread Joel Fernandes
On Sat, Nov 10, 2018 at 04:26:46AM -0800, Daniel Colascione wrote: > On Friday, November 9, 2018, Joel Fernandes wrote: > > > On Fri, Nov 09, 2018 at 10:19:03PM +0100, Jann Horn wrote: > > > On Fri, Nov 9, 2018 at 10:06 PM Jann Horn wrote: > > > > On Fri, Nov

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-09 Thread Joel Fernandes
On Fri, Nov 09, 2018 at 12:36:34PM -0800, Andrew Morton wrote: > On Wed, 7 Nov 2018 20:15:36 -0800 "Joel Fernandes (Google)" > wrote: > > > Android uses ashmem for sharing memory regions. We are looking forward > > to migrating all usecases of ashmem to memfd so

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-09 Thread Joel Fernandes
On Fri, Nov 09, 2018 at 10:19:03PM +0100, Jann Horn wrote: > On Fri, Nov 9, 2018 at 10:06 PM Jann Horn wrote: > > On Fri, Nov 9, 2018 at 9:46 PM Joel Fernandes (Google) > > wrote: > > > Android uses ashmem for sharing memory regions. We are looking forward > &g

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-09 Thread Joel Fernandes
On Fri, Nov 09, 2018 at 08:02:14PM +, Michael Tirado wrote: [...] > > > That aside: I wonder whether a better API would be something that > > > allows you to create a new readonly file descriptor, instead of > > > fiddling with the writability of an existing fd. > > > > Every now and then I

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-09 Thread Joel Fernandes
On Fri, Nov 09, 2018 at 03:14:02PM -0800, Andy Lutomirski wrote: > That aside: I wonder whether a better API would be something that > allows you to create a new readonly file descriptor, instead of > fiddling with the writability of an existing fd. > >>> > >>> That doesn't work,

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-09 Thread Joel Fernandes
On Fri, Nov 09, 2018 at 10:06:31PM +0100, Jann Horn wrote: > +linux-api for API addition > +hughd as FYI since this is somewhat related to mm/shmem > > On Fri, Nov 9, 2018 at 9:46 PM Joel Fernandes (Google) > wrote: > > Android uses ashmem for sharing memory regions. W

Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-09 Thread Joel Fernandes
On Wed, Nov 07, 2018 at 08:15:36PM -0800, Joel Fernandes (Google) wrote: > Android uses ashmem for sharing memory regions. We are looking forward > to migrating all usecases of ashmem to memfd so that we can possibly > remove the ashmem driver in the future from staging while also >

[PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

2018-11-07 Thread Joel Fernandes (Google)
write passed as expected future-write seal now active write failed as expected due to future-write seal map 2 prot-write failed as expected due to seal : Permission denied map 3 prot-read passed as expected Cc: jr...@google.com Cc: john.stu...@linaro.org Cc: tk...@google.com Cc: gre...@linuxf

[PATCH v3 resend 2/2] selftests/memfd: Add tests for F_SEAL_FUTURE_WRITE seal

2018-11-07 Thread Joel Fernandes (Google)
Add tests to verify sealing memfds with the F_SEAL_FUTURE_WRITE works as expected. Cc: dan...@google.com Cc: minc...@kernel.org Reviewed-by: John Stultz Signed-off-by: Joel Fernandes (Google) --- tools/testing/selftests/memfd/memfd_test.c | 74 ++ 1 file changed, 74

Re: [PATCH v2] driver-staging: vsoc.c: Add sysfs support for examining the permissions of regions.

2018-11-06 Thread Joel Fernandes
On Tue, Nov 06, 2018 at 01:21:16PM +0800, Jerry Lin wrote: > Add a attribute called permissions under vsoc device node for examining > current granted permissions in vsoc_device. > > This file will display permissions in following format: > begin_offset end_offset owner_offset owned_value >

Re: [PATCH 8/8] pstore/ram: Correctly calculate usable PRZ bytes

2018-11-05 Thread Joel Fernandes
On Mon, Nov 05, 2018 at 09:04:13AM -0800, Kees Cook wrote: > On Sun, Nov 4, 2018 at 8:42 PM, Joel Fernandes wrote: > > Dumping the magic bytes of the non decompressable .enc.z files, I get this > > which shows a valid zlib compressed header: > > > > Something like:

Re: [PATCH RFC v2 1/3] pstore: map pstore types to names

2018-11-04 Thread Joel Fernandes
On Sat, Nov 03, 2018 at 04:38:16PM -0700, Joel Fernandes (Google) wrote: > In later patches we will need to map types to names, so create a table > for that which can also be used and reused in different parts of old and > new code. Also use it to save the type in the PRZ which will

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-11-04 Thread Joel Fernandes
On Sun, Nov 04, 2018 at 07:43:30PM -0800, Paul E. McKenney wrote: [...] > > > > > > > > Also about GP memory ordering and RCU-tree-locking, I think you > > > > > > > > mentioned to > > > > > > > > me that the RCU reader-sections are virtually extended both > > > > > > > > forward and > > > > > >

Re: [PATCH 8/8] pstore/ram: Correctly calculate usable PRZ bytes

2018-11-04 Thread Joel Fernandes
nc.z" file), and triggering errors at boot: > >> > >> [2.790759] pstore: crypto_comp_decompress failed, ret = -22! > >> > >> Reported-by: Joel Fernandes > >> Fixes: b0aad7a99c1d ("pstore: Add compression support to pstore") > >> Sign

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-11-03 Thread Joel Fernandes
On Sat, Nov 03, 2018 at 04:22:59PM -0700, Paul E. McKenney wrote: > On Fri, Nov 02, 2018 at 10:12:26PM -0700, Joel Fernandes wrote: > > On Thu, Nov 01, 2018 at 09:13:07AM -0700, Paul E. McKenney wrote: > > > On Wed, Oct 31, 2018 at 10:00:19PM -0700, Joel Fernandes wrote: >

[PATCH RFC v2 2/3] pstore: simplify ramoops_get_next_prz arguments

2018-11-03 Thread Joel Fernandes (Google)
hed into a single patch to reduce fixup conflicts. Signed-off-by: Joel Fernandes (Google) --- fs/pstore/ram.c | 48 ++-- 1 file changed, 18 insertions(+), 30 deletions(-) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index b174d0fc009f..202eaa82bcc6 100

[PATCH RFC v2 0/3] cleanups for pstore and ramoops

2018-11-03 Thread Joel Fernandes (Google)
Here are some simple cleanups and fixes for ramoops in pstore. Let me know what you think, thanks. Joel Fernandes (Google) (3): pstore: map pstore types to names pstore: simplify ramoops_get_next_prz arguments pstore: donot treat empty buffers as valid fs/pstore/inode.c | 53

[PATCH RFC v2 1/3] pstore: map pstore types to names

2018-11-03 Thread Joel Fernandes (Google)
In later patches we will need to map types to names, so create a table for that which can also be used and reused in different parts of old and new code. Also use it to save the type in the PRZ which will be useful in later patches. Signed-off-by: Joel Fernandes (Google) --- fs/pstore/inode.c

[PATCH RFC v2 3/3] pstore: donot treat empty buffers as valid

2018-11-03 Thread Joel Fernandes (Google)
like: found existing buffer, size 0, start 0 When I was expecting: no valid data in buffer (sig = ...) Signed-off-by: Joel Fernandes (Google) --- Note that if you feel this patch is not necessary, then feel free to drop it. I would say it is harmless and is a good clean up. fs/pstore/ram_core.c

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-11-02 Thread Joel Fernandes
On Thu, Nov 01, 2018 at 09:13:07AM -0700, Paul E. McKenney wrote: > On Wed, Oct 31, 2018 at 10:00:19PM -0700, Joel Fernandes wrote: > > On Wed, Oct 31, 2018 at 11:17:48AM -0700, Paul E. McKenney wrote: > > > On Tue, Oct 30, 2018 at 06:11:19PM -0700, Joel Fernandes wrot

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-11-02 Thread Joel Fernandes
ommit bf3c11b7b9789283f993d9beb80caaabc4403916 > > > Author: Paul E. McKenney > > > Date: Thu Nov 1 09:05:02 2018 -0700 > > > > > > rcu: Add full memory barrier in __wait_rcu_gp() > > > > > > RCU grace periods have extremely strong any-to-any orderin

Re: [PATCH 7/8] pstore: Remove needless lock during console writes

2018-11-02 Thread Joel Fernandes
On Fri, Nov 02, 2018 at 01:40:06PM -0700, Kees Cook wrote: > On Fri, Nov 2, 2018 at 11:32 AM, Joel Fernandes > wrote: > > On Thu, Nov 01, 2018 at 04:51:59PM -0700, Kees Cook wrote: > >> Since commit 70ad35db3321 ("pstore: Convert console write to use > >> -&g

Re: [PATCH 7/8] pstore: Remove needless lock during console writes

2018-11-02 Thread Joel Fernandes
ree to add my Reviewed-by on future respins: Reviewed-by: Joel Fernandes (Google) Also I wonder if Namhyung is still poking around that virtio pstore driver he mentioned in the commit mentioned above. :) thanks, - Joel > Signed-off-by: Kees Cook > --- > fs/pstore/platform.c | 29 +++

Re: [PATCH 2/8] pstore: Do not use crash buffer for decompression

2018-11-02 Thread Joel Fernandes
On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote: > The pre-allocated compression buffer used for crash dumping was also > being used for decompression. This isn't technically safe, since it's > possible the kernel may attempt a crashdump while pstore is populating the > pstore filesystem

Re: [PATCH 8/8] pstore/ram: Correctly calculate usable PRZ bytes

2018-11-02 Thread Joel Fernandes
pstore: crypto_comp_decompress failed, ret = -22! > > Reported-by: Joel Fernandes > Fixes: b0aad7a99c1d ("pstore: Add compression support to pstore") > Signed-off-by: Kees Cook Thanks! Reviewed-by: Joel Fernandes (Google) Also should this be fixed for other backends or are those

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-11-02 Thread Joel Fernandes
9beb80caaabc4403916 > Author: Paul E. McKenney > Date: Thu Nov 1 09:05:02 2018 -0700 > > rcu: Add full memory barrier in __wait_rcu_gp() > > RCU grace periods have extremely strong any-to-any ordering > requirements that are met by placing full barriers in variou

Re: [RFC PATCH] Implement /proc/pid/kill

2018-11-01 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 09:24:00PM -0700, Joel Fernandes wrote: > On Tue, Oct 30, 2018 at 7:56 PM, Aleksa Sarai wrote: > > On 2018-10-31, Christian Brauner wrote: > >> > I think Aleksa's larger point is that it's useful to treat processes > >> > as other file-

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-10-31 Thread Joel Fernandes
On Wed, Oct 31, 2018 at 11:17:48AM -0700, Paul E. McKenney wrote: > On Tue, Oct 30, 2018 at 06:11:19PM -0700, Joel Fernandes wrote: > > Hi Paul, > > > > On Tue, Oct 30, 2018 at 04:43:36PM -0700, Paul E. McKenney wrote: > > > On Tue, Oct 30, 2018 at 03:26:49

Re: [PATCH v2] Implement /proc/pid/kill

2018-10-31 Thread Joel Fernandes
On Thu, Nov 01, 2018 at 04:33:53AM +1100, Aleksa Sarai wrote: > On 2018-10-31, Joel Fernandes wrote: > > I suggest to maintainers we take this in as an intermediate solution > > since we don't have anything close to it and this is a real issue, and > > the fix proposed is

Re: [PATCH v2] Implement /proc/pid/kill

2018-10-31 Thread Joel Fernandes
ip(buffer), 10, ); > + if (res) > + goto out; > + > + res = kill_pid(proc_pid(file_inode(file)), sig, 0); > + if (res) > + goto out; if (res) return res; Other than the security issues which I still think you're discussing, since we need this

Re: [RFC PATCH] Minimal non-child process exit notification support

2018-10-31 Thread Joel Fernandes
On Wed, Oct 31, 2018 at 7:41 AM, Joel Fernandes wrote: [...] >>> > Indeed, to avoid killing the wrong process you need to have opened >>> > some node of /proc/pid/* (maybe cmdline) before sending the kill >>> > signal. >>> >>> The ker

Re: [RFC PATCH] Minimal non-child process exit notification support

2018-10-31 Thread Joel Fernandes
On Wed, Oct 31, 2018 at 7:25 AM, David Laight wrote: > From: Daniel Colascione >> Sent: 31 October 2018 12:56 >> On Wed, Oct 31, 2018 at 12:27 PM, David Laight >> wrote: >> > From: Daniel Colascione >> >> Sent: 29 October 2018 17:53 >> >> >> >> This patch adds a new file under /proc/pid,

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 7:56 PM, Aleksa Sarai wrote: > On 2018-10-31, Christian Brauner wrote: >> > I think Aleksa's larger point is that it's useful to treat processes >> > as other file-descriptor-named, poll-able, wait-able resources. >> > Consistency is important. A process is just another

Re: [PATCH v4] pstore: Avoid duplicate call of persistent_ram_zap()

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 8:57 PM, Peng15 Wang 王鹏 wrote: > >>From: Joel Fernandes >>Sent: Wednesday, October 31, 2018 6:16 >>To: Kees Cook >>Cc: Peng15 Wang 王鹏; Anton Vorontsov; Colin Cross; Tony Luck; LKML; >>vipwangerx...@gmail.com >>Subject: Re:

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-10-30 Thread Joel Fernandes
Hi Paul, On Tue, Oct 30, 2018 at 04:43:36PM -0700, Paul E. McKenney wrote: > On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote: > > Hi Paul, > > > > On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote: > > > As per this thread [

Re: [RFC] rcu: doc: update example about stale data

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 04:50:39PM -0700, Paul E. McKenney wrote: > On Sun, Oct 28, 2018 at 06:16:31PM -0700, Joel Fernandes wrote: > > On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote: > > > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrot

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 11:10:47PM +, Daniel Colascione wrote: > On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes > wrote: > > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote: > >> On 2018-10-30, Joel Fernandes wrote: > >> > On Wed, Oct 31,

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Joel Fernandes
On Wed, Oct 31, 2018 at 09:49:08AM +1100, Aleksa Sarai wrote: > On 2018-10-30, Joel Fernandes wrote: > > > > [...] > > > > > > > (Unfortunately > > > > > > > there are lots of things that make it a bit difficult to use > > &

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Joel Fernandes
On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote: > On 2018-10-30, Joel Fernandes wrote: > > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote: > > [...] > > > > > (Unfortunately > > > > > there are lots of things that make it

Re: [RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-10-30 Thread Joel Fernandes
Hi Paul, On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote: > As per this thread [1], it seems this smp_mb isn't needed anymore: > "So the smp_mb() that I was trying to add doesn't need to be there." > > So let us remove this part from the memory

Re: [RFC PATCH] Minimal non-child process exit notification support

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 08:59:25AM +, Daniel Colascione wrote: > On Tue, Oct 30, 2018 at 3:06 AM, Joel Fernandes wrote: > > On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione wrote: > >> > >> Thanks for taking a look. > >> > >> On Mon, O

Re: [PATCH tip/core/rcu 02/19] rcu: Defer reporting RCU-preempt quiescent states when disabled

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 05:58:00AM -0700, Paul E. McKenney wrote: > On Mon, Oct 29, 2018 at 08:44:52PM -0700, Joel Fernandes wrote: > > On Mon, Oct 29, 2018 at 07:27:35AM -0700, Paul E. McKenney wrote: > > > On Mon, Oct 29, 2018 at 11:24:42AM +, Ran Rozenstein wrote: >

Re: [PATCH v4] pstore: Avoid duplicate call of persistent_ram_zap()

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 02:52:43PM -0700, Kees Cook wrote: > On Tue, Oct 30, 2018 at 2:38 PM, Joel Fernandes > wrote: > > On Tue, Oct 30, 2018 at 03:52:34PM +0800, Peng Wang wrote: > >> When initialing prz with invalid data in buffer(no PERSISTENT_RAM_SIG), > >&

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Joel Fernandes
On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote: [...] > > > (Unfortunately > > > there are lots of things that make it a bit difficult to use /proc/$pid > > > exclusively for introspection of a process -- especially in the context > > > of containers.) > > > > Tons of things

Re: [PATCH v4] pstore: Avoid duplicate call of persistent_ram_zap()

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 03:52:34PM +0800, Peng Wang wrote: > When initialing prz with invalid data in buffer(no PERSISTENT_RAM_SIG), > function call path is like this: > > ramoops_init_prz -> > | > |-> persistent_ram_new -> persistent_ram_post_init -> persistent_ram_zap > | > |->

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-30 Thread Joel Fernandes
On Tue, Oct 30, 2018 at 1:50 AM Daniel Colascione wrote: > > On Tue, Oct 30, 2018 at 3:21 AM, Joel Fernandes wrote: > > On Mon, Oct 29, 2018 at 3:11 PM Daniel Colascione wrote: > >> > >> Add a simple proc-based kill interface. To use /proc/pid/kill, just > >

[PATCH] doc: correct parameter in stallwarn

2018-10-29 Thread Joel Fernandes (Google)
The stallwarn document incorrectly mentions 'fps=' instead of 'fqs='. Correct that. Signed-off-by: Joel Fernandes (Google) --- Documentation/RCU/stallwarn.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt

Re: [PATCH v2] pstore: Avoid duplicate call of persistent_ram_zap()

2018-10-29 Thread Joel Fernandes
On Mon, Oct 29, 2018 at 06:37:53AM +, Peng15 Wang 王鹏 wrote: > > > >From: Kees Cook > >Sent: Monday, October 29, 2018 0:03 > >To: Peng15 Wang 王鹏 > >Cc: an...@enomsg.org; ccr...@android.com; tony.l...@intel.com; > &g

Re: [PATCH tip/core/rcu 02/19] rcu: Defer reporting RCU-preempt quiescent states when disabled

2018-10-29 Thread Joel Fernandes
t; RCU-preempt in CONFIG_PREEMPT=y kernels. This may require some > > > additional plumbing to provide the network denial-of-service guarantees > > > that have been traditionally provided by RCU-bh. Once these are in place, > > > CONFIG_PREEMPT=n kernels will be able to fold R

Re: [RFC PATCH] Implement /proc/pid/kill

2018-10-29 Thread Joel Fernandes
On Mon, Oct 29, 2018 at 3:11 PM Daniel Colascione wrote: > > Add a simple proc-based kill interface. To use /proc/pid/kill, just > write the signal number in base-10 ASCII to the kill file of the > process to be killed: for example, 'echo 9 > /proc/$$/kill'. > > Semantically, /proc/pid/kill works

Re: [RFC PATCH] Minimal non-child process exit notification support

2018-10-29 Thread Joel Fernandes
On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione wrote: > > Thanks for taking a look. > > On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes wrote: > > > > On Mon, Oct 29, 2018 at 10:53 AM Daniel Colascione > > wrote: > > > > > > This patch add

Re: [RFC PATCH] Minimal non-child process exit notification support

2018-10-29 Thread Joel Fernandes
On Mon, Oct 29, 2018 at 12:45 PM Joel Fernandes wrote: > > On Mon, Oct 29, 2018 at 10:53 AM Daniel Colascione wrote: > > > > This patch adds a new file under /proc/pid, /proc/pid/exithand. > > Attempting to read from an exithand file will block until the > > corresp

Re: [RFC PATCH] Minimal non-child process exit notification support

2018-10-29 Thread Joel Fernandes
On Mon, Oct 29, 2018 at 10:53 AM Daniel Colascione wrote: > > This patch adds a new file under /proc/pid, /proc/pid/exithand. > Attempting to read from an exithand file will block until the > corresponding process exits, at which point the read will successfully > complete with EOF. The file

Re: [RFC] rcu: doc: update example about stale data

2018-10-28 Thread Joel Fernandes
On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote: > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrote: > > The RCU example for 'rejecting stale data' on system-call auditting > > stops iterating through the rules if a deleted one is found. It

Re: [RFC] rcu: doc: update example about stale data

2018-10-27 Thread Joel Fernandes
On Sat, Oct 27, 2018 at 7:16 PM, Joel Fernandes (Google) wrote: > The RCU example for 'rejecting stale data' on system-call auditting > stops iterating through the rules if a deleted one is found. It makes > more sense to continue looking at other rules once a deleted one is > reject

[RFC] doc: rcu: remove note on smp_mb during synchronize_rcu

2018-10-27 Thread Joel Fernandes (Google)
As per this thread [1], it seems this smp_mb isn't needed anymore: "So the smp_mb() that I was trying to add doesn't need to be there." So let us remove this part from the memory ordering documentation. [1] https://lkml.org/lkml/2017/10/6/707 Signed-off-by: Joel Fernand

[RFC] rcu: doc: update example about stale data

2018-10-27 Thread Joel Fernandes (Google)
-by: Joel Fernandes (Google) --- Documentation/RCU/listRCU.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt index adb5a3782846..09e9a4fc723e 100644 --- a/Documentation/RCU/listRCU.txt +++ b/Documentation/RCU

Re: [RFC 1/6] pstore: map pstore types to names

2018-10-26 Thread Joel Fernandes
On Fri, Oct 26, 2018 at 08:04:24PM +0100, Kees Cook wrote: > On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google) > wrote: > > In later patches we will need to map types to names, so create a table > > for that which can also be used and reused in different parts of old and

Re: [RFC 5/6] pstore: donot treat empty buffers as valid

2018-10-26 Thread Joel Fernandes
On Fri, Oct 26, 2018 at 08:39:13PM +0100, Kees Cook wrote: > On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google) > wrote: > > pstore currently calls persistent_ram_save_old even if a buffer is > > empty. While this appears to work, it is simply not the right thing to >

Re: [RFC 6/6] Revert "pstore/ram_core: Do not reset restored zone's position and size"

2018-10-26 Thread Joel Fernandes
On Fri, Oct 26, 2018 at 08:42:12PM +0100, Kees Cook wrote: > On Fri, Oct 26, 2018 at 7:22 PM, Joel Fernandes > wrote: > > On Fri, Oct 26, 2018 at 07:16:28PM +0100, Kees Cook wrote: > >> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google) > >> wro

Re: [RFC 3/6] pstore: remove max argument from ramoops_get_next_prz

2018-10-26 Thread Joel Fernandes
On Fri, Oct 26, 2018 at 08:27:49PM +0100, Kees Cook wrote: > On Fri, Oct 26, 2018 at 8:22 PM, Joel Fernandes > wrote: > > On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote: > >> From the code flow, the 'max' checks are already being done o

Re: [RFC 4/6] pstore: further reduce ramoops_get_next_prz arguments by passing record

2018-10-26 Thread Joel Fernandes
On Fri, Oct 26, 2018 at 08:32:16PM +0100, Kees Cook wrote: > On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google) > wrote: > > Both the id and type fields of a pstore_record are set by > > ramoops_get_next_prz. So we can just pass a pointer to the pstore_record >

Re: [RFC 3/6] pstore: remove max argument from ramoops_get_next_prz

2018-10-26 Thread Joel Fernandes
On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote: > From the code flow, the 'max' checks are already being done on the prz > passed to ramoops_get_next_prz. Lets remove it to simplify this function > and reduce its arguments. > > Signed-off-by: Joel Fe

Re: [RFC 6/6] Revert "pstore/ram_core: Do not reset restored zone's position and size"

2018-10-26 Thread Joel Fernandes
On Fri, Oct 26, 2018 at 07:16:28PM +0100, Kees Cook wrote: > On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google) > wrote: > > This reverts commit 25b63da64708212985c06c7f8b089d356efdd9cf. > > > > Due to the commit which is being reverted here, it is not possible

[RFC 2/6] pstore: remove type argument from ramoops_get_next_prz

2018-10-26 Thread Joel Fernandes (Google)
Since we store the type of the prz when we initialize it, we no longer need to pass it again in ramoops_get_next_prz since we can just use that to setup the pstore record. So lets remove it from the argument list. Signed-off-by: Joel Fernandes (Google) --- fs/pstore/ram.c | 20

[RFC 4/6] pstore: further reduce ramoops_get_next_prz arguments by passing record

2018-10-26 Thread Joel Fernandes (Google)
Both the id and type fields of a pstore_record are set by ramoops_get_next_prz. So we can just pass a pointer to the pstore_record instead of passing individual elements. This results in cleaner more readable code and fewer lines. Signed-off-by: Joel Fernandes (Google) --- fs/pstore/ram.c | 18

[RFC 3/6] pstore: remove max argument from ramoops_get_next_prz

2018-10-26 Thread Joel Fernandes (Google)
>From the code flow, the 'max' checks are already being done on the prz passed to ramoops_get_next_prz. Lets remove it to simplify this function and reduce its arguments. Signed-off-by: Joel Fernandes (Google) --- fs/pstore/ram.c | 14 ++ 1 file changed, 6 insertions(+), 8 deleti

[RFC 5/6] pstore: donot treat empty buffers as valid

2018-10-26 Thread Joel Fernandes (Google)
pstore currently calls persistent_ram_save_old even if a buffer is empty. While this appears to work, it is simply not the right thing to do and could lead to bugs so lets avoid that. It also prevent misleading prints in the logs which claim the buffer is valid. Signed-off-by: Joel Fernandes

  1   2   3   4   5   6   7   8   9   10   >