Message ID | 20240216202442.2493031-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-69292-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp767484dyb; Fri, 16 Feb 2024 12:25:03 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVqMq4Gu/MdipInJKEZ0LgThNQGVZhS1HvWonZparc0ChHbH9OtyuWNExh70FrWitMNHjSwhXAUfdlEeLDzNPsCX1jvqg== X-Google-Smtp-Source: AGHT+IGAmT9E3HAhx9kK8ItUVJj6VYdlrNI2k6EoboM+dz6zPw5oq7oTrm7hbjxZ8ZVhANaZN5lr X-Received: by 2002:a05:6102:3218:b0:46d:6046:2951 with SMTP id r24-20020a056102321800b0046d60462951mr5796766vsf.2.1708115103289; Fri, 16 Feb 2024 12:25:03 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708115103; cv=pass; d=google.com; s=arc-20160816; b=dOBYstZqMmoqaH2Jcsh1Q/saDQC46oWRWnqE2D0VhtE9mo5nJ0atbvRsXkVH1dtnj1 VQNOANdFROYQ815Cqk1HvSG6Q3YQv4oiTeMo2QO7fqAb/kZmpbDFp+A8oCZR6jgS+bLS +7sAgbWM3vDzhhISb29bwb7+/HxwhAIP5d32Cq5Bu0XouSVjpJTS27zTemFMce47z2BW JukWsXjQjBsx/Kh+Ckh0kKGrbluUsIsyenroo7lG/102hTfgfb4z8Vdeu1uA/YjN26os 8d/sCSRUOW6Ahfjv+2t9r7VbTAtlNQw9YwmuiO+jWZt6soPSt9ZW7OJ/rKA+8Jku98zE VqdQ== 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:message-id:date:subject:cc:to :from:dkim-signature; bh=Q0L+j6R3TK0LzuWguZ8aBc6nyXkJcTXMxyXlMirQfjg=; fh=uM3b1fZGhprIEBQvE7EAfF3PHgVuA6genHmNzETK8b4=; b=tBqlqC5OD0aM+DgZjoX7A/Xe96OyL+AuMed5eBcNm8Onm6MqSADRs8B3mHJTDFsmB5 hi6qQJWYMNW3ang1h7TYSA1t++9Ovk1sFHGozyYPlr4fV/a4kwIjFk6N7vsT8HLwMKbV dzoeC0iNU58jvUyZt92Pkbu0V247L86RtWZm6HF11HfB/zlMyiNZFSdIiSpjHwO6ZGBR k/usBaGFMlhE06eZu9rsDXz8fDKmOlEV0jsIj0kOXXWKgCwXlkF9NVKS3rgBxPGE5nh2 V7evy270yspB212g76Nq/SFv/UdxnzWyc5tIL/g52r2Zq70y4qcKamk5jM0HCVW4aiLi M8JA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=o4pyvA3u; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-69292-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69292-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id l15-20020a05622a050f00b0042da96c1c18si692054qtx.551.2024.02.16.12.25.03 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Feb 2024 12:25:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-69292-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=o4pyvA3u; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-69292-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69292-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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 16E751C21357 for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 20:25:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 73E8D13AA46; Fri, 16 Feb 2024 20:24:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o4pyvA3u" 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 E12E1136640 for <linux-kernel@vger.kernel.org>; Fri, 16 Feb 2024 20:24:48 +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=1708115089; cv=none; b=HlheUhWppoRGYkwUjI84Ja4dhB+KWJ0F6F6PjPTkc7YagaB1VniBk7VsNl+ewXNJ2WtTlPx/UFcZT/oYQg75ADQ4OpcKRIHbrYc66Vq98mYZj0yngoq5gC2JEzYauN0vDU1NhpeaQZtv3nooHDxayoV1Yo0wgXD3PmLZXu3sM4M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708115089; c=relaxed/simple; bh=O3Vq/9iekbJvfivB8fPNqfc/VdUr6NW92uCL9/WplH8=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Xj7viJO8uTO6QjPE3KJmZyOQokA2y4b0sA7TXia8gJ5zAf7vrGcvjiQmEvIaLSME85pWj9QgD43Lzzg4aBXDhffiZSrmm7/wcaAvTnJX3KYkdAb8a+HsQY+wQ543tBd0ngYClo/Y07qcjud23UGuYmUBXx0MSoH2CSjnUgZO16Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o4pyvA3u; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 918C0C433F1; Fri, 16 Feb 2024 20:24:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708115088; bh=O3Vq/9iekbJvfivB8fPNqfc/VdUr6NW92uCL9/WplH8=; h=From:To:Cc:Subject:Date:From; b=o4pyvA3urDBZ5absWA/kHxTMsUxqDiraqvUHzCvCZsa7S0GmRjiXDAtU2otgYDGdq rFd7s2UI/6YOfwxfkRxyCzlxvmo9OxpsJT94IKgMtTq2yv3aMJlJUp7xbmbUym6AAx R2AVyJN9VY+gL9kRUqn9IeL+UdYV+I99jKHPtrKm2GnBCmSvhTaxKMD6/rminmP/9s Yg53Bk7R26epRSUPyl6s/TZWVFmjKU80plf8NXxpnBjeteQXHD05VIxUBo7/ZqgGAW j7t48iqo3h3QX6HuTT6gyPHYao49ciSc9jw0I/VRd8BbE121S1BGrTbjAt5zxKO4Fv w39jyPvupSZaQ== From: Arnd Bergmann <arnd@kernel.org> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de> Cc: Arnd Bergmann <arnd@arndb.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>, =?utf-8?q?Chris?= =?utf-8?q?tian_K=C3=B6nig?= <christian.koenig@amd.com>, David Gow <davidgow@google.com>, =?utf-8?q?Ma=C3=ADra_Canal?= <mcanal@igalia.com>, Matthew Auld <matthew.auld@intel.com>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH] drm/tests/drm_buddy: avoid 64-bit calculation Date: Fri, 16 Feb 2024 21:24:30 +0100 Message-Id: <20240216202442.2493031-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.2 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: 1791088502595399494 X-GMAIL-MSGID: 1791088502595399494 |
Series |
drm/tests/drm_buddy: avoid 64-bit calculation
|
|
Commit Message
Arnd Bergmann
Feb. 16, 2024, 8:24 p.m. UTC
From: Arnd Bergmann <arnd@arndb.de> The newly added drm_test_buddy_alloc_contiguous() test fails to link on 32-bit targets because of inadvertent 64-bit calculations: ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! From what I can tell, the numbers cannot possibly overflow a 32-bit size, so use different types for these. I noticed that the function has another possible flaw in that is mixes what it calls pages with 4KB units. This is a big confusing at best, or possibly broken when built on machines with larger pages. Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/gpu/drm/tests/drm_buddy_test.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Comments
On 2/16/24 12:24, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The newly added drm_test_buddy_alloc_contiguous() test fails to link on > 32-bit targets because of inadvertent 64-bit calculations: > > ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! > ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! > >>From what I can tell, the numbers cannot possibly overflow a 32-bit size, > so use different types for these. > > I noticed that the function has another possible flaw in that is mixes > what it calls pages with 4KB units. This is a big confusing at best, > or possibly broken when built on machines with larger pages. > > Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Randy Dunlap <rdunlap@infradead.org> Thanks. > --- > drivers/gpu/drm/tests/drm_buddy_test.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c b/drivers/gpu/drm/tests/drm_buddy_test.c > index fee6bec757d1..50a5f98cd5bd 100644 > --- a/drivers/gpu/drm/tests/drm_buddy_test.c > +++ b/drivers/gpu/drm/tests/drm_buddy_test.c > @@ -21,7 +21,8 @@ static inline u64 get_size(int order, u64 chunk_size) > > static void drm_test_buddy_alloc_contiguous(struct kunit *test) > { > - u64 mm_size, ps = SZ_4K, i, n_pages, total; > + u64 mm_size, total; > + u32 i, ps = SZ_4K, n_pages; > struct drm_buddy_block *block; > struct drm_buddy mm; > LIST_HEAD(left); > @@ -29,7 +30,8 @@ static void drm_test_buddy_alloc_contiguous(struct kunit *test) > LIST_HEAD(right); > LIST_HEAD(allocated); > > - mm_size = 16 * 3 * SZ_4K; > + n_pages = 16 * 3; > + mm_size = n_pages * SZ_4K; > > KUNIT_EXPECT_FALSE(test, drm_buddy_init(&mm, mm_size, ps)); > > @@ -42,7 +44,6 @@ static void drm_test_buddy_alloc_contiguous(struct kunit *test) > */ > > i = 0; > - n_pages = mm_size / ps; > do { > struct list_head *list; > int slot = i % 3;
Am 17.02.24 um 02:31 schrieb Randy Dunlap: > On 2/16/24 12:24, Arnd Bergmann wrote: >> From: Arnd Bergmann <arnd@arndb.de> >> >> The newly added drm_test_buddy_alloc_contiguous() test fails to link on >> 32-bit targets because of inadvertent 64-bit calculations: >> >> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >> ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >> >> >From what I can tell, the numbers cannot possibly overflow a 32-bit size, >> so use different types for these. >> >> I noticed that the function has another possible flaw in that is mixes >> what it calls pages with 4KB units. This is a big confusing at best, >> or possibly broken when built on machines with larger pages. >> >> Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Tested-by: Randy Dunlap <rdunlap@infradead.org> I've just pushed a similar patch Mathew came up a bit earlier to drm-misc-fixes. Sorry for the noise, I have to catch up on picking up patches for misc-fixes and misc-next. Christian. > > Thanks. > >> --- >> drivers/gpu/drm/tests/drm_buddy_test.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c b/drivers/gpu/drm/tests/drm_buddy_test.c >> index fee6bec757d1..50a5f98cd5bd 100644 >> --- a/drivers/gpu/drm/tests/drm_buddy_test.c >> +++ b/drivers/gpu/drm/tests/drm_buddy_test.c >> @@ -21,7 +21,8 @@ static inline u64 get_size(int order, u64 chunk_size) >> >> static void drm_test_buddy_alloc_contiguous(struct kunit *test) >> { >> - u64 mm_size, ps = SZ_4K, i, n_pages, total; >> + u64 mm_size, total; >> + u32 i, ps = SZ_4K, n_pages; >> struct drm_buddy_block *block; >> struct drm_buddy mm; >> LIST_HEAD(left); >> @@ -29,7 +30,8 @@ static void drm_test_buddy_alloc_contiguous(struct kunit *test) >> LIST_HEAD(right); >> LIST_HEAD(allocated); >> >> - mm_size = 16 * 3 * SZ_4K; >> + n_pages = 16 * 3; >> + mm_size = n_pages * SZ_4K; >> >> KUNIT_EXPECT_FALSE(test, drm_buddy_init(&mm, mm_size, ps)); >> >> @@ -42,7 +44,6 @@ static void drm_test_buddy_alloc_contiguous(struct kunit *test) >> */ >> >> i = 0; >> - n_pages = mm_size / ps; >> do { >> struct list_head *list; >> int slot = i % 3;
On Mon, Feb 19, 2024, at 12:22, Christian König wrote: > Am 17.02.24 um 02:31 schrieb Randy Dunlap: >> On 2/16/24 12:24, Arnd Bergmann wrote: >>> From: Arnd Bergmann <arnd@arndb.de> >>> >>> The newly added drm_test_buddy_alloc_contiguous() test fails to link on >>> 32-bit targets because of inadvertent 64-bit calculations: >>> >>> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >>> ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >>> >>> >From what I can tell, the numbers cannot possibly overflow a 32-bit size, >>> so use different types for these. >>> >>> I noticed that the function has another possible flaw in that is mixes >>> what it calls pages with 4KB units. This is a big confusing at best, >>> or possibly broken when built on machines with larger pages. >>> >>> Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") >>> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >> Tested-by: Randy Dunlap <rdunlap@infradead.org> > > I've just pushed a similar patch Mathew came up a bit earlier to > drm-misc-fixes. > > Sorry for the noise, I have to catch up on picking up patches for > misc-fixes and misc-next. Ok, thanks. Have you looked at how this code works for larger values of PAGE_SIZE? Is there any need to change other things or will this work with the hardcoded 4KB chunks? Arnd
Am 19.02.24 um 12:29 schrieb Arnd Bergmann: > On Mon, Feb 19, 2024, at 12:22, Christian König wrote: >> Am 17.02.24 um 02:31 schrieb Randy Dunlap: >>> On 2/16/24 12:24, Arnd Bergmann wrote: >>>> From: Arnd Bergmann <arnd@arndb.de> >>>> >>>> The newly added drm_test_buddy_alloc_contiguous() test fails to link on >>>> 32-bit targets because of inadvertent 64-bit calculations: >>>> >>>> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >>>> ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >>>> >>>> >From what I can tell, the numbers cannot possibly overflow a 32-bit size, >>>> so use different types for these. >>>> >>>> I noticed that the function has another possible flaw in that is mixes >>>> what it calls pages with 4KB units. This is a big confusing at best, >>>> or possibly broken when built on machines with larger pages. >>>> >>>> Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") >>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >>> Tested-by: Randy Dunlap <rdunlap@infradead.org> >> I've just pushed a similar patch Mathew came up a bit earlier to >> drm-misc-fixes. >> >> Sorry for the noise, I have to catch up on picking up patches for >> misc-fixes and misc-next. > Ok, thanks. > > Have you looked at how this code works for larger values of PAGE_SIZE? > Is there any need to change other things or will this work with the > hardcoded 4KB chunks? I haven't looked into the details, but I've pointed out before that using PAGE_SIZE in the buddy or its test cases would be incorrect. Background is that the buddy allocator is for devices and those work independent of the CPU PAGE_SIZE. So it can be that on a CPU with 64k pages the buddy still needs to work with 4k. Could be that this is work, but could as well be that this is completely broken. Arun and Mathew needs to answer this, I haven't tested it nor reviewed the code. Regards, Christian. > > Arnd
On 19/02/2024 11:41, Christian König wrote: > Am 19.02.24 um 12:29 schrieb Arnd Bergmann: >> On Mon, Feb 19, 2024, at 12:22, Christian König wrote: >>> Am 17.02.24 um 02:31 schrieb Randy Dunlap: >>>> On 2/16/24 12:24, Arnd Bergmann wrote: >>>>> From: Arnd Bergmann <arnd@arndb.de> >>>>> >>>>> The newly added drm_test_buddy_alloc_contiguous() test fails to >>>>> link on >>>>> 32-bit targets because of inadvertent 64-bit calculations: >>>>> >>>>> ERROR: modpost: "__aeabi_uldivmod" >>>>> [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >>>>> ERROR: modpost: "__aeabi_ldivmod" >>>>> [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined! >>>>> >>>>> >From what I can tell, the numbers cannot possibly overflow a >>>>> 32-bit size, >>>>> so use different types for these. >>>>> >>>>> I noticed that the function has another possible flaw in that is mixes >>>>> what it calls pages with 4KB units. This is a big confusing at best, >>>>> or possibly broken when built on machines with larger pages. >>>>> >>>>> Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") >>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >>>> Tested-by: Randy Dunlap <rdunlap@infradead.org> >>> I've just pushed a similar patch Mathew came up a bit earlier to >>> drm-misc-fixes. >>> >>> Sorry for the noise, I have to catch up on picking up patches for >>> misc-fixes and misc-next. >> Ok, thanks. >> >> Have you looked at how this code works for larger values of PAGE_SIZE? >> Is there any need to change other things or will this work with the >> hardcoded 4KB chunks? > > I haven't looked into the details, but I've pointed out before that > using PAGE_SIZE in the buddy or its test cases would be incorrect. > > Background is that the buddy allocator is for devices and those work > independent of the CPU PAGE_SIZE. So it can be that on a CPU with 64k > pages the buddy still needs to work with 4k. > > Could be that this is work, but could as well be that this is completely > broken. Arun and Mathew needs to answer this, I haven't tested it nor > reviewed the code. Yeah, we should not be using PAGE_SIZE or PAGE_SHIFT in drm_buddy.[ch] and tests/drm_buddy_test.c. The smallest default page size is SZ_4K for drm_buddy. A patch to fix that would be very welcome. If no takers I can send something. > > Regards, > Christian. > >> >> Arnd >
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c b/drivers/gpu/drm/tests/drm_buddy_test.c index fee6bec757d1..50a5f98cd5bd 100644 --- a/drivers/gpu/drm/tests/drm_buddy_test.c +++ b/drivers/gpu/drm/tests/drm_buddy_test.c @@ -21,7 +21,8 @@ static inline u64 get_size(int order, u64 chunk_size) static void drm_test_buddy_alloc_contiguous(struct kunit *test) { - u64 mm_size, ps = SZ_4K, i, n_pages, total; + u64 mm_size, total; + u32 i, ps = SZ_4K, n_pages; struct drm_buddy_block *block; struct drm_buddy mm; LIST_HEAD(left); @@ -29,7 +30,8 @@ static void drm_test_buddy_alloc_contiguous(struct kunit *test) LIST_HEAD(right); LIST_HEAD(allocated); - mm_size = 16 * 3 * SZ_4K; + n_pages = 16 * 3; + mm_size = n_pages * SZ_4K; KUNIT_EXPECT_FALSE(test, drm_buddy_init(&mm, mm_size, ps)); @@ -42,7 +44,6 @@ static void drm_test_buddy_alloc_contiguous(struct kunit *test) */ i = 0; - n_pages = mm_size / ps; do { struct list_head *list; int slot = i % 3;