linux-kernel - Re: [patch V2 10/17] posix-timers: Make signal_struct::next_posix_timer_id an atomic

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: <Z8d7tm5dQN6dZEvu@grain>
Date: Wed, 5 Mar 2025 01:16:22 +0300
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	Frederic Weisbecker <frederic@...nel.org>,
	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>
Subject: Re: [patch V2 10/17] posix-timers: Make
 signal_struct::next_posix_timer_id an atomic_t

On Tue, Mar 04, 2025 at 09:30:04PM +0100, Thomas Gleixner wrote:
> On Tue, Mar 04 2025 at 20:56, Cyrill Gorcunov wrote:
> > On Mon, Mar 03, 2025 at 10:24:28PM +0100, Thomas Gleixner wrote:
> >> 
> >> Welcome. Some quick validation with CRIU would be appreciated.
> >
> > Just tested in criu: works without problem, both modes -- with new
> > prctl and without it. Note that I only have ran separate posix-timers
> > test case, probably virtuozzo team might do more deep tesing.
> 
> Thank you very much!

Thanks for handling this) Also looking into this series I wonder why can't
we instead of mangling ::it_signal zero bit just use ::it_id with negative
value as a sign of not yet fully initialized timer? This would allow to not
read-modify action while traversing bucket hash chain. I mean we could do

static bool posix_timer_add_at(struct k_itimer *timer, struct signal_struct *sig, unsigned int id)
{
	struct timer_hash_bucket *bucket = hash_bucket(sig, id);

	scoped_guard (spinlock, &bucket->lock) {
		if (!posix_timer_hashed(bucket, sig, id)) {
--->			timer->it_id = -(timer_t)id;
			timer->it_signal = (struct signal_struct *)((unsigned long)sig | 1UL);
			hlist_add_head_rcu(&timer->t_hash, &bucket->head);
			return true;
		}
	}
	return false;
}

Then hash traverse won't find the timer until the do_timer_create will do

	scoped_guard (spinlock_irq, &current->sighand->siglock) {
		WRITE_ONCE(new_timer->it_id, abs(new_timer->it_id));
		hlist_add_head_rcu(&new_timer->list, &current->signal->posix_timers);
	}

Or I miss something obvious? (Of course when deleting timer we will have to pass
abs it_id for hash traversing).

It looks that in case of many many timers present in the system traversing hash
in read-modify way might be heavy (though I didn't measure of course).

	Cyrill