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_1 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 A44FBC33C9E for ; Thu, 30 Jan 2020 09:53:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7FBFD2082E for ; Thu, 30 Jan 2020 09:53:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726930AbgA3Jxv (ORCPT ); Thu, 30 Jan 2020 04:53:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:33068 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726922AbgA3Jxv (ORCPT ); Thu, 30 Jan 2020 04:53:51 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D4B6FAC4B; Thu, 30 Jan 2020 09:53:47 +0000 (UTC) Date: Thu, 30 Jan 2020 10:53:46 +0100 From: Petr Mladek To: Josh Poimboeuf Cc: Miroslav Benes , Peter Zijlstra , Steven Rostedt , Joe Lawrence , Jessica Yu , x86@kernel.org, linux-kernel@vger.kernel.org, mhiramat@kernel.org, bristot@redhat.com, jbaron@akamai.com, torvalds@linux-foundation.org, tglx@linutronix.de, mingo@kernel.org, namit@vmware.com, hpa@zytor.com, luto@kernel.org, ard.biesheuvel@linaro.org, live-patching@vger.kernel.org, Randy Dunlap , nstange@suse.de Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke() Message-ID: <20200130095346.6buhb3reehijbamz@pathway.suse.cz> References: <20200121161045.dhihqibnpyrk2lsu@treble> <20200122214239.ivnebi7hiabi5tbs@treble> <20200128150014.juaxfgivneiv6lje@treble> <20200128154046.trkpkdaz7qeovhii@pathway.suse.cz> <20200128170254.igb72ib5n7lvn3ds@treble> <20200129155951.qvf3tjsv2qvswciw@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200129155951.qvf3tjsv2qvswciw@treble> User-Agent: NeoMutt/20170912 (1.9.0) Sender: live-patching-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: live-patching@vger.kernel.org On Wed 2020-01-29 09:59:51, Josh Poimboeuf wrote: > In retrospect, the prerequisites for merging it should have been: OK, let me do one more move in this game. > 1) Document how source-based patches can be safely generated; I agree that the information are really scattered over many files in Documentation/livepatch/. Anyway, there is a lot of useful hints: + structure and behavior of the livepatch module, link to a sample, limitations, are described in livepatch.rst + many other catches are described in the other files: callbacks, module-elf-fomat, cumulative-patches, system-state. Yes, it would be great to have a better structure, more information. But do not get me wrong. Anyone, Joe definitely, is able to create livepatch from sources by this information. Anyone could play with it, ask questions, and improve the documentation. Better documentation would help but it is not a blocker, definitely. > 2) Fix the scheduler performance regression; The optimizations are disabled only when livepatching is enabled. I would consider this as a prize for the feature. There are many things like this. As it was said. It was 1-3 percent in scheduler microbenchmark. It would make sense to fix it only when it causes such a regression in real workloads. Do you have any? > 3) Figure out if there are any other regressions by detecting which > function interfaces are affected by the flag and seeing if they're > hot path; IMHO, benchmarks are much more effective and we spent non-trivial resources when running them. > 4) Provide a way for the N-1 users to opt-out AFAIK, the only prize is the 1-3 percent scheduler performance degradation. If you really do not want to pay this prize, let's make it configurable. But the option is definitely needed when source livepatches are used. There is no other reasonable way to detect and workaround these problems. For this, it has to be in upstream kernel. It is in line with the effort to make livepatching less and less error prone. And please, let's stop playing this multi-user games. There is at least one known user of source based livepatches. By coincidence, it is also a big contributor to this subsystem. Adding an extra option into CFLAGS is quite error prone. You can imagine how complicated is a kernel rpm spec file for more kernel flavors. The only safe way is to have the optimization tight with the CONFIG option in kernel sources. > 5) Fix the objtool warnings (or is it a GCC bug) Nobody was aware of them. I wonder if they even existed at that time. We have a simple fix now. Let's continue in the thread started by Jikos if we could get a better solution. > 6) Make -flive-patching compatible with LTO (or at least acknowledge > that it should and will be done soon) Is LTO officially supported upstream? Are all patches, features tested for LTO compactibility? Is there any simple way to build and run LTO kernel? > 7) At least make it build- or runtime-incompatible with Clang-built > kernels to prevent people from assuming it's safe. Same questions as for LTO. > If you don't want to revert the patch, then address my concerns instead > of minimizing and deflecting at every opportunity. I would really like to keep focusing on realistic problems and realistic solutions: + make the optimization configurable if you resist on it + fix the objtool warnings Anything else is out of scope of this thread from my POV. Best Regards, Petr