Eric Dumazet wrote:

> Andrew Morton a écrit :
>
>> Eric Dumazet <dada1@cosmosbay.com> wrote:
>>
>>> Considering :
>>>
>>> [root@dada1 linux-2.6.13-rc6]# find .|xargs grep f_maxcount
>>> ./fs/file_table.c:      f->f_maxcount = INT_MAX;
>>> ./fs/read_write.c:      if (unlikely(count > file->f_maxcount))
>>> ./include/linux/fs.h:   size_t                  f_maxcount;
>>>
>>>
>>> I was wondering if f_maxcount has a real use these days...
>>
>>
>>
>> No, I guess we can just stick a hard-wired INT_MAX in there.
>>
>>
>
> OK here is a patch doing the hard wiring then :)
>
> * struct file cleanup : f_maxcount has an unique value (INT_MAX). Just 
> use the hard-wired value.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
>------------------------------------------------------------------------
>diff -Nru linux-2.6.13-rc6/fs/read_write.c linux-2.6.13-rc6-ed/fs/read_write.c
>--- linux-2.6.13-rc6/fs/read_write.c	2005-08-07 20:18:56.000000000 +0200
>+++ linux-2.6.13-rc6-ed/fs/read_write.c	2005-08-19 23:51:20.000000000 +0200
>@@ -188,7 +188,7 @@
> 	struct inode *inode;
> 	loff_t pos;
> 
>-	if (unlikely(count > file->f_maxcount))
>+	if (unlikely(count > INT_MAX))
> 		goto Einval;
> 	pos = *ppos;
> 	if (unlikely((pos < 0) || (loff_t) (pos + count) < 0))
>

And depending upon how you feel about read(2) and write(2) returning larger
than can be represented by a ssize_t, you can get rid of this test too and
apply the attached patch to prevent failures occuring in the direct-io
subsystem.

Limiting i/o requests to INT_MAX is starting to seem a little small.

    Thanx...

       ps

Signed-off-by: Peter Staubach <staubach@redhat.com>