From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162000AbeBPRcE (ORCPT ); Fri, 16 Feb 2018 12:32:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:39162 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161052AbeBPRcD (ORCPT ); Fri, 16 Feb 2018 12:32:03 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E177217CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Fri, 16 Feb 2018 12:31:58 -0500 From: Steven Rostedt To: Josh Poimboeuf Cc: Jason Baron , x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Linus Torvalds , Peter Zijlstra , Borislav Petkov , Juergen Gross , Tejun Heo Subject: Re: [PATCH 1/3] jump_label: Warn on failed jump_label patch Message-ID: <20180216123158.2ab0c159@gandalf.local.home> In-Reply-To: <20180215223558.poirr2e6wxs2jhzb@treble> References: <20180214120112.43821b5e@gandalf.local.home> <20180214173407.guhytdurv4pmhzvk@treble> <20180214124034.13d7d833@gandalf.local.home> <20180214211707.hivwfwemghgy62mh@treble> <20180215223558.poirr2e6wxs2jhzb@treble> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 15 Feb 2018 16:35:58 -0600 Josh Poimboeuf wrote: > > Interesting idea. The static key's entries (i.e. tracepoint sites) are > > in a static array. Maybe we could rewrite the affected arrays when init > > memory is freed. I'm not sure whether that would be overkill though. I > > can tinker with it and see how it compares to the current solution. > > It turns out that something like this is already done for module init > code. It doesn't *remove* the entry, but it does disable it by setting > entry->code to zero. I'll just do the same thing right before initmem > is freed. Yes, I was actually going to mention to do it like the module code does. Thanks! -- Steve