[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20191013.112057.237383467723026890.davem@davemloft.net>
Date: Sun, 13 Oct 2019 11:20:57 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mkubecek@...e.cz
Cc: jiri@...lanox.com, johannes@...solutions.net,
jakub.kicinski@...ronome.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3] genetlink: do not parse attributes for
families with zero maxattr
From: Michal Kubecek <mkubecek@...e.cz>
Date: Fri, 11 Oct 2019 09:40:09 +0200
> Commit c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing
> to a separate function") moved attribute buffer allocation and attribute
> parsing from genl_family_rcv_msg_doit() into a separate function
> genl_family_rcv_msg_attrs_parse() which, unlike the previous code, calls
> __nlmsg_parse() even if family->maxattr is 0 (i.e. the family does its own
> parsing). The parser error is ignored and does not propagate out of
> genl_family_rcv_msg_attrs_parse() but an error message ("Unknown attribute
> type") is set in extack and if further processing generates no error or
> warning, it stays there and is interpreted as a warning by userspace.
>
> Dumpit requests are not affected as genl_family_rcv_msg_dumpit() bypasses
> the call of genl_family_rcv_msg_attrs_parse() if family->maxattr is zero.
> Move this logic inside genl_family_rcv_msg_attrs_parse() so that we don't
> have to handle it in each caller.
>
> v3: put the check inside genl_family_rcv_msg_attrs_parse()
> v2: adjust also argument of genl_family_rcv_msg_attrs_free()
>
> Fixes: c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a separate function")
> Signed-off-by: Michal Kubecek <mkubecek@...e.cz>
Applied, thanks.
Powered by blists - more mailing lists