All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Imre Kaloz" <kaloz@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/radeon: Check the VBIOS signature after copying it from VRAM
Date: Sun, 27 Sep 2026 11:03:47 +0000	[thread overview]
Message-ID: <20260927110347.6EE201F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260927105555.8771-2-kaloz@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] radeon: inefficient 256KB MMIO copy and allocation before VBIOS signature check
--

commit e7cbdfb764010827fd7b2b511a029cf30846ddbe
Author: Imre Kaloz <kaloz@kernel.org>

drm/radeon: Check the VBIOS signature after copying it from VRAM

This commit modifies the VBIOS reading logic to check the signature after
copying the data from VRAM. This is done to avoid a sparc64 fault caused
by a plain load through an ioremap() cookie.

> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c
> index 8595f4c6e2e5c..a8367e4811821 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -63,10 +63,6 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
>  		return false;
>  	}
>  
> -	if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
> -		iounmap(bios);
> -		return false;
> -	}
>  	rdev->bios = kmalloc(size, GFP_KERNEL);
>  	if (rdev->bios == NULL) {
>  		iounmap(bios);
> @@ -74,6 +70,12 @@ static bool igp_read_bios_from_vram(struct radeon_device *rdev)
>  	}
>  	memcpy_fromio(rdev->bios, bios, size);
>  	iounmap(bios);
> +
> +	if (size == 0 || rdev->bios[0] != 0x55 || rdev->bios[1] != 0xaa) {

[Severity: Medium]
Does this sequence perform an expensive unconditional 256KB kmalloc() and
PCIe MMIO read (memcpy_fromio()) for discrete GPUs before validating the
VBIOS header signature?

During device probe, radeon_get_bios() tries multiple fallback methods and
calls igp_read_bios_from_vram(). This allows posted discrete GPUs to proceed.
The new logic maps VRAM, immediately allocates 256KB, copies it, and only
then checks if the first two bytes match the expected 0x55 and 0xaa
signature. This wastes allocation overhead and introduces a noticeable boot
delay, as reading 256KB of un-cached MMIO over PCIe takes significant time.

To fix the sparc64 __iomem access fault without creating a performance
regression, could this code use readb(&bios[0]) for the signature validation
before performing the 256KB allocation and copy, matching the pattern
established in radeon_read_bios()?

> +		kfree(rdev->bios);
> +		rdev->bios = NULL;
> +		return false;
> +	}
>  	return true;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260927105555.8771-1-kaloz@kernel.org?part=1

  reply	other threads:[~2026-09-27 11:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-27 10:55 [PATCH 0/2] drm/radeon: Sun XVR-300 support on sparc64 Imre Kaloz
2026-09-27 10:55 ` [PATCH 1/2] drm/radeon: Check the VBIOS signature after copying it from VRAM Imre Kaloz
2026-09-27 11:03   ` sashiko-bot [this message]
2026-09-27 10:55 ` [PATCH 2/2] drm/radeon: add a connector table for the Sun XVR-300 Imre Kaloz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260927110347.6EE201F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kaloz@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.