linux-ext4 - Re: [PATCH] vfs: freeze filesystems just prior to reboot

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170519190115.GJ4519@birch.djwong.org>
Date:   Fri, 19 May 2017 12:01:15 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Colin Walters <walters@...bum.org>
Cc:     xfs <linux-xfs@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] vfs: freeze filesystems just prior to reboot

On Fri, May 19, 2017 at 10:00:31AM -0400, Colin Walters wrote:
> On Thu, May 18, 2017, at 08:20 PM, Darrick J. Wong wrote:
> 
> > Therefore, add a reboot hook to freeze all filesystems (which in general
> > will induce ext4/xfs/btrfs to checkpoint the log) just prior to reboot.
> > This is an unfortunate and insufficient workaround for multiple layers
> > of inadequate external software, but at least it will reduce boot time
> > surprises for the "OS updater failed to disengage the filesystem before
> > rebooting" case.
> 
> As a maintainer of one of those userspace tools
> (https://github.com/ostreedev/ostree), which I don't think is the one
> in question here, but likely has the same issue - I'd like to have
> some sort of API to fix this - maybe flush the journal *without*
> remounting r/o?

The convention (at least among ext4 and xfs) is that fs freeze should be
checkpointing the journal.

> Unlike the case you're talking about with rebooting into a special
> update mode, libostree constructs a new root with hardlinks while
> the system is running.  Hence, system downtime is just reboot, like
> dual-partition update systems, except we're more flexible.
> 
> Although hm...I guess an API to flush the journal would only narrow
> the race.
> 
> Is the single partition case really just doomed?  

Probably.  TBH given the current behavior of grub, I would always have a
separate /boot to minimize the amount it's allowed to touch. :)

--D

> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html