netdev - RE: NETLINK sockets dont honor SO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <D67825C5985D0647BE40A5F5B0B70D1106E9C568F1@HQ-EXCH-7.corp.brocade.com>
Date:	Wed, 18 Nov 2009 10:22:54 -0800
From:	Jeff Haran <jharan@...cade.COM>
To:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: NETLINK sockets dont honor SO_RCVLOWAT?

> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net] 
> Sent: Tuesday, November 17, 2009 11:17 PM
> To: Jeff Haran
> Cc: netdev@...r.kernel.org
> Subject: Re: NETLINK sockets dont honor SO_RCVLOWAT?
> 
> From: Jeff Haran <jharan@...cade.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html