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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FA19C4829A for ; Tue, 13 Feb 2024 20:44:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DAAE8D0013; Tue, 13 Feb 2024 15:44:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 963908D000E; Tue, 13 Feb 2024 15:44:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82A978D0013; Tue, 13 Feb 2024 15:44:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6BC038D000E for ; Tue, 13 Feb 2024 15:44:13 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3DD511C1642 for ; Tue, 13 Feb 2024 20:44:13 +0000 (UTC) X-FDA: 81787957986.03.2933263 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf20.hostedemail.com (Postfix) with ESMTP id 829A11C0022 for ; Tue, 13 Feb 2024 20:44:10 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=n6tQqiQh; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf20.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707857050; h=from:from:sender: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:dkim-signature; bh=wlocdpaTix27ODpbAmkE2apD6CxEfayqvsXg3/kH3xs=; b=THHll/7k7fajCN+ztqd6Kcrg4vN01pbkQqH8COHZsHHls+GBXFQ4sY9pPal7Bm71OUGA7a /QTY+pkef2oYyhCVvwAZ5bLKqMmedzusV+iNINSRGCHOmJUHQ2tow6TCZhZeT47CNQ7d2l TcgGP10wBz/P+ByGruW9FYTkirr6lgM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=n6tQqiQh; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf20.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707857050; a=rsa-sha256; cv=none; b=SH3+JPeC2rIBTeC6KxjqgUTO3QDGVHPHbqeSXnPR+bLXF2pskNbZonW/BBcy4nELdoY8gu NcxiahwpvLjQaGYzLHuypsTU0oeSfhtfloGATMjg+xxGMuS9l55BFaV0Vk3Cg7o2aG0XVx 798/Pwzr6q4H/4OqAqZxI04HUx6w+Dw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1707857049; bh=yUo9DUCia3ar+m9KYjMGC2jGiaN/K1370cCPMLE9D+g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=n6tQqiQhY/iYiGGtSq5QCt963/B9nm5PZBYJU3rj38L9Z/NreOlNA71CXtOcIpcC4 D4Q9G+c7BV903n2ROt9GxzWBUkb2SezhGwXt2ukpb8STVQREcuwTGPWcREgYgSK8Vi x73udNIfb75Gv05MHxomb16NoD86LpmWMkleZKOVfcxzySYHMGkEK13GOJ0CTtU5Jb 8QYfYxPSjvmEuTOKzi3ujd915YIp+xuQ7Vb7/IDRpuP1UmBNM6SJdA3ZYnxYi4mPKJ r/lQlXN7dqzKefA0xOYb70hPP45UBBBK8loUWnQbdWRl4pB/bEsipLosyvutUopvID v8y3skAAK55bQ== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4TZCwn3MQCzYPm; Tue, 13 Feb 2024 15:44:09 -0500 (EST) Message-ID: <5806e90f-a4b2-4f74-9cf6-5fc10a303ba7@efficios.com> Date: Tue, 13 Feb 2024 15:44:09 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [linux-next:master 5601/6082] drivers/md/dm.c:2131:undefined reference to `set_dax_nocache' Content-Language: en-US To: Andrew Morton Cc: oe-kbuild-all@lists.linux.dev, Linux Memory Management List , kernel test robot , Dan Williams References: <202402131351.a0FZOgEG-lkp@intel.com> From: Mathieu Desnoyers In-Reply-To: <202402131351.a0FZOgEG-lkp@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 829A11C0022 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 3hg51hno1eqtxmsbgrey71ifm5e7ywj3 X-HE-Tag: 1707857050-949044 X-HE-Meta: U2FsdGVkX1+B7pMukQQSlCmhw6cK/nbUXeD3uSDbXk3jxp98XHIOFknY/6gs/TIy2N4lyX8pzTMYOKlzHt1tt9yiS+dYpsgJw9tOkvoHFbU06teV/nJMER9fAH1d4jUMdWplBIskgYea/ccSK/5gUjrFU11QCaBzIVcsd+1fGzaeXC0HQ0gh/chXth3cUFi89HnJGl47zhuwWiCKtLTwfq2o2skTeRKkltXLzgoPl5hhsvqc8RB6vZnSA9vhDmTIeT3y3TrOjaijAGxZB36MfBT5l8mJSMQTCBfTc3sw2AbLi0YTbEYKEUYSy2VtIQIyNqqQvOknzXNHOF2hrQ0//KShC5Z4/Z87qaFR9cenrJAPYKxaD074rsocSfXEkZUE4SP4FUgEAHrQafl2So8ur+JYV9JFy5u9TAGCGL3lWx9fQzC9yoLeAaSmtQiW6eS1lO4i9to8NTdI/BeTK+sykorE4VHjK24kSc6fj0tJgWYfV2Gkxc6AnBe9McWfIv0pBuZS47gx1itJGPAMpXFWwj0+fkjeDCQ+GO+6/X4HzjhOWDrc+apR7YsXM/qhVtwlSj96SE6I79Dt/Ct+o/gE6M3TWtQ0QReLrYXD21CHFkb1kErgOrIXN9tLfKd6Z7ydKSt1pq+ksQvr+vuLHPTTJi2Wc3iHyfna+Onwe+FbHIWWOR8Nd7Yi9V3M8ZcpFka5DSJVyJZvpJU30D/OEQWpzDwM1rwwjCQq7jHFqco38AHc2bF0ZHyRscOw+J7eiYDgjFagiKBc3l4AvxKO/cNdcfHByn3v5mNJnCcx4J1GWTjJy21AJD1fnZ8QvH3kMgfhBL/iaS0ItKifzZ+vqjavNB/lMs7FE/pzGpgxmajLupTF1KZ7WE211xkKdd0y9qA9Fq3oR29kcVubNt3Z81zvqTruMEo9qZIZL7FwxGlwM5gcPcMX5J0WUOgiWaoyklXM59ccpi31vZak8bttJfq jxj1DFt4 re4r5bbdVimibFr//DhyQ6ikKhHfgASiw+tEw/DrAUy1cKVRC1ZVAFUtVbi2MFAwAlXbORnSbWrikHCs6PR1fkTbFBEnTvqxZL5KwJT47jMkli25fBOsVTtAAXjsXMeaUiZNCB31jkzmbqeXYp35E162Y3sxfVbtGSCZxKyST6X0N4nlIyTdF7ngkXVPbLPsWxRdKegSWdD23L5Z/nFe+HyIXEbo2L32VNzEZnW3QkIspAZQPkiKv/zD5WcAOLbG8A6P4wRAPsT/OTNguuYkhEppWG5c+Naqaji8Qiq7nWvpIXGVRoUEz9GpSAecA0RZ9ohdeosH+ljmus7RyBZWePGRingXwjc633oPL2Cm6N7n/z7/xrvf8eempkctVZmFbgAACR25eEc4//xOLiWRu7ezncNpmE4KSaSPpRbPprkn1litAiymiXCd+FDoPNanm+XUua8EOY92HCL1bcLIXOhUm7Fjub0PSnow/NDeW9sDoaBE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024-02-13 00:12, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > head: ae00c445390b349e070a64dc62f08aa878db7248 > commit: 9af4599a77df42dba7f32c76a97a19f5703f44b7 [5601/6082] dm: cleanup alloc_dax() error handling > config: openrisc-randconfig-r011-20221209 (https://download.01.org/0day-ci/archive/20240213/202402131351.a0FZOgEG-lkp@intel.com/config) > compiler: or1k-linux-gcc (GCC) 13.2.0 > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240213/202402131351.a0FZOgEG-lkp@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: https://lore.kernel.org/oe-kbuild-all/202402131351.a0FZOgEG-lkp@intel.com/ > > All errors (new ones prefixed by >>): > > or1k-linux-ld: drivers/md/dm.o: in function `alloc_dev': >>> drivers/md/dm.c:2131:(.text+0x9f34): undefined reference to `set_dax_nocache' >>> drivers/md/dm.c:2131:(.text+0x9f34): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `set_dax_nocache' >>> or1k-linux-ld: drivers/md/dm.c:2132:(.text+0x9f3c): undefined reference to `set_dax_nomc' >>> drivers/md/dm.c:2132:(.text+0x9f3c): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `set_dax_nomc' > pahole: .tmp_vmlinux.btf: Invalid argument > .btf.vmlinux.bin.o: file not recognized: file format not recognized It comes as a surprise that a call to set_dax_nocache() from within a branch provably never taken ends up keeping a reference to the missing symbol. I would have expected compiler optimizations to remove the call to the missing symbol altogether, but maybe I'm expecting too much. Basically here we have: CONFIG_DAX=n static inline struct dax_device *alloc_dax(void *private, const struct dax_operations *ops) { return ERR_PTR(-EOPNOTSUPP); } static struct mapped_device *alloc_dev(int minor) { [...] dax_dev = alloc_dax(md, &dm_dax_ops); if (IS_ERR(dax_dev)) { if (PTR_ERR(dax_dev) != -EOPNOTSUPP) goto bad; } else { set_dax_nocache(dax_dev); set_dax_nomc(dax_dev); md->dax_dev = dax_dev; if (dax_add_host(dax_dev, md->disk)) goto bad; } The simple fix would be something like this, but I would like to understand why we observe this specifically on openrisc and loongarch (https://lore.kernel.org/oe-kbuild-all/202402140037.wGfA1kqX-lkp@intel.com/). diff --git a/include/linux/dax.h b/include/linux/dax.h index df2d52b8a245..9d3e3327af4c 100644 --- a/include/linux/dax.h +++ b/include/linux/dax.h @@ -63,6 +63,8 @@ void kill_dax(struct dax_device *dax_dev); void dax_write_cache(struct dax_device *dax_dev, bool wc); bool dax_write_cache_enabled(struct dax_device *dax_dev); bool dax_synchronous(struct dax_device *dax_dev); +void set_dax_nocache(struct dax_device *dax_dev); +void set_dax_nomc(struct dax_device *dax_dev); void set_dax_synchronous(struct dax_device *dax_dev); size_t dax_recovery_write(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, size_t bytes, struct iov_iter *i); @@ -105,6 +107,12 @@ static inline bool dax_synchronous(struct dax_device *dax_dev) { return true; } +static inline void set_dax_nocache(struct dax_device *dax_dev) +{ +} +static inline void set_dax_nomc(struct dax_device *dax_dev) +{ +} static inline void set_dax_synchronous(struct dax_device *dax_dev) { } @@ -120,9 +128,6 @@ static inline size_t dax_recovery_write(struct dax_device *dax_dev, } #endif -void set_dax_nocache(struct dax_device *dax_dev); -void set_dax_nomc(struct dax_device *dax_dev); - struct writeback_control; #if defined(CONFIG_BLOCK) && defined(CONFIG_FS_DAX) int dax_add_host(struct dax_device *dax_dev, struct gendisk *disk); Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com