From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F33DC54FCB for ; Fri, 24 Apr 2020 13:14:40 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9908720776 for ; Fri, 24 Apr 2020 13:14:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9908720776 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 497vld0Cy0zDr7x for ; Fri, 24 Apr 2020 23:14:37 +1000 (AEST) Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 497vh24J8SzDr76 for ; Fri, 24 Apr 2020 23:11:30 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=goodmis.org Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) by bilbo.ozlabs.org (Postfix) with ESMTP id 497vh123j9z8sWS for ; Fri, 24 Apr 2020 23:11:29 +1000 (AEST) Received: by ozlabs.org (Postfix) id 497vh11BpDz9sT0; Fri, 24 Apr 2020 23:11:29 +1000 (AEST) Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=srs0=19w6=6i=goodmis.org=rostedt@kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=goodmis.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 497vgy5DLgz9sSM for ; Fri, 24 Apr 2020 23:11:26 +1000 (AEST) Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 47E6920728; Fri, 24 Apr 2020 13:11:23 +0000 (UTC) Date: Fri, 24 Apr 2020 09:11:21 -0400 From: Steven Rostedt To: Michael Ellerman Subject: Re: [RFC PATCH 2/3] powerpc/lib: Initialize a temporary mm for code patching Message-ID: <20200424091121.6999a428@gandalf.local.home> In-Reply-To: <87mu7bhqu1.fsf@mpe.ellerman.id.au> References: <20200323045205.20314-1-cmr@informatik.wtf> <20200323045205.20314-3-cmr@informatik.wtf> <1782990079.111623.1585624792778@privateemail.com> <8ff6d279-fdd9-4e4d-b4e0-f5c5cba480a4@c-s.fr> <87mu7bhqu1.fsf@mpe.ellerman.id.au> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev@ozlabs.org, Christopher M Riedl Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, 17 Apr 2020 10:57:10 +1000 Michael Ellerman wrote: > >>> Does it needs to be a BUG_ON() ? Can't we fail gracefully with just a > >>> WARN_ON ? > >>> > >> > >> I'm not sure what failing gracefully means here? The main reason this could > >> fail is if there is not enough memory to allocate the patching_mm. The > >> previous implementation had this justification for BUG_ON(): > > > > But the system can continue running just fine after this failure. > > Only the things that make use of code patching will fail (ftrace, kgdb, ...) > > That's probably true of ftrace, but we can't fail patching for jump > labels (static keys). > > See: > > void arch_jump_label_transform(struct jump_entry *entry, > enum jump_label_type type) > { > u32 *addr = (u32 *)(unsigned long)entry->code; > > if (type == JUMP_LABEL_JMP) > patch_branch(addr, entry->target, 0); > else > patch_instruction(addr, PPC_INST_NOP); > } I would still error on a WARN_ON() as a lot of static keys should still work if they don't get switched over. If a user is concerned about something like this, they can always set panic_on_warn. -- Steve