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]

Message-ID: <1422943582.246718.1641809643674.JavaMail.zimbra@nod.at>
Date:   Mon, 10 Jan 2022 11:14:03 +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>
> 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>
> Gesendet: Montag, 10. Januar 2022 10:35:02
> Betreff: Re: [PATCH v6 05/15] ubifs: Rename whiteout atomically

> Hi, Richard
>> 
>> 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.
>> 
> 
> The whiteout inode is clean after creation from create_whiteout(), and
> it can't be marked dirty until ubifs_jnl_rename() finished. So, I think
> there is no chance for whiteout being written on disk. Then,
> 'ubifs_assert(c, !whiteout_ui->dirty)' never fails in ubifs_jnl_rename()
> during my local stress tests. You may add some delay executions after
> whiteout creation to make sure that whiteout won't be written back
> before ubifs_jnl_rename().

>From UBIFS point of view I fully agree with you. I'm just a little puzzled why
other filesystems use the tmpfile approach. My fear is that VFS can do things
to the inode we don't have in mind right now.

Thanks,
//richard