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: Thu, 31 Oct 2019 09:17:58 -0700 From: Ira Weiny <ira.weiny@...el.com> To: Dave Chinner <david@...morbit.com> Cc: Boaz Harrosh <boaz@...xistor.com>, linux-kernel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, "Darrick J. Wong" <darrick.wong@...cle.com>, Dan Williams <dan.j.williams@...el.com>, Christoph Hellwig <hch@....de>, "Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [PATCH 0/5] Enable per-file/directory DAX operations On Mon, Oct 28, 2019 at 09:10:39AM +1100, Dave Chinner wrote: > On Fri, Oct 25, 2019 at 01:49:26PM -0700, Ira Weiny wrote: [snip] > > > Currently this works if I remount the fs or if I use <procfs>/drop_caches like > > Boaz mentioned. > > drop_caches frees all the dentries that don't have an active > references before it iterates over inodes, thereby dropping the > cached reference(s) to the inode that pins it in memory before it > iterates the inode LRU. > > > Isn't there a way to get xfs to do that on it's own? > > Not reliably. Killing all the dentries doesn't guarantee the inode > will be reclaimed immediately. The ioctl() itself requires an open > file reference to the inode, and there's no telling how many other > references there are to the inode that the filesystem a) can't find, > and b) even if it can find them, it is illegal to release them. > > IOWs, if you are relying on being able to force eviction of inode > from the cache for correct operation of a user controlled flag, then > it's just not going to work. Agree, I see the difficulty of forcing the effective flag to change in this path. However, the only thing I am relying on is that the ioctl will change the physical flag. IOW I am proposing that the semantic be that changing the physical flag does _not_ immediately change the effective flag. With that clarified up front the user can adjust accordingly. After thinking about this more I think there is a strong use case to be able to change the physical flag on a non-zero length file. That use case is to be able to restore files from backups. Therefore, having the effective flag flip at some later time when the a_ops can safely be changed (for example a remount/drop_cache event) is beneficial. I propose the user has no direct control over this event and it is mainly used to restore files from backups which is mainly an admin operation where a remount is a reasonable thing to do. Users direct control of the effective flag is through inheritance. The user needs to create the file in a DAX enable dir and they get effective operation right away. If in the future we can determine a safe way to trigger the a_ops change we can add that to the semantic as an alternative for users. Ira > > Cheers, > > Dave. > -- > Dave Chinner > david@...morbit.com
Powered by blists - more mailing lists