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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable 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 B2D24C33CAF for ; Wed, 22 Jan 2020 10:10:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8A9862467A for ; Wed, 22 Jan 2020 10:10:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729420AbgAVKKC (ORCPT ); Wed, 22 Jan 2020 05:10:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:55116 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725911AbgAVKKC (ORCPT ); Wed, 22 Jan 2020 05:10:02 -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 BB8DCB2C0; Wed, 22 Jan 2020 10:09:59 +0000 (UTC) Date: Wed, 22 Jan 2020 11:09:56 +0100 (CET) From: Miroslav Benes To: Josh Poimboeuf cc: 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 Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke() In-Reply-To: <20200121161045.dhihqibnpyrk2lsu@treble> Message-ID: References: <20191015135634.GK2328@hirez.programming.kicks-ass.net> <88bab814-ea24-ece9-2bc0-7a1e10a62f12@redhat.com> <20191015153120.GA21580@linux-8ccs> <7e9c7dd1-809e-f130-26a3-3d3328477437@redhat.com> <20191015182705.1aeec284@gandalf.local.home> <20191016074217.GL2328@hirez.programming.kicks-ass.net> <20191021150549.bitgqifqk2tbd3aj@treble> <20200120165039.6hohicj5o52gdghu@treble> <20200121161045.dhihqibnpyrk2lsu@treble> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > At this point, I only see downsides of -flive-patching, at least until > > > we actually have real upstream code which needs it. > > > > Can you explain this? The option makes GCC to avoid optimizations which > > are difficult to detect and would make live patching unsafe. I consider it > > useful as it is, so if you shared the other downsides and what you meant > > by real upstream code, we could discuss it. > > Only SLES needs it right? Why inflict it on other livepatch users? By > "real upstream code" I mean there's no (documented) way to create live > patches using the method which relies on this flag. So I don't see any > upstream benefits for having it enabled. I'd put it differently. SLES and upstream need it, RHEL does not need it. Or anyone using kpatch-build. It is perfectly fine to prepare live patches just from the source code using upstream live patching infrastructure. After all, SLES is nothing else than upstream here. We were creating live patches manually for quite a long time and only recently we have been using Nicolai's klp-ccp automation (https://github.com/SUSE/klp-ccp). So, everyone using upstream directly relies on the flag, which seems to be a clear benefit to me. Reverting the patch would be a step back. Also I think we're moving in the right direction to make the life of upstream user easier with a proposal of klp-ccp and Petr's patch set to split live patch modules. It is a path from inconvenient to comfortable and not from impossible to possible. Miroslav