public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: "Qu Wenruo" <quwenruo.btrfs@gmx.com>,
	u-boot@lists.denx.de, "Marek Behún" <kabel@kernel.org>
Cc: Qu Wenruo <wqu@suse.com>
Subject: Re: [PATCH] fs: btrfs: fix reading when length specified
Date: Thu, 16 Nov 2023 17:02:27 -0700	[thread overview]
Message-ID: <df0b432c-483b-5ebb-20bd-29800554b860@gmail.com> (raw)
In-Reply-To: <fff8b725-1c64-4407-acb8-c47c258e6571@gmx.com>

On 11/15/23 21:43, Qu Wenruo wrote:
> 
> I'm not sure why this happend for the EFI environment.
> 
> Doesn't the EFI runtime should also try to read the whole file? Or that
> EFI environment has specified the length to read instead?
> 

Hi Qu,

The Linux EFISTUB file loading routine (handle_cmdline_files) reads 
files in chunks, and not (necessarily) the whole file in one go. On x86 
platforms, the chunk size is 1MB, and the comments explain that this is 
to work around firmware implementations that have problems with large 
reads. On non-x86 platforms, the chunk size is ULONG_MAX -- which in 
practice means it reads the whole file in one exact-filesize chunk.

So, to answer your questions: "either/both depending on platform."

(The bug in the U-Boot implementation doubtlessly affects more than just 
EFI; I only happened to discover it while trying to use EFI.)

>>
>> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
> 
> Anyway, the fix looks good to me.
> 
> Reviewed-by: Qu Wenruo <wqu@suse.com>

Thank you greatly for the review!

> 
> Thanks,
> Qu

Likewise,
Sam

  reply	other threads:[~2023-11-17  0:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-11 15:19 [PATCH] fs: btrfs: fix reading when length specified Sam Edwards
2023-11-16  4:43 ` Qu Wenruo
2023-11-17  0:02   ` Sam Edwards [this message]
2023-11-17 13:41 ` Tom Rini

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=df0b432c-483b-5ebb-20bd-29800554b860@gmail.com \
    --to=cfsworks@gmail.com \
    --cc=kabel@kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=u-boot@lists.denx.de \
    --cc=wqu@suse.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox