Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp3231558rwl; Fri, 6 Jan 2023 18:26:49 -0800 (PST) X-Google-Smtp-Source: AMrXdXsWDXZHgnWKrjx0rOT5qBhopze0Vqoq2NezakYLEV7bdb2n9HnrRKa9Iuxz1+ep6SBW2y1T X-Received: by 2002:a17:902:7c90:b0:18f:6b2b:e88d with SMTP id y16-20020a1709027c9000b0018f6b2be88dmr57867722pll.36.1673058408975; Fri, 06 Jan 2023 18:26:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673058408; cv=none; d=google.com; s=arc-20160816; b=dSW/r4/0SePfD+hkt3plIC3B22D44kbmJ6Z1AUsTDkbLzK3z51jo2/xzbAEKNu6cR9 y800N6/jowTqG6PAQgTEqsrSYjm+8jxaCmZpx2zf92MwqiK1BYQo6u57G7CEJPaKF++h x6m0lcpCrjQMfQ3d8wNhaG70mwRD0B5CcJTpACIIIVfQNghQ1hH092o2Q9BDI5o09DX9 tfSY5kj+tIkbdXv8fY04GVIU6F6cDemWxLmG8y0u35oOIxl+4YzEFrTDeWQCSA6UsVGI Gf+oB00+urC9PY7ZwQgOZG6dVBDMqyYh+WT3bSIPDJUMJufWjzfsfs4gTVrLpCTA1bih 68Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=e/csDc1cGEKZcGyvYjvXUpRSAoHDEDFmMh2ZLrU3AOI=; b=cNVswPQcRF/vxh+K3j89N0kD1pA88ejVe5+g0ghtWtypr9GeoDd8mGMZtmFNf6LNVv D4yCoC+sC8dHC1kuPRV4kosqQbebyTlzmxUdQwzNsi0KboovviCUsQYtPkOGgmRaD0P3 7r2ZiWOIJmsjVgr4I/mx4LNUVtJl3FfjsopWXan8GK85GwD1SOw0Yw60B0RYlxKTHu7b vDRcjF6lVgt99epsyi7wgHq1M3TOyF1Yk7bVeqUGdww5rHyIjBEaJvE5bQeyd/RiFlxQ LszFg067QtLZ52dToAvv4jq8sI/ap+rVlUdvmVhF7dZGCqp4WumpsuNDKzuKyKjfMCN+ qIPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o21-20020a170903301500b0017486813f81si2275495pla.528.2023.01.06.18.26.39; Fri, 06 Jan 2023 18:26:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236590AbjAGCK0 (ORCPT + 56 others); Fri, 6 Jan 2023 21:10:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231187AbjAGCKX (ORCPT ); Fri, 6 Jan 2023 21:10:23 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3E5287F20 for ; Fri, 6 Jan 2023 18:10:20 -0800 (PST) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NpkCH3kZQzRqvs; Sat, 7 Jan 2023 10:08:43 +0800 (CST) Received: from [10.174.151.185] (10.174.151.185) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 7 Jan 2023 10:10:18 +0800 Subject: Re: [BUG Report] undefined reference to `convert_to_fxsr' To: Borislav Petkov CC: "x86@kernel.org" , linux-kernel , "tglx@linutronix.de" , "mingo@redhat.com" , Dave Hansen , References: <50aa72a7-043d-8091-78de-458cbcc6c356@huawei.com> <23e2907c-5188-5ac6-3db8-1c5a12120bf2@huawei.com> <64fe1be4-954f-fe6f-44f0-59b572548663@huawei.com> From: Miaohe Lin Message-ID: Date: Sat, 7 Jan 2023 10:10:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.151.185] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/1/6 7:14, Borislav Petkov wrote: > On Tue, Jan 03, 2023 at 11:05:01AM +0800, Miaohe Lin wrote: >> Yes, it still reproduces in my working server. It might be the problem of gcc >> version. > > What is that compiler you're using? Where did you get the package from? Does it > have some out-of-tree patches in it? My compiler is gcc 7.3.0: linux-rtfsc:/home/linmiaohe/linux # gcc --version gcc (GCC) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. linux-rtfsc:/home/linmiaohe/linux # And I cloned the code from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. It's a clean git repo without applying any out-of-tree patch to it. > >> I think it's because convert_to_fxsr() is only defined when CONFIG_X86_32 or >> CONFIG_IA32_EMULATION is enabled. > > No, convert_to_fxsr() is part of arch/x86/kernel/fpu/regset.c which is built-in > unconditionally. > > What happens is this here: > > bool fpu__restore_sig(void __user *buf, int ia32_frame) > > ... > > } else { > success = __fpu_restore_sig(buf, buf_fx, ia32_fxstate); > } > > That ia32_fxstate is false because > > ia32_frame &= (IS_ENABLED(CONFIG_X86_32) || > IS_ENABLED(CONFIG_IA32_EMULATION)); > > > neither of those config items are set... > > /* > * Only FXSR enabled systems need the FX state quirk. > * FRSTOR does not need it and can use the fast path. > */ > if (ia32_frame && use_fxsr()) { > buf_fx = buf + sizeof(struct fregs_state); > size += sizeof(struct fregs_state); > ia32_fxstate = true; > ^^^^^^^^^^^^^^^^^^^ > > ... so this doesn't happen. > > } > > Then, in __fpu_restore_sig() you have: > > if (likely(!ia32_fxstate)) { > /* Restore the FPU registers directly from user memory. */ > return restore_fpregs_from_user(buf_fx, user_xfeatures, fx_only, > state_size); > } > > and since ia32_fxstate is false, we return here, the compiler sees that > everything behind that code is dead code and eliminates it. Many thanks for your explanation! It's really helpful. I checked generated asm code and I found calling to convert_to_fxsr is not eliminated as expected: objdump -S arch/x86/kernel/fpu/signal.o 3fc: e9 00 00 00 00 jmpq 401 <__fpu_restore_sig+0x401> fpregs->xsave.header.xfeatures |= XFEATURE_MASK_FPSSE; 401: 48 83 8d 40 02 00 00 orq $0x3,0x240(%rbp) 408: 03 convert_to_fxsr(&fpregs->fxsave, &env); ^^^^^^^^^^^^^^^ 409: 48 8d 74 24 10 lea 0x10(%rsp),%rsi linux-rtfsc:/home/linmiaohe/linux # objdump -S arch/x86/kernel/fpu/signal.o | grep convert_to_fxsr convert_to_fxsr(&fpregs->fxsave, &env); linux-rtfsc:/home/linmiaohe/linux # And if I compile the code with below patch, convert_to_fxsr is eliminated: linux-rtfsc:/home/linmiaohe/linux # objdump -S arch/x86/kernel/fpu/signal.o | grep convert_to_fxsr linux-rtfsc:/home/linmiaohe/linux # diff --git a/arch/x86/include/asm/fpu/signal.h b/arch/x86/include/asm/fpu/signal.h index 611fa41711af..77ea052a8967 100644 --- a/arch/x86/include/asm/fpu/signal.h +++ b/arch/x86/include/asm/fpu/signal.h @@ -20,8 +20,14 @@ extern void convert_from_fxsr(struct user_i387_ia32_struct *env, struct task_struct *tsk); +#if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION extern void convert_to_fxsr(struct fxregs_state *fxsave, const struct user_i387_ia32_struct *env); +#else +static inline void convert_to_fxsr(struct fxregs_state *fxsave, + const struct user_i387_ia32_struct *env) +{} +#endif unsigned long fpu__alloc_mathframe(unsigned long sp, int ia32_frame, -- 2.27.0 > > Your compiler doesn't, apparently. > > It does remove it from regset.c, though, as it sees it is an unused function, > which leads to this undefined reference. > > So it looks like a funky compiler to me... It seems another issue with old compiler. Sigh... :( Thanks, Miaohe Lin