Re: [PATCH 09/16] [IPv6] address: Convert address notification to use rtnl_notify()

[Thomas Graf <tgraf@suug.ch>]

* Herbert Xu <herbert@gondor.apana.org.au> 2006-08-16 21:12
> On Wed, Aug 16, 2006 at 12:58:56PM +0200, Thomas Graf wrote:
> > 
> > All route and tc notifications already use the pid so applications
> > can decide whether the event was caused by them. A notification
> > is a reply to a request so it doesn't even violate RFC 2367.
> 
> Actually most IPv4 notifications *do* set the pid to zero which is
> the right thing to do for kernel-generated messages.
> 
> You're right though that the IPv6 notification modified by this patch
> does set the pid to the netlink originator.  Looking back in history
> it seems that this behaviour was only introduced last year to a subset
> of notifications.

It was added to help quagga identify which route modifications
are self caused. It's not possible to use rtm_protocol for this
purpose as other applications can delete routes added by quagga.

> This inconsistency is very bad.  IMHO this change (made last year)
> should be reverted so that all kernel generated (broadcast) notifications
> have the originator set to zero to match the source address of the
> message.

We can't just knowingly break quagga.

I think it's a good thing to include the pid, it's additional
information that is helpful to userspace. Userspace is already
aware that the notifications are orignating from the kernel,
we can't do userspace -> userspace communication anymore anyway.

> Any notification that sets the netlink pid to current->pid is
> *completely* bogus.  Let me repeat this, the netlink pid is not
> a process ID.

Everyone is aware of that, actually these patches fix all
occurences of current->pid by replacing them with a pid of 0.