From: Sahil <icegambit91@gmail.com>
To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
Quentin Monnet <quentin@isovalent.com>
Cc: martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@google.com, haoluo@google.com,
jolsa@kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2] bpftool: Mount bpffs on provided dir instead of parent dir
Date: Fri, 15 Mar 2024 02:46:41 +0530 [thread overview]
Message-ID: <10467264.nUPlyArG6x@valdaarhun> (raw)
In-Reply-To: <c3cb7598-f777-4714-9e43-d9e0fbdf8711@isovalent.com>
Hi,
On Wednesday, March 13, 2024 9:17:44 PM IST Quentin Monnet wrote:
> Thanks! Apologies for the delay.
No worries! Thank you for the review.
> [...]
> Note: you don't need the blank lines between the tags.
> [...]
> You can keep the changelog as part of the patch description.
Got it. I'll keep this in mind when I submit v3.
> [...]
> With all the checks and the potential directory creation, we could maybe
> rename this into "prepare_bpffs_dir()" or something like this?
"prepare_bpffs_dir" is quite apt. If longer names are acceptable then I
would also recommend "prepare_and_mount_bpffs_dir" so it indicates
that it'll also mount the bpffs on the dir (when relevant) after performing
the checks.
> [...]
> I'd maybe change this block a little (although it's up to you):
>
> bool dir_exists;
>
> dire_exists = (access(...) == 0);
> if (!dir_exists) {
> ...
> free(temp_name);
> }
>
> if (block_mount) {
> ...
> }
>
> if (!dir_exists) {
> err = mkdir(...);
> ...
> }
>
> err = mnt_fs(...);
> ...
>
> This would also enable us to remove the directory we just created, if
> we're not able to mount the bpffs on it, before leaving the function.
I agree with this. This will also keep the implementation a little more
succinct with just one "block_mount" conditional block.
> [...]
> I'd remove/replace "given" from the name, maybe "mount_bpffs_for_file"?
This is definitely a better name. I am not very good when it comes to
making up names :P
> [...]
> I'd remove "file", the existing object might be a directory and it might
> be confusing.
>
> > + return -1;
> > + }
> > +
> > + temp_name = malloc(strlen(file_name) + 1);
> > + if (!temp_name) {
> >
> > p_err("mem alloc failed");
> > return -1;
> >
> > }
> >
> > - strcpy(file, name);
> > - dir = dirname(file);
> > + strcpy(temp_name, file_name);
> > + dir = dirname(temp_name);
>
> Here, we could check for the existence of "dir", and error out
> otherwise. The reason is that with the current code, if dir does not
> exist but user passes --nomount, then we fail to pin the path (given
> that the directory is not present), but the message returned will be "no
> BPF file system found, not mounting it due to --nomount option", which
> is confusing.
>
> Same note applies to the other function as well.
>
> > if (is_bpffs(dir))
> >
> > /* nothing to do if already mounted */
> >
> > @@ -277,11 +333,11 @@ int mount_bpffs_for_pin(const char *name, bool
> > is_dir)>
> > if (err) {
> >
> > err_str[ERR_MAX_LEN - 1] = '\0';
> > p_err("can't mount BPF file system to pin the object (%s): %s",
>
> We could also indicate the path where we tried to mount the bpffs, in
> this message.
Understood. I'll make these changes as well.
> [...]
> Other than the comments above, the patch works well, and the different
> cases are much easier to follow than in v1, thanks!
>
> I've checked that the programs load as expected, the directories are
> created (or not) as expected, and the bpffs is mounted (or not) as
> expected, for all the cases I could think of, with the following
> commands (copied here, for the record), all worked as I expected:
That's really nice to hear. I'll incorporate the recommended changes and
will send v3 soon.
Thanks,
Sahil
next prev parent reply other threads:[~2024-03-14 21:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 13:06 [PATCH bpf-next v2] bpftool: Mount bpffs on provided dir instead of parent dir Sahil Siddiq
2024-03-13 15:47 ` Quentin Monnet
2024-03-14 21:16 ` Sahil [this message]
2024-03-15 9:59 ` Quentin Monnet
2024-03-21 19:22 ` Sahil
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=10467264.nUPlyArG6x@valdaarhun \
--to=icegambit91@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=quentin@isovalent.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yonghong.song@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.