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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 A0FB8C33CB3 for ; Tue, 28 Jan 2020 15:00:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 78C2C2467E for ; Tue, 28 Jan 2020 15:00:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZaSSm2k0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726859AbgA1PAc (ORCPT ); Tue, 28 Jan 2020 10:00:32 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:37927 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726610AbgA1PAb (ORCPT ); Tue, 28 Jan 2020 10:00:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580223630; 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=UciBCe0URT2sDPatGmTOte5M9IpV1BmQHRNEHQ3YlSQ=; b=ZaSSm2k0MNjHcI17wmW8T51Ylq+mJqNksA2MPVfg2FVsBd2cezMDVhxnoNLIIyX/XxZEWf I0U04zwY4tEkfH0L/d038TQN96wVEExDcfgVMbzUaZKhZ/EY9zNEBcER8MSGn5W771E+6G nDBDQyM4U1RAd4rA3C+9dLksF7NpNsA= 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-165-eqD_xNQHPAmiQzXLd2hz_g-1; Tue, 28 Jan 2020 10:00:28 -0500 X-MC-Unique: eqD_xNQHPAmiQzXLd2hz_g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1236513F7; Tue, 28 Jan 2020 15:00:25 +0000 (UTC) Received: from treble (ovpn-124-151.rdu2.redhat.com [10.10.124.151]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7904F1000337; Tue, 28 Jan 2020 15:00:16 +0000 (UTC) Date: Tue, 28 Jan 2020 09:00:14 -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: <20200128150014.juaxfgivneiv6lje@treble> References: <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> <20200122214239.ivnebi7hiabi5tbs@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 28, 2020 at 10:28:07AM +0100, Miroslav Benes wrote: > I don't think we have something special at SUSE not generally available... > > ...and I don't think it is really important to discuss that and replying > to the above, because there is a legitimate use case which relies on the > flag. We decided to support different use cases right at the beginning. > > I understand it currently complicates things for objtool, but objtool is > sensitive to GCC code generation by definition. "Issues" appear with every > new GCC version. I see no difference here and luckily it is not so > difficult to fix it. > > I am happy to help with acting on those objtool warning reports you > mentioned in the other email. Just Cc me where appropriate. We will take a > look. As I said, the objtool warnings aren't even the main issue. There are N users[*] of CONFIG_LIVEPATCH, where N is perhaps dozens. For N-1 users, they have to suffer ALL the drawbacks, with NONE of the benefits. And, even if they wanted those benefits, they have no idea how to get them because the patch creation process isn't documented. And, there's no direct upstream usage of the flag, i.e. the only user does so in a distro which can easily modify KCFLAGS in the spec file. As best as I can tell, these are facts, which you seem to keep glossing over. Did I get any of the facts wrong? [*] The term 'user' describes the creator/distributor of the live patches. -- Josh