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: <CANrsvRPAWv8LgSvPrGgLiXnjrtK3CmpJgdpNsuu-0LZJTYeYWQ@mail.gmail.com>
Date:   Thu, 21 Jun 2018 02:15:07 +0900
From:   Byungchul Park <max.byungchul.park@...il.com>
To:     Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc:     Byungchul Park <byungchul.park@....com>, jiangshanlai@...il.com,
        josh@...htriplett.org, Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        linux-kernel@...r.kernel.org, kernel-team@....com,
        Joel Fernandes <joel@...lfernandes.org>, luto@...nel.org
Subject: Re: [RFC 2/2] rcu: Remove ->dynticks_nmi_nesting from struct rcu_dynticks

On Thu, Jun 21, 2018 at 1:49 AM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:

[...]

> Perhaps the fact that there are architectures that can enter interrupt
> handlers and never leave them when the CPU is non-idle.  One example of
> this is the usermode upcalls in the comment that you removed.
>
> Or have all the architectures been modified so that each and every call to
> rcu_irq_enter() and to rcu_irq_exit() are now properly paired and nested?
>
> Proper nesting and pairing was -not- present in the past, hence the
> special updates (AKA "crowbar") to the counters when transitioning to
> and from idle.

Thank you very much for explaining it in detail.

> If proper nesting and pairing of rcu_irq_enter() and rcu_irq_exit()
> is now fully in force across all architectures and configurations, the
> commit log needs to say this, preferably pointing to the corresponding
> commits that made this change.

Right.

> There is a call to rcu_irq_enter() without a corresponding call to
> rcu_irq_exit(), so that the ->dynticks_nesting counter never goes back to
> zero so that the next time this CPU goes idle, RCU thinks that the CPU
> is still non-idle.  This can result in excessively long grace periods
> and needless IPIs to idle CPUs.

No doubt.

> But only if calls to rcu_irq_enter() and rcu_irq_exit() are now always
> properly paired and nested, which was definitely -not- the case last
> I looked.

I missed it. Right. It's worth only in the case that calls to rcu_irq_enter()
and rcu_irq_exit() are always properly paired and nested.

> OK, so I can further consider this pair of patches only if
> all architectures now properly pair and nest rcu_irq_enter() and
> rcu_irq_exit().  It would be very good if they did, but actually testing
> back in the day showed that they did not.  If that has changed, that
> would be a very good thing, but if not, this patch injects bugs.

Totally agree with you. Sorry bothering you.

-- 
Thanks,
Byungchul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ