Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 10 Oct 2022 18:56:50 +0200
From:   Guillaume Nault <gnault@redhat.com>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        Jeff Layton <jlayton@kernel.org>, linux-nfs@vger.kernel.org,
        Paolo Abeni <pabeni@redhat.com>,
        Benjamin Coddington <bcodding@redhat.com>
Subject: Re: [PATCH v2] sunrpc: Use GFP_NOFS to prevent use of
 current->task_frag.
Message-ID: <20221010165650.GA3456@ibm-p9z-18-fsp.mgmt.pnr.lab.eng.rdu2.redhat.com>
References: <de6d99321d1dcaa2ad456b92b3680aa77c07a747.1665401788.git.gnault@redhat.com>
 <Y0QyYV1Wyo4vof70@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y0QyYV1Wyo4vof70@infradead.org>
Precedence: bulk

On Mon, Oct 10, 2022 at 07:55:29AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 10, 2022 at 01:41:57PM +0200, Guillaume Nault wrote:
> > However, ->sk_allocation isn't used just by the memory allocator.
> > In particular, sk_page_frag() uses it to figure out if it can return
> > the page_frag from current or if it has to use the socket one.
> 
> Well, that just means sk_page_frag really needs to look at
> PF_MEMALLOC_* as well.  So instead of reverting the proper change
> please fix that.  A helper that looks at sk_allocation and
> current->flags is probably the right way to deal with that.

That's what my RFC patch did. It was rejected because reading
current->flags may incur a cache miss thus slowing down TCP fast path.
See the discussion in the Link tag:
https://lore.kernel.org/netdev/b4d8cb09c913d3e34f853736f3f5628abfd7f4b6.1656699567.git.gnault@redhat.com/