Steve French wrote:
> On Nov 10, 2007 7:03 AM, Przemyslaw Wegrzyn <[EMAIL PROTECTED]> wrote:
>
>> Steve French wrote:
>>
>>> That might be better, although without memory pools, this would perform
>>> much worse
>>>
>>>
>
Steve French wrote:
> below. The obvious need is to create an SendReceive-NoResponse (or
> equivalent) which
> frees the SMB request buffer after send, and does not copy into an smb
> response buffer. The following functions need to be changed to use
>
How about modifying SendReceive to behav
Steve French wrote:
> You are correct that the CIFS code calls SendReceive in cases in which
> the buffer may be too small to fit a large SMB response, and that
> should be fixed (e.g. to avoid possible overflows due to a server
> bug), None of the eight cases (SMB TreeDisconnect, SMB uLogoff, SMB
Hello all,
I was looking at CIFS VFS code recently, trying to solve other issue,
just to find something that looks like a buffer overflow bug.
The problem is in SendReceive() function in transport.c - it memcpy's
message payload into a buffer passed via out_buf param. The function
assumes that al
After adding second CPU to my server, I get the following strange
behavior:
earth:/home/czajnik# ping -s 1 213.25.174.24
PING 213.25.174.24 (213.25.174.24): 1 data bytes
10008 bytes from 213.25.174.24: icmp_seq=0 ttl=255 time=10551.5 ms
10008 bytes from 213.25.174.24: icmp_seq=6 ttl=255
On Sat, 19 May 2001, Axel Thimm wrote:
> This are the latest suggestions for handling the VIA Southbridge bug as
> derived from the hardware site www.au-ja.de (Many thanks to doelf).
Sorry - little off-topic. I can't find the clean answer anywhere.
I use KT7A-RAID, with one disc connected to H
6 matches
Mail list logo
