linux-kernel - [PATCH 0/1][RFC] mm: prepare

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

Message-ID: <87ejp37kid.fsf@sw.ru>
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)