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]
Date: Sat, 1 Jun 2024 14:30:25 +0100
From: Simon Horman <horms@...nel.org>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next] af_unix: Don't check last_len in
 unix_stream_data_wait().

On Thu, May 30, 2024 at 09:42:56AM -0700, Kuniyuki Iwashima wrote:
> When commit 869e7c62486e ("net: af_unix: implement stream sendpage
> support") added sendpage() support, data could be appended to the last
> skb in the receiver's queue.
> 
> That's why we needed to check if the length of the last skb was changed
> while waiting for new data in unix_stream_data_wait().
> 
> However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and
> commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use
> MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added
> to a new skb.
> 
> Now we no longer need to check the length of the last skb, so let's
> remove the dead logic in unix_stream_data_wait().
> 
> Signed-off-by: Kuniyuki Iwashima <kuniyu@...zon.com>

...

> @@ -2744,8 +2738,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
>  
>  			mutex_unlock(&u->iolock);
>  
> -			timeo = unix_stream_data_wait(sk, timeo, last,
> -						      last_len, freezable);
> +			timeo = unix_stream_data_wait(sk, timeo, last, freezable);

Hi Iwashima-san,

A minor nit from my side. In the case that you have to reason perhaps
keep the line above to <= 80 columns wide.

...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ