All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Cui <cui.tao@linux.dev>
To: linux-unionfs@vger.kernel.org, miklos@szeredi.hu, amir73il@gmail.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	brauner@kernel.org, jlayton@kernel.org, cui.tao@linux.dev,
	Tao Cui <cuitao@kylinos.cn>
Subject: [PATCH v2] overlayfs.rst: clarify the scope of file locks taken through the overlay
Date: Thu,  3 Sep 2026 21:26:36 +0800	[thread overview]
Message-ID: <20260903132636.1113789-1-cui.tao@linux.dev> (raw)

From: Tao Cui <cuitao@kylinos.cn>

File locks and leases taken on files through the overlay mount are
only meaningful between tasks that access the files through the same
overlay mount; they do not conflict with anything that changes the
underlying filesystems directly.  Add a short note to "Changes to
underlying filesystems" stating this scope.

Signed-off-by: Tao Cui <cuitao@kylinos.cn>
---
Changes since v1:
- minimal note within "Changes to underlying filesystems" instead of a
  separate section, per review (Amir Goldstein)
---
 Documentation/filesystems/overlayfs.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index 16c35b491dad..11af5bc73e32 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -671,6 +671,15 @@ filesystem are not allowed.  If the underlying filesystem is changed,
 the behavior of the overlay is undefined, though it will not result in
 a crash or deadlock.
 
+Note that file locks and leases taken on files through the overlay
+mount only provide mutual exclusion between tasks that access the
+files through the same overlay mount, and a lease taken through the
+overlay is broken by opens through that overlay.  They do not
+conflict with locks taken on the same files by anything that changes
+the underlying filesystems directly, so file locking cannot be relied
+on for mutual exclusion between overlay users and such direct
+changes.
+
 Offline changes, when the overlay is not mounted, are allowed to the
 upper tree.  Offline changes to the lower tree are only allowed if the
 "metacopy", "index", "xino" and "redirect_dir" features
-- 
2.43.0


             reply	other threads:[~2026-09-03 13:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 13:26 Tao Cui [this message]
2026-09-03 13:51 ` [PATCH v2] overlayfs.rst: clarify the scope of file locks taken through the overlay Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260903132636.1113789-1-cui.tao@linux.dev \
    --to=cui.tao@linux.dev \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=cuitao@kylinos.cn \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.