NETLINK sockets dont honor SO_RCVLOWAT?

NETLINK sockets dont honor SO_RCVLOWAT?

[Jeff Haran]

Hi,

Am I correct in my observation that the SO_RCVLOWAT socket option is not honored when one calls readv() on a PF_NETLINK socket?

The test application I wrote returns data as soon as it's available regardless of the option value I've specified and my perusal of the kernel sources leads me to believe that the NETLINK code does not honor it (support for the option appears to be protocol specific and I don't see it in the netlink code), but I could be missing something.

Please respond directly to my email address, jharan (at) brocade.com, as I do not subscribe to this list.

Thanks,

Jeff Haran
Brocade Communications

Re: NETLINK sockets dont honor SO_RCVLOWAT?

[David Miller]

From: Jeff Haran <jharan@Brocade.COM>
Date: Tue, 17 Nov 2009 17:54:59 -0800

> Am I correct in my observation that the SO_RCVLOWAT socket option is
> not honored when one calls readv() on a PF_NETLINK socket?

That's correct.

SO_RCVLOWAT is only available on stream based sockets such as TCP and
UNIX.

RE: NETLINK sockets dont honor SO_RCVLOWAT?

[Jeff Haran]

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net] 
> Sent: Tuesday, November 17, 2009 11:17 PM
> To: Jeff Haran
> Cc: netdev@vger.kernel.org
> Subject: Re: NETLINK sockets dont honor SO_RCVLOWAT?
> 
> From: Jeff Haran <jharan@Brocade.COM>
> Date: Tue, 17 Nov 2009 17:54:59 -0800
> 
> > Am I correct in my observation that the SO_RCVLOWAT socket option is
> > not honored when one calls readv() on a PF_NETLINK socket?
> 
> That's correct.
> 
> SO_RCVLOWAT is only available on stream based sockets such as TCP and
> UNIX.
> 

David,

Thanks for the prompt response.

So is this a bug or a feature?

When I call setsockopt() to set this option on a NETLINK socket, setsockopt() appears to return 0 to indicate success. If it's not going to be supported, shouldn't setsockopt() return -1 with ENOPROTOOPT in errno in this case?

This is the behavior I would assume from reading the setsockopt() man page.

I am running this on a 2.6.14 kernel, so perhaps this had been corrected in later versions.

Jeff Haran
Brocade Communications

Re: NETLINK sockets dont honor SO_RCVLOWAT?

[David Miller]

From: Jeff Haran <jharan@Brocade.COM>
Date: Wed, 18 Nov 2009 10:22:54 -0800

> So is this a bug or a feature?

It definitely seems intentional.

> When I call setsockopt() to set this option on a NETLINK socket,
> setsockopt() appears to return 0 to indicate success. If it's not
> going to be supported, shouldn't setsockopt() return -1 with
> ENOPROTOOPT in errno in this case?

There are a lot of socket option values that can be set but which
are not used by the protocol in question.

I don't think any changes need to be made.

RE: NETLINK sockets dont honor SO_RCVLOWAT?

[Jeff Haran]

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net] 
> Sent: Wednesday, November 18, 2009 10:25 AM
> To: Jeff Haran
> Cc: netdev@vger.kernel.org
> Subject: Re: NETLINK sockets dont honor SO_RCVLOWAT?
> 
> From: Jeff Haran <jharan@Brocade.COM>
> Date: Wed, 18 Nov 2009 10:22:54 -0800
> 
> > So is this a bug or a feature?
> 
> It definitely seems intentional.
> 
> > When I call setsockopt() to set this option on a NETLINK socket,
> > setsockopt() appears to return 0 to indicate success. If it's not
> > going to be supported, shouldn't setsockopt() return -1 with
> > ENOPROTOOPT in errno in this case?
> 
> There are a lot of socket option values that can be set but which
> are not used by the protocol in question.

All that means is that there are a lot of bugs.

> 
> I don't think any changes need to be made.

>From the setsockopt man page:

SETSOCKOPT(P)                                                   SETSOCKOPT(P)

NAME
       setsockopt - set the socket options

SYNOPSIS
       #include <sys/socket.h>

       int setsockopt(int socket, int level, int option_name,
              const void *option_value, socklen_t option_len);
...

ERRORS
       The setsockopt() function shall fail if:
...

       ENOPROTOOPT

              The option is not supported by the protocol.


The operative term is "shall". The RFCs define "shall" to be required behavior. I realize the RFCs do not dictate how Linux works, but even the common English language usage of the word "shall" conveys this meaning.

Thanks,

Jeff Haran
Brocade Communications

Re: NETLINK sockets dont honor SO_RCVLOWAT?

[David Miller]

From: Jeff Haran <jharan@Brocade.COM>
Date: Wed, 18 Nov 2009 10:41:06 -0800

> The operative term is "shall". The RFCs define "shall" to be
> required behavior. I realize the RFCs do not dictate how Linux
> works, but even the common English language usage of the word
> "shall" conveys this meaning.

The low water mark can be seen as a hint, therefore we can
apply the term "support" loosely here.

And the errors are advisory, just like things like -EFAULT.

Look, I'm not going to add a feature flag or some callback just to
handle this.

You have to know what kind of protocol you are working with, and
therefore which socket options make any sense for it.

RE: NETLINK sockets dont honor SO_RCVLOWAT?

[Jeff Haran]

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net] 
> Sent: Wednesday, November 18, 2009 10:45 AM
> To: Jeff Haran
> Cc: netdev@vger.kernel.org
> Subject: Re: NETLINK sockets dont honor SO_RCVLOWAT?
> 
> From: Jeff Haran <jharan@Brocade.COM>
> Date: Wed, 18 Nov 2009 10:41:06 -0800
> 
> > The operative term is "shall". The RFCs define "shall" to be
> > required behavior. I realize the RFCs do not dictate how Linux
> > works, but even the common English language usage of the word
> > "shall" conveys this meaning.
> 
> The low water mark can be seen as a hint, therefore we can
> apply the term "support" loosely here.
>
> And the errors are advisory, just like things like -EFAULT.
> 
> Look, I'm not going to add a feature flag or some callback just to
> handle this.
> 
> You have to know what kind of protocol you are working with, and
> therefore which socket options make any sense for it.

If the open source community doesn't want a fix for something that is obviously broken, that's fine. We fix a lot of broken kernel code here at Brocade. But at least now I know that I need not bother with submitting a patch. That will save everybody a lot of time.

Thanks,

Jeff Haran
Brocade Communications

Re: NETLINK sockets dont honor SO_RCVLOWAT?

[David Miller]

From: Jeff Haran <jharan@Brocade.COM>
Date: Wed, 18 Nov 2009 11:00:35 -0800

> If the open source community doesn't want a fix for something that
> is obviously broken, that's fine.

It is a bug in your opinion, and adding a check for these cases
doesn't necessarily make the kernel any better.

You can even check BSD, it behaves just like we do for several socket
options (they are just pieces of state stored in the socket, having
protocol specific checks and/or callbacks for every single socket
option would be just a lot of useless bloat).

And when all else fails BSD's behavior is what we use to determine
what is reasonable.