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=-5.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 8D870C32771 for ; Wed, 22 Jan 2020 21:42:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4F2782465A for ; Wed, 22 Jan 2020 21:42:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PPCrmiWC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729152AbgAVVmz (ORCPT ); Wed, 22 Jan 2020 16:42:55 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:48549 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725943AbgAVVmz (ORCPT ); Wed, 22 Jan 2020 16:42:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579729373; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1gFcEZJIvMTM55lub5PAcGjASB5nWcvJKHPzUNKZDoA=; b=PPCrmiWCvfrjFqBcEAFSNgJNCNm5yutIyhtsoeqPcunEVjGQwkx8Gqo48aLQWwXtVZKNjE Tb2ZQF3RfXyqVhCumf3MvP/MNOXYk1l0hZ9n9CYaTFLlvArtEj8iDxESUZuYcb7VM5SngW 6b7Gnd4qklA5e42/g2v39adz5DVNkKw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-46-vfrKVyS_PUyEIk0FIgm2lg-1; Wed, 22 Jan 2020 16:42:51 -0500 X-MC-Unique: vfrKVyS_PUyEIk0FIgm2lg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C11F9107ACC4; Wed, 22 Jan 2020 21:42:48 +0000 (UTC) Received: from treble (ovpn-122-154.rdu2.redhat.com [10.10.122.154]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6DE9A88893; Wed, 22 Jan 2020 21:42:41 +0000 (UTC) Date: Wed, 22 Jan 2020 15:42:39 -0600 From: Josh Poimboeuf To: Miroslav Benes 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() Message-ID: <20200122214239.ivnebi7hiabi5tbs@treble> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 22, 2020 at 11:09:56AM +0100, Miroslav Benes wrote: > > > > > 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. I'm confused about why you think upstream needs it. Is all the tooling available somewhere? Is there documentation available which describes how to build patches using that method from start to finish? Are there actual users other than SUSE? BTW, kpatch-build has a *lot* of users other than RHEL. All its tooling and documentation are available on Github. > It is perfectly fine to prepare live patches just from the source code > using upstream live patching infrastructure. Do you mean the dangerous method used by the livepatch sample code which completely ignores interprocedural optimizations? I wouldn't call that perfectly fine. > 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. Who exactly is "everyone using upstream"? >From what I can tell, kpatch-build is the only known way (to those outside of SUSE) to make safe patches for an upstream kernel. And it doesn't need this flag and the problems associated with it: performance, LTO incompatibility, clang incompatibility (I think?), the GCC dead code issue. -- Josh