linux-kernel - Re: Question about synchronize_sched

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] [day] [month] [year] [list]

Message-ID: <4CC69E8F.20003@kernel.org>
Date:	Tue, 26 Oct 2010 11:25:35 +0200
From:	Tejun Heo <tj@...nel.org>
To:	paulmck@...ux.vnet.ibm.com
CC:	linux-kernel@...r.kernel.org
Subject: Re: Question about synchronize_sched_expedited()

Hello, Paul.

On 10/25/2010 09:41 PM, Paul E. McKenney wrote:
>> I think your concern is valid and this can happen w/o preemption given
>> enough cpus and perfect timing.  Was the original code free from this
>> problem?
> 
> I believe so -- there was a mutex guarding the whole operation, including
> the increment.

I see.

>> IMHO the counter based mechanism is a bit too difficult to ponder and
>> verify.  Can we do more conventional double queueing (ie. flipping
>> pending and executing queues so that multiple sync calls can get
>> coalesced while another one is in progress)?  That's what the code is
>> trying to achieve anyway, right?
> 
> Hmmm...  But it would be necessary to flip the queues somewhere, and
> wouldn't determining where that somewhere was involve the same analysis
> and complexity as determining where to increment the counter?

I was thinking something like the following.

	lock;
	if (list_empty(running))
		add myself to running
		unlock;
	else
		remember list_empty(pending)
		append myself to pending queue;
		unlock and sleep;
		if (pending wasn't empty)
			return;

	do it;

	lock;
	wake up all on running and clear it;
	list_splice_init(pending, running);
	wake up the first of running;
	unlock;

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/