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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 5 Aug 2011 00:25:09 +0200 From: "Rafael J. Wysocki" <rjw@...k.pl> To: Pavel Machek <pavel@....cz> Cc: Nigel Cunningham <nigel@...onice.net>, Christoph Hellwig <hch@...radead.org>, Dave Chinner <david@...morbit.com>, Christoph <cr2005@...lub.de>, Linux PM mailing list <linux-pm@...ts.linux-foundation.org>, xfs@....sgi.com, LKML <linux-kernel@...r.kernel.org>, linux-ext4@...r.kernel.org, "Theodore Ts'o" <tytso@....edu> Subject: Re: [RFC][PATCH] PM / Freezer: Freeze filesystems along with freezing processes (was: Re: PM / hibernate xfs lock up / xfs_reclaim_inodes_ag) On Thursday, August 04, 2011, Rafael J. Wysocki wrote: > On Wednesday, August 03, 2011, Pavel Machek wrote: > > Hi! > > > > > Freeze all filesystems during the freezing of tasks by calling > > > freeze_bdev() for each of them and thaw them during the thawing > > > of tasks with the help of thaw_bdev(). > > > > > > This is needed by hibernation, because some filesystems (e.g. XFS) > > > deadlock with the preallocation of memory used by it if the memory > > > pressure caused by it is too heavy. > > > > > > The additional benefit of this change is that, if something goes > > > wrong after filesystems have been frozen, they will stay in a > > > consistent state and journal replays won't be necessary (e.g. after > > > a failing suspend or resume). In particular, this should help to > > > solve a long-standing issue that in some cases during resume from > > > hibernation the boot loader causes the journal to be replied for the > > > filesystem containing the kernel image and initrd causing it to > > > become inconsistent with the information stored in the hibernation > > > image. > > > > > +/** > > > + * freeze_filesystems - Force all filesystems into a consistent state. > > > + */ > > > +void freeze_filesystems(void) > > > +{ > > > + struct super_block *sb; > > > + > > > + lockdep_off(); > > > > Ouch. So... why do we need to silence this? > > So that it doesn't complain? :-) > > I'll need some time to get the exact details here. So, this is because ext3_freeze() that doesn't call journal_unlock_updates() on success, which quite frankly looks like a bug in ext3 to me. At least that's different from what ext4 does in exactly the same situation (which looks correct). If ext3_freeze() called journal_unlock_updates() on success too and the call to journal_unlock_updates() is removed from ext3_unfreeze(), we wouldn't need that lockdep_off()/lockdep_on() around the loop. I need someone with ext3/ext4 knowledge to comment here, though. Moreover, I'm not sure if other filesystems don't do such things. Anyway, this is just a false-positive, even with the ext3 code as is. > > > + /* > > > + * Freeze in reverse order so filesystems dependant upon others are > > > + * frozen in the right order (eg. loopback on ext3). > > > + */ > > > + list_for_each_entry_reverse(sb, &super_blocks, s_list) { > > > + if (!sb->s_root || !sb->s_bdev || > > > + (sb->s_frozen == SB_FREEZE_TRANS) || > > > + (sb->s_flags & MS_RDONLY) || > > > + (sb->s_flags & MS_FROZEN)) > > > + continue; > > > > Should we stop NFS from modifying remote server, too? > > What do you mean exactly? > > > Plus... ext3 writes to read-only filesystems on mount; not sure if it > > does it later. But RDONLY means 'user cant write to it' not 'bdev will > > not be modified'. Should we freeze all? > > > > How can 'already frozen' happen? > > > > > + list_for_each_entry(sb, &super_blocks, s_list) > > > + if (sb->s_flags & MS_FROZEN) { > > > + sb->s_flags &= ~MS_FROZEN; > > > + thaw_bdev(sb->s_bdev, sb); > > > + } > > > > ...because we'll unfreeze it even if we did not freeze it... > > So we need not check MS_FROZEN in freeze_filesystems(). OK Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists