title: nlmsg_new fails to allocate buffer
body: <p>I have a kernel module and a corresponding userspace module which use Netlink to communicate. The following code is used in the kernel module to send data to userspace:</p>
  
  <pre><code>int msglen = len - FRAME_PACKET_HEADER_SIZE;
  struct sk_buff* skb = nlmsg_new(msglen, GFP_ATOMIC);
  if (skb)
  {
      struct nlmsghdr* nlh = nlmsg_put(skb, 0, 0, NLMSG_DONE, msglen, GFP_ATOMIC);
      nlh-&gt;nlmsg_flags = NLM_F_REQUEST;
      NETLINK_CB(skb).dst_group = 0;
  
      memcpy(nlmsg_data(nlh), &amp;buf[FRAME_PACKET_HEADER_SIZE], msglen);
      status = nlmsg_unicast(mod_data-&gt;netlink_sock, skb, mod_data-&gt;netlink_pid);
  
  }
  </code></pre>
  
  <p>During a period of high data activity (Netlink messages sent from kernel to userspace), <code>nlmsg_new</code> starts returning <code>NULL</code> and fails to allocate. The high data activity relates to a file transfer, which is pushed to userspace in 16k blocks. After some debugging, I found that when <code>nlmsg_new</code> fails, I can successfully allocate a message slightly smaller than what I actually need to allocate (Required size is 16336 bytes, an allocation of 16000 works).</p>
  
  <p>Questions:</p>
  
  <ol>
  <li><p>The documentation I have read suggests that calling <code>nlmsg_new</code> for each message to be sent is correct. It seems that there is no way to reuse the <code>sk_buff</code> object because it may wait in a queue for a while and <code>nlmsg_unicast</code> handles deallocation when the message is actually sent (so no manual <code>nlmsg_free</code> is required). Is this definitely the case? Is there a way to possibly reuse the buffer allocated by <code>nlmsg_new</code>?</p></li>
  <li><p>I was wondering whether there are a bunch of ACK messages being queued up which are filling up some buffers somewhere. I set <code>nlmsg_flags</code> to <code>NLM_F_REQUEST</code>, so the userspace module should not be sending an ACK. Is this correct?</p></li>
  <li><p>Any other ideas why the allocation is failing?</p></li>
  </ol>
  
  <p>For context, this is running on an embedded ARM with 256 MiB RAM. Kernel is 3.14.28.</p>
  
  <p>The userspace module is constantly servicing the receive queue with a call to <code>recvmsg</code> so I don't think the receive buffer is becoming full. I think if this were the case, the kernel module would successfully allocate a buffer, but the call to <code>nlmsg_unicast</code> would return a <code>-EAGAIN</code> (which isn't happening).</p>
  
  <p>EDIT:
  I saw a note in <code>linux/netlink.h</code> which was interesting:</p>
  
  <pre><code>/*
   *  skb should fit one page. This choice is good for headerless malloc.
   *  But we should limit to 8K so that userspace does not have to
   *  use enormous buffer sizes on recvmsg() calls just to avoid
   *  MSG_TRUNC when PAGE_SIZE is very large.
   */
  </code></pre>
  
  <p>so I tried reducing the message size so that a netlink message and header was &lt; 8192 bytes but the same failure still occurred (just somewhat later, as expected).</p>
  
  <p>EDIT 2:
  After looking at the reported available memory, it looks like the <code>sk_buff</code> objects allocated via <code>nlmsg_new</code> are never being released. It seems that they should be released when the reference count (<code>users</code> for <code>sk_buff</code>) becomes 0. Would there be any reason that Netlink is holding on to the buffer, waiting for an ACK which never arrives maybe?</p>