From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbaAGNyO (ORCPT ); Tue, 7 Jan 2014 08:54:14 -0500 Received: from [217.140.96.21] ([217.140.96.21]:50499 "EHLO cam-smtp0.cambridge.arm.com" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751264AbaAGNyJ (ORCPT ); Tue, 7 Jan 2014 08:54:09 -0500 Date: Tue, 7 Jan 2014 13:53:14 +0000 From: Dave Martin To: Anurag Aggarwal Cc: Anurag Aggarwal , Naveen Kumar , Narendra Meher , "nico@linaro.org" , Ashish Kalra , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , "cpgs ." , "naveenkrishna.ch@gmail.com" , Rajat Suri , Poorva Srivastava , "linux-arm-kernel@lists.infradead.org" , Mohammad Irfan Ansari Subject: Re: [PATCH V6] ARM : unwinder : Prevent data abort due to stack overflow Message-ID: <20140107135254.GA3241@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 14, 2013 at 03:47:49PM +0530, Anurag Aggarwal wrote: > >You could try adding some debug printks to see how the backtrace fails. > >You could also try adding a few hand-crafted assembler functions > >with appropriate code and unwind directives to trigger different kinds > >of backtrace failure. You might have to add a way to artificially limit > >sp_high to check the cases where you run out of stack in the middle of > >popping multiple registers. > > I added a a printk statement > + if (*vsp >= (unsigned long *)ctrl->sp_high) { > + printk(KERN_ERR "Stack Overflow Detected, vsp = %lx", > + (unsigned long)*vsp); > + return -URC_FAILURE; > + } > > I ran a many test cases to try and get the above print in the dmesg log. > > I tried the following things : > > 1) Calling unwind_backtrace from diffrenet locations in the kernel, I > added the unwind call > in some irq, fork, exit and some sysfs entries call. > 2) I limited the value of sp_high in unwind_frame() itself, I tried > many values of sp_high, > varrying from (low + sizeof(ctrl.vrs)/4) to (low + 4*sizeof(ctrl.vrs)). > > When running the above cases I was able to see the above printk quiet > a few times in dmesg log. > > So, the error condition is being handled. > > If you have some test cases for verifying the unwinder, please share > the same. They might help > in thorough testing of unwinder. I think that sounds OK to give us reasonable confidence that the code is working correctly. Go ahead and add my Reviewed-by on the patch, if you're still waiting for it. Cheers ---Dave