On Wed, Jan 17, 2018 at 7:19 AM, Sowmini Varadhan
<[email protected]> wrote:
> Allow the application the ability to use MSG_PEEK with sk_error_queue
> so that it can peek and re-read message in cases where MSG_TRUNC
> may be encountered.
>
> Signed-off-by: Sowmini Varadhan <[email protected]>
> int sock_recv_errqueue(struct sock *sk, struct msghdr *msg, int len,
> - int level, int type)
> + int level, int type, int flags)
> {
> struct sock_exterr_skb *serr;
> struct sk_buff *skb;
> @@ -2916,7 +2916,10 @@ int sock_recv_errqueue(struct sock *sk, struct msghdr
> *msg, int len,
> err = copied;
>
> out_free_skb:
> - kfree_skb(skb);
> + if (likely(!(flags & MSG_PEEK)))
> + kfree_skb(skb);
> + else
> + skb_queue_head(&sk->sk_error_queue, skb);
This can cause reordering with parallel readers. Can we avoid the need
for peeking? It also caused a slew of subtle bugs previously.
How about just define a max number of cookies and require the caller
to always read with sufficient room to hold them?
