From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752924AbdF2RHF (ORCPT ); Thu, 29 Jun 2017 13:07:05 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53820 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751333AbdF2RHA (ORCPT ); Thu, 29 Jun 2017 13:07:00 -0400 Date: Thu, 29 Jun 2017 10:06:56 -0700 From: "Paul E. McKenney" To: Leon Yang Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] rcu: fix crash when reading rcudata debugfs node Reply-To: paulmck@linux.vnet.ibm.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17062917-2213-0000-0000-000001EC7004 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007294; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00880470; UDB=6.00438930; IPR=6.00660622; BA=6.00005447; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016010; XFM=3.00000015; UTC=2017-06-29 17:06:57 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062917-2214-0000-0000-000056B218D9 Message-Id: <20170629170656.GL3721@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-29_12:,, 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-1706290278 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 29, 2017 at 11:25:08AM -0500, Leon Yang wrote: > With CONFIG_RCU_TRACE=y set, reading the rcu//rcudata file > in debugfs will leads to a segmentation fault. > > dmesg reports general protection fault with the following message: > > task: ffffa0e715959d00 task.stack: ffffc117c7390000 > RIP: 0010:show_rcudata+0x4e/0x1e0 > RSP: 0018:ffffc117c7393d50 EFLAGS: 00010282 > RAX: ffffa0e8d7212098 RBX: ffffa0e8d721cd00 RCX: ffffa0e8d7200000 > RDX: 0000000000000000 RSI: 0000000000000e6c RDI: 0000000000000000 > RBP: ffffc117c7393d90 R08: 0000000000000000 R09: 0000000000000fff > R10: ffffa0e8bf464000 R11: ffffa0e715959d00 R12: ffffa0e81ecf4100 > R13: ffffa0e8c51fcd00 R14: ffffa0e8d721cd00 R15: ffffa0e81ecf4100 > FS: 00007fea5a064700(0000) GS:ffffa0e8d7440000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007fea5a041008 CR3: 00000006035f1000 CR4: 00000000000406e0 > Call Trace: > seq_read+0x9e/0x440 > ? lru_cache_add_active_or_unevictable+0x36/0xb0 > full_proxy_read+0x54/0x90 > __vfs_read+0x37/0x150 > ? security_file_permission+0x9b/0xc0 > vfs_read+0x93/0x130 > SyS_read+0x55/0xc0 > entry_SYSCALL_64_fastpath+0x1e/0xa9 > RIP: 0033:0x7fea59b89230 > RSP: 002b:00007ffca86f0418 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 > RAX: ffffffffffffffda RBX: 00007fea59e56b20 RCX: 00007fea59b89230 > RDX: 0000000000020000 RSI: 00007fea5a042000 RDI: 0000000000000003 > RBP: 0000000000021010 R08: ffffffffffffffff R09: 0000000000000000 > R10: 000000000000037b R11: 0000000000000246 R12: 0000000000022000 > R13: 00007fea59e56b78 R14: 0000000000001000 R15: 0000000000020000 > Code: f3 48 83 ec 18 48 63 8e 70 01 00 00 48 8b 86 c8 00 00 00 44 0f > b6 46 1a 48 8b 76 10 48 83 c0 18 48 89 ca 48 8b 0c cd e0 f3 54 90 <48> > 39 34 01 0f b6 73 18 89 d0 40 0f 94 c7 48 0f a3 05 5c 0f e8 > > In print_one_rcu_data(), the argument rdp is already a per_cpu pointer > (see r_start():66). Therefore, calling per_cpu() on > rdp->dynticks->rcu_qs_ctr will dereference invalid memory address. > Since rdp->dynticks points to the per_cpu struct rcu_dynticks, using > rdp->dynticks->rcu_qs_ctr directly will fix this problem. > > Fixes: 9577df9a3122af08fff84b8a1a60dccf524a3891 ("rcu: Pull rcu_qs_ctr > into rcu_dynticks structure") > Signed-off-by: Leon Yang Good catch! However, I have removed RCU's debugfs functionality because I have since added event tracing. It has been some years since I have used RCU's debugfs. Which might explain its bugginess. If you tell me what you were wanting to use the debugfs for, I would be happy to tell you how to some reasonable facsimile of that information from event tracing. Thanx, Paul > --- > --- kernel/rcu/tree_trace.c.orig > +++ kernel/rcu/tree_trace.c > @@ -121,7 +121,7 @@ static void print_one_rcu_data(struct se > cpu_is_offline(rdp->cpu) ? '!' : ' ', > ulong2long(rdp->completed), ulong2long(rdp->gpnum), > rdp->cpu_no_qs.b.norm, > - rdp->rcu_qs_ctr_snap == per_cpu(rdp->dynticks->rcu_qs_ctr, rdp->cpu), > + rdp->rcu_qs_ctr_snap == rdp->dynticks->rcu_qs_ctr, > rdp->core_needs_qs); > seq_printf(m, " dt=%d/%llx/%d df=%lu", > rcu_dynticks_snap(rdp->dynticks), >