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  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:   Tue, 18 Aug 2020 17:56:49 -0700
From:   Guenter Roeck <>
To:     Valdis Klētnieks <>,
        Mark Starovoytov <>,
        Igor Russkikh <>,
        "David S. Miller" <>
Cc:     Greg KH <>,
        "Ahmed S. Darwish" <>,,,,,,,,
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).
> 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 <>
> 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.


Powered by blists - more mailing lists