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
| ||
|
Date: Tue, 06 Feb 2007 11:33:46 +0300
From: Dmitriy Monakhov <dmonakhov@...ru>
To: Linux Kernel <linux-kernel@...r.kernel.org>
CC: Andrew Morton <akpm@...l.org>, Nick Piggin <npiggin@...e.de>,
Linux Filesystems <linux-fsdevel@...r.kernel.org>
Subject: [PATCH 0/1][RFC] mm: prepare_write positive return value
Almost all read/write operation handles data with chunks(segments or pages)
and result has integral behaviour for folowing scenario:
for_each_chunk() {
res = op(....);
if(IS_ERROR(res))
return progress ? progress : res;
progress += res;
}
prepare_write may has integral behaviour in case of blksize < pgsize,
for example we successfully allocated/read some blocks, but not all of them,
and than some error happend. Currently we eliminate this progress by doing
vmtrunate() after prepare_has failed.
It is good to have ability to signal about this progress. Interprete positive
prepare_write() ret code as bytes num that fs ready to handle at this moment.
I've ask SAW, he think it is sane. This size always less than PAGE_CACHE_SIZE
so it less than AOP_TRUNCATED_PAGE too.
BTH: This approach was used in OpenVZ 2.6.9 kernel in order to make FS with
delayed allocation more correct, and its works well.
I think not everybody will happy about this, but let's discuss all advantages
and disadvantages of this change.
Signed-off-by: Dmitriy Monakhov <dmonakhov@...nvz.org>
-------------
View attachment "diff-mm-fs-prepare_write-retval" of type "text/plain" (3633 bytes)
Powered by blists - more mailing lists