Re: [PATCH net-next] nfnetlink_queue: enable PID info retrieval

Hello,

On Fri, Jun 10, 2016 at 08:40:34AM +0200, Daniel Wagner wrote:

quoted

[ Cc'ing John, Daniel, et al ]

Btw, while I just looked at scm_detach_fds(), I think commits ...

 * 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not set
correctly")
 * d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not set
correctly")

... might not be correct, maybe I'm missing something ...? Lets say
process A
has a socket fd that it sends via SCM_RIGHTS to process B. Process A was
the
one that called sk_alloc() originally. Now in scm_detach_fds() we
install a new
fd for process B pointing to the same sock (file's private_data) and
above commits
update the cached socket cgroup data for net_cls/net_prio to the new
process B.
So, if process A for example still sends data over that socket, skbs
will then
wrongly match on B's cgroup membership instead of A's, no?

I can't remember the details right now (need to read up again but I wont
have time till Wednesday).

From your analysis I would say that is not the desired effect. A should
match against its own cgroup and not the one of B.

We don't have a good answer for resources which are shared across
different cgroups.  It is often too expensive to track such sharing
accurately and crude approximation (creator-owned, last-used or
whatever) is used widely even outside cgroup.  Different cgroup
controllers tried different approaches but most are settling down for
creator ownership with exceptions for high impact cases.

I don't think there's a solution which satifies all cases here.  Given
that, doing the minimum amount of work (not worrying about SCM_RIGHTS
transfers) is the right thing to do, but we've had this re-labeling
since 2012, so leaving as-is is likely the best option at this point.

Thanks.

-- 
tejun