[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y0xbzm81.ffs@tglx>
Date: Tue, 11 Mar 2025 15:16:30 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Anna-Maria Behnsen
<anna-maria@...utronix.de>, Benjamin Segall <bsegall@...gle.com>, Eric
Dumazet <edumazet@...gle.com>, Andrey Vagin <avagin@...nvz.org>, Pavel
Tikhomirov <ptikhomirov@...tuozzo.com>, Peter Zijlstra
<peterz@...radead.org>, Cyrill Gorcunov <gorcunov@...il.com>
Subject: Re: [patch V3 02/18] posix-timers: Initialise timer before adding
it to the hash table
On Tue, Mar 11 2025 at 14:25, Frederic Weisbecker wrote:
> Le Sat, Mar 08, 2025 at 05:48:14PM +0100, Thomas Gleixner a écrit :
>>
>> -static struct k_itimer *posix_timer_by_id(timer_t id)
>> +static inline struct signal_struct *posix_sig_owner(const struct k_itimer *timer)
>> {
>> - struct signal_struct *sig = current->signal;
>> - struct hlist_head *head = &posix_timers_hashtable[hash(sig, id)];
>> + unsigned long val = (unsigned long)timer->it_signal;
>
> When used from posix_timer_add() -> posix_timer_hashed(), it can race
> with another do_timer_create() that clears the BIT 0. It's fine but
> KCSAN is going to warn sooner or later.
Indeed
> It looks like a good candidate for data_race() ? Well, READ_ONCE() is
> fine too.
READ_ONCE() is the right thing to do.
Powered by blists - more mailing lists