aboutsummaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorDenis V. Lunev <den@openvz.org>2007-10-11 00:15:29 -0400
committerDavid S. Miller <davem@davemloft.net>2007-10-11 00:15:29 -0400
commitcd40b7d3983c708aabe3d3008ec64ffce56d33b0 (patch)
tree0d6fe9cfd2f03fdeee126e317d4bfb145afc458d /fs
parentaed815601f3f95281ab3a01f7e2cbe1bd54285a0 (diff)
[NET]: make netlink user -> kernel interface synchronious
This patch make processing netlink user -> kernel messages synchronious. This change was inspired by the talk with Alexey Kuznetsov about current netlink messages processing. He says that he was badly wrong when introduced asynchronious user -> kernel communication. The call netlink_unicast is the only path to send message to the kernel netlink socket. But, unfortunately, it is also used to send data to the user. Before this change the user message has been attached to the socket queue and sk->sk_data_ready was called. The process has been blocked until all pending messages were processed. The bad thing is that this processing may occur in the arbitrary process context. This patch changes nlk->data_ready callback to get 1 skb and force packet processing right in the netlink_unicast. Kernel -> user path in netlink_unicast remains untouched. EINTR processing for in netlink_run_queue was changed. It forces rtnl_lock drop, but the process remains in the cycle until the message will be fully processed. So, there is no need to use this kludges now. Signed-off-by: Denis V. Lunev <den@openvz.org> Acked-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'fs')
-rw-r--r--fs/ecryptfs/netlink.c14
1 files changed, 1 insertions, 13 deletions
diff --git a/fs/ecryptfs/netlink.c b/fs/ecryptfs/netlink.c
index 056519cd92bc..9aa345121e09 100644
--- a/fs/ecryptfs/netlink.c
+++ b/fs/ecryptfs/netlink.c
@@ -165,22 +165,10 @@ static int ecryptfs_process_nl_quit(struct sk_buff *skb)
165 * it to its desired netlink context element and wake up the process 165 * it to its desired netlink context element and wake up the process
166 * that is waiting for a response. 166 * that is waiting for a response.
167 */ 167 */
168static void ecryptfs_receive_nl_message(struct sock *sk, int len) 168static void ecryptfs_receive_nl_message(struct sk_buff *skb)
169{ 169{
170 struct sk_buff *skb;
171 struct nlmsghdr *nlh; 170 struct nlmsghdr *nlh;
172 int rc = 0; /* skb_recv_datagram requires this */
173 171
174receive:
175 skb = skb_recv_datagram(sk, 0, 0, &rc);
176 if (rc == -EINTR)
177 goto receive;
178 else if (rc < 0) {
179 ecryptfs_printk(KERN_ERR, "Error occurred while "
180 "receiving eCryptfs netlink message; "
181 "rc = [%d]\n", rc);
182 return;
183 }
184 nlh = nlmsg_hdr(skb); 172 nlh = nlmsg_hdr(skb);
185 if (!NLMSG_OK(nlh, skb->len)) { 173 if (!NLMSG_OK(nlh, skb->len)) {
186 ecryptfs_printk(KERN_ERR, "Received corrupt netlink " 174 ecryptfs_printk(KERN_ERR, "Received corrupt netlink "