[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJhHMCB57G6LSFTX8pjoHKNKYv4ND1=8bhFWai0UxT-N-tQHdg@mail.gmail.com>
Date: Tue, 17 Jun 2014 14:22:50 -0400
From: Pranith Kumar <bobby.prani@...il.com>
To: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Romanov Arya <romanov.arya@...il.com>,
Josh Triplett <josh@...htriplett.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
torvalds <torvalds@...ux-foundation.org>, Waiman.Long@...com
Subject: Re: [RFC PATCH 1/1] kernel/rcu/tree.c: simplify force_quiescent_state()
On Tue, Jun 17, 2014 at 1:10 PM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
>
> Pranith, Romanov: You do -not-, repeat -not-, get to shoot from the hip
> with this code. You absolutely need to understand what it is doing and
> why before you try hacking on it. Otherwise, all that will happen is
> that you will come up with additional creative ways to break RCU. Your
> commit log and comments will need to clearly indicate that you understand
> what happens if (say) 4096 CPUs all call force_quiescent_state() at the
> same time.
>
I do apologize for the noise I am causing.
I totally agree that I need to understand what exactly is happening
before I propose to do anything. I am trying to understand how all
this works by asking questions. I did try looking at why the locks
were there and spent quite some time trying to figure it out looking
at the history, but could not entirely get it. Hence the RFC.
Thank you for patiently considering and replying to my RFCs.
Regards,
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists