[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080402140538.GC20815@postel.suug.ch>
Date: Wed, 2 Apr 2008 16:05:38 +0200
From: Thomas Graf <tgraf@...g.ch>
To: Patrick McHardy <kaber@...sh.net>
Cc: hadi@...erus.ca, David Miller <davem@...emloft.net>,
shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-2.6.26] netlink: make socket filters work on netlink
* Patrick McHardy <kaber@...sh.net> 2008-04-02 14:07
> jamal wrote:
> >a) that the pid belonged to the source - and 0 means "kernel".
I'm using the term netlink port for now, it avoids the confusion
and makes it clear what nlmsg_pid really is.
> Yes, for ioctl it can't carry anything but zero because it
> should contains the netlink socket pid, not the process ID,
> which obviously doesn't exist in that case.
I like the idea of a magic number although I would define it as
originator is userspace but we do not know the netlink port number.
> >b) The pid could also be some negative number (even in qdisc_notify) if
> >you have multiple netlink sockets in one process (resolvable if you
> >getname())
>
> True, but that doesn't really matter. You also can't assume that
> a positive number matches the process ID.
The netlink port is a unsigned 32 bit value, period.
> >c) what happens when processid goes to > 32-bit?
>
> Wouldn't be a problem, its the netlink socket pids, which are 32
> bit no matter what.
Also the process id is not even 32 bit so far which gives libnl the
ability to generate unique netlink ports based on the real process id
plus some iterator value. Applications using libnl which do not
generate the port number themselves could theoretiaclly resolve the real
process id back even if there are multiple sockets per application.
> In my opinion we should try to set nlmsg_pid properly since thats
> whats defined as unique identifier for netlink sockets.
Agreed.
--
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
Powered by blists - more mailing lists