[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AF1602CB2550CE4381C0C75118A7856B0135AC94@ala-mail02.corp.ad.wrs.com>
Date: Wed, 20 Jun 2007 07:13:22 -0700
From: "Stephens, Allan" <allan.stephens@...driver.com>
To: "Patrick McHardy" <kaber@...sh.net>,
"Florian Westphal" <fw-kernel@...len.de>
Cc: <netdev@...r.kernel.org>, <jon.maloy@...csson.com>,
<per.liden@...csson.com>, <tipc-discussion@...ts.sourceforge.net>
Subject: RE: [PATCH] TIPC: Fix infinite loop in netlink handler
Patrick McHardy wrote:
> Florian Westphal wrote:
> > From: Florian Westphal <fw@...len.de>
> >
> > The tipc netlink config handler uses the nlmsg_pid from the request
> > header as destination for its reply. If the application initialized
> > nlmsg_pid to 0, the reply is looped back to the kernel, causing
> > hangup. Fix: use nlmsg_pid of the skb that triggered the request.
> >
> > - genlmsg_unicast(rep_buf, req_nlh->nlmsg_pid);
> > + genlmsg_unicast(rep_buf, NETLINK_CB(skb).pid);
>
>
> This is the second time we're seeing this bug within a few
> weeks, maybe we should rename NETLINK_CB(skb).pid to dst_pid
> to avoid similar confusion in the future? We could even
> rename nlmsg_pid to nlmsg_src within the kernel, which should
> make it completely clear what is being refered to.
I'm assuming that Patrick's first suggestion should have read "rename
NETLINK_CB(skb).pid to src_pid", as there is already a "dst_pid" field
in the netlink_skb_parms structure type.
I agree that such a change would make things clearer to folks who are
relative novices when it comes to Netlink.
-- Al
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists