linux-kernel - Re: [PATCH 1/2] fs: truncate blocks outside i_size after generic_file_direct

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] [day] [month] [year] [list]

Message-ID: <m3r66bidqs.fsf@dmon-lap.sw.ru>
Date:	Mon, 20 Oct 2008 17:43:07 +0400
From:	Dmitri Monakhov <dmonakhov@...nvz.org>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/2] fs: truncate blocks outside i_size after generic_file_direct_write error

Jeff Moyer <jmoyer@...hat.com> writes:

> Dmitri Monakhov <dmonakhov@...nvz.org> writes:
>
>> We need to remove block that was allocated in generic_file_direct_write()
>> if we fail. We have to do it *regardless* to blocksize. At least ext2,
>> ext3 and reiserfs interpret (i_size < biggest block) condition as error.
>> Fsck will complain about wrong i_size. Then fsck will fix the error
>> by changing i_size according to the biggest block. This is bad because
>> this blocks contain gurbage from previous write attempt. And result in
>> data corruption.
>>
>> In order to call vmtruncate() we have to hold host->i_mutex. This is true
>> for generic_file_aio_write(). In fact occasionally it is also true for all
>> generic_file_aio_write_nolock() callers except blockdev. But this situation
>> may change someday. This patch fix only generic_write_aio_write() case.
>> BTW: update generic_file_direct_write's comment with currently outdated.
>
> Do you have a test case for this, by any chance?
Off courre.
####TESTCASE_BEGIN
$touch /mnt/test/BIG_FILE
## at this moment /mnt/test/BIG_FILE size and blocks equal to zero
open("/mnt/test/BIG_FILE", O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3
write(3, "aaaaaaaaaaaa"..., 104857600) = -1 ENOSPC (No space left on device)
## size and block sould't be changed because write op failed.
$stat /mnt/test/BIG_FILE
File: `/mnt/test/BIG_FILE'
Size: 0 Blocks: 110896 IO Block: 1024 regular empty file
<<<<<<<<^^^^^^^^^^^^^^^^^^^^^^^^^^^^^file size is less than biggest block idx
Device: fe07h/65031d Inode: 14 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-01-24 20:03:38.000000000 +0300
Modify: 2007-01-24 20:03:38.000000000 +0300
Change: 2007-01-24 20:03:39.000000000 +0300

#fsck.ext3 -f /dev/VG/test
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Inode 14, i_size is 0, should be 56556544. Fix<y>? yes
Pass 2: Checking directory structure
....
#####TESTCASE_END

>
> Cheers,
>
> Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/