linux-kernel - Re: [PATCH 4/4] nohz: Fix iowait overcounting if iowait task migrates

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]

Date:	Mon, 05 May 2014 20:14:19 +0200
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	linux-kernel@...r.kernel.org,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Fernando Luis Vazquez Cao <fernando_b1@....ntt.co.jp>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH 4/4] nohz: Fix iowait overcounting if iowait task migrates

On 04/29/2014 06:20 PM, Frederic Weisbecker wrote:
>> index 268a45e..ffea757 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -4218,7 +4218,14 @@ void __sched io_schedule(void)
>>  	current->in_iowait = 1;
>>  	schedule();
>>  	current->in_iowait = 0;
>> +#ifdef CONFIG_NO_HZ_COMMON
>> +	if (atomic_dec_and_test(&rq->nr_iowait)) {
>> +		if (raw_smp_processor_id() != cpu_of(rq))
>> +			tick_nohz_iowait_to_idle(cpu_of(rq));
> 
> Note that even using seqlock doesn't alone help to fix the preemption issue
> when the above may overwrite the exittime of the next last iowait task from
> the old rq.

Meaning: between atomic_dec_and_test(&rq->nr_iowait) going to zero
and tick_nohz_iowait_to_idle(), CPU left idle, acquired a new task,
this task submitted IO, IO completed, this second task also reached
this place, its atomic_dec_and_test(&rq->nr_iowait) went to zero
and now we race doing

	ts->iowait_exittime = now;

from two tasks?

This shouldn't be a problem anyway since the value of "now"
in this situation will be nearly the same - provided that
(a) store is atomic (no corruption due to the race) and
(b) we are careful when we are using it (for example, we
clamp it to be not earlier than idle start time).

Do you see a problem here which I miss?

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