Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2782688imu; Mon, 17 Dec 2018 07:45:53 -0800 (PST) X-Google-Smtp-Source: AFSGD/ULKBZS60Ce/fhyVhzqjsZccLMFun36v1d1ntF58QvKx/rdPLfVKjDabKr1AW1ElgcO3yuV X-Received: by 2002:a17:902:8a95:: with SMTP id p21mr13424196plo.183.1545061552996; Mon, 17 Dec 2018 07:45:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545061552; cv=none; d=google.com; s=arc-20160816; b=r6k0VPOxgRVsYpw0GD60+e4RAsuSO+XE5OaA2g87MUSBJKuV+0M3PO5X3G/qsZBwfG 5kcZTdu0tljHQMoTTlyXuxG7ZqjOcGsD/pZLMTOPbIvs8rZB5lKEzn/DbB4N2j3jEQax dAx3nL9IZHL7RUUlXObDlWvfPic0vMem6n9sSyWe/wGV+DukmoBTsMploaxMA1JP7AC7 XPcC+Q5Tz8Zb7A3VzAuyTuK9dzCEHD5tKTsy7fNhfMcPtBKgTZ75ebhH9UCkB2DqHmFi ZBubzR8drE3bWglul5tYhY1/XYwVIiqNSUFYOxHvVdCClVx89CAI9ef/09GIGr7TiYG/ 7uyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=odHYTVF+jzSBREH3ixO3bdW8tVNlXLl2NJsxkrfJ4TM=; b=BKO5ecAcCjC5X060XQ6OhxdZ1EBZ4AfZTzSJCv3RSZkdB51ftlLteMehEk0dpKf1V0 ekZHDWM0MuAU6oY1CDW1aBwgQJab5YbXCtVHCuwilr8KjxfKUV3t+p3dqIT2n3DlV2Es YuXtOMUjV7ih+DJzXw30iMhGw4Ff0zP5tTTj8tbjLf1awNNTlE6ifPUL2M/kFOGgqKrZ dlHmGq7aRfH/xwoQR5MklkX3ydnS9w66hg6DUskgp3qOEozIL/uyzZDlT69LKkFSaNOt 6zSAjW++c0RvtdRdN+uVZt2NaOpyi2r+2IHSK2lqHMqe1+spYdPQ/0rXWXQWRlT0vPre l2TQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9si11081119pgm.112.2018.12.17.07.45.36; Mon, 17 Dec 2018 07:45:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387698AbeLQPoj (ORCPT + 99 others); Mon, 17 Dec 2018 10:44:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40190 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387434AbeLQPoi (ORCPT ); Mon, 17 Dec 2018 10:44:38 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0325588E48; Mon, 17 Dec 2018 15:44:38 +0000 (UTC) Received: from jlaw-desktop.bos.csb (dhcp-17-208.bos.redhat.com [10.18.17.208]) by smtp.corp.redhat.com (Postfix) with ESMTP id E30D06012B; Mon, 17 Dec 2018 15:44:36 +0000 (UTC) Subject: Re: [PATCH V2] livepatch: fix non-static warnings To: Miroslav Benes , Nicholas Mc Guire Cc: Josh Poimboeuf , Jessica Yu , Jiri Kosina , Petr Mladek , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <1544965657-26804-1-git-send-email-hofrat@osadl.org> From: Joe Lawrence Organization: Red Hat Message-ID: <20ef1d3a-2916-ce00-2938-3397746efac9@redhat.com> Date: Mon, 17 Dec 2018 10:44:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 17 Dec 2018 15:44:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/17/2018 07:03 AM, Miroslav Benes wrote: > Hi, > > I'm sorry for being late to the party. > > On Sun, 16 Dec 2018, Nicholas Mc Guire wrote: > >> Sparse reported warnings about non-static symbols. For the variables >> a simple static attribute is fine - for those symbols referenced by >> livepatch via klp_func the symbol-names must be unmodified in the >> symbol table - to resolve this the __noclone attribute is used >> for the shared statically declared functions. >> >> Signed-off-by: Nicholas Mc Guire >> Suggested-by: Joe Lawrence >> Link: https://lkml.org/lkml/2018/12/13/827 > > A nit, but I'd reorder the tags. Link, Suggested-by:, Signed-off-by:. Also > it would be great if you used https://lkml.kernel.org/r/${Msg-ID} > redirection. > >> --- >> >> V2: not all static functions shared need to carry the __noclone >> attribute only those that need to be resolved at runtime by >> livepatch - so drop the unnecessary __noclone attributes as >> well as the Note on __noclone as suggested by Joe Lawrence >> - thanks ! > > I talked to Martin Jambor (GCC) and he suggested __attribute__((used)). It > should be better than __noclone, which was reportedly implemented only for > testing purposes (which is why it does not imply noinline, although > inlining internally uses cloning). Newer gcc also has "noipa" attribute, > but "used" would definitely be safe. > > Sorry for not responding earlier. > Hi Miroslav, Thanks for following up on this. "noipa" would have been nice to use, but as you say, is a newer gcc attribute. Regarding "used" vs. "noclone", can we assume that "used" implies that the function name remains unchanged? The gcc online doc [1] speaks about ensuring that "code must be emitted". This reads like it solves our static-function-not-directly-referenced problem, but isn't explicit about naming. used This attribute, attached to a function, means that code must be emitted for the function even if it appears that the function is not referenced. This is useful, for example, when the function is referenced only in inline assembly. Perhaps it's equivalent to a "I want to keep this function and leave it's symbols alone" attribute. FWIW, I modified Nicholas' change on my box to use "used" and it worked as Martin advertised, so it would get my Ack. I'm just being picky about its documentation and how we should note its usage in the v3 patch. Think that s/__noclone/used/g of the v2 commit message would be sufficient? [1] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noclone-function-attribute Thanks, -- Joe