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
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
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 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
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 03:40 +0300, Alexey Kuznetsov wrote:
> 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.
>
Thats one way to do it (and may infact resolve things)- but not exactly
the way it is at the moment:
netlink_sendmsg() has changed such that even if libnetlink user call
specified more than one target group, in the kernel it will only got to
the first one; you should really take a look at the whole of
netlink_sendmsg() but here is a sample snippet:
---
if (msg->msg_namelen) {
if (addr->nl_family != AF_NETLINK)
return -EINVAL;
dst_pid = addr->nl_pid;
dst_group = ffs(addr->nl_groups);
if (dst_group && !netlink_capable(sock,
NL_NONROOT_SEND))
return -EPERM;
} else {
dst_pid = nlk->dst_pid;
dst_group = nlk->dst_group;
}
-
which used to be:
-
if (msg->msg_namelen) {
if (addr->nl_family != AF_NETLINK)
return -EINVAL;
dst_pid = addr->nl_pid;
dst_groups = addr->nl_groups;
if (dst_groups && !netlink_capable(sock, NL_NONROOT_SEND))
return -EPERM;
} else {
dst_pid = nlk->dst_pid;
dst_groups = nlk->dst_groups;
}
---
note: there is no "groups" anymore.
> Do something use this? I do not think so.
>
I am not aware of anyone using it but desktop people want > 32 mcast
groups.
>
> > (libnetlink assumes its existence). I can explain more if what i said
> > didnt make sense.
>
> Please...
>
Basically I have an app that sent to multi groups by using one of the
calls in libnetlink [rtnl_talk()] with say groups = 0x3; which
translates to 0x1 and 0x2 in the kernel and such a message will be
delivered to two listeners one subscribed to 0x1 and another to 0x2. -
Now it will only get delivered to the socket listening on 0x1.
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
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
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
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
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
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: > 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
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: > 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 Thu, 2006-09-02 at 00:02 +0300, Alexey Kuznetsov wrote: > I am afraid It is not logical and inconsistent and really breaks > netlink. :-) > > Those nl_pid's are _addresses_ of netlink sockets. You cannot fill them > with random numbers. > Ok, Alexey: 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? This is where the majority of those changes occurred (as well as in the case of the patch you posted). by consistency i mean this: 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 b) if the same user-app used ioctl instead the reported nl_pid is 0 in the event 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
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
Hello! > 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? In the part, where v6 routes added via netlink it was a long expected thing.. I was lazy in many places to pass identity of author of change through the layers. Use of 0 was enough good replacement for bummers, because you never can distinguish the report about change made by you from a report made by kernel in any case. What's about use of current->pid, they must be replaced with 0s, I am sorry I did not search for this bug in net/ipv6... > Same with v4 iirc? If yes, then isnt it logical that if ifconfig added > an ip address it should naturally be ifconfig's pid that shows up (for > consistency)? I am afraid It is not logical and inconsistent and really breaks netlink. :-) Those nl_pid's are _addresses_ of netlink sockets. You cannot fill them with random numbers. > [1] I understand the point put forward by Alexey that: had he called > that field "port" instead of "pid" when he created netlink, things would > have had different semantics - I am just talking about consistency here. The semantics is clear. nl_pid is not a pid. :-) 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: > 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
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? Same with v4 iirc? If yes, then isnt it logical that if ifconfig added an ip address it should naturally be ifconfig's pid that shows up (for consistency)? Note we can add ip addresses via netlink with newer kernels and the apps/user-space pid will show up[1]. cheers, jamal [1] I understand the point put forward by Alexey that: had he called that field "port" instead of "pid" when he created netlink, things would have had different semantics - I am just talking about consistency here. On Wed, 2006-08-02 at 22:08 +0200, Hasso Tepper wrote: > Hasso Tepper wrote: > > 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. > > It was unclear, so I have to correct myself - "... by application via > netlink socket." That was the change: > http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=061262a38daa1717e8343846bc9a8fd5712bd07a > > > 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. > > That was the change Alexey is talking about: > http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=bd982ca8d4365a3c34e66d8d1be1df04466a19e8 > > - 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
Hasso Tepper wrote: > 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. It was unclear, so I have to correct myself - "... by application via netlink socket." That was the change: http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=061262a38daa1717e8343846bc9a8fd5712bd07a > 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. That was the change Alexey is talking about: http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=bd982ca8d4365a3c34e66d8d1be1df04466a19e8 -- 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: > 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
Hi Alexey, On Wed, 2006-08-02 at 18:27 +0300, Alexey Kuznetsov wrote: > Hello! > > 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. > > 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 BTW, Alexey - if you have a chance can you look at the breakage of sendmsg() in relation to multicast that exists today? It came in as a result of trying to extend the number of multicast groups to be > 32 (libnetlink assumes its existence). I can explain more if what i said didnt make sense. 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
[PATCH] illegal use of pid in rtnetlink
Hello!
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.
Jamal, please, review. Did you have reasons to do this?
Signed-off-by: Alexey Kuznetsov <[EMAIL PROTECTED]>
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 8700379..eca2976 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -455,7 +455,7 @@ void rtmsg_ifinfo(int type, struct net_d
if (!skb)
return;
- if (rtnetlink_fill_ifinfo(skb, dev, type, current->pid, 0, change, 0) <
0) {
+ if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change, 0) < 0) {
kfree_skb(skb);
return;
}
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 95b9d81..3ffa60d 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1135,7 +1135,7 @@ static void rtmsg_ifa(int event, struct
if (!skb)
netlink_set_err(rtnl, 0, RTNLGRP_IPV4_IFADDR, ENOBUFS);
- else if (inet_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) {
+ else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTNLGRP_IPV4_IFADDR, EINVAL);
} else {
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index ef4724d..0f4145b 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1045,7 +1045,7 @@ fib_convert_rtentry(int cmd, struct nlms
}
nl->nlmsg_flags = NLM_F_REQUEST;
- nl->nlmsg_pid = current->pid;
+ nl->nlmsg_pid = 0;
nl->nlmsg_seq = 0;
nl->nlmsg_len = NLMSG_LENGTH(sizeof(*rtm));
if (cmd == SIOCDELRT) {
-
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
