Message ID | 20230329065532.2122295-1-davidgow@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp212948vqo; Wed, 29 Mar 2023 00:01:06 -0700 (PDT) X-Google-Smtp-Source: AKy350YAHTCKpviTiS3feH0Umqr/VyCqVZD7Rt5biwTp7/q6nKytf0T/L53Q6rA4rjZXvQ3ebwR5 X-Received: by 2002:a17:903:234a:b0:19d:f7e:9864 with SMTP id c10-20020a170903234a00b0019d0f7e9864mr21410551plh.57.1680073266467; Wed, 29 Mar 2023 00:01:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680073266; cv=none; d=google.com; s=arc-20160816; b=alhOPOdrrQVMguGLj/m/CX8eYzObY/10eu63oF3qd2pRxtgPMD3IDoMdAvp8Hk9ekb rkhLmvC5atwgvSz7X8YDLjR0uBc63Hb82LYHDdpRtOI0ECJkIuBzOtM26y6gikGh4CBl XmeNVwOPhX8yuAQOsjVO9FvnaVwONfvf/MTb7dTLRWal6waFKrQ65RP8lZYthP4VH6ye aCib2n/sd0LwM1QBtm7YSQkqQGAvc0/LlNsT0QAvKS7AidVrX0CVL2uGOkUlJqdFIUYd 1hPRHN9T5LVU+YTNfhTPltYIkNAhUdEAehcPjZa81R182P+OC2Z2BnXpSZ4YLBUSFuAD JOAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:from:subject :message-id:mime-version:date:dkim-signature; bh=Yb6T5Nix/3hrpi04qTRDKmlC5J5N+Z2zQezjqCwHQSc=; b=N2pHNNOMt6xLMCK9JATjTtLRgTrZZUU01Va609qA6PPgwo3FVhOvJQJqdRVyl0h+t7 vUMMjhvhCdpK+D5wMTCCb5VK2AXmCxG1Y7tKvD7kfRJUqoH9n8dTPayobTQNvMEOUoC4 zteGpzuzu3EK1V8euTdDvJLzcbNAk3lOMskNSs2C1vRm73otzp3ggzlMCtyGF3Mny8tp ZSIUi04dGo4R8a9Q3X586Iiyni1k3a209fGRFiHwSxusL+/QDZnoZ/JtaY7ssc0+FrZA DHFuzjLXR7IB2KW+yhvN0AM/Y9UsAGkT2oRFig1yLhBSmaxEEtptZQQhtT17KZYFivDN fmvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=I70iBO8V; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r8-20020a654988000000b0050c0674ab43si31381076pgs.378.2023.03.29.00.00.50; Wed, 29 Mar 2023 00:01:06 -0700 (PDT) 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; dkim=pass header.i=@google.com header.s=20210112 header.b=I70iBO8V; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229692AbjC2Gzy (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Wed, 29 Mar 2023 02:55:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbjC2Gzw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 29 Mar 2023 02:55:52 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD018211D for <linux-kernel@vger.kernel.org>; Tue, 28 Mar 2023 23:55:51 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-54629ed836aso6038957b3.10 for <linux-kernel@vger.kernel.org>; Tue, 28 Mar 2023 23:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680072951; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=Yb6T5Nix/3hrpi04qTRDKmlC5J5N+Z2zQezjqCwHQSc=; b=I70iBO8V621lm+2OBg9UTLn3NwNxaOjH81/kUFD8B1L+O1fwBhekEA+10JCdKiD3tA kECwcwUJvSNC88bYchl5stnbjXXBAo59zC+OgGa1lyXqpdfSBAdKUplbtKbZ6b4sx+Io fOQ63v3lHvtOi4jdjxoivD4NQGgJEUDTIXFSDL+0qLQm7CfslCBvEOlc6kmoSJRnTYhx pEEhi7f4mATzlqPFiW1w4VEErXrG7EzcULjUI2XpAcYsYU34pW9Tn9qbtYIEjkN0lEZr djC+4bkDVcIBW8KqxkB9oMzR05gvvb+gdeHsobNc5dq91YSjLozfTnVS9sd8c8258dDQ ayIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680072951; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Yb6T5Nix/3hrpi04qTRDKmlC5J5N+Z2zQezjqCwHQSc=; b=LqdZuR+n4lt142LZVFnSf1hPzegTqDYeKL5zmWdyAWquig7mjonzv/IHyRffLdoHuf o63PUU8mwSFHkkI5OxveavCM9IWbQMUpR0sKhUHNYHp3O4M60TqXH/CRJVO+NHnZlp/D YhiSEhIc8P6gFnclZnTQot5ehlzIsfdUMcJ957gRPaU+Z0yRPJbu3Cpglu1C57FTRMle a9rDlsETJVhi2sWCuGrLua0hZl4s5qIGmJlKcWogl6NlaWbCZbl/39FdIPhQrqK1ok4D Hut9439sE94/WsY3y2hqrr/eZqkWx+/Ol6bjEPgla9/oYii8cIDHw/bYeUjyUDMjB8Kk XSrA== X-Gm-Message-State: AAQBX9feUbY7uTZIEN1l51KnleIhPMKXscrppirgdeTzej0MeHAuEYvB OhBjmGa/3WSBXx8CYBIZ4PGTtLcy/pAYRw== X-Received: from slicestar.c.googlers.com ([fda3:e722:ac3:cc00:4f:4b78:c0a8:20a1]) (user=davidgow job=sendgmr) by 2002:a05:6902:1003:b0:b1d:5061:98e3 with SMTP id w3-20020a056902100300b00b1d506198e3mr12429289ybt.6.1680072951072; Tue, 28 Mar 2023 23:55:51 -0700 (PDT) Date: Wed, 29 Mar 2023 14:55:32 +0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230329065532.2122295-1-davidgow@google.com> Subject: [PATCH 1/2] drm: buddy_allocator: Fix buddy allocator init on 32-bit systems From: David Gow <davidgow@google.com> To: " =?utf-8?q?Lu=C3=ADs_Mendes?= " <luis.p.mendes@gmail.com>, " =?utf-8?q?Christian_K=C3=B6nig?= " <christian.koenig@amd.com>, 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>, " =?utf-8?q?Ma=C3=ADra_Canal?= " <mairacanal@riseup.net>, Arthur Grillo <arthurgrillo@riseup.net> Cc: David Gow <davidgow@google.com>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761684505308524391?= X-GMAIL-MSGID: =?utf-8?q?1761684505308524391?= |
Series |
[1/2] drm: buddy_allocator: Fix buddy allocator init on 32-bit systems
|
|
Commit Message
David Gow
March 29, 2023, 6:55 a.m. UTC
The drm buddy allocator tests were broken on 32-bit systems, as
rounddown_pow_of_two() takes a long, and the buddy allocator handles
64-bit sizes even on 32-bit systems.
This can be reproduced with the drm_buddy_allocator KUnit tests on i386:
./tools/testing/kunit/kunit.py run --arch i386 \
--kunitconfig ./drivers/gpu/drm/tests drm_buddy
(It results in kernel BUG_ON() when too many blocks are created, due to
the block size being too small.)
This was independently uncovered (and fixed) by Luís Mendes, whose patch
added a new u64 variant of rounddown_pow_of_two(). This version instead
recalculates the size based on the order.
Reported-by: Luís Mendes <luis.p.mendes@gmail.com>
Link: https://lore.kernel.org/lkml/CAEzXK1oghXAB_KpKpm=-CviDQbNaH0qfgYTSSjZgvvyj4U78AA@mail.gmail.com/T/
Signed-off-by: David Gow <davidgow@google.com>
---
drivers/gpu/drm/drm_buddy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Am 29.03.23 um 08:55 schrieb David Gow: > The drm buddy allocator tests were broken on 32-bit systems, as > rounddown_pow_of_two() takes a long, and the buddy allocator handles > 64-bit sizes even on 32-bit systems. > > This can be reproduced with the drm_buddy_allocator KUnit tests on i386: > ./tools/testing/kunit/kunit.py run --arch i386 \ > --kunitconfig ./drivers/gpu/drm/tests drm_buddy > > (It results in kernel BUG_ON() when too many blocks are created, due to > the block size being too small.) > > This was independently uncovered (and fixed) by Luís Mendes, whose patch > added a new u64 variant of rounddown_pow_of_two(). This version instead > recalculates the size based on the order. > > Reported-by: Luís Mendes <luis.p.mendes@gmail.com> > Link: https://lore.kernel.org/lkml/CAEzXK1oghXAB_KpKpm=-CviDQbNaH0qfgYTSSjZgvvyj4U78AA@mail.gmail.com/T/ > Signed-off-by: David Gow <davidgow@google.com> Acked-by: Christian König <christian.koenig@amd.com> for the series. > --- > drivers/gpu/drm/drm_buddy.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c > index 3d1f50f481cf..7098f125b54a 100644 > --- a/drivers/gpu/drm/drm_buddy.c > +++ b/drivers/gpu/drm/drm_buddy.c > @@ -146,8 +146,8 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64 chunk_size) > unsigned int order; > u64 root_size; > > - root_size = rounddown_pow_of_two(size); > - order = ilog2(root_size) - ilog2(chunk_size); > + order = ilog2(size) - ilog2(chunk_size); > + root_size = chunk_size << order; > > root = drm_block_alloc(mm, NULL, order, offset); > if (!root)
On Wed, 29 Mar 2023, David Gow <davidgow@google.com> wrote: > The drm buddy allocator tests were broken on 32-bit systems, as > rounddown_pow_of_two() takes a long, and the buddy allocator handles > 64-bit sizes even on 32-bit systems. > > This can be reproduced with the drm_buddy_allocator KUnit tests on i386: > ./tools/testing/kunit/kunit.py run --arch i386 \ > --kunitconfig ./drivers/gpu/drm/tests drm_buddy > > (It results in kernel BUG_ON() when too many blocks are created, due to > the block size being too small.) > > This was independently uncovered (and fixed) by Luís Mendes, whose patch > added a new u64 variant of rounddown_pow_of_two(). This version instead > recalculates the size based on the order. > > Reported-by: Luís Mendes <luis.p.mendes@gmail.com> > Link: https://lore.kernel.org/lkml/CAEzXK1oghXAB_KpKpm=-CviDQbNaH0qfgYTSSjZgvvyj4U78AA@mail.gmail.com/T/ > Signed-off-by: David Gow <davidgow@google.com> > --- > drivers/gpu/drm/drm_buddy.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c > index 3d1f50f481cf..7098f125b54a 100644 > --- a/drivers/gpu/drm/drm_buddy.c > +++ b/drivers/gpu/drm/drm_buddy.c > @@ -146,8 +146,8 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64 chunk_size) > unsigned int order; > u64 root_size; > > - root_size = rounddown_pow_of_two(size); > - order = ilog2(root_size) - ilog2(chunk_size); > + order = ilog2(size) - ilog2(chunk_size); > + root_size = chunk_size << order; Just noticed near the beginning of the function there's also: if (!is_power_of_2(chunk_size)) return -EINVAL; which is also wrong for 32-bit. BR, Jani. > > root = drm_block_alloc(mm, NULL, order, offset); > if (!root)
Am 30.03.23 um 12:53 schrieb Jani Nikula: > On Wed, 29 Mar 2023, David Gow <davidgow@google.com> wrote: >> The drm buddy allocator tests were broken on 32-bit systems, as >> rounddown_pow_of_two() takes a long, and the buddy allocator handles >> 64-bit sizes even on 32-bit systems. >> >> This can be reproduced with the drm_buddy_allocator KUnit tests on i386: >> ./tools/testing/kunit/kunit.py run --arch i386 \ >> --kunitconfig ./drivers/gpu/drm/tests drm_buddy >> >> (It results in kernel BUG_ON() when too many blocks are created, due to >> the block size being too small.) >> >> This was independently uncovered (and fixed) by Luís Mendes, whose patch >> added a new u64 variant of rounddown_pow_of_two(). This version instead >> recalculates the size based on the order. >> >> Reported-by: Luís Mendes <luis.p.mendes@gmail.com> >> Link: https://lore.kernel.org/lkml/CAEzXK1oghXAB_KpKpm=-CviDQbNaH0qfgYTSSjZgvvyj4U78AA@mail.gmail.com/T/ >> Signed-off-by: David Gow <davidgow@google.com> >> --- >> drivers/gpu/drm/drm_buddy.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c >> index 3d1f50f481cf..7098f125b54a 100644 >> --- a/drivers/gpu/drm/drm_buddy.c >> +++ b/drivers/gpu/drm/drm_buddy.c >> @@ -146,8 +146,8 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64 chunk_size) >> unsigned int order; >> u64 root_size; >> >> - root_size = rounddown_pow_of_two(size); >> - order = ilog2(root_size) - ilog2(chunk_size); >> + order = ilog2(size) - ilog2(chunk_size); >> + root_size = chunk_size << order; > Just noticed near the beginning of the function there's also: > > if (!is_power_of_2(chunk_size)) > return -EINVAL; > > which is also wrong for 32-bit. Yeah, but that isn't vital. We just use u64 for the chunk_size for consistency. In reality I wouldn't except more than 256K here. Regards, Christian. > > > BR, > Jani. > > >> >> root = drm_block_alloc(mm, NULL, order, offset); >> if (!root)
On Thu, 30 Mar 2023, Christian König <christian.koenig@amd.com> wrote: > Am 30.03.23 um 12:53 schrieb Jani Nikula: >> On Wed, 29 Mar 2023, David Gow <davidgow@google.com> wrote: >>> The drm buddy allocator tests were broken on 32-bit systems, as >>> rounddown_pow_of_two() takes a long, and the buddy allocator handles >>> 64-bit sizes even on 32-bit systems. >>> >>> This can be reproduced with the drm_buddy_allocator KUnit tests on i386: >>> ./tools/testing/kunit/kunit.py run --arch i386 \ >>> --kunitconfig ./drivers/gpu/drm/tests drm_buddy >>> >>> (It results in kernel BUG_ON() when too many blocks are created, due to >>> the block size being too small.) >>> >>> This was independently uncovered (and fixed) by Luís Mendes, whose patch >>> added a new u64 variant of rounddown_pow_of_two(). This version instead >>> recalculates the size based on the order. >>> >>> Reported-by: Luís Mendes <luis.p.mendes@gmail.com> >>> Link: https://lore.kernel.org/lkml/CAEzXK1oghXAB_KpKpm=-CviDQbNaH0qfgYTSSjZgvvyj4U78AA@mail.gmail.com/T/ >>> Signed-off-by: David Gow <davidgow@google.com> >>> --- >>> drivers/gpu/drm/drm_buddy.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c >>> index 3d1f50f481cf..7098f125b54a 100644 >>> --- a/drivers/gpu/drm/drm_buddy.c >>> +++ b/drivers/gpu/drm/drm_buddy.c >>> @@ -146,8 +146,8 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64 chunk_size) >>> unsigned int order; >>> u64 root_size; >>> >>> - root_size = rounddown_pow_of_two(size); >>> - order = ilog2(root_size) - ilog2(chunk_size); >>> + order = ilog2(size) - ilog2(chunk_size); >>> + root_size = chunk_size << order; >> Just noticed near the beginning of the function there's also: >> >> if (!is_power_of_2(chunk_size)) >> return -EINVAL; >> >> which is also wrong for 32-bit. > > Yeah, but that isn't vital. We just use u64 for the chunk_size for > consistency. > > In reality I wouldn't except more than 256K here. Right. It's just not pedantically correct either. ;) is_power_of_2() is pretty scary as it is, since it just truncates. BR, Jani. > > Regards, > Christian. > >> >> >> BR, >> Jani. >> >> >>> >>> root = drm_block_alloc(mm, NULL, order, offset); >>> if (!root) >
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index 3d1f50f481cf..7098f125b54a 100644 --- a/drivers/gpu/drm/drm_buddy.c +++ b/drivers/gpu/drm/drm_buddy.c @@ -146,8 +146,8 @@ int drm_buddy_init(struct drm_buddy *mm, u64 size, u64 chunk_size) unsigned int order; u64 root_size; - root_size = rounddown_pow_of_two(size); - order = ilog2(root_size) - ilog2(chunk_size); + order = ilog2(size) - ilog2(chunk_size); + root_size = chunk_size << order; root = drm_block_alloc(mm, NULL, order, offset); if (!root)