From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eddie.linux-mips.org ([148.251.95.138]:35296 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751850AbdFHN7B (ORCPT ); Thu, 8 Jun 2017 09:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1]:38520 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S23993894AbdFHNLvi1CAQ (ORCPT ); Thu, 8 Jun 2017 15:11:51 +0200 Date: Thu, 8 Jun 2017 15:11:41 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: James Hogan , linux-mips@linux-mips.org, stable@vger.kernel.org Subject: Re: [PATCH 4/9] MIPS: Send SIGILL for BPOSGE32 in `__compute_return_epc_for_insn' Message-ID: <20170608131141.GB8108@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Tue, Jun 06, 2017 at 12:17:05AM +0100, Maciej W. Rozycki wrote: > Fix commit e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") and > send SIGILL rather than SIGBUS whenever an unimplemented BPOSGE32 DSP > ASE instruction has been encountered in `__compute_return_epc_for_insn' > as our Reserved Instruction exception handler would in response to an > attempt to actually execute the instruction. Sending SIGBUS only makes > sense for the unaligned PC case, since moved to `__compute_return_epc'. > Adjust function documentation accordingly, correct formatting and use > `pr_info' rather than `printk' as the other exit path already does. > > Cc: stable@vger.kernel.org # 2.6.14+ > Fixes: e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") > Signed-off-by: Maciej W. Rozycki > --- > I hope folding the formatting fix and `pr_info' update with the base > change is fine given that they all apply to the same code line. Ok, but ... > sigill_dsp: > - printk("%s: DSP branch but not DSP ASE - sending SIGBUS.\n", current->comm); > - force_sig(SIGBUS, current); > + pr_info("%s: DSP branch but not DSP ASE - sending SIGILL.\n", > + current->comm); Shouldn't this then maybe be a pr_debug then? With pr_info the right kind of program can produce lots of useless clutter. Ralf