Linux filesystem development
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Jeff Layton <jlayton@kernel.org>
Cc: Jan Kara <jack@suse.cz>, Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	Josef Bacik <josef@toxicpanda.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] fs: add the ability for statmount() to report the mount devicename
Date: Thu, 7 Nov 2024 12:57:01 +0100	[thread overview]
Message-ID: <20241107115701.ueeykzbel22sdr2f@quack3> (raw)
In-Reply-To: <7554bd2b13330f8b44b23b775dd4d611ad6cdcae.camel@kernel.org>

On Thu 07-11-24 06:15:40, Jeff Layton wrote:
> On Thu, 2024-11-07 at 10:40 +0100, Jan Kara wrote:
> > On Wed 06-11-24 14:53:06, Jeff Layton wrote:
> > > /proc/self/mountinfo displays the devicename for the mount, but
> > > statmount() doesn't yet have a way to return it. Add a new
> > > STATMOUNT_MNT_DEVNAME flag, claim the 32-bit __spare1 field to hold the
> > > offset into the str[] array. STATMOUNT_MNT_DEVNAME will only be set in
> > > the return mask if there is a device string.
> > > 
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > 
> > Just one question below:
> > 
> > > @@ -5078,6 +5091,12 @@ static int statmount_string(struct kstatmount *s, u64 flag)
> > >  		if (seq->count == sm->fs_subtype)
> > >  			return 0;
> > >  		break;
> > > +	case STATMOUNT_MNT_DEVNAME:
> > > +		sm->mnt_devname = seq->count;
> > > +		ret = statmount_mnt_devname(s, seq);
> > > +		if (seq->count == sm->mnt_devname)
> > 
> > Why this odd check? Why don't you rather do:
> > 		if (ret)
> > ?
> >
> 
> statmount_mnt_devname() can return without emitting anything to the seq
> if ->show_devname and r->mnt_devname are both NULL. In that case, we
> don't want statmount_string() to return an error, but we also don't
> want to do any further manipulation of the seq. So, the above handles
> either the case where show_devname returned an error and the case where
> there was nothing to emit.
> 
> I did consider having statmount_mnt_devname() return -ENOBUFS if there
> was nothing to emit, and then handle that in the caller, but checking
> to see whether the seq has advanced seemed like a cleaner solution.

OK, but don't we want to emit an empty string - i.e., just \0 character in
case r->mnt_devname is NULL and there's no ->show_devname? Because now we
literaly emit nothing and it's going to be very confusing for userspace to
parse this when this happens in the middle of other strings in the seq.
And emitting \0 is exactly what will happen if we don't do anything special
in STATMOUNT_MNT_DEVNAME case...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2024-11-07 11:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06 19:53 [PATCH v2 0/2] fs: allow statmount to fetch the sb->s_subtype field Jeff Layton
2024-11-06 19:53 ` [PATCH v2 1/2] fs: add the ability for statmount() to report the fs_subtype Jeff Layton
2024-11-06 19:53 ` [PATCH v2 2/2] fs: add the ability for statmount() to report the mount devicename Jeff Layton
2024-11-07  9:40   ` Jan Kara
2024-11-07 11:15     ` Jeff Layton
2024-11-07 11:57       ` Jan Kara [this message]
2024-11-07 12:04         ` Jeff Layton
2024-11-07 13:50   ` Miklos Szeredi
2024-11-07 14:25     ` Jeff Layton

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=20241107115701.ueeykzbel22sdr2f@quack3 \
    --to=jack@suse.cz \
    --cc=brauner@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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