From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH] x86/traps: Remove redundant trapnr parameter from fatal_trap() Date: Sat, 06 Sep 2014 20:18:57 -0400 Message-ID: <540BA471.5000601@terremark.com> References: <1409565974-9539-1-git-send-email-andrew.cooper3@citrix.com> <54049A5B.4080507@terremark.com> <54049E6F.20205@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54049E6F.20205@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Jan Beulich , Don Slutz , Xen-devel List-Id: xen-devel@lists.xenproject.org On 09/01/14 12:27, Andrew Cooper wrote: > On 01/09/14 17:10, Don Slutz wrote: >> On 09/01/14 06:06, Andrew Cooper wrote: >>> It is always available via regs->entry_vector. >>> >>> Signed-off-by: Andrew Cooper >>> CC: Jan Beulich >>> --- >>> -void fatal_trap(int trapnr, const struct cpu_user_regs *regs) >>> +void fatal_trap(const struct cpu_user_regs *regs) >>> { >>> static DEFINE_PER_CPU(char, depth); >>> + unsigned int trapnr = regs->entry_vector; >> Should this be: >> >> unsigned int trapnr = regs->entry_vector & >> ~(TRAP_regs_partial|TRAP_syscall); >> >> >> To get rid of the extra bits? >> >> -Don Slutz > No; I don't think so. There should be no paths into fatal_trap() which > would set these bits, as these bits are only set as a result of guest > sys/hypercall interaction, while fatal_trap() is a terminal error condition. > > Furthermore, if a path is discovered then a) it will be more obvious > from the error message and b) we probably have a security problem to fix. > > ~Andrew Ok. Reviewed-by: Don Slutz