Re: [PATCH] illegal use of pid in rtnetlink
Hello! I am not aware of anyone using it So, do not worry. The feature is dead. Sending to multiple groups never was used in real life and now it just does not exist, as it should happen with useless features. It is sad, that dead nl_groups stays in struct sockaddr_nl, of course. Alexey - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
On Thu, 2006-09-02 at 13:08 +0300, Alexey Kuznetsov wrote: Hello! I am not aware of anyone using it So, do not worry. The feature is dead. I misunderstood your question. I thought you were asking about the 32 groups. Sending to multiple groups never was used in real life and now it just does not exist, as it should happen with useless features. _I_ use it although i am not aware of anyone else (but since you put it in libnetlink, i suspect there may be other people) - so it is not totally useless ;- [It is useful for selectively sending messages to different process groups using a single socket]. Note: Dave made a similar comment to yours; so i am fine working around this and use the konnector for example (which provides this functionality). The other idea i was tossing in my brain cells was using an xcast scheme to sendmsg by introducing a new structure which would allow explicitly listing 1 groups and 1 pid. It is sad, that dead nl_groups stays in struct sockaddr_nl, of course. Its value has been highly reduced for sure. Let me know your thoughts on the xcast idea. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
jamal wrote: It is sad, that dead nl_groups stays in struct sockaddr_nl, of course. Its value has been highly reduced for sure. Let me know your thoughts on the xcast idea. All routing protocols suite implementations use it to select rtnetlink multicast groups they want to listen in various stages of work. -- Hasso Tepper - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
On Thu, 2006-09-02 at 15:18 +0200, Hasso Tepper wrote: jamal wrote: It is sad, that dead nl_groups stays in struct sockaddr_nl, of course. Its value has been highly reduced for sure. Let me know your thoughts on the xcast idea. All routing protocols suite implementations use it to select rtnetlink multicast groups they want to listen in various stages of work. That would still work fine. What is broken is ability to send a message (from user space) so that multiple groups can hear it. Look at libnetlink::rtnl_talk() when groups parameter is a bitmask representing more than one group. Do you guys use libnetlink at all? cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
Hello! _I_ use it although i am not aware of anyone else (but since you put it in libnetlink, i suspect there may be other people No, really. It just was easy, but there were no specific applications. It is important for listener to be able to subscribe to many groups, but sending is apparently optional, provided receiver subscribes to correct set of groups. [It is useful for selectively sending messages to different process groups using a single socket]. Frankly speaking, I would reorganize application protocol, so that set of all the groups, which are you going to send to, forms one more group and you just send to this super-group. Apparently, receivers must be aware of this convention. The other idea i was tossing in my brain cells was using an xcast scheme to sendmsg by introducing a new structure which would allow explicitly listing 1 groups and 1 pid. Well, if this is really necessary, it is not difficult. But it still looks as a workaround for some badness in application protocol. Alexey - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
jamal wrote: On Wed, 2006-08-02 at 18:27 +0300, Alexey Kuznetsov wrote: When a netlink message is not related to a netlink socket, it is issued by kernel socket with pid 0. Netlink pid has nothing to do with current-pid. I called it incorrectly, if it was named port, the confusion would be avoided. This confusion was the main reason I rewrote rtnetlink.7 manpage. I received 0 comments till now, though ... does it mean it's so good? ;) Can you, Alexey, comment at least pid part? http://www.mail-archive.com/netdev%40vger.kernel.org/msg06166.html Jamal, please, review. Did you have reasons to do this? The reason was driven by some apps such as quagga/zebra which get confused when they see pid of 0 for things _they_ added. Essentially there was lack of consistency, at times the app that made the kernel change has its pid appear on the resulting netlink message and at others it was 0 or the large (negative) number when you had more than 1 socket within the same process. CCing Hasso Tepper and more details of the original fix are here: http://lists.quagga.net/pipermail/quagga-dev/2005-June/003507.html No, that was different issue and isn't related with issue Alexey poiting to. The issue I complained and you fixed it, Jamal, was that IPv6 related netlink messages had always pid 0 even if they were issued by application. What Alexey pointing to is the change you did earlier - set pid in the messages not related to netlink sockets - ie. changes initiated by user using ioctls for example. -- Hasso Tepper - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
jamal wrote: Ok, thanks for the reminder Hasso. so essentially at the moment the pid that will show up (if quagga added the v6 route) will be that of quagga, correct? No. Quote from Alexey: Netlink pid has nothing to do with current-pid. I called it incorrectly, if it was named port, the confusion would be avoided. And quote from netlink.7 I wrote: nl_pid is the unicast address of netlink socket. It's always 0 if the destination is in the kernel. For a userspace process, nl_pid is usually the PID of the process owning the destination socket. However, nl_pid identifies a netlink socket, not a process. If a process owns several netlink sockets, then nl_pid can only be equal to the process ID for at most one socket. There are two ways to assign nl_pid to a netlink socket. If the application sets nl_pid before calling bind(2), then it is up to the application to make sure that nl_pid is unique. If the application sets it to 0, the kernel takes care of assigning it. The kernel assigns the process ID to the first netlink socket the process opens and assigns a unique nl_pid to every netlink socket that the process subsequently creates. Once again link to the archive to the message I posted with new netlink.7 no one bother to comment yet ;). http://www.mail-archive.com/netdev%40vger.kernel.org/msg06166.html -- Hasso Tepper - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
On Wed, 2006-08-02 at 22:50 +0200, Hasso Tepper wrote: jamal wrote: Ok, thanks for the reminder Hasso. so essentially at the moment the pid that will show up (if quagga added the v6 route) will be that of quagga, correct? No. Quote from Alexey: I sense you missed my question. I understand the variants of PIDs that can occur(real, 0 or ones that need you to do a getname()), the question is: At the moment if a route (v6 or v4) was added by quagga and i had a socket that was listening in a different process - what pid will i see (in my user space app)? Is it of the quagga process or is it 0? cheers, jamal PS:-I will read your man-page - I have it printed, just havent got around to it yet. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
jamal wrote: On Wed, 2006-08-02 at 22:50 +0200, Hasso Tepper wrote: jamal wrote: Ok, thanks for the reminder Hasso. so essentially at the moment the pid that will show up (if quagga added the v6 route) will be that of quagga, correct? No. Quote from Alexey: I sense you missed my question. I understand the variants of PIDs that can occur(real, 0 or ones that need you to do a getname()), the question is: At the moment if a route (v6 or v4) was added by quagga and i had a socket that was listening in a different process - what pid will i see (in my user space app)? Is it of the quagga process or is it 0? No, it's 0xefff for most of Quagga users. The reason behind is that Quagga uses the first netlink socket it opens only for listening multicast groups. For sending messages to the kernel it opens second socket. Quagga lets kernel assign nl_pid's to the socket (by setting it to 0 before calling bind()). The first socket gets nl_pid equal to process pid of quagga (actually it's zebra daemon of quagga suite ;) and the second gets (0 - 4097) - see net/netlink/af_netlink.c:netlink_autobind() for details. As far as I understand it - the only connection between process pid and nl_pid member in sockaddr_nl structure is that Alexey happened to use pid of the process opening netlink socket as base of algorithm assigning unique unicast address to this socket if application doesn't set it itself (ie. it's 0 before calling bind()). -- Hasso Tepper Elion Enterprises Ltd. WAN administrator - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
On Wed, 2006-08-02 at 23:41 +0200, Hasso Tepper wrote: jamal wrote: At the moment if a route (v6 or v4) was added by quagga and i had a socket that was listening in a different process - what pid will i see (in my user space app)? Is it of the quagga process or is it 0? No, it's 0xefff for most of Quagga users. The reason behind is that Quagga uses the first netlink socket it opens only for listening multicast groups. For sending messages to the kernel it opens second socket. Quagga lets kernel assign nl_pid's to the socket (by setting it to 0 before calling bind()). The first socket gets nl_pid equal to process pid of quagga (actually it's zebra daemon of quagga suite ;) and the second gets (0 - 4097) - Right - this is what i referred to as the negative number. if you add a third socket it will go below 0xefff etc net/netlink/af_netlink.c:netlink_autobind() for details. As far as I understand it - the only connection between process pid and nl_pid member in sockaddr_nl structure is that Alexey happened to use pid of the process opening netlink socket as base of algorithm assigning unique unicast address to this socket if application doesn't set it itself (ie. it's 0 before calling bind()). So the question is what would be the address/nl_pid of something issued by an ioctl (refer to my earlier email to Alexey). cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
jamal wrote: So the question is what would be the address/nl_pid of something issued by an ioctl (refer to my earlier email to Alexey). It's the kernel who creates this message and puts it to the netlink domain, so I'd say 0. -- Hasso Tepper - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
Hello! What about the dilemma of when there are no netlink sockets involved? ;- i.e what is the semantics when there is no netlink socket to map them to, such as in the case of ioctl? 0, which is legal address of kernel socket. In this case it means that kernel did the operation. Moreover, it is legal (not good, but legal) to use 0 even when it was an explicit responce to a netlink request. Kernel did the work, eventually. a) if user-app using netlink modifies something, the event will report the nl_pid mapped to its pid or other non-zero value depending on the number of netlink sockets mapped to that process/user-app It is pid of netlink socket requesting the operation. If this pid is negative, it will be negative number. The idea was that someone who heard the message, could ask the author for an additional information via netlink. It is not used, of course, but however only real netlink addresses should be used, otherwise you could decide that the change was made by an innocent party, which bound to this number by some reason. b) if the same user-app used ioctl instead the reported nl_pid is 0 in the event Exactly. Alexey - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
jamal wrote: a) if user-app using netlink modifies something, the event will report the nl_pid mapped to its pid or other non-zero value depending on the number of netlink sockets mapped to that process/user-app It will always be nl_pid of the socket. And don't forget that this pid and negative numbers stuff is valid only if application doesn't set nl_pid. It's completely legal for application to do that before calling bind() and if there's no conflict (no already open netlink socket with this nl_pid), everything is OK. -- Hasso Tepper - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
On Thu, 2006-09-02 at 01:46 +0300, Alexey Kuznetsov wrote: Hello! What about the dilemma of when there are no netlink sockets involved? ;- i.e what is the semantics when there is no netlink socket to map them to, such as in the case of ioctl? 0, which is legal address of kernel socket. In this case it means that kernel did the operation. Ok, that settles it then - so I have no qualms with the patch. All along i was looking at the nl_pid as a representation of who ordered the operation not who did the operation I actually have found such knowledge useful in user space. It is a good thing Hasso is writing the manpages because he has good grasp of the whole thing. Alexey - if you have time take a look at the sendmsg() thing i referenced earlier. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
Hello! BTW, Alexey - if you have a chance can you look at the breakage of sendmsg() in relation to multicast that exists today? If it is is about groups 31, which cannot be mapped to nl_groups, it is possible just to add setsockopt(), setting dst_group. It is just to complete the API. Do something use this? I do not think so. (libnetlink assumes its existence). I can explain more if what i said didnt make sense. Please... Alexey - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] illegal use of pid in rtnetlink
From: jamal [EMAIL PROTECTED] Date: Wed, 08 Feb 2006 19:07:25 -0500 On Thu, 2006-09-02 at 01:46 +0300, Alexey Kuznetsov wrote: Hello! What about the dilemma of when there are no netlink sockets involved? ;- i.e what is the semantics when there is no netlink socket to map them to, such as in the case of ioctl? 0, which is legal address of kernel socket. In this case it means that kernel did the operation. Ok, that settles it then - so I have no qualms with the patch. All along i was looking at the nl_pid as a representation of who ordered the operation not who did the operation I actually have found such knowledge useful in user space. It is a good thing Hasso is writing the manpages because he has good grasp of the whole thing. I'll put in the patch either tonight or tomorrow. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
