Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:43971 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751561AbbEARiA (ORCPT ); Fri, 1 May 2015 13:38:00 -0400 Date: Fri, 1 May 2015 10:37:59 -0700 From: Christoph Hellwig To: Trond Myklebust Cc: Christoph Hellwig , Chuck Lever , "J. Bruce Fields" , Linux NFS Mailing List Subject: Re: [PATCH, RFC] backchannel overflows Message-ID: <20150501173759.GA23778@infradead.org> References: <20150429173454.GA23284@fieldses.org> <20150430062558.GA25660@infradead.org> <2ED34DBC-D928-4F1F-B5EF-B9F77D8AA075@oracle.com> <20150430143731.GA22038@infradead.org> <20CCFEFF-8D28-431C-A1E2-5E42FB42D8FB@oracle.com> <20150501172345.GB29624@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On Fri, May 01, 2015 at 01:28:12PM -0400, Trond Myklebust wrote: > The concern is not so much static vs dynamic. The concern is limiting > incoming RPC calls to the number allowed by the NFSv4.1 session. Right > now, the static allocation enforces the limit of 1 slot that the > client offers to the server (albeit with the race) and so I want any > replacement to meet the same requirement. Either variant will allow accepting more than one backchannel request at the RPC layer, that's the whole point. With the simple patch I posted it will accept a 2nd one, with dynamic allocation the number would be potentially unbound. But given that the NFS client already enforces the slot limit properly in validate_seqid, and even returns the proper nfs error for this case I don't really see what enforcing it at a lower level we we can't even report proper errors buys us.