linux-kernel - Re: [PATCH v6 05/15] ubifs: Rename whiteout atomically

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:   Sun, 9 Jan 2022 22:14:19 +0100 (CET)
From:   Richard Weinberger <richard@....at>
To:     chengzhihao1 <chengzhihao1@...wei.com>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        mcoquelin stm32 <mcoquelin.stm32@...il.com>,
        kirill shutemov <kirill.shutemov@...ux.intel.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 05/15] ubifs: Rename whiteout atomically

----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@...wei.com>
> An: "richard" <richard@....at>, "Miquel Raynal" <miquel.raynal@...tlin.com>, "Vignesh Raghavendra" <vigneshr@...com>,
> "mcoquelin stm32" <mcoquelin.stm32@...il.com>, "kirill shutemov" <kirill.shutemov@...ux.intel.com>, "Sascha Hauer"
> <s.hauer@...gutronix.de>
> CC: "linux-mtd" <linux-mtd@...ts.infradead.org>, "linux-kernel" <linux-kernel@...r.kernel.org>
> Gesendet: Montag, 27. Dezember 2021 04:22:36
> Betreff: [PATCH v6 05/15] ubifs: Rename whiteout atomically

> Currently, rename whiteout has 3 steps:
>  1. create tmpfile(which associates old dentry to tmpfile inode) for
>     whiteout, and store tmpfile to disk
>  2. link whiteout, associate whiteout inode to old dentry agagin and
>     store old dentry, old inode, new dentry on disk
>  3. writeback dirty whiteout inode to disk
> 
> Suddenly power-cut or error occurring(eg. ENOSPC returned by budget,
> memory allocation failure) during above steps may cause kinds of problems:
>  Problem 1: ENOSPC returned by whiteout space budget (before step 2),
>	     old dentry will disappear after rename syscall, whiteout file
>	     cannot be found either.
> 
>	     ls dir  // we get file, whiteout
>	     rename(dir/file, dir/whiteout, REANME_WHITEOUT)
>	     ENOSPC = ubifs_budget_space(&wht_req) // return
>	     ls dir  // empty (no file, no whiteout)
>  Problem 2: Power-cut happens before step 3, whiteout inode with 'nlink=1'
>	     is not stored on disk, whiteout dentry(old dentry) is written
>	     on disk, whiteout file is lost on next mount (We get "dead
>	     directory entry" after executing 'ls -l' on whiteout file).
> 
> Now, we use following 3 steps to finish rename whiteout:
>  1. create an in-mem inode with 'nlink = 1' as whiteout
>  2. ubifs_jnl_rename (Write on disk to finish associating old dentry to
>     whiteout inode, associating new dentry with old inode)
>  3. iput(whiteout)
> 
> Rely writing in-mem inode on disk by ubifs_jnl_rename() to finish rename
> whiteout, which avoids middle disk state caused by suddenly power-cut
> and error occurring.

How do you make sure the the whiteout is never written to disk (by writeback) before ubifs_jnl_rename() linked
it? That's the reason why other filesystems use the tmpfile mechanism for whiteouts too.

Thanks,
//richard