query: TCPCT setsockopt kmalloc's

On both the client and server side, the setsockopt does a kmalloc(). Only once per connect on the client side, once per listen on the server side.

However, after Miller's expressed concern, it seems possible to reorganize the code to do the kmalloc() before the lock_sock(). Does that mean that it should be GFP_KERNEL? Or should it still be GFP_ATOMIC?

[Not that anybody cares, but based on recent discussion on the list about internal kernel coding standards, I've changed Adam's old sizeof(struct) to sizeof(*tcvp). Previously, I was trying to make as few changes as possible, thinking everything was already correct.]

===
new:

+ /* Allocate ancillary memory before locking.
+ */
+ if ((0 < tcd.tcpcd_used
...
+ && NULL == (tcvp = kmalloc(sizeof(*tcvp) + tcd.tcpcd_used,
+ GFP_KERNEL))) {
+ return -ENOMEM;
+ }
+
+ lock_sock(sk);
...
+ } else {
+ if (unlikely(NULL != tp->cookie_values)) {
+ kref_put(&tp->cookie_values->kref,
+ tcp_cookie_values_release);
+ }
+ kref_init(&tcvp->kref);
...
+ tp->cookie_values = tcvp;
+ }
+
+ release_sock(sk);
+ return err;

===
old:

+ lock_sock(sk);
...
+ } else if (NULL != (tsdplp =
+ kmalloc(sizeof(struct tcp_s_data_payload)
+ + tcd.tcpcd_used,
+ GFP_ATOMIC))) {
+ if (unlikely(tp->s_data_payload)) {
+ kref_put(&tp->s_data_payload->kref,
+ tcp_s_data_payload_release);
+ }
+ kref_init(&tsdplp->kref);
...
+ tp->s_data_payload = tsdplp;
+ } else {
+ err = -ENOMEM;
+ }
+
+ release_sock(sk);
+ return err;

But if server has to generate a random data for a connection, you'll have to clone the data to be able to give it at application request ?

GFP_KERNEL is better in this context, it allows the requestor to sleep a bit if necessary.