Re: [PATCH] ncpfs bug
Michael Tross (mtross@compu-shack.com)
Tue, 01 Jun 1999 10:42:23 +0200
"Petr Vandrovec Ing. VTEI" wrote:
> in both 2.2.9 and 2.3.3 kernel code continues with:
> if (read_this_time < to_read) {
> break;
> }
> So code should exit from this loop if read_this_time is not equal to to_read.
> So it will not quit only if 'to_read==0'. And 'to_read' can be zero only
> 'count==already_read'. And if 'already_read >= count', we do not enter
> to this loop... So could you send me testcase? In any case, you should
> simple 'break' out of the loop, otherwise reading at the end will give
> '-EFAULT' (for example 'cat /file/on/ncpfs' will end with this error).
Absolute, you're definitely right. But as I read file.c (v2.2.9), if
ncp_read() returns without error and read_this_time is ==0, then
ncp_file_read() breaks out of the loop cause of (read_this_time <
to_read); but the point is that ncp_file_read() then exits with the
return code 0. My patch changed this to return an error in this case.
The ncpfs misbehaviour I described occured in all kernels I have tested
in the last year, 2.0.32, 2.0.36, 2.2.0 and now 2.2.9. I have LANalyzer
samples of the network traffic that my workstation has generated in this
case, about 1000 packets/sec. It was not completely clear to me, which
function causes this network-traffic-overflow, but the patch worked for
me.
> Could you try 2.2.10-pre1 or 2.3.4-pre1 (& newer)? There are some changes
> in pagefault mmap handling code, maybe that your problems came from that bug.
I just tried 2.2.10-pre1 and it works fine without my "patch". Or to be
more exact: I cannot reproduce it anymore. Seems that the source of the
problem was not the NCP call itself.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/