linux-kernel - Re: [patch 2/2] vfs: relax count check in rw_verify

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]

Date:	Tue, 26 Oct 2010 16:44:50 +0200
From:	Edward Shishkin <edward.shishkin@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>
CC:	linux-fsdevel@...r.kernel.org, Eric Sandeen <sandeen@...hat.com>,
	lmcilroy@...hat.com, LKML <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [patch 2/2] vfs: relax count check in rw_verify_area

Andrew Morton wrote:
> On Wed, 13 Oct 2010 22:46:21 +0200
> Edward Shishkin <edward.shishkin@...il.com> wrote:
>
>   
>> Increase count limit in rw_verify_area().
>>
>>     
>
> OK, now this is a truly awful attempt to describe a patch.
>   

I was sure I have nicely described everything in the
"[patch 0/2][RFC] vfs: artefact(?) in rw_verify_area"
Well, I'll provide more details..

> afaict what the patch does is to change rw_verify_area() so that the
> kernel now permits single reads and writes of up to 2^63 bytes on
> 64-bit systems.  Whereas it was previously limited to 2^31.  And the
> patch also fixes up a couple of callsites which were assuming that
> rw_verify_area() had that particular behaviour.
>   

I found such assumptions rather strange. Why to not assume
documentation for read(2), write(2), where we can nominate
SSIZE_MAX bytes to read/write?

Now about the bad aspect of this limitation.
There is a so-called concept of transactions, which is very useful.
Sometimes we want some operations to be performed atomically. For
example, when you pay by your credit card. Should I explain what
can happen, if such operation will be half done?

Now note that the 2G restriction in rw_verify_area means that a file
system can not write more then 2G bytes atomically without a special
notification from user space. Do we really need such workarounds?

Large transactions are possible, they can be issued, for example,
by some trusted centre, which has many clients (like commercial
bank, notary, etc). Actually, 2G is not a large value nowadays..

> But that's just my guess, based on a quick read of the implementation. 
> I didn't check how far this change penetrates.  Does it affect all
> filesystems, for example?  If so were they all reviewed (or tested!)
> for correctness?
>   

Currently I have tested 15 callsites, and only 2 of them was failed
(direct-io and ecryptfs). The direct-io has been fixed already:
there was a truncation bug (see
[patch 1/2] vfs: fix overflow in direct-io subsystem).

I am ready to check/fix other ones, if there are any chances, that
this permit of large IOs will be eventually accepted.

> And why was this patch written?  What motivated you?

Our users ask us.

>   What are the user-visible effects?

There must not be any effects: in accordance with documentation
we can nominate SSIZE_MAX bytes to read/write.

>   Do manpages need updating?
>   

No, they don't.

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