From patchwork Wed Dec 19 17:10:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?b?0JPQtdC+0YDQs9C40Lkg0JHRi9GB0YLRgNC10L3QuNC9?= X-Patchwork-Id: 1016201 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-cifs-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Xr/LXLg6"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 43KhHR4bTwz9s1c for ; Thu, 20 Dec 2018 04:10:59 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729255AbeLSRK6 (ORCPT ); Wed, 19 Dec 2018 12:10:58 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:33020 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726555AbeLSRK6 (ORCPT ); Wed, 19 Dec 2018 12:10:58 -0500 Received: by mail-lj1-f195.google.com with SMTP id v1-v6so18099712ljd.0 for ; Wed, 19 Dec 2018 09:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=oupfvznlufP1dcG54/oGcgo8b+CdhKwCpdrdoZf4ZzU=; b=Xr/LXLg6nChnNigxORO9LqIYXM1ExKYouygBeCX45Rr/LSxGa5bzy5Z5dZaBq+tlJK FLGIcZD95MJOo+8yC1wYovokROZE+dN8dxkCAecV/RkLeDrJB6m9xiHBZIeeI6SjH9dh 3n61161MGUBJhA5cIAse100gu0Zkm6oqSfm0BH6BZ5sqNjiqH2nfX2fHszvjdITs2IQE luvIO6ptKQoMVFn85ea0Bo21oc62mAu2F/53G91SrouJOup4X4YnnzAIITBaxgA1P2AZ xqpHkHMmne5l5habTic9Xf1/NsMpii9RcAcdVhpM6Bw3W4ZkS1wJUPBHYZlcUbqmiGg4 GrnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=oupfvznlufP1dcG54/oGcgo8b+CdhKwCpdrdoZf4ZzU=; b=Lteg9RCf8i1U7vVC+BmJm4B/6WosVwPWyPf/A0ncBx/zdggq6alD0ptMwjfBVEYK6I XbuNao4JUyN4QFAgX+hH1Ixa2xvRs4QujgFxorfuii+uP3f7kh/UWcMh/OJjSVKlFHtJ 4h9TIkhcrhyxaphWgnBMcierpGyHvAlwGv9Jal4HFdZ67qCQ9WygLRVP9QyHgxDtkDAO ZKhWOr5hVIDguzITY0Mr7HboAu9NOVD5H82VhnyQXSQ2o0Hom9GlSrF9xddCiruGjyIA //4gznMArseOPdzSSNpUIAz9Sl+2zTnHWKqAcj+0PvmnFLek/viasii99N5b0EPzbQyk 21UA== X-Gm-Message-State: AA+aEWaQhdm7VTtSWOz7tlIzYd8r+og01UbYVm2ZKj8/0diW20kpc4a7 DtDxToHjX8TowzsMx7bX9CwpTr/I+S6e4sFKnzIo/1mt X-Google-Smtp-Source: AFSGD/UlE6TFrzG44rCxq4eMM6QQ/svyayT2dQ2O2JULhfkcIJXmAP5kYNn1eSeQD+CXgNbMu8en558fg2ELvDrViAk= X-Received: by 2002:a2e:2106:: with SMTP id h6-v6mr12775710ljh.37.1545239455325; Wed, 19 Dec 2018 09:10:55 -0800 (PST) MIME-Version: 1.0 From: =?utf-8?b?0JPQtdC+0YDQs9C40Lkg0JHRi9GB0YLRgNC10L3QuNC9?= Date: Wed, 19 Dec 2018 21:10:42 +0400 Message-ID: Subject: [PATCH] cifs: Fixed OFD locks do not conflict with eachother To: linux-cifs@vger.kernel.org Cc: Pavel Shilovskiy , Michael Shigorin , Evgeny Sinelnikov Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org 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] (https://github.com/torvalds/linux/blob/master/fs/cifs/netmisc.c#L66) but for SMB2+ mapping is [STATUS_LOCK_NOT_GRANTED to -EIO] (https://github.com/torvalds/linux/blob/master/fs/cifs/smb2maperror.c#L383) 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 --- fs/cifs/smb2maperror.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) "STATUS_CTL_FILE_NOT_SUPPORTED"}, -- 2.17.1 diff --git a/fs/cifs/smb2maperror.c b/fs/cifs/smb2maperror.c index 62c88dfed57b..d7e839cb773f 100644 --- a/fs/cifs/smb2maperror.c +++ b/fs/cifs/smb2maperror.c @@ -378,8 +378,8 @@ static const struct status_to_posix_error smb2_error_map_table[] = { {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,