linux-kernel - Re: [PATCH] sched: allow preempt notifiers to self-unregister.

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: <20111216172523.GB4569@madism.org>
Date:	Fri, 16 Dec 2011 18:25:23 +0100
From:	Pierre Habouzit <pierre.habouzit@...ersec.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Avi Kivity <avi@...ranet.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sched: allow preempt notifiers to self-unregister.

On Fri, Dec 16, 2011 at 06:09:45PM +0100, Peter Zijlstra wrote:
> On Fri, 2011-12-16 at 17:15 +0100, Pierre Habouzit wrote:
> 
> >   As a background, this need is because I have some kind of module code
> >   that uses this facility to evaluate how many of a group of threads are
> >   concurrently running (to regulate a pool of threads).
> 
> Typically such stuff is only merged along with whomever uses it.

Well for now I'm just toying with it, it's nowhere nead to be ready to
be even shown without me having to bury my head from shame ;)

> >   Hence I install those callbacks for the thread registering themselves
> >   and want to keep them until the thread dies. Sadly I have no way to
> >   unregister those callbacks right now, but for horrible hacks (involving
> >   private delayed queues processed regularly walked to kfree() the
> >   structures referencing pids that are dead, urgh).
> 
> kfree_rcu() is the 'normal' way to cheat your way out of this.

Hmm, if when I'm scheduled "out" with the TASK_DEAD bit set, am I sure
the _in/_out callback will never ever be called again?

It experimentally seems that the answer is yes, but I'm not familiar
enough with the scheduler to be a 100% sure. If yes then kfree_rcu is
just fine indeed and I don't need the patch, at all.

If it's not "sure" then I assume I can probably use call_rcu() but that
looks like a total overkill for something that can be fully avoided with
my patch, which incidentally, doesn't slow the typical sched path (there
should be no callbacks and the _safe iterator exits as fast as the non
safe iterator).
-- 
Intersec <http://www.intersec.com>
Pierre Habouzit <pierre.habouzit@...ersec.com> | Chief Software Architect
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie
--
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/