Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2997505yba; Sat, 18 May 2019 07:21:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGzSVH1aUOyFpe2+pbKBumeZW5xDnwYPyvDKe1iwYC5yM7MQrt8KTVWjjo0vANeJyQTNfd X-Received: by 2002:a62:ac01:: with SMTP id v1mr5876780pfe.110.1558189273957; Sat, 18 May 2019 07:21:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558189273; cv=none; d=google.com; s=arc-20160816; b=B1qT7tZ7v8mXce4T/kOW4XDP/YR69/peIB/6iacrn+Tgitg+5SoV2sdRHAPk2gKS+Z XkAIduXimT558ytdvUhRIS8GQINPQA/jIrlbZj56EXUslPLYGbo8PfNnRRmYjQ3gYJxZ jLRuHsaFbkom9h/0xhkTSmG/QgJ3KoFeuHK9IDw+YPWTugRnRYOiSL6dgHFinhDROoxw 415xj3hLcrVVoZS97FuT0is6KBzi/jWDKW1jxKoaPSj4doVv9CeQmxgvyGFAnoBb2+Mr LPSdTKfMck95LkMFRYNJ21BTy6UWToVLzLWvd+zpxFxC3wpxcfX5lf7qMnUDl06LB/PF j6pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=GCD9zJ80HqNQAcUO6yN6gZhMUSfoVeOqXz/GJ1r0lX0=; b=wh7FdrVbGfUYrjWEK+6PErfQ6KW3FMhT+gIsvaJDcy98vpPRp111Mgrh3yG/oyeWeb rcZQL/ikLplKznfSPU3WmkYSm10TQ6feZmsChaNzCn2ZAR4HWf0n1b+mVLIUqna7bGA6 EXNHgQ4KUQ46tSXy7wcyoMwB1+Vy/MPqxfcDTtrwM6ABove+LQxnyHqnj/2FEW3ded/G ITQ76zMGxvdERbEWIj2FSaV47gRm/CSvaozEy5gc/yrMHjzkoEddg1tLRq1/6vQQI1x+ drc1s5a6OvOl/ykmTxt40itYfNx0YHlKSszyYN/m+jUEnvCrwffhsLuCLOyZQxLcrJGe qxFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d6si11926982pln.144.2019.05.18.07.20.46; Sat, 18 May 2019 07:21:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-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-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729858AbfERMJn (ORCPT + 99 others); Sat, 18 May 2019 08:09:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54606 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729791AbfERMJn (ORCPT ); Sat, 18 May 2019 08:09:43 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 701623082E4D; Sat, 18 May 2019 12:09:43 +0000 (UTC) Received: from [10.10.66.2] (ovpn-66-2.rdu2.redhat.com [10.10.66.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 98B252D1C6; Sat, 18 May 2019 12:09:41 +0000 (UTC) From: "Benjamin Coddington" To: "Xuewei Zhang" Cc: bfields@fieldses.org, "Grigor Avagyan" , "Trevor Bourget" , "Nauman Rafique" , trond.myklebust@hammerspace.com, anna.schumaker@netapp.com, jlayton@kernel.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH] lockd: Show pid of lockd for remote locks Date: Sat, 18 May 2019 08:09:42 -0400 Message-ID: <3A924C3F-A161-4EE2-A74E-2EE1B6D2CA14@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Sat, 18 May 2019 12:09:43 +0000 (UTC) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 17 May 2019, at 17:45, Xuewei Zhang wrote: > Seems this patch introduced a bug in how lock protocol handles > GRANTED_MSG in nfs. Yes, you're right: it's broken, and broken badly because we find conflicting locks based on lockd's fl_pid and lockd's fl_owner, which is current->files. That means that clients are not differentiated, and that means that v3 locks are broken. I'd really like to see the fl_pid value make sense on the server when we show it to userspace, so I think that we should stuff the svid in fl_owner. Clearly I need to be more careful making changes here, so I am going to take my time fixing this, and I won't get to it until Monday. A revert would get us back to safe behavior. Ben