Thomas Graf wrote:
* Oleg Nesterov <[email protected]> 2006-11-01 21:26
Introduce mk_reply() helper which does all nla_put()s on reply.
Saves 453 bytes and a preparation for the next patch.
Signed-off-by: Oleg Nesterov <[email protected]>
taskstats.c | 55 ++++++++++++++++++++++++++++---------------------------
1 files changed, 28 insertions(+), 27 deletions(-)
--- STATS/kernel/taskstats.c~5_factor 2006-10-31 16:33:56.000000000 +0300
+++ STATS/kernel/taskstats.c 2006-11-01 14:00:03.000000000 +0300
@@ -348,6 +348,25 @@ static int parse(struct nlattr *na, cpum
return ret;
}
+static int mk_reply(struct sk_buff *skb, int type, u32 pid, struct taskstats *stats)
+{
+ struct nlattr *na;
+ int aggr;
+
+ aggr = TASKSTATS_TYPE_AGGR_TGID;
+ if (type == TASKSTATS_TYPE_PID)
+ aggr = TASKSTATS_TYPE_AGGR_PID;
+
+ na = nla_nest_start(skb, aggr);
if (!na)
goto nla_put_failure;
+ NLA_PUT_U32(skb, type, pid);
+ NLA_PUT_TYPE(skb, struct taskstats, TASKSTATS_TYPE_STATS, *stats);
+ nla_nest_end(skb, na);
+
+ return 0;
+nla_put_failure:
+ return -1;
+}
nla_nest_start() may return NULL, either rely on prepare_reply() to be
correct and BUG() on failure or do proper error handling for all
functions.
Thanks for catching that bug which was present in the unrefactored code.
The error path from prepare_reply() which generates the skb is being
handled already.
But as you point out, nla_nest_start failure, unlike those of the NLA_PUT_*
macros, isn't handled by having a nla_put_failure label alone. So we'll
need to add something like the above since we certainly don't want a BUG()
on failure !
Thanks,
Shailabh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
