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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,URIBL_BLOCKED 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 AE910C04AB6 for ; Tue, 28 May 2019 11:42:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7D3532070D for ; Tue, 28 May 2019 11:42:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rvS/8Vs+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=agner.ch header.i=@agner.ch header.b="vCtJIP83" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D3532070D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=agner.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To: Subject:To:From:Date:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tNZuz9FJBxU07y2rvO6dkqoF0zxIl86/o1mfPXnqSoQ=; b=rvS/8Vs+w7ThqK d0S7iHlL7/MPaBabHQHBOdi20tLEAdim1zmn/ADeGXLhMUCpp+gouvo80QlBJ3b98OZm6RKuJMIrs g8YA4C6Y1dUWHgyp9lBh1FGAxrqwLump8wKYN3J5srHgteJOAsk3THGZE76VF3eEthqjrf+TczYsX nNQ3014GiaUNE2kQ20Oy+SMHF2cdpVGHHn5f+hI8olJy9Y1zjzlfbkj5e7EC/z1Oi60K1ITDhbfhY ZKr8BbEbzRFQiXwsMpS3WOoZWOc0LbNQbEFDVTR200kvXH7LUQZIvgOm705wItfxLVRTlCIb8hSrz iFXe1RvR+zrPaUT/VDfw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hVaUL-0000kW-RZ; Tue, 28 May 2019 11:41:53 +0000 Received: from mail.kmu-office.ch ([2a02:418:6a02::a2]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hVaUI-0000jx-6H for linux-arm-kernel@lists.infradead.org; Tue, 28 May 2019 11:41:51 +0000 Received: from webmail.kmu-office.ch (unknown [IPv6:2a02:418:6a02::a3]) by mail.kmu-office.ch (Postfix) with ESMTPSA id D719F5C2152; Tue, 28 May 2019 13:41:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agner.ch; s=dkim; t=1559043707; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZAWnyww2Ad3RGDOl/TiNiAw73Skz4lrvgbBinry4WDU=; b=vCtJIP83uk0FYwnUivViDQFoG6xwRgDSE+/kWkrzQlUe6EQnqYNmqNNUOwi0nhxoelEzXP yey1EApalqiylfSqX4WBkdXsB7OV+SCmuqoDb+YKfcXFmg0qV9JC0T5Exbnw1Vae50MLGX kCfOigkAipI2uZGAX2DELIG2tNHg3KY= MIME-Version: 1.0 Date: Tue, 28 May 2019 13:41:47 +0200 From: Stefan Agner To: Arnd Bergmann Subject: Re: Linker error `.exit.text' referenced in section `.alt.smp.init' In-Reply-To: References: <2072571511d5c77bb9ac53168e44e90b@agner.ch> Message-ID: X-Sender: stefan@agner.ch User-Agent: Roundcube Webmail/1.3.7 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190528_044150_380723_47428B45 X-CRM114-Status: GOOD ( 17.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Masami Hiramatsu , Linux ARM , Russell King - ARM Linux Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 28.05.2019 09:32, Arnd Bergmann wrote: > On Tue, May 28, 2019 at 9:12 AM Stefan Agner wrote: >> >> Hi, >> >> Cross compiling Linux v5.2-rc2 with CONFIG_DNS_RESOLVER=y using gcc 8.2 >> I noticed the following build error: >> >> ... >> GEN .version >> CHK include/generated/compile.h >> UPD include/generated/compile.h >> CC init/version.o >> AR init/built-in.a >> LD vmlinux.o >> MODPOST vmlinux.o >> MODINFO modules.builtin.modinfo >> `.exit.text' referenced in section `.alt.smp.init' of >> net/dns_resolver/dns_key.o: defined in discarded section `.exit.text' of >> net/dns_resolver/dns_key.o >> >> make: *** [Makefile:1052: vmlinux] Error 1 >> >> It seems that Masami noticed this a while back: >> https://lore.kernel.org/lkml/20180911231012.fdc45840f3d91860daa2e180@kernel.org/T/#u >> >> Anybody else seen this? >> >> When I remove put_cred in exit_dns_resolver the kernel links fine... > > I've seen two or thre of these in total. This only happens on 32-bit ARM > when a function that needs SMP patching gets inlined into an __exit > function. In this case, it's the atomic_dec_and_test(). > > The last one I fixed was https://lkml.org/lkml/2019/4/15/625 > I think I've seen the one in the dns_resolver before but couldn't > reproduce it recently. > > I used to have a patch that completely avoided dropping .exit when > SMP patching was active, but I think we can fix them up as they happen, > as I have built thousands of randconfig kernels without hitting this. Yeah dropping .exit seems rather harsh. > > The easiestwork around here would be to drop the __exit annotation > and add a comment. We could also move put_cred out-of-line and > make it non-__exit, or add an extern wrapper for it. Hm, both seem not very appealing to me. I think I'd rather prefer an extern wrapper. Is this an actual problem? As far as I understand that fixup happens very early and only once during boot, so by the time the kernel drops those .exit.text fixup has been done long time ago... Is this maybe a case for __ref (defined in include/linux/init.h)? Or could we have the section marked init/exit such that this does not trigger the error? -- Stefan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel