linux-kernel - Use case for TASKS

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

Message-Id: <20170515182354.GA25440@linux.vnet.ibm.com>
Date:   Mon, 15 May 2017 11:23:54 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     mingo@...nel.org, rostedt@...dmis.org
Cc:     linux-kernel@...r.kernel.org
Subject: Use case for TASKS_RCU

Hello!

The question of the use case for TASKS_RCU came up, and here is my
understanding.  Steve will not be shy about correcting any misconceptions
I might have.  ;-)

The use case is to support freeing of trampolines used in tracing/probing
in CONFIG_PREEMPT=y kernels.  It is necessary to wait until any task
executing in the trampoline in question has left it, taking into account
that the trampoline's code might be interrupted and preempted.  However,
the code in the trampolines is guaranteed never to context switch.

Note that in CONFIG_PREEMPT=n kernels, synchronize_sched() suffices.
It is therefore tempting to think in terms of disabling preemption across
the trampolines, but there is apparently not enough room to accommodate
the needed preempt_disable() and preempt_enable() in the code invoking
the trampoline, and putting the preempt_disable() and preempt_enable()
in the trampoline itself fails because of the possibility of preemption
just before the preempt_disable() and just after the preempt_enable().
Similar reasoning rules out use of rcu_read_lock() and rcu_read_unlock().

Another possibility would be to place the trampolines in a known region
of memory, and check for the task's PC being in that region.  This fails
because trampolines can be interrupted, and I vaguely recall something
about them calling function as well.  Stack tracing could be added,
but stack tracing is not as reliable as it would need to be.

The solution chosen relies on the fact that code in trampolines
(and code invoked from trampolines) is not permitted to do voluntary
context switches.  Thus, if a trampoline is removed, and a given task
later does a voluntary context switch (or has been seen in usermode),
that task will never again reference that trampoline.  Once all tasks
are accounted for, the trampoline may safely be removed.

TASKS_RCU implements a flavor of RCU that does exactly this.  It has
only a single use at the moment, but avoiding memory leaks on
production machines being instrumented seems to me to be quite valuable.

So, Steve, please correct any misconceptions!

							Thanx, Paul