[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87msdrz0i9.ffs@tglx>
Date: Tue, 11 Mar 2025 23:05:34 +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 17/18] posix-timers: Provide a mechanism to allocate
a given timer ID
On Tue, Mar 11 2025 at 22:35, Frederic Weisbecker wrote:
> Le Sat, Mar 08, 2025 at 05:48:47PM +0100, Thomas Gleixner a écrit :
>> @@ -364,6 +389,16 @@ static enum hrtimer_restart posix_timer_
>> return HRTIMER_NORESTART;
>> }
>>
>> +long posixtimer_create_prctl(unsigned long ctrl)
>> +{
>> + if (ctrl > PR_TIMER_CREATE_RESTORE_IDS_ON)
>> + return -EINVAL;
>> +
>> + guard(spinlock_irq)(¤t->sighand->siglock);
>> + current->signal->timer_create_restore_ids = ctrl == PR_TIMER_CREATE_RESTORE_IDS_ON;
>
> Is the locking necessary here? It's not used on the read side.
> It only makes sense if more flags are to be added later in struct signal and the
> fields write can race.
True.
> Also do we want to carry this PR_TIMER_CREATE_RESTORE_IDS_ON accross exec? Posix
> timers are removed then anyway.
Indeed, we should clear that.
Powered by blists - more mailing lists