From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754413AbcEPQZA (ORCPT ); Mon, 16 May 2016 12:25:00 -0400 Received: from relay2.sgi.com ([192.48.180.65]:53135 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754328AbcEPQY7 (ORCPT ); Mon, 16 May 2016 12:24:59 -0400 Date: Mon, 16 May 2016 11:24:55 -0500 From: Alex Thorlton To: Ingo Molnar Cc: Alex Thorlton , linux-kernel@vger.kernel.org, Dimitri Sivanich , Russ Anderson , Mike Travis , Matt Fleming , Borislav Petkov , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-efi@vger.kernel.org Subject: Re: [PATCH 2/2] Fix efi_call Message-ID: <20160516162455.GD98477@stormcage.americas.sgi.com> References: <1462996545-98387-1-git-send-email-athorlton@sgi.com> <1462996545-98387-3-git-send-email-athorlton@sgi.com> <20160512064835.GB30717@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160512064835.GB30717@gmail.com> 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 Thu, May 12, 2016 at 08:48:35AM +0200, Ingo Molnar wrote: > I suppose the SGI/UV code is the only one using 7 arguments or more? Might make > sense to point that out in the changelog. First off, to everybody, sorry for the delayed responses. I've been AFK for a few days and forgot to set my vacation notice :( Yes, I believe that's it. I didn't do a full audit, but a quick glance at the other users of this call showed that nobody else appears to be using that many args. > Just curious, how did you find this bug? It's a pretty obscure one, of the > 'developer tears out hairs from frustruation' type ... Yes, this one was a real puzzle to figure out. Basically I just stepped through the assembly code from a known good point to see how we ended up where we did. I quite a bit of help from the vets around here, as well as from our simulator that I used to step through our early boot code to find the problem. The real hair pulling mostly came from trying to figure out *WHY* we were putting the return address in this seemingly random spot on the stack. After thoroughly re-reading assorted Intel (et. al.) docs about a hundred times, I was able to piece together what I thought was supposed to be going on here. The solution may be simple, but arriving there was anything but that :) - Alex