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: <20211201134610.GA1815@quack2.suse.cz>
Date:   Wed, 1 Dec 2021 14:46:10 +0100
From:   Jan Kara <jack@...e.cz>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Chengguang Xu <cgxu519@...ernel.net>, Jan Kara <jack@...e.cz>,
        Miklos Szeredi <miklos@...redi.hu>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        ronyjin <ronyjin@...cent.com>,
        charliecgxu <charliecgxu@...cent.com>,
        Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode
 operation

On Wed 01-12-21 09:19:17, Amir Goldstein wrote:
> On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@...ernel.net> wrote:
> > So the final solution to handle all the concerns looks like accurately
> > mark overlay inode diry on modification and re-mark dirty only for
> > mmaped file in ->write_inode().
> >
> > Hi Miklos, Jan
> >
> > Will you agree with new proposal above?
> >
> 
> Maybe you can still pull off a simpler version by remarking dirty only
> writably mmapped upper AND inode_is_open_for_write(upper)?

Well, if inode is writeably mapped, it must be also open for write, doesn't
it? The VMA of the mapping will hold file open. So remarking overlay inode
dirty during writeback while inode_is_open_for_write(upper) looks like
reasonably easy and presumably there won't be that many inodes open for
writing for this to become big overhead?

> If I am not mistaken, if you always mark overlay inode dirty on ovl_flush()
> of FMODE_WRITE file, there is nothing that can make upper inode dirty
> after last close (if upper is not mmaped), so one more inode sync should
> be enough. No?

But we still need to catch other dirtying events like timestamp updates,
truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that
can be done...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ