Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Zoltan Racz <racz.zoli@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: Fix get_partition_sector_size_sysfs() to handle loopback and device mapper devices
Date: Sat, 2 Aug 2025 13:49:31 +0930	[thread overview]
Message-ID: <3a8f23bf-e1cf-4803-a290-8d77b0d5dadd@gmx.com> (raw)
In-Reply-To: <20250801110318.37249-1-racz.zoli@gmail.com>



在 2025/8/1 20:33, Zoltan Racz 写道:
> Commit e39ed66 added get_partition_sector_size_sysfs() used by "btrfs device usage"
> which returns the sector size of a partition (or its parent). After more testing
> it turned out it couldn`t handle loopback or mapper devices. This patch adds a fix
> for them.

I can fold this change into the original patch if needed.

Although during my test, even unprivileged users can still do regular 
ioctl based size detection, as long as the user have read permission to 
that device.

And if the user can not even read the device, I'd say the environment is 
set up to intentionally prevent user accesses to that block device.

So I'm not convinced about all the fallback method, especially we're 
doing a lot of special handling (partition vs raw devices).

Mind to also provide the test setup you're using and the involved block 
device mode?

> 
> Signed-off-by: Zoltan Racz <racz.zoli@gmail.com>
> ---
>   common/device-utils.c | 48 +++++++++++++++++++++++++++++--------------
>   1 file changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/common/device-utils.c b/common/device-utils.c
> index dd781bc5..a75194bf 100644
> --- a/common/device-utils.c
> +++ b/common/device-utils.c
> @@ -353,26 +353,44 @@ static ssize_t get_partition_sector_size_sysfs(const char *name)
>   	char sysfs[PATH_MAX] = {};
>   	char sizebuf[128];
>   
> -	snprintf(link_path, PATH_MAX, "/sys/class/block/%s/..", name);
> +	/*
> +	 * First we look for hw_sector_size directly directly under
> +	 * /sys/class/block/[partition_name]/queue. In case of loopback and
> +	 * device mapper devices there is no parent device (like /dev/sda1 -> /dev/sda),
> +	 * and the partition`s sysfs folder itself contains informations regarding
> +	 * the sector size
> +	 */
> +	snprintf(sysfs, PATH_MAX, "/sys/class/block/%s/queue/hw_sector_size", name);
> +	sysfd = open(sysfs, O_RDONLY);
>   
> -	if (!realpath(link_path, real_path)) {
> -		error("Failed to resolve realpath of %s: %s\n", link_path, strerror(errno));
> -		return -1;
> -	}
> +	if (sysfd < 0) {

Just a small nitpic, it's better to check the errno against ENOENT.

But my question still stands, does it really make sense to use sysfs as 
a fallback?

Thanks,
Qu

> +		/*
> +		 * If we couldn`t find it, it means our partition is created on a real
> +		 * device and we need to find its parent
> +		 */
> +		snprintf(link_path, PATH_MAX, "/sys/class/block/%s/..", name);
>   
> -	dev_name = basename(real_path);
> +		if (!realpath(link_path, real_path)) {
> +			error("Failed to resolve realpath of %s: %s\n", link_path, strerror(errno));
> +			return -1;
> +		}
>   
> -	if (!dev_name) {
> -		error("Failed to determine basename for path %s\n", real_path);
> -		return -1;
> -	}
> +		dev_name = basename(real_path);
>   
> -	snprintf(sysfs, PATH_MAX, "/sys/class/block/%s/queue/hw_sector_size", dev_name);
> +		if (!dev_name) {
> +			error("Failed to determine basename for path %s\n", real_path);
> +			return -1;
> +		}
>   
> -	sysfd = open(sysfs, O_RDONLY);
> -	if (sysfd < 0) {
> -		error("Error opening %s to determine dev sector size: %s\n", real_path, strerror(errno));
> -		return -1;
> +		memset(sysfs, 0, PATH_MAX);
> +		snprintf(sysfs, PATH_MAX, "/sys/class/block/%s/queue/hw_sector_size", dev_name);
> +
> +		sysfd = open(sysfs, O_RDONLY);
> +
> +		if (sysfd < 0) {
> +			error("Error opening %s to determine dev sector size: %s\n", real_path, strerror(errno));
> +			return -1;
> +		}
>   	}
>   
>   	ret = sysfs_read_file(sysfd, sizebuf, sizeof(sizebuf));


  reply	other threads:[~2025-08-02  4:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-01 11:03 [PATCH] btrfs-progs: Fix get_partition_sector_size_sysfs() to handle loopback and device mapper devices Zoltan Racz
2025-08-02  4:19 ` Qu Wenruo [this message]
2025-08-02  9:29   ` Racz Zoli
2025-08-02  9:32     ` Qu Wenruo
2025-08-02 12:45       ` Racz Zoli
2025-08-02 23:16         ` Qu Wenruo
2025-08-06  3:59 ` Qu Wenruo

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=3a8f23bf-e1cf-4803-a290-8d77b0d5dadd@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=racz.zoli@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