linux-kernel - Re: [PATCH v5 tip/core/rcu 4/9] completion: Replace spin_unlock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170817141304.GP7017@linux.vnet.ibm.com>
Date:   Thu, 17 Aug 2017 07:13:04 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org, jiangshanlai@...il.com,
        dipankar@...ibm.com, akpm@...ux-foundation.org,
        mathieu.desnoyers@...icios.com, josh@...htriplett.org,
        tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
        dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
        oleg@...hat.com, Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Alan Stern <stern@...land.harvard.edu>,
        Andrea Parri <parri.andrea@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v5 tip/core/rcu 4/9] completion: Replace
 spin_unlock_wait() with lock/unlock pair

On Thu, Aug 17, 2017 at 02:49:09PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > > this change - or can I pick this up into the scheduler tree?
> > 
> > Timely question!  ;-)
> > 
> > My current plan is to send you a pull request like the following later
> > today, Pacific Time (but rebased adding Steve Rostedt's Reviewed-by).
> > This patch is on one of the branches, currently v4.13-rc2..93d8d7a12090
> > ("arch: Remove spin_unlock_wait() arch-specific definitions") in my
> > -rcu tree.
> > 
> > Ah, and v4.13-rc2..7391304c4959 ("membarrier: Expedited private command")
> > is mostly outside of RCU as well.
> > 
> > Since I will be rebasing and remerging anyway, if you would prefer that I
> > split the spin_unlock_wait() and/or misc branches out, I am happy to do so.
> > If I don't hear otherwise, though, I will send all seven branches using
> > my usual approach.
> > 
> > So, if you want something different than my usual approach, please just
> > let me know!
> 
> No, all branches together sounds good to me!

Very good, will do!

> If you are rebasing anyway, here are some (very minor) commit title nits I noticed:
> 
> >       swait: add idle variants which don't contribute to load average
> >       rcu: use idle versions of swait to make idle-hack clear
> 
> Capitalization.

Will fix!  Believe it or not, I looked for these...  :-/

> >       membarrier: Expedited private command
> 
> Should start with a verb.

OK, something like "Provide expedited private command".

> >       doc: RCU documentation update
> 
>   doc: Update RCU documentation
> 
> ?

Works for me!

> >       doc: No longer allowed to use rcu_dereference on non-pointers
> 
>   doc: Describe that it is no longer allowed to use rcu_dereference() on non-pointers
> 
> ?

Will add a real commit log.

> >       torture: Add --kconfig argument to kvm.sh
> >       rcutorture: Don't wait for kernel when all builds fail
> 
> Is there a difference between 'torture: ' and 'rcutorture: ' prefixes?

Yes, rcutorture is specific to RCU, while torture would also affect
locktorture.

Ah, and if I am delaying the cond_resched() patch, I need to retest,
which means I will send you the pull request tomorrow or Monday, depending
on how the testing goes.

							Thanx, Paul

> Thanks,
> 
> 	Ingo
>