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

[Shailabh Nagar]

Andrew Morton wrote:

> On Thu, 08 Jun 2006 10:27:46 -0400
> Shailabh Nagar <nagar@xxxxxxxxxxxxxx> wrote:
>
>  
>
> > Andrew Morton wrote:
> >
> >    
> >
> > > On Tue, 06 Jun 2006 18:28:15 -0400
> > > Shailabh Nagar <nagar@xxxxxxxxxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/