Patrick McHardy wrote:
Florian Westphal wrote:
From: Florian Westphal [EMAIL PROTECTED]
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,
Stephens, Allan [EMAIL PROTECTED] wrote:
[removed tipc-discussion list from CC]
Patrick McHardy wrote:
Florian Westphal wrote:
- 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
From: Florian Westphal [EMAIL PROTECTED]
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
Florian Westphal wrote:
From: Florian Westphal [EMAIL PROTECTED]
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
