As of 4.16.10, it appears to me that sk->sk_backlog_len does not provide an accurate estimate of backlog length; this reduces the usefulness of the "limit" argument to sk_add_backlog.
The problem is that, under heavy load, sk->sk_backlog_len can grow arbitrarily large, even though the actual amount of data in the backlog is small. This happens because __release_sock doesn't reset the backlog length until it gets completely caught up. Under heavy load, new packets can be arriving continuously into the backlog (which increases sk_backlog.len) while other packets are being serviced. This can go on forever, so sk_backlog.len never gets reset and it can become arbitrarily large. Because of this, the "limit" argument to sk_add_backlog may not be useful, since it could result in packets being discarded even though the backlog is not very large.