netdev - Re: [PATCH net-next] sock: deduplicate errqueue dequeue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20140901.214953.1483394533495236.davem@davemloft.net>
Date:	Mon, 01 Sep 2014 21:49:53 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	willemb@...gle.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] sock: deduplicate errqueue dequeue

From: Willem de Bruijn <willemb@...gle.com>
Date: Sun, 31 Aug 2014 21:30:27 -0400

> sk->sk_error_queue is dequeued in four locations. All share the
> exact same logic. Deduplicate.
> 
> Also collapse the two critical sections for dequeue (at the top of
> the recv handler) and signal (at the bottom).
> 
> This moves signal generation for the next packet forward, which should
> be harmless.
> 
> It also changes the behavior if the recv handler exits early with an
> error. Previously, a signal for follow-up packets on the errqueue
> would then not be scheduled. The new behavior, to always signal, is
> arguably a bug fix.
> 
> For rxrpc, the change causes the same function to be called repeatedly
> for each queued packet (because the recv handler == sk_error_report).
> It is likely that all packets will fail for the same reason (e.g.,
> memory exhaustion).
> 
> This code runs without sk_lock held, so it is not safe to trust that
> sk->sk_err is immutable inbetween releasing q->lock and the subsequent
> test. Introduce int err just to avoid this potential race.
> 
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html