linux-ext4 - Re: [PATCH] ext4: serialize unaligned asynchronous DIO

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: <4D2FD3E6.1000509@redhat.com>
Date:	Thu, 13 Jan 2011 22:41:10 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Ted Ts'o" <tytso@....edu>
CC:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: serialize unaligned asynchronous DIO

On 1/13/11 10:15 PM, Ted Ts'o wrote:
> On Thu, Jan 13, 2011 at 04:23:14PM -0600, Eric Sandeen wrote:
>> Mingming suggested that perhaps we can track outstanding
>> conversions, and wait on that instead so that non-sparse
>> files won't be affected, but I've had trouble making that
>> work so far, and would like to get the corruption hole
>> plugged ASAP.  Perhaps adding a prink_once() warning of
>> the perf degradation on this path would be useful?
> 
> Yeah, I think a printk_once(), or maybe better yet, a warning
> ext4_msg() ratelimited to once a day, is the way to go.  I'd print the
> inode number and process name that did the offending async DIO, so it
> can help out the system administrator.

I'll add something like that.

> I've looked over the rest of the patch, and it seems good.  Just one
> question:
> 
>> +static int
>> +ext4_unaligned_aio(struct inode *inode, const struct iovec *iov,
>> +		unsigned long nr_segs, loff_t pos)
>> +{
>> +	struct super_block *sb = inode->i_sb;
>> +	int blockmask = sb->s_blocksize - 1;
>> +	size_t count = iov_length(iov, nr_segs);
>> +	loff_t final_size = pos + count;
>> +
>> +	if (pos >= inode->i_size)
>> +		return 0;
> 
> Why is it ok if the write is extended the file?  Are you depending on
> some other lock (i_data_sem, perhaps?) to serialize the write in that
> case?  If so, could you please add a comment to that effect?

We only have this problem if we are going down the unwritten extent
route, which only happens for writes inside i_size:

        if (rw == WRITE && final_size <= inode->i_size) {
                /*
                 * We could direct write to holes and fallocate.
		   ...

I can add a comment, good point.  In fact I'll liberally add a few
comments, sorry, I usually do that but didn't tidy this patch up
prior to sending.  :)

-Eric
 
>        	      	    	       	     	     - Ted

--
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