From patchwork Wed Feb 20 06:11:43 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ronnie Sahlberg X-Patchwork-Id: 10821379 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B457113B5 for ; Wed, 20 Feb 2019 06:11:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 973412DF2D for ; Wed, 20 Feb 2019 06:11:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 932062DF1B; Wed, 20 Feb 2019 06:11:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 388EA2DF1B for ; Wed, 20 Feb 2019 06:11:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726592AbfBTGLy (ORCPT ); Wed, 20 Feb 2019 01:11:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726421AbfBTGLx (ORCPT ); Wed, 20 Feb 2019 01:11:53 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BA5CC6698A; Wed, 20 Feb 2019 06:11:53 +0000 (UTC) Received: from test1135.test.redhat.com (vpn2-54-96.bne.redhat.com [10.64.54.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3B1184242; Wed, 20 Feb 2019 06:11:52 +0000 (UTC) From: Ronnie Sahlberg To: linux-cifs Cc: Steve French , Pavel Shilovsky Subject: [PATCH 0/2] Simplify handling of credits in compound_send_recv() Date: Wed, 20 Feb 2019 16:11:43 +1000 Message-Id: <20190220061145.28241-1-lsahlber@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 20 Feb 2019 06:11:53 +0000 (UTC) Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Pavel, Steve, I think we can simplify the credits handling in compound_send_recv() a bit. The first patch adds an extra argument to wait_for_free_request() and allows us to atomically wait for n (n >= 1) requests/credits instead of just a single one. All callsites pass 1 as number of requests so no behaviour should be changed. The second patch uses this new feature to now atomically wait for num_rqst requests/credits in one single call. This makes the code much simpler, since we no longer need to return the credits if we only got a partial number of requests (can no longer happen). It also solves a potential deadlock if we have many concurrent threads trying to allocate requests/credits at the same time. I.e. each one grabs one or two requests but then block on the final request. We still have the issue that if we we do not have enough credits for the compound, and the server will not grant us any additional credits in any responses yet to be received, and the client is not doing any other I/O which might bump the number of requests, then we might block indefinitely, or until the session is reconnected. That is unchanged but should be a lot rarer since we no longer have the deadlock between many concurrent threads.