From patchwork Sat Feb 27 09:26:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pavel Shilovsky X-Patchwork-Id: 8444051 Return-Path: X-Original-To: patchwork-cifs-client@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 54F89C0553 for ; Sat, 27 Feb 2016 09:26:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 85889201D3 for ; Sat, 27 Feb 2016 09:26:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3E3D82010F for ; Sat, 27 Feb 2016 09:26:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756115AbcB0J0i (ORCPT ); Sat, 27 Feb 2016 04:26:38 -0500 Received: from mail-ig0-f169.google.com ([209.85.213.169]:36588 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756127AbcB0J0e (ORCPT ); Sat, 27 Feb 2016 04:26:34 -0500 Received: by mail-ig0-f169.google.com with SMTP id xg9so48831551igb.1 for ; Sat, 27 Feb 2016 01:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=p2uB7QVVJEiWpsspERpmE6EM2SH3Co0tHlSgJfsUq9g=; b=eG5HlWfXJiCjn9Xph3M2YcmByaaEr1GsrANz8aMwr3Biwkmj40BjSlYUsZOxmXfFqz PWNrqMcDtKmBpVLwawgmH3/meaIIdO0SuWi6HlHuTTz6zN1wounMhJlhrGp3Z8AS/De8 xGnr14e4q7F1ruj6fCK5CSUCo/xZPAstloey+myt51Z+BWkiqqRJyBSQ16Ffex1WLONo inFntlcmGQF5A7xO0zFh3+S3hKB+HFGQ7+VBAlexkE3g+9twKuMjjHQ50yX/9yL+/9ui ruB6S85ReYnx9JD79P53nAOh6jR4zwu9V65Rk6iXmLcAEmxKqUCygF+xhdMyRmUmtkBR Usjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=p2uB7QVVJEiWpsspERpmE6EM2SH3Co0tHlSgJfsUq9g=; b=YKps7xAqY8pSjAcgGe5hQTx5mx/720jVLxE/ocys5BZNwcRODjWmMMjvnCBXC0idlO 193+VS+PLUZhT0T69OYyYDoE4XhqvYVCK1YZR6UwHhpfhdgHK/hJSuHdJawP0exkLEzS HrZTOS3wSAnIr0ivozwXiPY8cdDFTjtqMfsD8BLbP6E8hnUCNnET5ctbIxLCXmyGkH6I 5mPxKEW2e20C70mv32cJCzdyveA6CE00ZIUYyB5pXF/PjKBYBS/uWFeHVKf84VjmeNEF Xe6fgxinYWs/BLDwJu2wKWTIsA7WQGOAUzx/MQ3zOJhw4rTu4qQoK3H+lAQraMqgKtk7 7DCQ== X-Gm-Message-State: AD7BkJLBfsoFqN8WMmTDQqTGZKs3nfAdExAIzpzrP1Sfz8h1DsEzm008TRHNlrRIb3JFtF+NIZZMzc9huxzhAw== MIME-Version: 1.0 X-Received: by 10.50.160.41 with SMTP id xh9mr1783384igb.76.1456565193407; Sat, 27 Feb 2016 01:26:33 -0800 (PST) Received: by 10.64.81.107 with HTTP; Sat, 27 Feb 2016 01:26:33 -0800 (PST) In-Reply-To: References: Date: Sat, 27 Feb 2016 12:26:33 +0300 X-Google-Sender-Auth: awQtdRu17Afaisx_0MQBHCmH5nQ Message-ID: Subject: Re: Interop Issue: SMB2+ async replies, and the kernel, Samba side fix enclosed. From: Pavel Shilovsky To: Ira Cooper Cc: Samba Technical , linux-cifs , sfrench Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 2016-02-27 12:11 GMT+03:00 Pavel Shilovsky : > > 2016-02-23 15:55 GMT+03:00 Ira Cooper : >> >> If the server sends an interim response, then the real response, the real >> response, is handled by standard_receive3() in the kernel, instead of the >> proper function, and this causes a disconnect. If there isn't a >> disconnect, I believe the reply will just be discarded if I understand the >> code correctly. (That is a big if here ;) ) >> >> I've written a patch for Samba to stop sending interim replies on SMB2_READ >> and SMB2_WRITE, when non-compounded to stop the impact of this issue. We >> may want to add SMB2_CREATE to the list of ops we don't send async replies >> for non-compounded, but I'm not sold either way, I know we CAN go async >> there! I want some opinions here. >> >> This is not hidden behind a flag because compatibility issues that don't >> impact protocol correctness usually aren't. >> >> Setting req->async_te = talloc_new(NULL); is just ugly, though it works. >> If you have a cleaner approach, I welcome it. >> >> I request you please ASK me before pushing this one, yes, that means you >> jra! >> >> For those interested in reproduction: I'd suggest using a server that's >> rebuilt with a lower timeout set in smb2_read.c, though we've hit it with >> vfs_glusterfs straight up, in our testing. >> >> Thanks, >> >> -Ira / ira@(samba.org|redhat.com|wakeful.net) > > > > Thank you for catching this! > > It is the issue in the kernel client - a check for interim responses is missed for SMB2_READ command. I created a patch that should fix the problem. > > Could you please test it? > > -- > Best regards, > Pavel Shilovsky CC'ing @samba-technical (my original email was rejected by the server). Sorry for the spam. From 09904bf0c6a1ecc7f61d4755db33b762b53176d6 Mon Sep 17 00:00:00 2001 From: Pavel Shilovsky Date: Sat, 27 Feb 2016 11:58:18 +0300 Subject: [PATCH] CIFS: Fix SMB2+ interim response processing for read requests For interim responses we only need to parse a header and update a number credits. Now it is done for all SMB2+ command except SMB2_READ which is wrong. Fix this by adding such processing. Signed-off-by: Pavel Shilovsky --- fs/cifs/cifssmb.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index 90b4f9f..76fcb50 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -1396,11 +1396,10 @@ openRetry: * current bigbuf. */ static int -cifs_readv_discard(struct TCP_Server_Info *server, struct mid_q_entry *mid) +discard_remaining_data(struct TCP_Server_Info *server) { unsigned int rfclen = get_rfc1002_length(server->smallbuf); int remaining = rfclen + 4 - server->total_read; - struct cifs_readdata *rdata = mid->callback_data; while (remaining > 0) { int length; @@ -1414,10 +1413,20 @@ cifs_readv_discard(struct TCP_Server_Info *server, struct mid_q_entry *mid) remaining -= length; } - dequeue_mid(mid, rdata->result); return 0; } +static int +cifs_readv_discard(struct TCP_Server_Info *server, struct mid_q_entry *mid) +{ + int length; + struct cifs_readdata *rdata = mid->callback_data; + + length = discard_remaining_data(server); + dequeue_mid(mid, rdata->result); + return length; +} + int cifs_readv_receive(struct TCP_Server_Info *server, struct mid_q_entry *mid) { @@ -1446,6 +1455,12 @@ cifs_readv_receive(struct TCP_Server_Info *server, struct mid_q_entry *mid) return length; server->total_read += length; + if (server->ops->is_status_pending && + server->ops->is_status_pending(buf, server, 0)) { + discard_remaining_data(server); + return -1; + } + /* Was the SMB read successful? */ rdata->result = server->ops->map_error(buf, false); if (rdata->result != 0) { -- 2.1.4