linux-kernel - Re: [PATCH v3 RESEND] NFS: Add mount option 'fasc'

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] [day] [month] [year] [list]

Date:   Wed, 30 Aug 2023 13:59:51 +0800
From:   Chengen Du <chengen.du@...onical.com>
To:     Benjamin Coddington <bcodding@...hat.com>
Cc:     trond.myklebust@...merspace.com, anna@...nel.org,
        linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 RESEND] NFS: Add mount option 'fasc'

Hi Benjamin,

I'd like to provide some context about the new behavior introduced by
the commit - 0eb43812c027 "NFS: Clear the file access cache upon
login."
This recent adoption has successfully resolved a long-standing issue.
The current outcome is that the file access cache gets cleared when a
user logs out and subsequently logs back in.

In specific scenarios, users might access NFS-mounted folders via a
'sudo'-like behavior, inadvertently adding to the NFS server's load
due to the inability to use the file cache efficiently.

To alleviate this performance overhead, my proposal centers on
reverting to the original behavior, where the file access cache
remains untouched upon user login.
This stems from the rationale that the cache should only be cleared
when the server's group membership changes after a user has already
logged in on the client.
This alteration rarely occurs in stable environments, thus rendering
the file access cache reliable.
With this in mind, my suggestion involves adding a mount option that
empowers administrators to dictate which NFS-mounted folders adhere to
the POSIX behavior - one that refreshes a user's supplementary group
information upon login.

The genesis of this patch places a premium on performance while also
maintaining alignment with the original behavior prior to the adoption
of the commit 0eb43812c027.
Transitioning to adhere strictly to the POSIX policy also carries merit.
I believe that further discussion can facilitate a consensus on this matter.

Thank you for lending your perspective to this discourse.

Best regards,
Chengen Du

On Tue, Aug 29, 2023 at 9:35 PM Benjamin Coddington <bcodding@...hat.com> wrote:
>
> On 28 Aug 2023, at 3:14, Chengen Du wrote:
>
> > Hi,
> >
> > The performance issue has been brought to our attention by users
> > within the Ubuntu community.
> > However, it seems to be confined to specific user scenarios.
> > Canonical has taken proactive measures to tackle the problem by
> > implementing a temporary solution [1], which has effectively resolved
> > the issue at hand.
> > Nonetheless, our earnest desire is for a definitive resolution of the
> > performance concern at its source upstream.
> >
> > I've taken the initiative to send the patches addressing this matter.
> > Regrettably, as of now, I've yet to receive any response.
> > This situation leads me to consider the possibility of reservations or
> > deliberations surrounding this issue.
> > I am genuinely keen to gain insights and perspectives from the
> > upstream community.
> >
> > I kindly ask for your valuable input on this matter.
> > Your thoughts would significantly aid my progress and contribute to a
> > collective consensus.
>
> Hi Chengen Du,
>
> This patch changes the default behavior for everyone.  Instead of that,
> perhaps the new option should change the behavior.  That would reduce the
> change surface for all NFS users.
>
> The default behavior has already been hotly debated on this list and so I
> think changing the default would need to be accompanied by excellent
> reasons.
>
> Ben
>