Andrew Morton wrote:
On Wed, 13 Oct 2010 22:46:21 +0200
Edward Shishkin <edward.shishkin@xxxxxxxxx> 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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
