linux-kernel - Re: [PATCH 4.19 35/98] NFS: Fix regression whereby fscache errors are appearing on nofsc mounts

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:   Wed, 28 Aug 2019 12:52:26 +0000
From:   Trond Myklebust <trondmy@...merspace.com>
To:     "pavel@...x.de" <pavel@...x.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "sashal@...nel.org" <sashal@...nel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "steved@...hat.com" <steved@...hat.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>
Subject: Re: [PATCH 4.19 35/98] NFS: Fix regression whereby fscache errors are
 appearing on nofsc mounts

On Wed, 2019-08-28 at 09:11 +0200, Pavel Machek wrote:
> On Tue 2019-08-27 09:50:14, Greg Kroah-Hartman wrote:
> > [ Upstream commit dea1bb35c5f35e0577cfc61f79261d80b8715221 ]
> > 
> > People are reporing seeing fscache errors being reported concerning
> > duplicate cookies even in cases where they are not setting up
> > fscache
> > at all. The rule needs to be that if fscache is not enabled, then
> > it
> > should have no side effects at all.
> > 
> > To ensure this is the case, we disable fscache completely on all
> > superblocks
> > for which the 'fsc' mount option was not set. In order to avoid
> > issues
> > with '-oremount', we also disable the ability to turn fscache on
> > via
> > remount.
> 
> Actually, the code seems to suggest that you disable the ability to
> turn fscache _off_ via remount, too.
> 
> Is that intentional?
> 

Yes. That is intentional. Otherwise we would have to clear all the
fscache cookies from the inodes.

> Best regards,
> 								Pavel
> 
> > @@ -2239,6 +2239,7 @@ nfs_compare_remount_data(struct nfs_server
> > *nfss,
> >  	    data->acdirmin != nfss->acdirmin / HZ ||
> >  	    data->acdirmax != nfss->acdirmax / HZ ||
> >  	    data->timeo != (10U * nfss->client->cl_timeout->to_initval
> > / HZ) ||
> > +	    (data->options & NFS_OPTION_FSCACHE) != (nfss->options &
> > NFS_OPTION_FSCACHE) ||
> >  	    data->nfs_server.port != nfss->port ||
> >  	    data->nfs_server.addrlen != nfss->nfs_client->cl_addrlen ||
> >  	    !rpc_cmp_addr((struct sockaddr *)&data->nfs_server.address,
-- 
Trond Myklebust
CTO, Hammerspace Inc
4300 El Camino Real, Suite 105
Los Altos, CA 94022
www.hammer.space