linux-kernel - Re: [PATCH RFC tip/core/rcu] SRCU rewrite

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]

Date:   Thu, 17 Nov 2016 12:31:34 -0800
From:   Lance Roy <ldr709@...il.com>
To:     Lai Jiangshan <jiangshanlai@...il.com>
Cc:     Boqun Feng <boqun.feng@...il.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>, dipankar@...ibm.com,
        akpm@...ux-foundation.org,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Josh Triplett <josh@...htriplett.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        David Howells <dhowells@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, dvhart@...ux.intel.com,
        Frédéric Weisbecker <fweisbec@...il.com>,
        oleg@...hat.com, pranith kumar <bobby.prani@...il.com>
Subject: Re: [PATCH RFC tip/core/rcu] SRCU rewrite

On Thu, 17 Nov 2016 23:07:02 +0800
Lai Jiangshan <jiangshanlai@...il.com> wrote:

> On Thu, Nov 17, 2016 at 10:31 PM, Boqun Feng <boqun.feng@...il.com> wrote:
> > After reading the comment for a while, I actually got a question, maybe
> > I miss something ;-)
> >
> > Why "at most NR_CPUS worth of readers using the old index haven't
> > incremented the counters" could save us from overflow the counter?
> >
> > Please consider the following case in current implementation:
> >
> >
> > {sp->completed = 0} so idx = 1 in srcu_advance_batches(...)
> >
> > one thread A is currently in __srcu_read_lock() and using idx = 1 and
> > about to increase the percpu c[idx], and ULONG_MAX __srcu_read_lock()s
> > have been called and returned with idx = 1, please note I think this is
> > possible because I assume we may have some code like this:
> >
> >         unsigned long i = 0;
> >         for (; i < ULONG_MAX; i++)
> >                 srcu_read_lock(); // return the same idx 1;  
> 
> this is the wrong usage of the api.
> 
> 
> you might rewrite it as:
> 
>         unsigned long index[2] = {0, 0};
>         unsigned long i = 0;
>         for (;  index[1] < ULONG_MAX; i++)
>                  index[srcu_read_lock()]++;
Doesn't this still fail the API by not nesting correctly? If you don't keep
track of the order the indices were returned in then it seems like you would
exit the critical sections in the wrong order.

Thanks,
Lance