linux-kernel - Re: [PATCH] Revert "seqlock: lockdep assert non-preemptibility on seqcount

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: <fa442483-00b5-169e-dac2-71fbf8307117@roeck-us.net>
Date:   Tue, 18 Aug 2020 17:56:49 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Valdis Klētnieks <valdis.kletnieks@...edu>,
        Mark Starovoytov <mstarovoitov@...vell.com>,
        Igor Russkikh <irusskikh@...vell.com>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        "Ahmed S. Darwish" <a.darwish@...utronix.de>,
        bigeasy@...utronix.de, linux-kernel@...r.kernel.org,
        mingo@...hat.com, paulmck@...nel.org, peterz@...radead.org,
        rostedt@...dmis.org, tglx@...utronix.de, will@...nel.org
Subject: Re: [PATCH] Revert "seqlock: lockdep assert non-preemptibility on
 seqcount_t write"

On 8/18/20 3:51 PM, Valdis Klētnieks wrote:
> On Mon, 10 Aug 2020 07:10:32 -0700, Guenter Roeck said:
>>> 	ERROR: modpost: "__bad_udelay" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
>>>
>>
>> I don't think that is new. If anything, it is surprising that builds don't fail more
>> widely because of it. AFAICS it was introduced back in 2018 (a hot 50-ms delay loop
>> really isn't such a good idea).
> 
> Well...it wasn't broken in next-20200720.  A bit of poking with nm,
> and building hw_atl/hw_atl_b0.s, it looks like the culprit is this commit:
> 
> commit 8dcf2ad39fdb2d183b7bd4307c837713e3150b9a
> Author: Mark Starovoytov <mstarovoitov@...vell.com>
> Date:   Mon Jul 20 21:32:44 2020 +0300
> 
>     net: atlantic: add hwmon getter for MAC temperature
> 
> specifically this chunk around line 1634 of hw_atl/hw_atl_b0.c:
> 
> 
> +       err = readx_poll_timeout_atomic(hw_atl_b0_ts_ready_and_latch_high_get,
> +                                       self, val, val == 1, 10000U, 500000U);
> 
> And doing a 'git revert' makes the build work....
> 

Nice catch. FWIW, there is no obvious reason why this would need to be atomic.
The calling code does not set a lock, meaning there can be two (or more)
callers entering this code. Weird, especially since the code looks like it
would actually need a mutex to work correctly. It might be interesting to
see what happens if there are, say, half a dozen scripts/processes trying
to read the hwmon attribute introduced by this patch at the same time.

Guenter