Re: Merge of per task delay accounting (was Re: 2.6.18 -mm merge plans)

[Shailabh Nagar <nagar@watson.ibm.com>]

Andrew Morton wrote:

>On Thu, 08 Jun 2006 10:27:46 -0400
>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
>  
>
>>Andrew Morton wrote:
>>
>>    
>>
>>>On Tue, 06 Jun 2006 18:28:15 -0400
>>>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>So, we have a good consensus from existing/potential users of taskstats and would
>>>>very much appreciate it being included in 2.6.18.
>>>>   
>>>>
>>>>        
>>>>
>>>Yes, for 2.6.18 I'm inclined to send taskstats and to continue to play
>>>wait-and-see on the statistics infrastructure.  Greg is taking a look at
>>>the stats code, which is good.
>>>
>>> 
>>>
>>>      
>>>
>>Thanks !
>>
>>The suggestion from  Jay Lan to extend the interface by making sending 
>>of tgid stats configurable
>>is quite reasonable and can be done relatively simply:
>>set some parameter, either by sending a separate command (verify sender 
>>is privileged) or by
>>some sysfs parameter and use that to control sending of tgid stats on 
>>task exit (as well as allocation of
>>any tgid stat related structures).
>>    
>>
>
>hm.  Is it possible to check the privileges of a netlink message sender?
>  
>
Not entirely sure. But there's a check in net/netlink/genetlink.c: 
genl_rcv_msg()
for
if ((ops->flags & GENL_ADMIN_PERM) && security_netlink_recv(skb))
{    err = -EPERM;
    goto errout;
}

and security_netlink_recv(skb), normally set to cap_netlink_recv, checks 
on the skb's effective capability
being CAP_NET_ADMIN which I thought would be sufficient.
Need to look further.

If it doesn't turn out to fit properly, sysfs config variable can be used.

>>Would you recommend we submit a patch for it now or wait till after 
>>delay accounting has gone into
>>2.6.18 ?
>>    
>>
>
>Earlier, please.
>  
>
Ok. will submit asap.

>  
>
>>Such requests for extending the interface are likely to happen as more 
>>users start using the interface.
>>But since any patch will need some testing etc. and we are very close to 
>>the 2.6.18 merge window, I
>>wanted your advice on whether this should wait until later.
>>    
>>
>
>If it's merged, we'll have a couple more months to test it, and to fix any
>little problems.
>  
>
Sounds good.


Thanks,
Shailabh