linux-kernel - Re: [PATCH] Introduce freeze_super and thaw

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:	Wed, 24 Mar 2010 09:31:51 +1100
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	Josef Bacik <josef@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, chris.mason@...cle.com, hch@....de
Subject: Re: [PATCH] Introduce freeze_super and thaw_super for the fsfreeze
 ioctl

Hi.

On 24/03/10 02:09, Al Viro wrote:
> On Tue, Mar 23, 2010 at 11:03:01AM -0400, Josef Bacik wrote:
>>> sb is an active reference
>>>
>>
>> I don't understand how this is an active reference?  We are talking about
>> s_active right?
>
> It's an opened file, for crying out loud!  If there is anything that makes
> sure that superblock will stay alive, that is it...
>
> And lose the "locked" argument, please.  The sane solution is to make
> get_active_super() return it unlocked and have your freeze_bdev() simply
> grab s_umount.  Unconditionally.  I'll do the first part in #untested in
> a minute or so (and make it grab s_umount in the current variant of code in
> fs/block_dev.c); then your patch would shift taking s_umount down into
> freeze_super().

Since TuxOnIce was mentioned, I guess he's thinking on the following 
routine.

Regards,

Nigel

/**
  * freeze_filesystems - lock all filesystems and force them into a 
consistent
  * state
  * @which:      What combination of fuse & non-fuse to freeze.
  */
void freeze_filesystems(int which)
{
         struct super_block *sb;

         lockdep_off();

         /*
          * 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) {
                 FS_PRINTK(KERN_INFO "Considering %s.%s: (root %p, bdev 
%x)",
                         sb->s_type->name ? sb->s_type->name : "?",
                         sb->s_subtype ? sb->s_subtype : "", sb->s_root,
                         sb->s_bdev ? sb->s_bdev->bd_dev : 0);

                 if (sb->s_type->fs_flags & FS_IS_FUSE &&
                     sb->s_frozen == SB_UNFROZEN &&
                     which & FS_FREEZER_FUSE) {
                         sb->s_frozen = SB_FREEZE_TRANS;
                         sb->s_flags |= MS_FROZEN;
                         FS_PRINTK("Fuse filesystem done.\n");
                         continue;
                 }

                 if (!sb->s_root || !sb->s_bdev ||
                     (sb->s_frozen == SB_FREEZE_TRANS) ||
                     (sb->s_flags & MS_RDONLY) ||
                     (sb->s_flags & MS_FROZEN) ||
                     !(which & FS_FREEZER_NORMAL)) {
                         FS_PRINTK(KERN_INFO "Nope.\n");
                         continue;
                 }

                 FS_PRINTK(KERN_INFO "Freezing %x... ", sb->s_bdev->bd_dev);
                 freeze_bdev(sb->s_bdev);
                 sb->s_flags |= MS_FROZEN;
                 FS_PRINTK(KERN_INFO "Done.\n");
         }

         lockdep_on();
}
--
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/