Hi Linus,
Here are a set of miscellaneous small fixes to the afs filesystem
including:
(1) Fix the afs_server_list struct to be cleaned up with RCU.
(2) Fix afs to translate a no-data result from a DNS lookup into ENOENT,
not EDESTADDRREQ for consistency with OpenAFS.
(3) Fix afs to translate a negative DNS lookup result into ENOENT rather
than EDESTADDRREQ.
(4) Fix file locking on R/O volumes to operate in local mode as the server
doesn't handle exclusive locks on such files.
(5) Set SB_RDONLY on superblocks for RO and Backup volumes so that the VFS
can see that they're read only.
Btw, I did want to ask about (5): Does a superblock being marked SB_RDONLY
imply immutability to the application? A 'read only' AFS volume is a snapshot
of a writable volume and can be updated. It's only read-only in the sense you
can't perform normal filesystem modification ops on it.
Link: https://lore.kernel.org/r/[email protected]/ # v1
Reviewed-by: Jeffrey Altman <[email protected]>
Thanks,
David
---
The following changes since commit 76df934c6d5f5c93ba7a0112b1818620ddc10b19:
MAINTAINERS: Add netdev subsystem profile link (2023-11-17 03:44:21 +0000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/afs-fixes-20231124
for you to fetch changes up to 68516f60c1d8b0a71e516d630f66b99cb50e0150:
afs: Mark a superblock for an R/O or Backup volume as SB_RDONLY (2023-11-24 14:52:24 +0000)
----------------------------------------------------------------
AFS Fixes
----------------------------------------------------------------
David Howells (5):
afs: Fix afs_server_list to be cleaned up with RCU
afs: Make error on cell lookup failure consistent with OpenAFS
afs: Return ENOENT if no cell DNS record can be found
afs: Fix file locking on R/O volumes to operate in local mode
afs: Mark a superblock for an R/O or Backup volume as SB_RDONLY
fs/afs/dynroot.c | 4 ++--
fs/afs/internal.h | 1 +
fs/afs/server_list.c | 2 +-
fs/afs/super.c | 4 ++++
fs/afs/vl_rotate.c | 10 ++++++++++
5 files changed, 18 insertions(+), 3 deletions(-)
On Fri, 24 Nov 2023 at 07:52, David Howells <[email protected]> wrote:
> Btw, I did want to ask about (5): Does a superblock being marked SB_RDONLY
> imply immutability to the application?
Obviously not - any network filesystem can and will change from under
you, even if the local copy is read-only.
So SB_RDONLY can only mean that writes to that instance of the
filesystem will fail.
It's a bit stronger than MNT_READONLY, in that for a *local*
filesystem, SB_RDONLY tends to mean that it's truly immutable (while
MNT_READONLY is obviously per mount) but even then some sub-mount
thing (and I guess the AFS snapshot is a good example of that) might
expose the same filesystem through multiple superblocks.
Exactly like a network filesystem inevitably will.
In any case, any user space that thinks SB_RDONLY is some kind of
immutability signal is clearly buggy. At a minimum, such user space
would have to limit itself to particular filesystem types and say "I
know _this_ filesystem can have only one superblock"). And I'd argue
that while that might work in practice, it's insane.
Linus
The pull request you sent on Fri, 24 Nov 2023 15:52:20 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/afs-fixes-20231124
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5b7ad877e4d81f8904ce83982b1ba5c6e83deccb
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html