linux-kernel - Re: [PATCH RESEND v5] fat: editions to support fat

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: <CAKYAXd8kyN1w5GJ8zCoKL+XS67125dUf0ivqCQWKjGCSxnXYpg@mail.gmail.com>
Date:	Tue, 18 Jun 2013 14:47:10 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH RESEND v5] fat: editions to support fat_fallocate

Hi, OGAWA.

We checked several cases with respect to your questions. But we cannot
find any issue.
Also, We compare the results with Ext4. It is same.
>cluster size == 512b

>1) create new file
>2) fallocate 100MB
>3) write(2) data for each 512b

>With this, write_begin() will be called for each 512b data. When we
>allocates new page for this file, write_begin() writes data 0-512. Then,
>we have to initialize 512-4096 by zero. Because mmap read maps 0-4096,
>even if i_size == 512.

>Who is initializing area for 512-4096?
When we checked, we found that page which is allocated to mmap is
already filled with zeros. And 512byte is filled in this page. If we
try to read mmap beyond the file size of 512 bytes , nulls are
returned . Hence , mmap works correctly in such cases .

>>From other view, I guess fat_zero_falloc_area() is for filling zero for
>0-10000, in the following case?

> 1) create new file
> 2) lseek(10000)
> 3) write data by write(2)

>This job is for cont_write_begin(). If example is correct, why
>cont_write_begin() doesn't work? I guess, because get_block() doesn't
>set buffer_new() for those area.
If we will not call fallocate with keep size flags, cont_write_begin
will work and zero out on lseek area (this works like expanding
truncate).

>If above is correct, right implement to change get_block().
Now when we try to write in the fallocated region ( with keep size) in
the fat_write_begin when it is called first time it checks that the
mismatch is present between the mmu_private and mmu_actual , and hence
zero out the region ; since buffer_new is not set for fallocated
region by fat_get_block , we explicitly zero out the lseeked region
using “fat_zero_falloc_area” and normal write occurs beyond that , and
i_size is updated accordingly , and as such there is no need to move
the code to fat_get_block .
>I'm ok as start if it works.
>
>But from this discussion, discard at last close(2) doesn't look like
>working for your requirement. Since you want to discard at last close of
>inode, so, rather, I guess you actually want to discard at last
>dereference of inode.
We also moved the release of fallocated clusters from the
“fat_file_release” to “fat_evict_inode” and on the basis of i_count so
that the fallocated clusters are released at the last reference of the
inode.

Thanks.
--
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/