[for-next][PATCH 04/12] ftrace: Have the cached module list show in set_ftrace_filter

From: "Steven Rostedt (VMware)" When writing in a module filter into set_ftrace_filter for a module that is not yet loaded, it it cached, and will be executed when the module is loaded (although that is not implemented yet at this commit). Display the list of cached modules to be traced.

[for-next][PATCH 08/12] ftrace: Remove unused function ftrace_arch_read_dyn_info()

From: "Steven Rostedt (VMware)" ftrace_arch_read_dyn_info() was used so that archs could add its own debug information into the dyn_ftrace_total_info in the tracefs file system. That file is for debugging usage of dynamic ftrace. No arch uses that function anymore, so just get rid of it. This

[for-next][PATCH 06/12] ftrace: Have cached module filters be an active filter

From: "Steven Rostedt (VMware)" When a module filter is added to set_ftrace_filter, if the module is not loaded, it is cached. This should be considered an active filter, and function tracing should be filtered by this. That is, if a cached module filter is the only filter

[for-next][PATCH 06/12] ftrace: Have cached module filters be an active filter

From: "Steven Rostedt (VMware)" When a module filter is added to set_ftrace_filter, if the module is not loaded, it is cached. This should be considered an active filter, and function tracing should be filtered by this. That is, if a cached module filter is the only filter set, then no function

[for-next][PATCH 05/12] ftrace: Implement cached modules tracing on module load

From: "Steven Rostedt (VMware)" If a module is cached in the set_ftrace_filter, and that module is loaded, then enable tracing on that module as if the cached module text was written into set_ftrace_filter just as the module is loaded. # echo ":mod:kvm_intel" > # cat

[for-next][PATCH 05/12] ftrace: Implement cached modules tracing on module load

From: "Steven Rostedt (VMware)" If a module is cached in the set_ftrace_filter, and that module is loaded, then enable tracing on that module as if the cached module text was written into set_ftrace_filter just as the module is loaded. # echo ":mod:kvm_intel" > # cat

[for-next][PATCH 11/12] tracing: Add support for display of tgid in trace output

From: Joel Fernandes Earlier patches introduced ability to record the tgid using the 'record-tgid' option. Here we read the tgid and output it if the option is enabled. Link: http://lkml.kernel.org/r/20170626053844.5746-3-joe...@google.com Cc: kernel-t...@android.com Cc:

[for-next][PATCH 11/12] tracing: Add support for display of tgid in trace output

From: Joel Fernandes Earlier patches introduced ability to record the tgid using the 'record-tgid' option. Here we read the tgid and output it if the option is enabled. Link: http://lkml.kernel.org/r/20170626053844.5746-3-joe...@google.com Cc: kernel-t...@android.com Cc: Ingo Molnar

[for-next][PATCH 12/12] ftrace: Unlock hash mutex on failed allocation in process_mod_list()

From: "Steven Rostedt (VMware)" If the new_hash fails to allocate, then unlock the hash mutex on error. Reported-by: Julia Lawall Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/ftrace.c | 3 ++- 1 file changed, 2

[for-next][PATCH 12/12] ftrace: Unlock hash mutex on failed allocation in process_mod_list()

From: "Steven Rostedt (VMware)" If the new_hash fails to allocate, then unlock the hash mutex on error. Reported-by: Julia Lawall Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/ftrace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ftrace.c

[for-next][PATCH 10/12] tracing: Add support for recording tgid of tasks

From: Joel Fernandes Inorder to support recording of tgid, the following changes are made: * Introduce a new API (tracing_record_taskinfo) to additionally record the tgid along with the task's comm at the same time. This has has the benefit of not setting

[for-next][PATCH 10/12] tracing: Add support for recording tgid of tasks

From: Joel Fernandes Inorder to support recording of tgid, the following changes are made: * Introduce a new API (tracing_record_taskinfo) to additionally record the tgid along with the task's comm at the same time. This has has the benefit of not setting trace_cmdline_save before all the

[for-next][PATCH 01/12] ftrace: Add missing comment for FTRACE_OPS_FL_RCU

From: "Steven Rostedt (VMware)" All the enum flags for FTRACE_OPS has a comment except for the RCU one. Add the comment for that. Signed-off-by: Steven Rostedt (VMware) --- include/linux/ftrace.h | 1 + 1 file changed, 1 insertion(+) diff --git

[for-next][PATCH 00/12] tracing: More updates for 4.13

Added some more features. One from Joel that lets events display tgid. The other allows for functions in modules to be traced when the module is loaded. It uses the :mod: function command that already exists in set_ftrace_filter, but instead of giving you an error if the module does not exist, it

[for-next][PATCH 02/12] tracing: Show address when function names are not found

From: "Steven Rostedt (VMware)" Currently, when a function is not found in kallsyms, instead of simply showing the function address, it shows nothing at all: # echo ':mod:kvm_intel' > /sys/kernel/tracing/set_ftrace_filter # echo function >

[for-next][PATCH 01/12] ftrace: Add missing comment for FTRACE_OPS_FL_RCU

From: "Steven Rostedt (VMware)" All the enum flags for FTRACE_OPS has a comment except for the RCU one. Add the comment for that. Signed-off-by: Steven Rostedt (VMware) --- include/linux/ftrace.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/ftrace.h

[for-next][PATCH 00/12] tracing: More updates for 4.13

Added some more features. One from Joel that lets events display tgid. The other allows for functions in modules to be traced when the module is loaded. It uses the :mod: function command that already exists in set_ftrace_filter, but instead of giving you an error if the module does not exist, it

[for-next][PATCH 02/12] tracing: Show address when function names are not found

From: "Steven Rostedt (VMware)" Currently, when a function is not found in kallsyms, instead of simply showing the function address, it shows nothing at all: # echo ':mod:kvm_intel' > /sys/kernel/tracing/set_ftrace_filter # echo function > /sys/kernel/tracing/set_ftrace_filter # qemu

[for-next][PATCH 09/12] ftrace: Decrement count for dyn_ftrace_total_info file

From: "Steven Rostedt (VMware)" The dyn_ftrace_total_info file is used to show how many functions have been converted into nops and can be used by ftrace. The problem is that it does not get decremented when functions are removed (init boot code being freed, and modules

[for-next][PATCH 07/12] sh/ftrace: Remove only user of ftrace_arch_read_dyn_info()

From: Steven Rostedt I noticed that there's only one user of ftrace_arch_read_dyn_info(). That was used a while ago during the NMI updating in x86, and superh copied it to implement its version of handling NMIs during stop_machine(). But that is a debug feature, and this

[for-next][PATCH 09/12] ftrace: Decrement count for dyn_ftrace_total_info file

From: "Steven Rostedt (VMware)" The dyn_ftrace_total_info file is used to show how many functions have been converted into nops and can be used by ftrace. The problem is that it does not get decremented when functions are removed (init boot code being freed, and modules being freed). That means

[for-next][PATCH 07/12] sh/ftrace: Remove only user of ftrace_arch_read_dyn_info()

From: Steven Rostedt I noticed that there's only one user of ftrace_arch_read_dyn_info(). That was used a while ago during the NMI updating in x86, and superh copied it to implement its version of handling NMIs during stop_machine(). But that is a debug feature, and this code hasn't been

Re: [PATCH] clk: scpi: error when clock fails to register

On 06/28, Jerome Brunet wrote: > Current implementation of scpi_clk_add just print a warning when clock > fails to register but then keep going as if nothing happened. The > provider is then registered with bogus data. > > This may latter lead to an Oops in __clk_create_clk when >

Re: [PATCH] clk: scpi: error when clock fails to register

On 06/28, Jerome Brunet wrote: > Current implementation of scpi_clk_add just print a warning when clock > fails to register but then keep going as if nothing happened. The > provider is then registered with bogus data. > > This may latter lead to an Oops in __clk_create_clk when >

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 05:10:41PM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 5:06 PM, Linus Torvalds > wrote: > > > > Please don't make this one commit fopr every architecture. > > > > Once something gets removed, it gets removed. There's no point in >

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 05:10:41PM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 5:06 PM, Linus Torvalds > wrote: > > > > Please don't make this one commit fopr every architecture. > > > > Once something gets removed, it gets removed. There's no point in > > "remove it from architecture

Re: [PATCH] clk: si5351: expand compatible strings in documentation

To is to nobody? Rob can apply it I suppose. On 06/29, Brandon Streiff wrote: > checkpatch.pl doesn't know how to expand "silabs,si5351{a,a-msop,b,c}" > and so generates warnings about si5351-compatible devices appearing to > be un-documented. Resolve this by documenting the compatible options >

Re: [PATCH] clk: si5351: expand compatible strings in documentation

To is to nobody? Rob can apply it I suppose. On 06/29, Brandon Streiff wrote: > checkpatch.pl doesn't know how to expand "silabs,si5351{a,a-msop,b,c}" > and so generates warnings about si5351-compatible devices appearing to > be un-documented. Resolve this by documenting the compatible options >

Re: [RESEND PATCH v4] clk: stm32h7: Add stm32h743 clock driver

On 06/29, Gabriel FERNANDEZ wrote: > > > On 06/28/2017 05:59 PM, Stephen Boyd wrote: > > On 06/27, Gabriel FERNANDEZ wrote: > >> > >> On 06/22/2017 12:07 AM, Stephen Boyd wrote: > >>> readl_poll_timeout? > >>> > >> if i use readl_poll_timeout (wich use 'ktime_get()') it can be > >> operational

Re: [RESEND PATCH v4] clk: stm32h7: Add stm32h743 clock driver

On 06/29, Gabriel FERNANDEZ wrote: > > > On 06/28/2017 05:59 PM, Stephen Boyd wrote: > > On 06/27, Gabriel FERNANDEZ wrote: > >> > >> On 06/22/2017 12:07 AM, Stephen Boyd wrote: > >>> readl_poll_timeout? > >>> > >> if i use readl_poll_timeout (wich use 'ktime_get()') it can be > >> operational

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

On Thu, Jun 29, 2017 at 10:29:12AM -0600, Jeffrey Hugo wrote: > On 6/27/2017 6:11 PM, Paul E. McKenney wrote: > >On Tue, Jun 27, 2017 at 04:32:09PM -0600, Jeffrey Hugo wrote: > >>On 6/22/2017 9:34 PM, Paul E. McKenney wrote: > >>>On Wed, Jun 21, 2017 at 09:18:53AM -0700, Paul E. McKenney wrote: >

wake_wide mechanism clarification

Dear Mike, I wanted your kind help to understand your patch "sched: beef up wake_wide()"[1] which is a modification to the original patch from Michael Wang [2]. In particular, I didn't following the following comment: " to shared cache, we look for a minimum 'flip' frequency of llc_size in one

Re: [BUG] Deadlock due due to interactions of block, RCU, and cpu offline

On Thu, Jun 29, 2017 at 10:29:12AM -0600, Jeffrey Hugo wrote: > On 6/27/2017 6:11 PM, Paul E. McKenney wrote: > >On Tue, Jun 27, 2017 at 04:32:09PM -0600, Jeffrey Hugo wrote: > >>On 6/22/2017 9:34 PM, Paul E. McKenney wrote: > >>>On Wed, Jun 21, 2017 at 09:18:53AM -0700, Paul E. McKenney wrote: >

wake_wide mechanism clarification

Dear Mike, I wanted your kind help to understand your patch "sched: beef up wake_wide()"[1] which is a modification to the original patch from Michael Wang [2]. In particular, I didn't following the following comment: " to shared cache, we look for a minimum 'flip' frequency of llc_size in one

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 05:09:56PM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 05:06:16PM -0700, Linus Torvalds wrote: > > On Thu, Jun 29, 2017 at 5:01 PM, Paul E. McKenney > > wrote: > > > There is no agreed-upon definition of spin_unlock_wait()'s

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 05:09:56PM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 05:06:16PM -0700, Linus Torvalds wrote: > > On Thu, Jun 29, 2017 at 5:01 PM, Paul E. McKenney > > wrote: > > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > > and it appears

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

le (write(fd, buffer, sizeof(buffer)) == sizeof(buffer)) fsync(fd); _exit(0); } } for (size = 1048576; size < 512UL * (1 << 30); size <<= 1) { char *cp = realloc(buf, size); if (!

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

le (write(fd, buffer, sizeof(buffer)) == sizeof(buffer)) fsync(fd); _exit(0); } } for (size = 1048576; size < 512UL * (1 << 30); size <<= 1) { char *cp = realloc(buf, size); if (!

[PATCH RFC 05/26] exit: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_exit() with spin_lock() followed immediately by spin_unlock(). This should be safe

[PATCH RFC 05/26] exit: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_exit() with spin_lock() followed immediately by spin_unlock(). This should be safe

[PATCH RFC 10/26] arc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 10/26] arc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Vineet Gupta Cc: Cc:

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 5:06 PM, Linus Torvalds wrote: > > Please don't make this one commit fopr every architecture. > > Once something gets removed, it gets removed. There's no point in > "remove it from architecture X". If there are no more users, we're > done

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 5:06 PM, Linus Torvalds wrote: > > Please don't make this one commit fopr every architecture. > > Once something gets removed, it gets removed. There's no point in > "remove it from architecture X". If there are no more users, we're > done with it, and making it be 25

[PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in task_work_run() with spin_lock() followed immediately by spin_unlock(). This should be

[PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in task_work_run() with spin_lock() followed immediately by spin_unlock(). This should be

[PATCH RFC 12/26] arm64: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 12/26] arm64: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Catalin Marinas Cc: Will

[PATCH RFC 03/26] sched: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_task_dead() with spin_lock() followed immediately by spin_unlock(). This should be

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 05:06:16PM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 5:01 PM, Paul E. McKenney > wrote: > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > and it appears that all callers could do just as well with a

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 05:06:16PM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 5:01 PM, Paul E. McKenney > wrote: > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > and it appears that all callers could do just as well with a lock/unlock > > pair. This

[PATCH RFC 03/26] sched: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in do_task_dead() with spin_lock() followed immediately by spin_unlock(). This should be

[PATCH RFC 15/26] ia64: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 15/26] ia64: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Tony Luck Cc: Fenghua Yu

[PATCH RFC 16/26] m32r: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 16/26] m32r: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Will Deacon Cc: Peter

[PATCH RFC 19/26] mn10300: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 19/26] mn10300: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: David Howells Cc: Cc:

[PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Benjamin Herrenschmidt

Re: [PATCH] fs: Reorder inode_owner_or_capable() to avoid needless

On Tue, Jun 20, 2017 at 02:40:24PM -0700, Kees Cook wrote: > Checking for capabilities should be the last operation when performing > access control tests so that PF_SUPERPRIV is set only when it was required > for success (implying that the capability was needed for the operation). Applied

Re: [PATCH] fs: Reorder inode_owner_or_capable() to avoid needless

On Tue, Jun 20, 2017 at 02:40:24PM -0700, Kees Cook wrote: > Checking for capabilities should be the last operation when performing > access control tests so that PF_SUPERPRIV is set only when it was required > for success (implying that the capability was needed for the operation). Applied

[PATCH RFC 07/26] drivers/ata: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore eliminates the spin_unlock_wait() call and associated else-clause and hoists the then-clause's lock and unlock out of the "if"

[PATCH RFC 07/26] drivers/ata: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore eliminates the spin_unlock_wait() call and associated else-clause and hoists the then-clause's lock and unlock out of the "if"

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 5:01 PM, Paul E. McKenney wrote: > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > and it appears that all callers could do just as well with a lock/unlock > pair. This commit therefore removes the underlying

Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

On Thu, Jun 29, 2017 at 5:01 PM, Paul E. McKenney wrote: > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > and it appears that all callers could do just as well with a lock/unlock > pair. This commit therefore removes the underlying arch-specific >

Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

On Thu, Jun 29, 2017 at 3:53 PM, Kees Cook wrote: > I see a few possible solutions: Or this ugly hack: diff --git a/include/linux/sched.h b/include/linux/sched.h index e2ad3531e7fe..5d131f9f1dac 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -749,6

Re: [PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

On Thu, Jun 29, 2017 at 3:53 PM, Kees Cook wrote: > I see a few possible solutions: Or this ugly hack: diff --git a/include/linux/sched.h b/include/linux/sched.h index e2ad3531e7fe..5d131f9f1dac 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -749,6 +749,19 @@ struct

[PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() calls in nf_conntrack_lock() and nf_conntrack_all_lock() with spin_lock() followed immediately

[PATCH RFC 18/26] mips: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() calls in nf_conntrack_lock() and nf_conntrack_all_lock() with spin_lock() followed immediately

[PATCH RFC 18/26] mips: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Ralf Baechle Cc: Cc:

[PATCH RFC 22/26] s390: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 22/26] s390: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Martin Schwidefsky Cc:

[PATCH RFC 14/26] hexagon: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 14/26] hexagon: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Richard Kuo Cc: Cc: Will

[PATCH RFC 23/26] sh: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 24/26] sparc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 23/26] sh: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Yoshinori Sato Cc: Rich

[PATCH RFC 24/26] sparc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: "David S. Miller" Cc:

[PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes spin_unlock_wait() and related definitions from core code. Signed-off-by: Paul E. McKenney

[PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes spin_unlock_wait() and related definitions from core code. Signed-off-by: Paul E. McKenney Cc: Arnd Bergmann Cc:

[PATCH RFC 04/26] completion: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in completion_done() with spin_lock() followed immediately by spin_unlock(). This should

[PATCH RFC 04/26] completion: Replace spin_unlock_wait() with lock/unlock pair

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore replaces the spin_unlock_wait() call in completion_done() with spin_lock() followed immediately by spin_unlock(). This should

[PATCH RFC 09/26] alpha: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 09/26] alpha: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Richard Henderson Cc:

[PATCH RFC 13/26] blackfin: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 26/26] xtensa: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 26/26] xtensa: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Chris Zankel Cc: Max

[PATCH RFC 13/26] blackfin: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Steven Miao Cc: Cc: Will

[PATCH RFC 20/26] parisc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 20/26] parisc: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: "James E.J. Bottomley"

[PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 11/26] arm: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney

[PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Chris Metcalf Cc: Will

[PATCH RFC 11/26] arm: Remove spin_unlock_wait() arch-specific definitions

There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This commit therefore removes the underlying arch-specific arch_spin_unlock_wait(). Signed-off-by: Paul E. McKenney Cc: Russell King Cc: Cc:

[PATCH RFC 0/26] Remove spin_unlock_wait()

Hello! There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This series therefore removes spin_unlock_wait() and changes its users to instead use a lock/unlock pair. The commits are as follows, in

[PATCH RFC 0/26] Remove spin_unlock_wait()

Hello! There is no agreed-upon definition of spin_unlock_wait()'s semantics, and it appears that all callers could do just as well with a lock/unlock pair. This series therefore removes spin_unlock_wait() and changes its users to instead use a lock/unlock pair. The commits are as follows, in

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Thu, 29 Jun 2017 17:21:22 -0400 Richard Guy Briggs wrote: > > Looking at this again today, why would we want to clear name->dentry > > in audit_copy_inode() if it is already set? Does that ever happen? > > I'm not sure it does ... > > It has been nearly 3 months since I

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Thu, 29 Jun 2017 17:21:22 -0400 Richard Guy Briggs wrote: > > Looking at this again today, why would we want to clear name->dentry > > in audit_copy_inode() if it is already set? Does that ever happen? > > I'm not sure it does ... > > It has been nearly 3 months since I coded that, so

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