netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>,
	Alexander Aring <aring@mojatatu.com>,
	davem@davemloft.net
Cc: xiyou.wangcong@gmail.com, jiri@resnulli.us,
	netdev@vger.kernel.org, kernel@mojatatu.com
Subject: Re: [PATCH net-next 1/6] net: sched: sch_api: handle generic qdisc errors
Date: Thu, 7 Dec 2017 10:52:01 -0700	[thread overview]
Message-ID: <5b8015b8-4fd2-0b1e-2e78-9b318b529f30@gmail.com> (raw)
In-Reply-To: <61d9b390-3193-3e17-ea65-30f457647eae@mojatatu.com>

On 12/7/17 5:04 AM, Jamal Hadi Salim wrote:
> On 17-12-07 12:28 AM, David Ahern wrote:
> 
>>>   -    err = nla_parse_nested(tb, TCA_STAB_MAX, opt, stab_policy, NULL);
>>> -    if (err < 0)
>>> +    err = nla_parse_nested(tb, TCA_STAB_MAX, opt, stab_policy, extack);
>>> +    if (err < 0) {
>>> +        NL_SET_ERR_MSG(extack, "Failed to parse stab netlink msg");
>>
>> you don't want to set extack here; it should be set in nla_parse_nested
>> since it is passed as an arg.
>>
> 
> Can you really have a generic message in nla_parse(_nested)? What
> would it say?
> Note: the bad attribute is saved in the bowels of nla_parsing.

sure, nla_parse only sets the bad attr arg. If you keep the above, then
it needs to be corrected - it is failing to parse the TCA_STAB nested
attribute.
> 
> -
>>>       stab = kmalloc(sizeof(*stab) + tsize * sizeof(u16), GFP_KERNEL);
>>> -    if (!stab)
>>> +    if (!stab) {
>>> +        NL_SET_ERR_MSG(extack, "Failed to allocate memory for stab
>>> data");
>>
>> ENOMEM does not need a text message. Which memory allocation failed is
>> not really relevant.
>>
> 
> YMMV.
> On the one hand it is useful to distinguish which allocation
> in the code path failed(if there was a bug for example).
> On the other hand you could argue an alloc failure is as dramatic
> as the "sky is falling" - doesnt matter what part of the globe it is
> falling at. If the cost of sending or not is the same why not include
> the message?

What value are the messages providing above and beyond the standard libc
strerror(errno)? In the case of ENOMEM, there is nothing in the user can
do to fix that particular command, so why bloat the code with extraneous
messages? Similarly with other errors like ENODEV -- if there is only 1
device in question AND the user specified the device then you do not
need to augment with an additional error message.

The value of extack is in explaining EINVAL, EOPNOTSUPP, or the
confusing inter-dependencies in command arguments. It is not a matter of
adding an extack message for every single error path; add messages that
provide value in helping the user.

  reply	other threads:[~2017-12-07 17:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06 16:08 [PATCH net-next 0/6] net: sched: sch: introduce extack support Alexander Aring
2017-12-06 16:08 ` [PATCH net-next 1/6] net: sched: sch_api: handle generic qdisc errors Alexander Aring
2017-12-06 16:52   ` Jamal Hadi Salim
2017-12-07  5:28   ` David Ahern
2017-12-07 12:04     ` Jamal Hadi Salim
2017-12-07 17:52       ` David Ahern [this message]
2017-12-07 18:08         ` David Miller
2017-12-06 16:08 ` [PATCH net-next 2/6] net: sched: sch: add extack for init callback Alexander Aring
2017-12-06 16:54   ` Jamal Hadi Salim
2017-12-06 16:08 ` [PATCH net-next 3/6] net: sched: sch: add extack for change qdisc ops Alexander Aring
2017-12-06 16:56   ` Jamal Hadi Salim
2017-12-06 16:08 ` [PATCH net-next 4/6] net: sched: sch: add extack to change class Alexander Aring
2017-12-06 16:56   ` Jamal Hadi Salim
2017-12-06 16:08 ` [PATCH net-next 5/6] net: sched: sch: add extack for block callback Alexander Aring
2017-12-06 16:57   ` Jamal Hadi Salim
2017-12-06 16:08 ` [PATCH net-next 6/6] net: sched: sch: add extack for graft callback Alexander Aring
2017-12-06 16:58   ` Jamal Hadi Salim
2017-12-06 19:10 ` [PATCH net-next 0/6] net: sched: sch: introduce extack support Cong Wang
2017-12-06 20:40 ` David Miller
2017-12-06 22:34   ` Alexander Aring
2017-12-06 22:36     ` David Miller

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=5b8015b8-4fd2-0b1e-2e78-9b318b529f30@gmail.com \
    --to=dsahern@gmail.com \
    --cc=aring@mojatatu.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kernel@mojatatu.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).