linux-kernel - Re: [tip: timers/core] hrtimer: Annotate lockless access to timer->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: <CANn89iLMD0=tiQ181qQ=qKo=Nom-XX4MqonZw6pKiYUzTDVjQg@mail.gmail.com>
Date:   Thu, 7 Nov 2019 08:35:30 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     paulmck@...nel.org
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-tip-commits@...r.kernel.org,
        syzbot <syzkaller@...glegroups.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>
Subject: Re: [tip: timers/core] hrtimer: Annotate lockless access to timer->state

On Thu, Nov 7, 2019 at 8:11 AM Paul E. McKenney <paulmck@...nel.org> wrote:
>
> OK, so this is due to timer_pending() lockless access to ->entry.pprev
> to determine whether or not the timer is on the list.  New one on me!
>
> Given that use case, I don't have an objection to your patch to list.h.
>
> Except...
>
> Would it make sense to add a READ_ONCE() to hlist_unhashed()
> and to then make timer_pending() invoke hlist_unhashed()?  That
> would better confine the needed uses of READ_ONCE().

Sounds good to me, I had the same idea but was too lazy to look at the
history of timer_pending()
to check if the pprev pointer check was really the same underlying idea.