Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757940AbdCUPc6 (ORCPT ); Tue, 21 Mar 2017 11:32:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47082 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757862AbdCUPc4 (ORCPT ); Tue, 21 Mar 2017 11:32:56 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D9BB781252 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D9BB781252 Date: Tue, 21 Mar 2017 10:32:52 -0500 From: Josh Poimboeuf To: Peter Zijlstra Cc: mingo@kernel.org, tglx@linutronix.de, hpa@zytor.com, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, arjan@linux.intel.com, bp@alien8.de, richard.weinberger@gmail.com Subject: Re: [PATCH 1/5] x86: Implement __WARN using UD0 Message-ID: <20170321153252.ssmrumchartuvy5m@treble> References: <20170317211918.393791494@infradead.org> <20170317212350.828368979@infradead.org> <20170321140340.urru2lmjko6txwl5@treble> <20170321151446.GV3093@worktop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170321151446.GV3093@worktop> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 21 Mar 2017 15:32:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1586 Lines: 47 On Tue, Mar 21, 2017 at 04:14:46PM +0100, Peter Zijlstra wrote: > > to WARN, they should probably be renamed to describe their new purpose, > > like: > > > > "report_bug" -> "report_bug_or_warning" > > "fixup_bug" -> "fixup_bug_or_warning" > > > > On a related note, if warn and bug are going to continue to use two > > separate ud instructions for the foreseeable future, report_bug() could > > be cleaned up a bit: e.g., for a ud0 instruction, it doesn't make sense > > to call find_bug(). > > I'm sure you'll break $random arch if you go futz with that. Also, I > think you mean UD2, since that's BUG. We actually need the bug_entry for > WARNs (aka UD0). > > Also, you're now optimizing the BUG() code; I don't think anybody cares > about saving a few cycles there. It shouldn't happen in the first place. My thinking was to make report_bug() a little less obtuse, but yeah, that would break other arches, so never mind... > > > +static int fixup_bug(struct pt_regs *regs, int trapnr) > > > +{ > > > + if (trapnr != X86_TRAP_UD) > > > + return 0; > > > + > > > + switch (report_bug(regs->ip, regs)) { > > > + case BUG_TRAP_TYPE_NONE: > > > + case BUG_TRAP_TYPE_BUG: > > > + break; > > > + > > > + case BUG_TRAP_TYPE_WARN: > > > + regs->ip += 2; > > > + return 1; > > > > For self-documentation purposes, maybe use a define for the length of > > the ud0 instruction? > > Well, UD0 and UD2 really. LENGTH_UD0_OR_UD2 is a bit of a fail, name > wise. Why UD2? Warnings are UD0-only, no? What about UD0_LEN? Or at least a comment would be helpful I think. -- Josh