On Wed, May 16, 2018 at 11:37 AM, David Miller <da...@davemloft.net> wrote: > From: Roopa Prabhu <ro...@cumulusnetworks.com> > Date: Tue, 15 May 2018 20:55:06 -0700 > >> +static int inet_rtm_getroute_reply(struct sk_buff *in_skb, struct nlmsghdr >> *nlh, >> + __be32 dst, __be32 src, struct flowi4 *fl4, >> + struct rtable *rt, struct fib_result *res) >> +{ >> + struct net *net = sock_net(in_skb->sk); >> + struct rtmsg *rtm = nlmsg_data(nlh); >> + u32 table_id = RT_TABLE_MAIN; >> + struct sk_buff *skb; >> + int err = 0; >> + >> + skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); >> + if (!skb) >> + return -ENOMEM; > > If the caller can use GFP_KERNEL, so can this allocation.
yes, but we hold rcu read lock before calling the reply function for fib result. I did consider allocating the skb before the read lock..but then the refactoring (into a separate netlink reply func) would seem unnecessary. I am fine with pre-allocating and undoing the refactoring if that works better.