linux-kernel - Re: [PATCH] sched: fix another race when reading /proc/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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Dec 2008 01:41:45 -0800
From:	Paul Menage <menage@...gle.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Li Zefan <lizf@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [PATCH] sched: fix another race when reading /proc/sched_debug

On Mon, Dec 15, 2008 at 2:43 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>>
>> +             /*
>> +              * Some subsystems (cpu cgroup) might still be able to
>> +              * accessing the cgroup in rcu section.
>> +              */
>> +             synchronize_rcu();
>> +
>>               kfree(cgrp);
>>       }
>>       iput(inode);
>
> Is there any reason we cannot use call_rcu() ?

It should be OK to rcu-free cgrp and have it still safe to call
cgroup_path() on it - as long as we're confident that the dentry (and
all its parents) won't be released until after the RCU section as
well, since that's where we get the path elements from. And that does
seem to be the case from looking at dcache.c

It's certainly nicer than having two calls to synchronize_rcu() in
quick succession in cgroup_diput().
>
> Perhaps wrap that check in a cgroup_*() helper? That would avoid the
> duplication, be clearer and not open code the ->dentry assumption.

I think it would be simpler to not have the cgroup exposed to the
subsystem until the dentry and other structures have been created. The
current order (create subsystems, then create fs structures) is more
or less a carry-over from when I extended cpusets, rather than an
explicit design choice.

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