linux-kernel - Re: [PATCH v4 04/11] fs/9p: Remove unnecessary superblock flags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 18 Feb 2023 10:24:17 -0600
From:   Eric Van Hensbergen <ericvh@...il.com>
To:     asmadeus@...ewreck.org
Cc:     Eric Van Hensbergen <ericvh@...nel.org>,
        v9fs-developer@...ts.sourceforge.net, rminnich@...il.com,
        lucho@...kov.net, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux_oss@...debyte.com
Subject: Re: [PATCH v4 04/11] fs/9p: Remove unnecessary superblock flags

That's fair -- and it didn't seem to hurt anything to have DIRSYNC at
the moment, so I can drop this patch if we think its too much noise.
I guess it was more of a reaction the filesystem implicitly setting
mount flags which might override whatever the user intended.  FWIW
SB_SYNCHRONOUS did seem to have an effect on behavior (although I
didn't specifically track down where) -- I noticed this because the
problems Christian found seemed to go away if I mounted the filesystem
with sync (which basically ended up overriding aspects of the cache
configuration I guess).

     -eric

On Sat, Feb 18, 2023 at 3:34 AM <asmadeus@...ewreck.org> wrote:
>
> Eric Van Hensbergen wrote on Sat, Feb 18, 2023 at 12:33:16AM +0000:
> > These flags just add unnecessary extra operations.
> > When 9p is run without cache, it inherently implements
> > these options so we don't need them in the superblock
> > (which ends up sending extraneous fsyncs, etc.).  User
> > can still request these options on mount, but we don't
> > need to set them as default.
>
> Hm, I don't see where they'd add any operations -- if you have time
> would you mind pointing me at some?
>
> As far as I can see, it's just about 'sync' or 'dirsync' in /proc/mounts
> and the ST_SYNCHRONOUS statvfs flag; that looks harmless to me and it
> looks more correct to keep to me.
>
> (Sorry, didn't take the time to actually try taking a trace; I've
> checked the flag itself and the IS_SYNC/IS_DIRSYNC -> inode_needs_sync
> wrappers and that only seems used by specific filesystems who'd care
> about users setting the mount options, not the other way aorund.)
>
> --
> Dominique