lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 03 Nov 2021 09:49:27 +0000 From: bugzilla-daemon@...zilla.kernel.org To: linux-ext4@...r.kernel.org Subject: [Bug 214927] New: re-mount read-write (mount -oremount,rw) of read-only filesystem rejected with EROFS, but block device is nor read-only https://bugzilla.kernel.org/show_bug.cgi?id=214927 Bug ID: 214927 Summary: re-mount read-write (mount -oremount,rw) of read-only filesystem rejected with EROFS, but block device is nor read-only Product: File System Version: 2.5 Kernel Version: 4.12.14-122.91-default (SLES12 SP5) Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext3 Assignee: fs_ext3@...nel-bugs.osdl.org Reporter: Ulrich.Windl@...uni-regensburg.de Regression: No I think there's a kernel or filesystem bug related to ext3: We run a SLES12 SP5 Xen PVM that gets its system disk from a sparse file located on a SLES15 SP2 Xen host using OCFS2 (the host is a node in a pacemaker cluster). The OCFS2 filesystem became full or almost full, and thus the ext3 filesystem(s) experienced write errors, remounting to read-only. So far, so good, but: The errors behavior of ext 3 was set to "continue", so I wonder why it had been set to read-only at all. Next, after having extended the OCFS2 filesystem size, any remount-attempt fails with: mount: /: cannot remount /dev/... read-write, is write-protected. I strace-d the mount command and the mount syscall is returning EROFS (Read-only filesystem). However in the VM configuration on the host the disk is marked read-write, the disk in the VM is flagged read-write, also the VG, LVs, etc. I checked the /sys/block/*/ro, too: It's all "0". I also did an fsck (which succeeded), but still after that the error is the same. Interestingly I noticed that after a *failed* remount attempt, the filesystem (that is mounted read-only) got the error flag being set again. The only conclusion I have is that there is at least one kernel bug regarding the read-only status of the block device. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Powered by blists - more mailing lists