All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3 3/3] tst_find_backing_dev(): add support for overlayfs
Date: Tue, 18 Feb 2025 15:01:06 -0500	[thread overview]
Message-ID: <x49frkbaupp.fsf@segfault.usersys.redhat.com> (raw)
In-Reply-To: <20250218125746.GC2469726@pevik> (Petr Vorel's message of "Tue, 18 Feb 2025 13:57:46 +0100")

Hi, Petr,

Petr Vorel <pvorel@suse.cz> writes:

> Hi Jeff,
>
>
>> Add checks for overlayfs in tst_find_backing_dev.  As with btrfs, only
>> a single device is checked (the upper one) and returned from
>> tst_find_backing_dev().
>
>> The implementation uses both /proc/self/mountinfo and /proc/self/mounts.
>> The former is used to map a device to a mountpoint, and the latter is
>> used to get the file system options for the mountpoint.  All of the
>> information is present in mountinfo, but the file format is more complex,
>> and there are no glibc helpers for parsing it.
>
>> The '#define _GNU_SOURCE' was added for the use of the strchrnul(3)
>> function.
>
>> Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
>
>> ---
>> v3: Address review comments from Petr:
>>     - Don't split long strings across lines
>>     - use TST_OVERLAYFS_MAGIC instead of the kernel's definition
>>     Note that I did not use SAFE_SSCANF, as tst_device.c uses the old
>>     style safe macros, and that function is not covered.
>> v2: Don't use libmount.  Instead, map from device number to mount-point
>>     using /proc/self/mountinfo, and then use the mntent.h helpers to get
>>     the mount options for the mountpoint from /proc/self/mounts.
>
> LGTM, thanks for a very nice work!
>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
>
> I'd prefer others have look into it before merging.

Sure, any review is appreciated.

> Again, I'll apply minor formatting changes before merge (using SAFE_STAT(),
> moving else branch after break to it's own and checkpatch.pl fixes).

It looks fine, but I will make a couple of observations.

> @@ -634,11 +633,11 @@ static char *overlay_get_upperdir(char *mountpoint)
>  			upperdir = calloc(optend - optstart + 1, 1);
>  			memcpy(upperdir, optstart, optend - optstart);
>  			break;
> -		} else {
> -			tst_brkm(TBROK, NULL,
> -				 "mount point %s does not contain an upperdir",
> -				 mountpoint);
>  		}
> +
> +		tst_brkm(TBROK, NULL,
> +			 "mount point %s does not contain an upperdir",
> +			 mountpoint);

This is technically different, but I don't think it matters.  All
overlay mount points need an upperdir, so it is valid to error out here.

>  	}
>  	endmntent(mntf);
>  
> @@ -679,26 +678,21 @@ static char *overlay_get_upperdir(char *mountpoint)
>   */
>  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");
> +	SAFE_STAT(NULL, tmp_path, &st);

Sorry for not using SAFE_STAT.  I don't know how I missed that.  Thanks
again for the review and for fixing up these issues.

Cheers,
Jeff


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-02-18 20:01 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 [this message]
2025-02-20  4:12       ` Petr Vorel
2025-02-20 11:15   ` Cyril Hrubis
2025-03-04 21:15     ` Jeff Moyer

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=x49frkbaupp.fsf@segfault.usersys.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=pvorel@suse.cz \
    /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.