recv(2), MSG_TRUNK and kernels older than 2.6.22

recv(2), MSG_TRUNK and kernels older than 2.6.22

[Roy Marples]

Hi

I would like to support all possible kernels I can and previously used a 
fixed buffer of size 256 to read from netlink sockets. This is now 
proving too small for some 64-bit kernels so I would like to use recv(2) 
with MSG_TRUNK to wor out the size. However, the man page says that this 
only works for 2.6.22 kernels or newer.

My question is, what is the behaviour of recv on older kernels where 
MSG_TRUNC is not supported? I would rather not use some arbitary size if 
at all possible.

Reply directly please as I'm not subscribed here.

Thanks

Roy

Re: recv(2), MSG_TRUNK and kernels older than 2.6.22

[Eric Dumazet]

Le mardi 20 juillet 2010 à 09:26 +0100, Roy Marples a écrit :
> Hi
> 
> I would like to support all possible kernels I can and previously used a 
> fixed buffer of size 256 to read from netlink sockets. This is now 
> proving too small for some 64-bit kernels so I would like to use recv(2) 
> with MSG_TRUNK to wor out the size. However, the man page says that this 
> only works for 2.6.22 kernels or newer.
> 
> My question is, what is the behaviour of recv on older kernels where 
> MSG_TRUNC is not supported? I would rather not use some arbitary size if 
> at all possible.
> 

Is it for the dhcpcd problem we talk about few week ago, disturbed by
new 64bit stats ?

Why do you want to have a fixed size of 256 bytes ?

Using 8192 bytes on stack would avoid MSG_TRUNK mess.

static int
get_netlink(int fd, int flags,
    int (*callback)(struct nlmsghdr *))
{
        char buffer[8192];
        ssize_t bytes;
        struct nlmsghdr *nlm;
        int r = -1;

        for (;;) {
                bytes = recv(fd, buffer, sizeof(buffer), flags);
                if (bytes == -1) {
                        if (errno == EAGAIN) {
                                r = 0;
                                goto eexit;
                        }
                        if (errno == EINTR)
                                continue;
                        goto eexit;
                }

Re: recv(2), MSG_TRUNK and kernels older than 2.6.22

[Roy Marples]

On 20/07/2010 09:54, Eric Dumazet wrote:
> Is it for the dhcpcd problem we talk about few week ago, disturbed by
> new 64bit stats ?

Yes

>
> Why do you want to have a fixed size of 256 bytes ?
>
> Using 8192 bytes on stack would avoid MSG_TRUNK mess.

Yes it would, but that doesn't answer my question :)
I would like to use a buffer big enough, but not a whole 8k in size.
dhcpcd has quite a small runtime and I'd like to keep it that way.

Thanks

Roy

Re: recv(2), MSG_TRUNK and kernels older than 2.6.22

[Eric Dumazet]

Le mardi 20 juillet 2010 à 10:08 +0100, Roy Marples a écrit :
> On 20/07/2010 09:54, Eric Dumazet wrote:
> > Is it for the dhcpcd problem we talk about few week ago, disturbed by
> > new 64bit stats ?
> 
> Yes
> 
> >
> > Why do you want to have a fixed size of 256 bytes ?
> >
> > Using 8192 bytes on stack would avoid MSG_TRUNK mess.
> 
> Yes it would, but that doesn't answer my question :)

Your question might be wrong ? :=)

> I would like to use a buffer big enough, but not a whole 8k in size.
> dhcpcd has quite a small runtime and I'd like to keep it that way.

8192 bytes on stack is too much for you ?

Then you should automatically resize your buffer, and not using
MSG_TRUNK at all (there is no guarantee the information you need will be
part of the truncated part)

Re: recv(2), MSG_TRUNK and kernels older than 2.6.22

[Eric Dumazet]

Le mardi 20 juillet 2010 à 11:24 +0200, Eric Dumazet a écrit :
> Le mardi 20 juillet 2010 à 10:08 +0100, Roy Marples a écrit :
> > On 20/07/2010 09:54, Eric Dumazet wrote:
> > > Is it for the dhcpcd problem we talk about few week ago, disturbed by
> > > new 64bit stats ?
> > 
> > Yes
> > 
> > >
> > > Why do you want to have a fixed size of 256 bytes ?
> > >
> > > Using 8192 bytes on stack would avoid MSG_TRUNK mess.
> > 
> > Yes it would, but that doesn't answer my question :)
> 
> Your question might be wrong ? :=)
> 
> > I would like to use a buffer big enough, but not a whole 8k in size.
> > dhcpcd has quite a small runtime and I'd like to keep it that way.
> 
> 8192 bytes on stack is too much for you ?
> 
> Then you should automatically resize your buffer, and not using
> MSG_TRUNK at all (there is no guarantee the information you need will be
> part of the truncated part)
> 
> 

On < 2.6.22 kernels, recv() returns the length of your buffer, not size
of netlink frame.

You'll need something like :

size_t sz = 256;
char *buf = malloc(sz);
while (1) {
	if (!buf) error();
	len = recv(fd, buf, sz, MSG_PEEK | MSG_TRUNC);
	if (len < sz)
		break;
	if (len == sz)
		sz *= 2; // old kernel, try to double size
	else
		sz = len; // recent kernel is nice with us
	buf = realloc(buf, sz);
}
len = recv(fd, buf, sz, 0);

Re: recv(2), MSG_TRUNK and kernels older than 2.6.22

[Roy Marples]

On 20/07/2010 11:02, Eric Dumazet wrote:
> Le mardi 20 juillet 2010 à 11:24 +0200, Eric Dumazet a écrit :
>> Le mardi 20 juillet 2010 à 10:08 +0100, Roy Marples a écrit :
>>> On 20/07/2010 09:54, Eric Dumazet wrote:
>>>> Is it for the dhcpcd problem we talk about few week ago, disturbed by
>>>> new 64bit stats ?
>>>
>>> Yes
>>>
>>>>
>>>> Why do you want to have a fixed size of 256 bytes ?
>>>>
>>>> Using 8192 bytes on stack would avoid MSG_TRUNK mess.
>>>
>>> Yes it would, but that doesn't answer my question :)
>>
>> Your question might be wrong ? :=)
>>
>>> I would like to use a buffer big enough, but not a whole 8k in size.
>>> dhcpcd has quite a small runtime and I'd like to keep it that way.
>>
>> 8192 bytes on stack is too much for you ?
>>
>> Then you should automatically resize your buffer, and not using
>> MSG_TRUNK at all (there is no guarantee the information you need will be
>> part of the truncated part)
>>
>>
>
> On<  2.6.22 kernels, recv() returns the length of your buffer, not size
> of netlink frame.
>
> You'll need something like :
>
> size_t sz = 256;
> char *buf = malloc(sz);
> while (1) {
> 	if (!buf) error();
> 	len = recv(fd, buf, sz, MSG_PEEK | MSG_TRUNC);
> 	if (len<  sz)
> 		break;
> 	if (len == sz)
> 		sz *= 2; // old kernel, try to double size
> 	else
> 		sz = len; // recent kernel is nice with us
> 	buf = realloc(buf, sz);
> }
> len = recv(fd, buf, sz, 0);

Thankyou

If buf is NULL and sz is 0, would 0 still be returned? I'm guessing so.

Thanks

Roy