linux-kernel - Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 06 Feb 2007 11:45:44 +1100
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Christoph Hellwig <hch@....de>
Cc:	akpm@...l.org, haveblue@...ibm.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)

Hi.

On Mon, 2007-02-05 at 18:32 +0100, Christoph Hellwig wrote:
> Hi there,
> 
> in two recent discussions (file_list_lock scalability and remount r/o
> on suspend) I stumbled over this emergency remount feature.  It's not
> actually useful because it tries a potentially dangerous remount
> despite writers still beeing in progress, which we can't get rid.
> 
> I've attached one patch in this mail that simply kills the
> functionality, and in a reply to this mail I'll send a second one
> that keeps the sysrq functionality, but removes the force argument
> from do_remount_sb that overrides the still busy check.  This version
> is currently not useful, but makes a lot of sense once Dave Hansens
> per-mountpoint r/o patches get in, as we can check for a real write
> in progress instead of simply a file opened with write permission.
> 
> Any ideas and comments?

I'm not really keen - it sometimes get's invoked here and by others in a
sysrq-s sysrq-u sysrq-b sequence (sync, unmount, reboot) in a context
where things have gone south (particularly if there's some process
stuck). In that context it helps make filesystems cleaner than they'd
otherwise be, and the fact that writers might still be in progress is
irrelevant because the next keypress is going to reboot anyway.

Ok. I'll admit to being a heretic ext3 user, loving not having to fsck
after the above and still getting zero corruption as a result.

Regards,

Nigel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/