From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756907AbcK2UdM (ORCPT ); Tue, 29 Nov 2016 15:33:12 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60717 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751991AbcK2UdD (ORCPT ); Tue, 29 Nov 2016 15:33:03 -0500 Date: Tue, 29 Nov 2016 12:32:59 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Petr Mladek , Josh Poimboeuf , Vince Weaver , "linux-kernel@vger.kernel.org" , Ingo Molnar , Arnaldo Carvalho de Melo , "dvyukov@google.com" Subject: Re: perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind_start Reply-To: paulmck@linux.vnet.ibm.com References: <20161128215411.fkis7bbimjy4v4j7@treble> <20161129004021.GL3924@linux.vnet.ibm.com> <20161129055241.6dy2dt4q4ptazk2s@treble> <20161129124323.GJ3092@twins.programming.kicks-ass.net> <20161129151004.GU3924@linux.vnet.ibm.com> <20161129162920.GF21230@pathway.suse.cz> <20161129171038.GN3092@twins.programming.kicks-ass.net> <20161129193935.GE3924@linux.vnet.ibm.com> <20161129195204.GG3045@worktop.programming.kicks-ass.net> <20161129200711.GF3924@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161129200711.GF3924@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112920-0008-0000-0000-00000634A447 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006164; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000193; SDB=6.00787025; UDB=6.00380653; IPR=6.00564711; BA=6.00004928; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013484; XFM=3.00000011; UTC=2016-11-29 20:33:01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112920-0009-0000-0000-00003D6E65D1 Message-Id: <20161129203259.GA28037@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-29_05:,, 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-1609300000 definitions=main-1611290338 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 29, 2016 at 12:07:11PM -0800, Paul E. McKenney wrote: > On Tue, Nov 29, 2016 at 08:52:04PM +0100, Peter Zijlstra wrote: > > On Tue, Nov 29, 2016 at 11:39:35AM -0800, Paul E. McKenney wrote: > > > On Tue, Nov 29, 2016 at 06:10:38PM +0100, Peter Zijlstra wrote: > > > > > > It mostly works, most of the time, and that seems to be what Linus > > > > wants, since its really the best we can have given the constraints. But > > > > for debugging, when you have a UART, it totally blows. > > > > > > UART??? They still make those things??? ;-) > > > > Yes, most computer like devices actually have them, trouble is, most > > consumer devices don't have the pins exposed. Luckily most server class > > hardware still does. > > > > And they're absolutely _awesome_ for debugging; getting data out is a > > matter of trivial MMIO poll loops. Rock solid stuff. > > They very clearly need to bring the baud rate into the current millenium, > many tens of Mbaud at the -very- least. On a more practical note... Currently, cond_resched_rcu_qs() is not permitted to be invoked until after the scheduler has started. However, it appears that there is some kernel code that can loop for quite some time at runtime, but which also executes during early boot. So it would be good to make it so that cond_resched_rcu_qs() could be called at boot. One approach would be to check rcu_scheduler_active, but this isn't defined in normal Tiny RCU builds. I can expand Tiny RCU, or I can kludge the non-CONFIG_DEBUG_LOCK_ALLOC value of rcu_scheduler_active to false (with this latter being the current state). But it occurred to me that I could also condition on !is_idle_task(), given that idle tasks shouldn't ever be invoking the scheduler anyway. So is the following a sensible approach, or should I look elsewhere? #define cond_resched_rcu_qs() \ do { \ if (!is_idle_task(current) && !cond_resched()) \ rcu_note_voluntary_context_switch(current); \ } while (0) Thanx, Paul