Linux filesystem development
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: linux-fsdevel@vger.kernel.org, Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH 2/2 V2] fat: Convert to new mount api
Date: Mon, 1 Jul 2024 15:20:17 -0500	[thread overview]
Message-ID: <ef8519df-a1f4-4f90-9e42-0c8d91bd982d@redhat.com> (raw)
In-Reply-To: <216b2317-cec3-4cfd-9dc2-ed9d29b5c099@sandeen.net>

On 7/1/24 12:35 PM, Eric Sandeen wrote:
> On 7/1/24 9:15 AM, OGAWA Hirofumi wrote:
>> Eric Sandeen <sandeen@redhat.com> writes:

[...]

>> [...]
>>
>>> +	/* If user doesn't specify allow_utime, it's initialized from dmask. */
>>> +	if (opts->allow_utime == (unsigned short)-1)
>>> +		opts->allow_utime = ~opts->fs_dmask & (S_IWGRP | S_IWOTH);
>>> +	if (opts->unicode_xlate)
>>> +		opts->utf8 = 0;
>>
>> Probably, this should move to fat_parse_param()?
> 
> In my conversions, I have treated parse_param as simply handling one option at
> a time, and not dealing with combinations, because we don't have the "full view"
> of all options until we are done (previously we parsed everything, and then could
> "clean up" at the bottom of the function). So now, I was handling this sort of
> checking after parsing was complete, and fill_super seemed an OK place to do it.
> 
> But sure - I will look at whether doing it in fat_parse_param makes sense.
> 

I don't think that will work.

For example, for the allow_utime adjustment...

Before parsing begins, allow_utime is defaulted to -1 (unset) and
fs_dmask is defaulted to current_umask()

If we put the 

+	if (opts->allow_utime == (unsigned short)-1)
+		opts->allow_utime = ~opts->fs_dmask & (S_IWGRP | S_IWOTH);

test at the bottom of parse_param, then this sequence of parsing:

("mount -o fs_uid=42,fs_dmask=0XYZ")

fs_uid=42
 --> sets opts->allow_utime to (~opts->fs_dmask & (S_IWGRP | S_IWOTH))
     where fs_dmask is default / current_umask()
fs_dmask=0XYZ
 --> changes fs_dmask from default, but does not update allow_utime which
     was set based on the old fs_dmask

leads to different results than:

("mount -o fs_dmask=0XYZ",fs_uid=42)

fs_dmask=0XYZ
 --> changes fs_dmask from the default
     updates allow_utime based on this user-specified fs_dmask rather than default
fs_uid=42
 --> allow_utime is now set, so no further changes are made

IOWS, the final allow_utime value may differ depending on the order of option
parsing, unless we wait until parsing is complete before we inspect and adjust it.

dhowells did, however, suggest that perhaps these adjustments should generally
be done in get_tree rather than fill_super, so I'll give that a shot.

Sound ok?

-Eric


  reply	other threads:[~2024-07-01 20:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-29 17:30 [PATCH 0/2] fat: convert to the new mount API Eric Sandeen
2024-06-29 17:31 ` [PATCH 1/2] fat: move debug into fat_mount_options Eric Sandeen
2024-06-29 17:32 ` [PATCH 2/2] fat: Convert to new mount api Eric Sandeen
2024-06-29 18:02   ` [PATCH 2/2 V2] " Eric Sandeen
2024-07-01 14:15     ` OGAWA Hirofumi
2024-07-01 17:35       ` Eric Sandeen
2024-07-01 20:20         ` Eric Sandeen [this message]
2024-07-02  5:04           ` OGAWA Hirofumi
2024-06-29 18:00 ` [PATCH 0/2] fat: convert to the new mount API Eric Sandeen

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=ef8519df-a1f4-4f90-9e42-0c8d91bd982d@redhat.com \
    --to=sandeen@redhat.com \
    --cc=brauner@kernel.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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