[<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