On Sat, 2006-25-03 at 21:06 +0530, Balbir Singh wrote: > On Sat, Mar 25, 2006 at 07:52:13AM -0500, jamal wrote: I didnt pay attention to failure paths etc; i suppose your testing should catch those. Getting there, a couple more comments: > +enum { > + TASKSTATS_CMD_UNSPEC = 0, /* Reserved */ > + TASKSTATS_CMD_GET, /* user->kernel request */ > + TASKSTATS_CMD_NEW, /* kernel->user event */ Should the comment read "kernel->user event/get-response" > + > +static int taskstats_send_stats(struct sk_buff *skb, struct genl_info *info) > +{ > + > + if (info->attrs[TASKSTATS_CMD_ATTR_PID]) { > + u32 pid = nla_get_u32(info->attrs[TASKSTATS_CMD_ATTR_PID]); > + rc = fill_pid((pid_t)pid, NULL, &stats); > + if (rc < 0) > + goto err; > + > + na = nla_nest_start(rep_skb, TASKSTATS_TYPE_AGGR_PID); > + NLA_PUT_U32(rep_skb, TASKSTATS_TYPE_PID, pid); > + } else if (info->attrs[TASKSTATS_CMD_ATTR_TGID]) { in regards to the elseif above: Could you not have both PID and TGID passed? From my earlier understanding it seemed legit, no? if answer is yes, then you will have to do your sizes + reply TLVs at the end. Also in regards to the nesting, isnt there a need for nla_nest_cancel in case of failures to add TLVs? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: "Balbir Singh" <balbir@in.ibm.com>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- References:
- Re: [Patch 9/9] Generic netlink interface for delay accounting
- From: Matt Helsley <matthltc@us.ibm.com>
- Re: [Patch 9/9] Generic netlink interface for delay accounting
- From: jamal <hadi@cyberus.ca>
- [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: Balbir Singh <balbir@in.ibm.com>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: jamal <hadi@cyberus.ca>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: Balbir Singh <balbir@in.ibm.com>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: jamal <hadi@cyberus.ca>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: Balbir Singh <balbir@in.ibm.com>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: jamal <hadi@cyberus.ca>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: Balbir Singh <balbir@in.ibm.com>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: jamal <hadi@cyberus.ca>
- Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- From: Balbir Singh <balbir@in.ibm.com>
- Re: [Patch 9/9] Generic netlink interface for delay accounting
- Prev by Date: Virtual Serial Port
- Next by Date: Re: RFC: Non Power of 2 memory allocator
- Previous by thread: Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- Next by thread: Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
- Index(es):
![]() |