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: <20150220120547.GA6293@quack.suse.cz> Date: Fri, 20 Feb 2015 13:05:47 +0100 From: Jan Kara <jack@...e.cz> To: Dave Chinner <david@...morbit.com> Cc: Jan Kara <jack@...e.cz>, Matthew Wilcox <willy@...ux.intel.com>, "Wilcox, Matthew R" <matthew.r.wilcox@...el.com>, "ross.zwisler@...ux.intel.com" <ross.zwisler@...ux.intel.com>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "Dilger, Andreas" <andreas.dilger@...el.com>, "axboe@...nel.dk" <axboe@...nel.dk>, "boaz@...xistor.com" <boaz@...xistor.com>, "hch@....de" <hch@....de>, "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, "mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>, "rdunlap@...radead.org" <rdunlap@...radead.org>, "tytso@....edu" <tytso@....edu>, "mm-commits@...r.kernel.org" <mm-commits@...r.kernel.org>, "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>, xfs@....sgi.com Subject: Re: + ext4-add-dax-functionality.patch added to -mm tree On Fri 20-02-15 08:12:10, Dave Chinner wrote: > On Thu, Feb 19, 2015 at 04:42:41PM +0100, Jan Kara wrote: > > On Thu 19-02-15 08:55:23, Dave Chinner wrote: > > > On Wed, Feb 18, 2015 at 11:40:09AM +0100, Jan Kara wrote: > > > > On Tue 17-02-15 08:37:45, Matthew Wilcox wrote: > > > > > On Tue, Feb 17, 2015 at 09:52:00AM +0100, Jan Kara wrote: > > > > > > > > This got added to fix a problem that Dave Chinner pointed out. We need > > > > > > > > the allocated extent to either be zeroed (as ext2 does), or marked as > > > > > > > > unwritten (ext4, XFS) so that a racing read/page fault doesn't return > > > > > > > > uninitialized data. If it's marked as unwritten, we need to convert it > > > > > > > > to a written extent after we've initialised the contents. We use the > > > > > > > > b_end_io() callback to do this, and it's called from the DAX code, not in > > > > > > > > softirq context. > > > > > > > OK, I see. But I didn't find where ->b_end_io gets called from dax code > > > > > > > (specifically I don't see it anywhere in dax_do_IO() or dax_io()). Can you > > > > > > > point me please? > > > > > > > > > > For faults, we call it in dax_insert_mapping(), the very last thing > > > > > before returning in the fault path. The normal I/O path gets to use > > > > > the dio_iodone_t for the same purpose. > > > > I see. I didn't think of races with reads (hum, I actually wonder whether > > > > we don't have this data exposure problem for ext4 for mmapped write into > > > > a hole vs direct read as well). So I guess we do need those unwritten > > > > extent dances after all (or we would need to have a page covering hole when > > > > writing to it via mmap but I guess unwritten extent dances are somewhat > > > > more standard). > > > > > > Right, that was the reason for doing it that way - it leveraged all > > > the existing methods we have for avoiding data exposure races in > > > XFS. but it's also not just for races - it's for ensuring that if we > > > crash between the allocation and the write to the persistent store > > > we don't expose the underlying contents when the system next comes > > > up. > > Well, ext3/4 handles the crash situation differently - we make sure we > > flush data to allocated blocks before committing a transaction that > > allocates them. That works perfectly for crashes but doesn't avoid the > > race with DIO. > > I was talking about direct IO, not buffered IO. DAX is modeled on Ah, OK. For DIO writes ext4 uses unwritten extents as well. But the race I was talking about is between mmap allocating write (i.e. going through page cache) and DIO read of the same location. > the direct IO stack, not buffered IO. I did go and look at the ext4 > IO completion path, and I can see where ext4_end_io_dio() triggers a > commit outside of doing unwritten extent conversion. Can you clue me > in - IO completion in ext4 is a maze of twisty passages... I don't quite follow you. Why should ext4_end_io_dio() trigger a commit? Honza -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- 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