From patchwork Tue Sep 6 15:12:34 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 9317201 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0A9F5607D3 for ; Tue, 6 Sep 2016 15:12:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2A34628DE5 for ; Tue, 6 Sep 2016 15:12:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1F19128DE6; Tue, 6 Sep 2016 15:12:56 +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=-6.9 required=2.0 tests=BAYES_00,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 C770328DEA for ; Tue, 6 Sep 2016 15:12:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933724AbcIFPMp (ORCPT ); Tue, 6 Sep 2016 11:12:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58516 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933737AbcIFPMn (ORCPT ); Tue, 6 Sep 2016 11:12:43 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BBF91C037F62; Tue, 6 Sep 2016 15:12:42 +0000 (UTC) Received: from tlielax.poochiereds.net (ovpn-116-58.rdu2.redhat.com [10.10.116.58]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u86FCeln030277; Tue, 6 Sep 2016 11:12:42 -0400 From: Jeff Layton To: trond.myklebust@primarydata.com Cc: linux-nfs@vger.kernel.org Subject: [PATCH 3/9] nfs: check for POSIX lock capability on server even for flock locks Date: Tue, 6 Sep 2016 11:12:34 -0400 Message-Id: <1473174760-29859-4-git-send-email-jlayton@redhat.com> In-Reply-To: <1473174760-29859-1-git-send-email-jlayton@redhat.com> References: <1473174760-29859-1-git-send-email-jlayton@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 06 Sep 2016 15:12:42 +0000 (UTC) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We may end up in here with a FL_FLOCK lock request. We translate those to POSIX locks on the server, so we need to verify that the server supports them no matter what sort of lock request this is. Signed-off-by: Jeff Layton --- fs/nfs/nfs4proc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 85817e4103ea..e3bf95369daf 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -6135,8 +6135,7 @@ static int _nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lock unsigned char fl_flags = request->fl_flags; int status = -ENOLCK; - if ((fl_flags & FL_POSIX) && - !test_bit(NFS_STATE_POSIX_LOCKS, &state->flags)) + if (!test_bit(NFS_STATE_POSIX_LOCKS, &state->flags)) goto out; /* Is this a delegated open? */ status = nfs4_set_lock_state(state, request);