linux-kernel - Re: [f2fs-dev] [PATCH] f2fs: give RO message when recovering superblock

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160323211048.GA7279@schmorp.de>
Date:	Wed, 23 Mar 2016 22:10:48 +0100
From:	Marc Lehmann <schmorp@...morp.de>
To:	Jaegeuk Kim <jaegeuk@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: give RO message when recovering
 superblock

On Wed, Mar 23, 2016 at 01:38:19PM -0700, Jaegeuk Kim <jaegeuk@...nel.org> wrote:
> When one of superblocks is missing, f2fs recovers it with the valid one.
> But, even if f2fs is mounted as RO, we'd better notify that too.

(I have written this in my other mail, but in case you didn't see it, because
it wasn't directly sent to you, I replied directly).

Basically all other filesystems do not treat "ro" as anything but as a vfs
flag - the mounted volume will be readonly, but they will happily write to
the volume for recovery or integrity purposes. This has been extensively
discussed on lkml in the past and it was decided that overloading "ro" to
have two different meanings is bad.

If f2fs wants to suppress writes, it should use the norecovery option to
decide, not the ro option. This is the behaviour that other filesystems
follow (at least extN, xfs).

Unless f2fs has a very good reason (which I don't think it has), it should
behave like the other filesystems, and treat "ro" merely as a vfs flag to
suppress writing.

There is a third reason to not change the meaning: typically, the root fs
is mounted ro first and later rw. Therefore f2fs must make sure to have
full integrity on a ro mount, even if that means writing to the backing
store. It isn't acceptable to make ro mounts fail when rw mounts would
work, for example, when upgrading the kernel and rebooting.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@...morp.de
      -=====/_/_//_/\_,_/ /_/\_\