Seeing EINVAL from writev on 8.0 to a non-blocking socket even though the data seems to hit the wire

[Richard Sharpe]

On Wed, May 1, 2013 at 9:34 PM, Alfred Perlstein <bright at mu.org> wrote:
> On 5/1/13 8:03 PM, Richard Sharpe wrote:
>> Hi folks,
>>
>> I am checking to see if there are any known bugs with respect to this
>> in FreeBSD 8.0.
>>
>> Situation is that Samba 3.6.6 uses writev to a non-blocking socket to
>> get the SMB2 requests on the wire.
>>
>> Intermittently, we see the writev return EINVAL even though the data
>> has gotten on the wire. This I have verified by grabbing a capture and
>> comparing the SMB Sequence number in the last outgoing packet on the
>> wire vs the in-memory contents when we get EINVAL.
>>
>> Sometimes it occurs on a four-element IOVEC, sometimes we get EAGAIN
>> on the four-element IOVEC and then we get EINVAL when retrying on a
>> smaller IOVEC.
>>
>> Where should I look to check if there is some path where this might be
>> happening? Is this even the correct mailing list?
>>
> What does the iovec look like when you get EINVAL? Can you sanity check
> it? Is there anything special about it? (zero length vecs?)
>
> I think there are a few "maxvals" that if overrun cause EINVAL to be
> returned. example is if your iovec is somehow huge or has many, many
> elements.

It usually consists of four elements. All of the elements are
accessible because I checked some of the data. Well, actually, I did
not check the 65536 bytes of the last element, but they seemed to go
out on the wire, although I should check the last offset.

The lengths were usually: 4, 64, 8 or 16, 65536.

So, I do need to check the last element. I think it all went out on
the wire. With 4,64,16 and 65536 byte segments that is 65620 bytes and
they were all accounted for and the SMB2 sequence number matched what
was in memory.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)