From nobody Tue Dec 30 11:40:30 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED5F7C5ACB3 for ; Thu, 16 Nov 2023 15:53:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345433AbjKPPxf (ORCPT ); Thu, 16 Nov 2023 10:53:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345423AbjKPPx3 (ORCPT ); Thu, 16 Nov 2023 10:53:29 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 993C819E for ; Thu, 16 Nov 2023 07:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700150004; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BO25tpR4cJ6zDnaYLefhwrjxAjZo0cT3GLAVT5S6v5c=; b=IpCE18dw0AW+utgwBMCTLi6eGdTF6EWPQSOH2r6PKyiDJ078kHIiFquh/1DDrEyAc2gh+n S5bS3S/qMQKZgQFsQK6UfP3UmVDKXyvKMhtBhlY516TOkIa5qeMnq4ONQgNz/gV4Gq6tv+ FdhTYQ+Zs2DRtO9trUwmqL/t0aIVT9o= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-524-TwrH04qRMJORC-m4gYeeZw-1; Thu, 16 Nov 2023 10:53:23 -0500 X-MC-Unique: TwrH04qRMJORC-m4gYeeZw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9CDE01C06916; Thu, 16 Nov 2023 15:53:22 +0000 (UTC) Received: from warthog.procyon.org.com (unknown [10.42.28.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id CEF891121307; Thu, 16 Nov 2023 15:53:21 +0000 (UTC) From: David Howells To: Marc Dionne Cc: David Howells , linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 4/5] afs: Fix file locking on R/O volumes to operate in local mode Date: Thu, 16 Nov 2023 15:53:11 +0000 Message-ID: <20231116155312.156593-5-dhowells@redhat.com> In-Reply-To: <20231116155312.156593-1-dhowells@redhat.com> References: <20231116155312.156593-1-dhowells@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" AFS doesn't really do locking on R/O volumes as fileservers don't maintain state with each other and thus a lock on a R/O volume file on one fileserver will not be be visible to someone looking at the same file on another fileserver. Further, the server may return an error if you try it. Fix this by doing what other AFS clients do and handle filelocking on R/O volume files entirely within the client and don't touch the server. Fixes: 6c6c1d63c243 ("afs: Provide mount-time configurable byte-range file = locking emulation") Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Reviewed-by: Marc Dionne --- fs/afs/super.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/afs/super.c b/fs/afs/super.c index 95d713074dc8..e95fb4cb4fcd 100644 --- a/fs/afs/super.c +++ b/fs/afs/super.c @@ -407,6 +407,8 @@ static int afs_validate_fc(struct fs_context *fc) return PTR_ERR(volume); =20 ctx->volume =3D volume; + if (volume->type !=3D AFSVL_RWVOL) + ctx->flock_mode =3D afs_flock_mode_local; } =20 return 0;