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 <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Mar 3, 2011 at 10:28 AM, Mark Lord <kernel@xxxxxxxxxxxx> wrote: >> 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 from >>> 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're > 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 do > the straightforward "let's just do the normal mount thing". > > Linus > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
