From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753063AbcGVIYx (ORCPT ); Fri, 22 Jul 2016 04:24:53 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:34151 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751417AbcGVIYu (ORCPT ); Fri, 22 Jul 2016 04:24:50 -0400 Date: Fri, 22 Jul 2016 10:24:46 +0200 From: Ingo Molnar To: Josh Poimboeuf Cc: Andy Lutomirski , Thomas Gleixner , "H . Peter Anvin" , X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds , Steven Rostedt , Brian Gerst , Kees Cook , Peter Zijlstra , Frederic Weisbecker , Byungchul Park Subject: Re: [PATCH 07/19] x86/dumpstack: add IRQ_USABLE_STACK_SIZE define Message-ID: <20160722082446.GA12425@gmail.com> References: <20160722014812.3adsrej7zj4qpbff@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160722014812.3adsrej7zj4qpbff@treble> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Josh Poimboeuf wrote: > > > irq_stack_end = (unsigned long *)(per_cpu(irq_stack_ptr, cpu)); > > > - irq_stack = (unsigned long *)(per_cpu(irq_stack_ptr, cpu) - IRQ_STACK_SIZE); > > > + irq_stack = (unsigned long *)(per_cpu(irq_stack_ptr, cpu) - > > > + IRQ_USABLE_STACK_SIZE); > > > > This is different. > > If nobody knows the reason for it, I may just remove it. It doesn't > seem to blow anything up on my system. I tried digging through the git > history but it's been there since the beginning of git time. Please do any behavioral changes in separate patches - ordered after all the 'does not change behavior' low-risk patches. I.e. try to order the patches by risk: (near-)zero-risk ones first, followed by lower risk ones, closed by higher risk ones. This makes both review, application of the patches and any bisection/fixing work later on easier. If you ever see a good chance to split a patch that changes behavior into a zero-risk and a low-risk component, do so - we'd rather err on the side of being too finegrained in a series than having to scratch heads when bisecting to overly large patches. Thanks, Ingo