Linux Test Project
 help / color / mirror / Atom feed
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

      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