From: Shailabh Nagar <nagar@watson.ibm.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: Oleg Nesterov <oleg@tv-sign.ru>, Andrew Morton <akpm@osdl.org>,
Balbir Singh <balbir@in.ibm.com>, Jay Lan <jlan@sgi.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] taskstats: factor out reply assembling
Date: Thu, 02 Nov 2006 07:37:31 -0500 [thread overview]
Message-ID: <4549E68B.4020300@watson.ibm.com> (raw)
In-Reply-To: <20061102103402.GH12964@postel.suug.ch>
Thomas Graf wrote:
> * Oleg Nesterov <oleg@tv-sign.ru> 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 <oleg@tv-sign.ru>
>>
>> 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
prev parent reply other threads:[~2006-11-02 12:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-01 18:26 [PATCH 1/2] taskstats: factor out reply assembling Oleg Nesterov
2006-11-01 20:31 ` Shailabh Nagar
2006-11-02 5:13 ` Balbir Singh
2006-11-02 13:22 ` Oleg Nesterov
2006-11-02 13:44 ` Balbir Singh
2006-11-02 10:34 ` Thomas Graf
2006-11-02 12:37 ` Shailabh Nagar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4549E68B.4020300@watson.ibm.com \
--to=nagar@watson.ibm.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=jlan@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.