genlmsg_reply() indirectly makes a call to kmalloc but takes no
GFP flags, instead using GFP_ATOMIC if in a softirq and GFP_KERNEL
otherwise.  However, here we hold rcu_read_lock(), which requires
GFP_ATOMIC but is not a softirq.  Since we've already built the
reply message, it is safe to release rcu_read_lock(), so do that
before calling genlmsg_reply().

Signed-off-by: Jesse Gross <[email protected]>
CC: Hao Zheng <[email protected]>
---
 datapath/datapath.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/datapath/datapath.c b/datapath/datapath.c
index 826d899..7280122 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -1904,7 +1904,9 @@ static int odp_vport_cmd_get(struct sk_buff *skb, struct 
genl_info *info)
        if (IS_ERR(reply))
                goto exit_unlock;
 
-       err = genlmsg_reply(reply, info);
+       rcu_read_unlock();
+
+       return genlmsg_reply(reply, info);
 
 exit_unlock:
        rcu_read_unlock();
-- 
1.7.4.1

_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

Reply via email to