From patchwork Thu Feb 28 06:24:00 2019
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Ronnie Sahlberg <lsahlber@redhat.com>
X-Patchwork-Id: 10832569
Return-Path: <linux-cifs-owner@kernel.org>
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 1B2D813B5
	for <patchwork-cifs-client@patchwork.kernel.org>;
 Thu, 28 Feb 2019 06:24:14 +0000 (UTC)
Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1])
	by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0BC032C78F
	for <patchwork-cifs-client@patchwork.kernel.org>;
 Thu, 28 Feb 2019 06:24:14 +0000 (UTC)
Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486)
	id F1BE32CA1C; Thu, 28 Feb 2019 06:24:13 +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 AD55C2C78F
	for <patchwork-cifs-client@patchwork.kernel.org>;
 Thu, 28 Feb 2019 06:24:13 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726088AbfB1GYN (ORCPT
        <rfc822;patchwork-cifs-client@patchwork.kernel.org>);
        Thu, 28 Feb 2019 01:24:13 -0500
Received: from mx1.redhat.com ([209.132.183.28]:37168 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1725988AbfB1GYN (ORCPT <rfc822;linux-cifs@vger.kernel.org>);
        Thu, 28 Feb 2019 01:24:13 -0500
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
        (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by mx1.redhat.com (Postfix) with ESMTPS id 153A930D039E;
        Thu, 28 Feb 2019 06:24:13 +0000 (UTC)
Received: from test1135.test.redhat.com (vpn2-54-37.bne.redhat.com
 [10.64.54.37])
        by smtp.corp.redhat.com (Postfix) with ESMTP id 8150F601A3;
        Thu, 28 Feb 2019 06:24:12 +0000 (UTC)
From: Ronnie Sahlberg <lsahlber@redhat.com>
To: linux-cifs <linux-cifs@vger.kernel.org>
Cc: Steve French <smfrench@gmail.com>,
        Pavel Shilovsky <pshilov@microsoft.com>
Subject: [PATCH 0/5] Simplify credits handling for compound requests
Date: Thu, 28 Feb 2019 16:24:00 +1000
Message-Id: <20190228062405.32107-1-lsahlber@redhat.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted,
 not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]);
 Thu, 28 Feb 2019 06:24:13 +0000 (UTC)
Sender: linux-cifs-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-cifs.vger.kernel.org>
X-Mailing-List: linux-cifs@vger.kernel.org
X-Virus-Scanned: ClamAV using ClamSMTP

Pavel, Steve,

Here is an updated series that tries to simplify the handling of 
allocating credits to compound requests by using a new method
to atomically wait for n>=1 credits.

Aside from simplifying compound_send_recv() it also solves a potential
(but very unlikely) deadlock that could happen in the current code.

The first two patches are just rearranging the code and changing signatures.
There should not be any change in behaviour from them.

The third patch makes it possible to wait for >1 credits atomically
however no codepath yet uses this.

Fourth patch is to address a potential starvation issue that could happen
IF there are requests for >1 credits.

Fifth patch changes compound_send_recv() to ask for the required n
credits in one atomic wait.