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
| ||
|
Message-ID: <20131206040722.GA15325@parisc-linux.org> Date: Thu, 5 Dec 2013 21:07:22 -0700 From: Matthew Wilcox <matthew@....cx> To: Dave Chinner <david@...morbit.com> Cc: Ross Zwisler <ross.zwisler@...ux.intel.com>, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, carsteno@...ibm.com, matthew.r.wilcox@...el.com, andreas.dilger@...el.com Subject: Re: [PATCH v2 2/4] ext4: Add XIP functionality On Fri, Dec 06, 2013 at 02:13:54PM +1100, Dave Chinner wrote: > I think I see a significant problem here with XIP write support: > unwritten extents. > > xip_file_write() has no concept of post IO completion processing - > it assumes that all that is necessary is to memcpy() the data into > the backing memory obtained by ->get_xip_mem(), and that's all it > needs to do. > > For ext4 (and other filesystems that use unwritten extents) they > need a callback - normally done from bio completion - to run > transactions to convert extent status from unwritten to written, or > run other post-IO completion operations. > > I don't see any hooks into ext4 to turn off preallocation (e.g. > fallocate is explicitly hooked up for XIP) when XIP is in use, so I > can't see how XIP can work with such filesystem requirements without > further infrastructure being added. i.e. bypassing the need for the > page cache does not remove the need to post-IO completion > notification to the filesystem.... The two are mutually exclusive: if (ext4_use_xip(inode->i_sb)) inode->i_mapping->a_ops = &ext4_xip_aops; else if (test_opt(inode->i_sb, DELALLOC)) inode->i_mapping->a_ops = &ext4_da_aops; else inode->i_mapping->a_ops = &ext4_aops; Is it worth implementing delayed allocation support on top of XIP? Indeed, what would that *mean*? Assuming that the backing store is close to DRAM speeds, we don't want to cache in DRAM first, then copy to the backing store, we just want to write to the backing store. > Indeed, for making filesystems like XFS be able to use XIP, we're > going to need such facilities to be provided by the XIP > infrastructure.... I have a patch in my development tree right now which changes the create argument to get_xip_mem into a flags argument, with 'GXM_CREATE' and 'GXM_HINT' as the first two flags. Adding a GXM_ALLOC flag would presumably be enough of a hint to the filesystem that it's time to commit this range to disk. Admitedly, it's pre-write and not post-write, but does that matter when the write is a memcpy? I must admit to not quite understanding all 100k+ lines of XFS, so maybe you really do need to know when the memcpy has finished. I also don't see a problem with the filesystem either having a wrapper around xip_file_write or providing its own entire implementation of ->write. Equally, I'm sure we could add some other callback in, say, address_space_operations that the XIP code could call after the memcpy if that's what XFS needs. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists