From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ken Sumrall Subject: Re: [PATCH] Syscalls: reboot: Add options to the reboot syscall to remount filesystems ro Date: Thu, 3 Mar 2011 18:00:45 -0800 Message-ID: References: <1299137483-10975-1-git-send-email-ksumrall@android.com> <4D6FDDB1.3060209@teksavvy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Mark Lord , linux-kernel@vger.kernel.org, Alexander Viro , Christoph Hellwig , Andrew Morton , Jan Kara , Jens Axboe , Matthew Wilcox , Eric Paris , Dave Young , Jiri Slaby , James Morris , linux-fsdevel@vger.kernel.org To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Writing a single byte to /proc/sysrq-trigger is an asynchronous operation, with no obvious way to be informed that it has completed the remount. I did actually try this at first, but the reboot happened before the remount finished. I could of course add a sleep of a few seconds, but just how long to wait is not obvious, nor is it a guarantee that the remount will always finish in the time chosen. I'm heading down the path of reading /proc/mounts and remounting all read-wirte filesystems backed by a block device as read-only. ___ Ken On Thu, Mar 3, 2011 at 3:36 PM, Linus Torvalds wrote: > On Thu, Mar 3, 2011 at 10:28 AM, Mark Lord wrot= e: >> On 11-03-03 12:45 PM, Linus Torvalds wrote: >>> >>> If you can change whatever user-land process that does the reboot >>> system call (and clearly you can, since you're adding new commands = and >>> using those), then why the heck don't you just do the remount-ro fr= om >>> that same user land? >> >> Is there a system call for emergency_remount_*() ? >> I've been writing to /proc/proc/sysrq-trigger to accomplish this. > > So I don't know what this has to do with "emergency_remount()" - we'r= e > talking about a regular controlled shutdown/reset. The fact that the > patch used the emergency_remount() code seems to be purely an > implementation issue, nothing more. > > And while sysrq-trigger certainly works (when it's enabled, but that'= s > true of /proc too, of course), I do think it's a rather odd way of > solving the problem, when the simple "just remount read-only" is what > the code actually _wants_ to do. > > But you're certainly right that it takes less code to open > /proc/sysrq-trigger and writing a single byte to it than it does to d= o > the straightforward "let's just do the normal mount thing". > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Linus >