linux-kernel - Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

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: <f35aa0d8-3bbf-0900-7bcd-81ba6e03fe86@lge.com>
Date:   Mon, 14 May 2018 12:11:59 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Joel Fernandes <joel@...lfernandes.org>, jiangshanlai@...il.com,
        josh@...htriplett.org, mathieu.desnoyers@...icios.com,
        linux-kernel@...r.kernel.org, kernel-team@....com,
        peterz@...radead.org
Subject: Re: [PATCH] rcu: Report a quiescent state when it's exactly in the
 state



On 2018-05-13 오전 2:26, Steven Rostedt wrote:
> On Sat, 12 May 2018 07:41:19 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> 
>> Don't get me wrong, this discussion was quite useful to me.  We probably
>> need to at least change the comments, and perhaps the code as well.  But
>> I agree that we need input from Peter and Steven to make much more forward
>> progress.
> 
> It's the weekend so I skimmed more than read this thread, but I will
> just add this.
> 
> The table Joel posted is interesting, and perhaps we should keep things
> consistent with that. But that said, with respect to task-RCU, as
> nothing on a trampoline should ever call cond_resched() (and perhaps I
> should add code in lockdep that verifies this), we just want a
> quiescent state that tells us that the task has left the trampoline. A
> cond_resched() should be one of those points that does.
> 
> It really has nothing to do with scheduling or preemption. The issue is
> that if a task is on a trampoline and gets preempted, there's no
> knowing when it is off that trampoline where we can free it. We need to
> have places in the kernel that we know is a quiescent state to move
> task-RCU forward. cond_resched() seems to be one of them. schedule
> itself can not be, because it can be called from an interrupt preempting
> a task while it is on the trampoline.

Exactly. I think Steven explained how we should consider them exactly.

> -- Steve
-- 
Thanks,
Byungchul