Message ID | 20240226124736.1272949-3-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-81409-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp2070762dyb; Mon, 26 Feb 2024 05:22:42 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXi8FpQgIA2Fevhd8YnGrae9PMMtZwvPGlzdOjE12ej0TTpSbAl8lS1AqawCfKKW8nSnai27+QyRfupIfWr8mCv/Zh0Qw== X-Google-Smtp-Source: AGHT+IGGwGIIplGxMHNtWQvSA1scqIItp/+8T38NAcAxxHukoERStpWmGbjE3OOQc92l31dKEU4r X-Received: by 2002:a05:6358:7f87:b0:17b:c8d:f396 with SMTP id c7-20020a0563587f8700b0017b0c8df396mr10088563rwo.29.1708953762670; Mon, 26 Feb 2024 05:22:42 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708953762; cv=pass; d=google.com; s=arc-20160816; b=GsgB7ku15bqFx0tF4/SWx9dk3fJvcXhFzZPIR3FPBw3POhDx8Nk6XEdnDS3z7XJjv0 3eHUXxLmeUE/g3hoVXDIkMdSku+uNp/K+3tTC5BPNpUUCJCzy6P5j277dp5QFmUuU31h UxZqXMZBS04ZpK3adH6/5sVXGaLnQnbCY8mBaETyqfkiL64K13xH+WN5ysp0ofiqfzHK eG210LkrAZ0Nvs4svwhlcjHWpKFzVjrgXFUITx+r3opkTnC5K24VZBI83SOyUwUD1oH1 mA7Y/ykSaaR6jgOPVgOvRjedD9GdJ70o7nyf+5g13gXtKza+9G6kA1dso0muVEpOwpE1 sRlw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=17ahSFh/eKpmcygEqatVZh4Si+jTpsfUHm1LJ3Q2WxE=; fh=3AVzhxMHlCDYUvMlVTBT8zggu3rBxTju+/hqxuBNucA=; b=is7Drpk94qKDMubZYq4IXAffCrx7+er3NdB0vQhmKvviomvFnCLxgCeDt9uk6y1OO+ spWiYNhJ4U5paxnGJV7/PK5ozozCx49EiFYcJS45hQu7pbeG0hwI57F/aipGOV41mVmZ gAPcfjnAnU5b3Qe6iuuLPAa9vSnS64EEiLjA0xAbGQm+fcesItcD3KPjYU3tyNxqKoiy BjFSedVd9Rc/KbjtHe7XrtAn/IJgGNpt4bO/htupztUXPb3ZteNxC2wB1zZR2Gc14w9c FnhiBKA1UxZlMgUqXTi0/uj6KXQ/pygk4APnLi/e3XTELliJl7fZCicBauSvleKnP0aE x9+A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="j5gwv/oL"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-81409-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-81409-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id f19-20020a635553000000b005d9252c9d05si3718890pgm.103.2024.02.26.05.22.42 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 05:22:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-81409-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="j5gwv/oL"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-81409-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-81409-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id E5F46B2BB00 for <ouuuleilei@gmail.com>; Mon, 26 Feb 2024 12:49:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EC30E83A01; Mon, 26 Feb 2024 12:48:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j5gwv/oL" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53F06EC7 for <linux-kernel@vger.kernel.org>; Mon, 26 Feb 2024 12:48:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708951734; cv=none; b=FXiyO5tFg5b/LQTLiphCILcsByvTta7ETIoBbcdWohEbkxg9AzMlylkxqpG/ZL6oMrHHITyvegmOx3ofbdlfIz5WuqlPkqP2NS7m3YQ5bZTOwRhAJjZNrTnciwgLwWOiErmoiZK3iQh7PUkI9hrqHdVj0rus92+fvevrUE6mkDk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708951734; c=relaxed/simple; bh=Q3NH181a85YRTFivknWhvRlGzUVX6ut6yEVQtESkJik=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=omZEzyZRPO5y37Q3VlK2MIqXk7bypSvwVOXjfLmOsRIztJajxcFO6RcnJEcoYNiD6BNDFDJqPJ08CP/ChaiT3NPJBIqXfcMy2CDU2LSMslp4mYEQW91NjfMsIMGXomAui+o0LGzzN4mLDK8t5NilNbeuE8JpupvAidA020yzUyg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j5gwv/oL; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD553C43390; Mon, 26 Feb 2024 12:48:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708951734; bh=Q3NH181a85YRTFivknWhvRlGzUVX6ut6yEVQtESkJik=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j5gwv/oLxGBvshYM4XJsakKQspn+4PiYoY+JB8H+VNY+uM3lMbovSewvvS7qT4pPq NSpcoaLyasTfkJ9GZE0Ekv0zTg4XXDqtbcUNwIa2GVPeWQe70PVIrWjdD6hzUaCMKg hG24PwowVape7egBViKaXaknYe26QfBheDfrpqGdB6IE4W81shxhUm6pSrLgtDMM9C +RDgNYsJh8GwsjSI8kboes7lAMcB+jJH7zl70rs8XL+f6J+pgewKs/puDY8dj2mX3U 5h1Khj5tIT8dSvdkzBje5gz/b6PPaTcopUTRzqdEVRU6BHxqN8SfcOcS0G42nq+oWN 54jKq5HRKHgiw== From: Arnd Bergmann <arnd@kernel.org> To: Lucas De Marchi <lucas.demarchi@intel.com>, Oded Gabbay <ogabbay@kernel.org>, =?utf-8?q?Thomas_Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Matt Roper <matthew.d.roper@intel.com>, Matthew Brost <matthew.brost@intel.com>, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] [v2] drm/xe/xe2: fix 64-bit division in pte_update_size Date: Mon, 26 Feb 2024 13:46:38 +0100 Message-Id: <20240226124736.1272949-3-arnd@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240226124736.1272949-1-arnd@kernel.org> References: <20240226124736.1272949-1-arnd@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791967900701023284 X-GMAIL-MSGID: 1791967900701023284 |
Series |
[1/3,v2] drm/xe/kunit: fix link failure with built-in xe
|
|
Commit Message
Arnd Bergmann
Feb. 26, 2024, 12:46 p.m. UTC
From: Arnd Bergmann <arnd@arndb.de> This function does not build on 32-bit targets when the compiler fails to reduce DIV_ROUND_UP() into a shift: ld.lld: error: undefined symbol: __aeabi_uldivmod >>> referenced by xe_migrate.c >>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive vmlinux.a There are two instances in this function. Change the first to use an open-coded shift with the same behavior, and the second one to a 32-bit calculation, which is sufficient here as the size is never more than 2^32 pages (16TB). Fixes: 237412e45390 ("drm/xe: Enable 32bits build") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- v2: use correct Fixes tag --- drivers/gpu/drm/xe/xe_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, Feb 26, 2024 at 01:46:38PM +0100, Arnd Bergmann wrote: >From: Arnd Bergmann <arnd@arndb.de> > >This function does not build on 32-bit targets when the compiler >fails to reduce DIV_ROUND_UP() into a shift: > >ld.lld: error: undefined symbol: __aeabi_uldivmod >>>> referenced by xe_migrate.c >>>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive vmlinux.a > >There are two instances in this function. Change the first to >use an open-coded shift with the same behavior, and the second >one to a 32-bit calculation, which is sufficient here as the size >is never more than 2^32 pages (16TB). > >Fixes: 237412e45390 ("drm/xe: Enable 32bits build") >Signed-off-by: Arnd Bergmann <arnd@arndb.de> >--- >v2: use correct Fixes tag but what about the other comment? How are we supposed to use DIV_ROUND_UP() but then in some places (which?) have to open code it? What compiler does this fail on? >--- > drivers/gpu/drm/xe/xe_migrate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c >index a66fdf2d2991..ee1bb938c493 100644 >--- a/drivers/gpu/drm/xe/xe_migrate.c >+++ b/drivers/gpu/drm/xe/xe_migrate.c >@@ -462,7 +462,7 @@ static u32 pte_update_size(struct xe_migrate *m, > } else { > /* Clip L0 to available size */ > u64 size = min(*L0, (u64)avail_pts * SZ_2M); >- u64 num_4k_pages = DIV_ROUND_UP(size, XE_PAGE_SIZE); >+ u32 num_4k_pages = (size + XE_PAGE_SIZE - 1) >> XE_PTE_SHIFT; also the commit message doesn't seem to match the patch as you are only changing one instance. Lucas De Marchi > > *L0 = size; > *L0_ofs = xe_migrate_vm_addr(pt_ofs, 0); >-- >2.39.2 >
On Mon, Feb 26, 2024, at 17:40, Lucas De Marchi wrote: > On Mon, Feb 26, 2024 at 01:46:38PM +0100, Arnd Bergmann wrote: >> >>Fixes: 237412e45390 ("drm/xe: Enable 32bits build") >>Signed-off-by: Arnd Bergmann <arnd@arndb.de> >>--- >>v2: use correct Fixes tag > > but what about the other comment? How are we supposed to use > DIV_ROUND_UP() but then in some places (which?) have to open code it? The problem is not DIV_ROUND_UP() but the division but the 64-bit division itself. There is a DIV_ROUND_UP_ULL() macro that would address the build failure as well, but doing the shift is much more efficient here since it can be done in a couple of instructions. > What compiler does this fail on? I saw it with clang-19 on 32-bit arm, but I assume it happens on others as well. >> drivers/gpu/drm/xe/xe_migrate.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >>diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c >>index a66fdf2d2991..ee1bb938c493 100644 >>--- a/drivers/gpu/drm/xe/xe_migrate.c >>+++ b/drivers/gpu/drm/xe/xe_migrate.c >>@@ -462,7 +462,7 @@ static u32 pte_update_size(struct xe_migrate *m, >> } else { >> /* Clip L0 to available size */ >> u64 size = min(*L0, (u64)avail_pts * SZ_2M); >>- u64 num_4k_pages = DIV_ROUND_UP(size, XE_PAGE_SIZE); >>+ u32 num_4k_pages = (size + XE_PAGE_SIZE - 1) >> XE_PTE_SHIFT; > > also the commit message doesn't seem to match the patch as you are only > changing one instance. Not sure what you mean. As I wrote in the changelog, the second instance is fixed by using a 32-bit division here, which does not cause link failures. Arnd
On Wed, Feb 28, 2024 at 01:26:29PM +0100, Arnd Bergmann wrote: >On Mon, Feb 26, 2024, at 17:40, Lucas De Marchi wrote: >> On Mon, Feb 26, 2024 at 01:46:38PM +0100, Arnd Bergmann wrote: >>> >>>Fixes: 237412e45390 ("drm/xe: Enable 32bits build") >>>Signed-off-by: Arnd Bergmann <arnd@arndb.de> >>>--- >>>v2: use correct Fixes tag >> >> but what about the other comment? How are we supposed to use >> DIV_ROUND_UP() but then in some places (which?) have to open code it? > >The problem is not DIV_ROUND_UP() but the division but the 64-bit >division itself. There is a DIV_ROUND_UP_ULL() macro that would >address the build failure as well, but doing the shift is much >more efficient here since it can be done in a couple of instructions. > >> What compiler does this fail on? > >I saw it with clang-19 on 32-bit arm, but I assume it happens >on others as well. somehow it passed on x86 :-/ > >>> drivers/gpu/drm/xe/xe_migrate.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>>diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c >>>index a66fdf2d2991..ee1bb938c493 100644 >>>--- a/drivers/gpu/drm/xe/xe_migrate.c >>>+++ b/drivers/gpu/drm/xe/xe_migrate.c >>>@@ -462,7 +462,7 @@ static u32 pte_update_size(struct xe_migrate *m, >>> } else { >>> /* Clip L0 to available size */ >>> u64 size = min(*L0, (u64)avail_pts * SZ_2M); >>>- u64 num_4k_pages = DIV_ROUND_UP(size, XE_PAGE_SIZE); >>>+ u32 num_4k_pages = (size + XE_PAGE_SIZE - 1) >> XE_PTE_SHIFT; >> >> also the commit message doesn't seem to match the patch as you are only >> changing one instance. > >Not sure what you mean. As I wrote in the changelog, the >second instance is fixed by using a 32-bit division here, >which does not cause link failures. I missed the type conversion to u32 and was thinking there was another hunk missing for the second change. all looks good to me now and I will apply later today to drm-xe-next. Thanks. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Lucas De Marchi > > Arnd
diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c index a66fdf2d2991..ee1bb938c493 100644 --- a/drivers/gpu/drm/xe/xe_migrate.c +++ b/drivers/gpu/drm/xe/xe_migrate.c @@ -462,7 +462,7 @@ static u32 pte_update_size(struct xe_migrate *m, } else { /* Clip L0 to available size */ u64 size = min(*L0, (u64)avail_pts * SZ_2M); - u64 num_4k_pages = DIV_ROUND_UP(size, XE_PAGE_SIZE); + u32 num_4k_pages = (size + XE_PAGE_SIZE - 1) >> XE_PTE_SHIFT; *L0 = size; *L0_ofs = xe_migrate_vm_addr(pt_ofs, 0);