From: Avnish Chouhan <avnish@linux.ibm.com>
To: mchang@suse.com
Cc: grub-devel@gnu.org, Daniel Kiper <daniel.kiper@oracle.com>,
mlewando@redhat.com, ngompa13@gmail.com
Subject: Re: [PATCH v2 1/9] util/grub-editenv: add basic structures and probe call for external envblk
Date: Tue, 16 Sep 2025 22:36:04 +0530 [thread overview]
Message-ID: <16c9bf1debdca93d73724805e47a397e@linux.ibm.com> (raw)
In-Reply-To: <x7crgh2dthtcxmcqo3rfcxavel37au74aciqi7umdfio2fdfxh@rlv5rtimfvts>
On 2025-09-16 10:28, Michael Chang wrote:
> Hi Avnish,
>
> Thanks for the review. Please see my comments below.
>
> On Mon, Sep 15, 2025 at 06:37:05PM +0530, Avnish Chouhan wrote:
>> On 2025-09-15 14:39, grub-devel-request@gnu.org wrote:
>> >
>> > Message: 2
>> > Date: Mon, 15 Sep 2025 17:08:40 +0800
>> > From: Michael Chang <mchang@suse.com>
>> > To: The development of GNU GRUB <grub-devel@gnu.org>
>> > Cc: Neal Gompa <ngompa13@gmail.com>, Marta Lewandowska
>> > <mlewando@redhat.com>
>> > Subject: [PATCH v2 1/9] util/grub-editenv: add basic structures and
>> > probe call for external envblk
>> > Message-ID: <20250915090848.131937-2-mchang@suse.com>
>> >
>> > This patch prepares for using an environment block stored in a reserved
>> > area of the filesystem. It adds a constant ENV_BTRFS_OFFSET at 256 KiB
>> > in the Btrfs header. It also introduces the fs_envblk_spec and fs_envblk
>> > structures together with the probe_fs_envblk function to identify the
>> > root filesystem and to avoid configurations that involve diskfilter or
>> > cryptodisk.
>> >
>> > The probe is only invoked when grub-editenv is working on the default
>> > environment file path. This restriction ensures that probing and
>> > possible raw device access are not triggered for arbitrary user supplied
>> > paths, but only for the standard grubenv file. In that case the code
>> > checks if the filename equals DEFAULT_ENVBLK_PATH and then calls
>> > probe_fs_envblk with fs_envblk_spec. The result is stored in the global
>> > fs_envblk handle. At this stage the external environment block is only
>> > detected and recorded, and the behavior of grub editenv is unchanged.
>> >
>> > Signed-off-by: Michael Chang <mchang@suse.com>
>
> Well xstrdup() and other x* functions like xmalloc() and xcalloc()
> already handle the NULL check, so we do not need to add repetitive NULL
> checks and error handling in the code. This makes the code more concise
> and less verbose IMHO.
>
>
> I hope the clarification makes sense to you.
>
> Thanks,
> Michael
>
>>
>> Regards,
>> Avnish Chouhan
Hi Michael,
Thank you so much for your clarification!
In my opinion, using grub_*() would be better instead of x*(). My
suggestion here was not about adding a NULL check, it was about "we can
use grub_*() and add a NULL check instead of using x*()". Using grub_*()
would be safe!
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
next prev parent reply other threads:[~2025-09-16 17:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.4306.1757927367.1200.grub-devel@gnu.org>
2025-09-15 13:07 ` [PATCH v2 1/9] util/grub-editenv: add basic structures and probe call for external envblk Avnish Chouhan
2025-09-16 4:58 ` Michael Chang via Grub-devel
2025-09-16 17:06 ` Avnish Chouhan [this message]
2025-09-17 10:43 ` [PATCH v2 2/9] util/grub-editenv: add fs_envblk open helper Avnish Chouhan
2025-10-02 5:44 ` Michael Chang via Grub-devel
2025-10-07 5:24 ` Avnish Chouhan
2025-09-17 11:04 ` [PATCH v2 3/9] util/grub-editenv: add fs_envblk write helper Avnish Chouhan
2025-10-02 5:53 ` Michael Chang via Grub-devel
2025-10-07 5:22 ` Avnish Chouhan
2025-09-15 9:08 [PATCH v2 0/9] Add support for external environment block on Btrfs Michael Chang via Grub-devel
2025-09-15 9:08 ` [PATCH v2 1/9] util/grub-editenv: add basic structures and probe call for external envblk Michael Chang via Grub-devel
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=16c9bf1debdca93d73724805e47a397e@linux.ibm.com \
--to=avnish@linux.ibm.com \
--cc=daniel.kiper@oracle.com \
--cc=grub-devel@gnu.org \
--cc=mchang@suse.com \
--cc=mlewando@redhat.com \
--cc=ngompa13@gmail.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;
as well as URLs for NNTP newsgroup(s).