Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1318465yba; Tue, 2 Apr 2019 06:47:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqy+hCyrOwzoObGo+N3JqO1ruqZ/1oLn0gA/2iMddNEeQOox3ngLfIS5CthXmr0mL3qY0oxe X-Received: by 2002:a63:4f1c:: with SMTP id d28mr13506430pgb.144.1554212847871; Tue, 02 Apr 2019 06:47:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554212847; cv=none; d=google.com; s=arc-20160816; b=Y9vBzVTDj70YTMR7cum7M9SMJ3s3e8PDrwBfiAsWx66gv4NHskfZcsgk4pGkEDPbYp fPRcNh/O+u9gyZs2PAjJCA0cFJEQH8BI0EgkRXKBhYJh/sY5BOADkIXidJzhFAUextQp T0dX5DScDlUWb2W2XsYLSGmto8+/UehPuHYAR0pk44uIg8EseqIjU37jXsT9kIWbyQ9A jWwFIhNY+xdmCL3QaTYjdLPoJnQGsxhuCFaJ58gqabGuf2ArZqPBdK4whcj05i8o+0Uv Z1xIelrt9WWUEzz4Ke3cCD8nCOeT92cdRdojwx+d1nFzURK1ZUtHt5aIADmP7iaUSPLD 2JjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=2mZQyWtPfLHfap5vJ7jOQwZJyjQ0IklfMib4fgArVd4=; b=pGFuugJH7/q6r+TCKjxtf2/AMJ1wjtOsFkpzXgqHeLdVZZZt+tXo8tdFUSW18E7khi JLHUEGVJqNtsp8zO65w0BYgwJz1A9ypKPINijauYlV7PLC4Vmw1B+Sby8ETgJH5RDcjk MI6hxptyJSFogt+HBJ+8ShIzxyQoAvnssH+Kj1miMhWKE+QjUJmVPei69nYhdDApfG0N rC0FLUgk4Sawt6GCz4I6GIj4UwNpS3Csq3MhM3tNHcFpt9yoQ8RhjvQgOYJ0MeU10MdT BRrnB4foEuARVAzDYSSRuGHUtVSzT/ebbT0sw7vFbPkS11KF6aOiBrB4pt2zuZdtnDse wyDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n9si11181879pgc.472.2019.04.02.06.47.12; Tue, 02 Apr 2019 06:47:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732059AbfDBNox (ORCPT + 99 others); Tue, 2 Apr 2019 09:44:53 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:43418 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731470AbfDBNkI (ORCPT ); Tue, 2 Apr 2019 09:40:08 -0400 Received: from [167.98.27.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hBJe0-0002oJ-J5; Tue, 02 Apr 2019 14:40:04 +0100 Received: from ben by deadeye with local (Exim 4.92) (envelope-from ) id 1hBJdx-0004wl-JY; Tue, 02 Apr 2019 14:40:01 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Steve French" , "Georgy A Bystrenin" , "Pavel Shilovsky" Date: Tue, 02 Apr 2019 14:38:28 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 78/99] CIFS: Fix error mapping for SMB2_LOCK command which caused OFD lock problem In-Reply-To: X-SA-Exim-Connect-IP: 167.98.27.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.65-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Georgy A Bystrenin commit 9a596f5b39593414c0ec80f71b94a226286f084e upstream. While resolving a bug with locks on samba shares found a strange behavior. When a file locked by one node and we trying to lock it from another node it fail with errno 5 (EIO) but in that case errno must be set to (EACCES | EAGAIN). This isn't happening when we try to lock file second time on same node. In this case it returns EACCES as expected. Also this issue not reproduces when we use SMB1 protocol (vers=1.0 in mount options). Further investigation showed that the mapping from status_to_posix_error is different for SMB1 and SMB2+ implementations. For SMB1 mapping is [NT_STATUS_LOCK_NOT_GRANTED to ERRlock] (See fs/cifs/netmisc.c line 66) but for SMB2+ mapping is [STATUS_LOCK_NOT_GRANTED to -EIO] (see fs/cifs/smb2maperror.c line 383) Quick changes in SMB2+ mapping from EIO to EACCES has fixed issue. BUG: https://bugzilla.kernel.org/show_bug.cgi?id=201971 Signed-off-by: Georgy A Bystrenin Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Ben Hutchings --- fs/cifs/smb2maperror.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/cifs/smb2maperror.c +++ b/fs/cifs/smb2maperror.c @@ -377,8 +377,8 @@ static const struct status_to_posix_erro {STATUS_NONEXISTENT_EA_ENTRY, -EIO, "STATUS_NONEXISTENT_EA_ENTRY"}, {STATUS_NO_EAS_ON_FILE, -ENODATA, "STATUS_NO_EAS_ON_FILE"}, {STATUS_EA_CORRUPT_ERROR, -EIO, "STATUS_EA_CORRUPT_ERROR"}, - {STATUS_FILE_LOCK_CONFLICT, -EIO, "STATUS_FILE_LOCK_CONFLICT"}, - {STATUS_LOCK_NOT_GRANTED, -EIO, "STATUS_LOCK_NOT_GRANTED"}, + {STATUS_FILE_LOCK_CONFLICT, -EACCES, "STATUS_FILE_LOCK_CONFLICT"}, + {STATUS_LOCK_NOT_GRANTED, -EACCES, "STATUS_LOCK_NOT_GRANTED"}, {STATUS_DELETE_PENDING, -ENOENT, "STATUS_DELETE_PENDING"}, {STATUS_CTL_FILE_NOT_SUPPORTED, -ENOSYS, "STATUS_CTL_FILE_NOT_SUPPORTED"},