Received-SPF: pass (google.com: domain of linux-ext4+bounces-1765-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 218648] ext4: previously opened file remains writeable on
 readonly ext4 filesystem; Data loss.
Date: Thu, 28 Mar 2024 14:55:22 +0000
Message-ID: <bug-218648-13602-n7LY5ZJJYn@https.bugzilla.kernel.org/>
In-Reply-To: <bug-218648-13602@https.bugzilla.kernel.org/>
References: <bug-218648-13602@https.bugzilla.kernel.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0

https://bugzilla.kernel.org/show_bug.cgi?id=3D218648

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu

--- Comment #1 from Theodore Tso (tytso@mit.edu) ---
Normally, if there is a file opened for writing when there is an attempt to
remount a file system read-only via a command, e.g., "mount -o remount,ro
/dev/sdc", the remount with fail with EBUSY.

The problem is what should we do if the block device has failed or otherwise
disappeared.   In that situation, we can either do absolutely nothing
("errors=3Dcontinue"), panic and halt the system ("errors=3Dpanic"), or rem=
ount the
file-system ("errors=3Dremount-ro").  However, what should be done if there=
 is a
file descriptor open for writing?

1) We could fail the remount, which would mean that the file system would
continue to be mounted read/write, which would cause the behavior to devolv=
e to
"errors=3Dcontinue".

2) We could force the file system to be read-only, but any file descriptors
that are still would be still open --- but attempts to write to the file wi=
ll
fail with EIO.

We've chosen because it's the best we can do.  We can refuse a remount
read-only if it is initiated by the system administrator, if a user yanks t=
he
USB thumb drive out of the laptop, or a terrorist slams a plain into the
machine room at the Pentagon, it's not like the kernel can stop something l=
ike
that from happening.   ("I'm sorry Hal, I'm afraid I can't allow you to do =
that
ala the movie "2001: A Spacey Odessey" is not yet a thing; although maybe
sometime soon our AI Overlords will have that power.  :-)

--=20
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.=