Messages in this thread | | | Date | Tue, 01 Jun 1999 10:42:23 +0200 | From | Michael Tross <> | Subject | Re: [PATCH] ncpfs bug |
| |
"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/
| |