From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935318AbdEOSX7 (ORCPT ); Mon, 15 May 2017 14:23:59 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:49550 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933346AbdEOSXy (ORCPT ); Mon, 15 May 2017 14:23:54 -0400 Date: Mon, 15 May 2017 11:23:54 -0700 From: "Paul E. McKenney" To: mingo@kernel.org, rostedt@goodmis.org Cc: linux-kernel@vger.kernel.org Subject: Use case for TASKS_RCU Reply-To: paulmck@linux.vnet.ibm.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17051518-0044-0000-0000-0000032D3B43 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007067; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000212; SDB=6.00860892; UDB=6.00426933; IPR=6.00640555; BA=6.00005350; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015467; XFM=3.00000015; UTC=2017-05-15 18:23:52 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051518-0045-0000-0000-0000075B477F Message-Id: <20170515182354.GA25440@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-15_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705150174 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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