Quoting Dan Smith (danms@xxxxxxxxxx): > >> /* Make sure there's room in the send buffer */ > >> sndbuf = sk->sk_sndbuf; > >> - if (((sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc)) < len) && > >> + if (((sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc)) < h->lin_len) && > >> capable(CAP_NET_ADMIN)) > >> - sk->sk_sndbuf += len; > >> + sk->sk_sndbuf += h->lin_len; > >> else > sk-> sk_sndbuf = sysctl_wmem_max; > > SH> Can you explain what's going on here? > > If we're trying to restore a buffer that is larger than the remaining > space in the buffer, then one of two things can happen: > > 1. You're privileged and we make the space you need > 2. You're not privileged so we give you the benefit of the doubt and > set the buffer limit to the system default > > In the case of 2, if that system default still isn't enough then the > sendmsg() will fail like it normally would. But so should check whether h->len_len < sysctl_wmem_max before doing the capable check? Remember that any check for capable() will set PF_SUPERPRIV on the task, so it's better to not call it if it wasn't definately needed. > The reason for this is that the application could have loaded up its > legitimate buffer with data and then set the buffer limit low. That > doesn't purge the data it already had buffered, it just limits how > much you can add to it. So, in order to not fail a restart of such a > legitimate situation, we assume the system default instead of the > limit set by the user. thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers