From: Jeff Moyer <jmoyer@redhat.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3 3/3] tst_find_backing_dev(): add support for overlayfs
Date: Tue, 04 Mar 2025 16:15:08 -0500 [thread overview]
Message-ID: <x495xkozeeb.fsf@segfault.usersys.redhat.com> (raw)
In-Reply-To: <Z7cOxcRhtPcZSpsL@yuki.lan> (Cyril Hrubis's message of "Thu, 20 Feb 2025 12:15:17 +0100")
Hi, Cyril,
Thanks for the review. Comments inline.
Cyril Hrubis <chrubis@suse.cz> writes:
>> +static char *overlay_mount_from_dev(dev_t dev)
>> +{
>> + unsigned dev_major, dev_minor, mnt_major, mnt_minor;
>> + FILE *fp;
>> + char line[PATH_MAX];
>
> PATH_MAX does not really make any sense here. It's as good as any other
> number so I would just hardcode 4096 here.
Agreed. Also, the theoretical max is beyond 4k, but it shouldn't be a
practical issue. I did struggle with plucking a value out of thin air,
here.
>> + if (ret != 3)
>> + tst_brkm(TBROK, NULL,
>> + "failed to parse mountinfo line: \"%s\"",
> ^
> We usually use ' instead of " inside of strings in LTP.
Ok.
>> + if (!mountpoint)
>> + tst_brkm(TBROK, NULL,
>> + "Unable to find mount entry for device %u:%u\n",
> ^
> No newlines in
> tst_*()
> messages please.
Oops!
>> + while ((mnt = getmntent(mntf)) != NULL) {
>> + if (strncmp(mnt->mnt_dir, mountpoint, strlen(mountpoint)))
>> + continue;
>
> Why strncmp() here? Isn't this possibly generating false positives in
> the case that we there is more mounts that have the same prefix that
> matches mountpoint?
Yes, good point. Thanks!
>> + if (strncmp(mnt->mnt_type, "overlay", strlen("overlay")))
>> + tst_brkm(TBROK, NULL,
>> + "expected overlayfs on mount point \"%s\", but it is of type %s.",
>> + mountpoint, mnt->mnt_type);
>
> Here as well, I suppose that the probability of false positive here is
> close to zero, but I do not see the reason for strncmp() here either.
Agreed.
>> + optstr = hasmntopt(mnt, "upperdir");
>> + if (optstr) {
>> + optstart = strchr(optstr, '=');
>> + optstart++;
>> + optend = strchrnul(optstr, ',');
>> + upperdir = calloc(optend - optstart + 1, 1);
>> + memcpy(upperdir, optstart, optend - optstart);
>
> Isn't this just a complicated way how to re-implement strndup()?
Yes. :) I'll fix that up.
>> +static void overlay_get_uevent_path(char *tmp_path, char *uevent_path)
>> +{
>> + int ret;
>> + struct stat st;
>> + char *mountpoint, *upperdir;
>> +
>> + tst_resm(TINFO, "Use OVERLAYFS specific strategy");
>> +
>> + ret = stat(tmp_path, &st);
>> + if (ret)
>> + tst_brkm(TBROK | TERRNO, NULL, "stat failed");
>> +
>> + mountpoint = overlay_mount_from_dev(st.st_dev);
>> + upperdir = overlay_get_upperdir(mountpoint);
>> + free(mountpoint);
>
> Since the mntpoint is only intermediate result, why can't we pass the
> st.dev to the overlay_get_upperdir() and call overlay_mount_from_dev()
> from there?
It makes more logical sense to me to pass a mount point to that
function. Another argument against changing would be that
overlay_get_upperdir is already pretty large. However, if you feel
strongly about it, I can certainly change it.
Thanks again for the thorough review!
Cheers,
Jeff
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2025-03-04 21:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 21:46 [LTP] [PATCH v3 0/3] tst_device: add support for overlayfs Jeff Moyer
2025-02-17 21:46 ` [LTP] [PATCH v3 1/3] lib/tst_device.c: factor out btrfs-specific logic from tst_find_backing_dev Jeff Moyer
2025-02-20 10:23 ` Cyril Hrubis
2025-02-17 21:46 ` [LTP] [PATCH v3 2/3] lib/tst_device.c: check for BTRFS_SUPER_MAGIC instead of device major of 0 Jeff Moyer
2025-02-18 12:50 ` Petr Vorel
2025-02-18 19:54 ` Jeff Moyer
2025-02-20 10:24 ` Cyril Hrubis
2025-02-20 11:53 ` Petr Vorel
2025-02-17 21:46 ` [LTP] [PATCH v3 3/3] tst_find_backing_dev(): add support for overlayfs Jeff Moyer
2025-02-18 12:57 ` Petr Vorel
2025-02-18 20:01 ` Jeff Moyer
2025-02-20 4:12 ` Petr Vorel
2025-02-20 11:15 ` Cyril Hrubis
2025-03-04 21:15 ` Jeff Moyer [this message]
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=x495xkozeeb.fsf@segfault.usersys.redhat.com \
--to=jmoyer@redhat.com \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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