netdev - Re: TIOCOUTQ implementation for sockets vs. tty

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210310182935.GC17851@1wt.eu>
Date:   Wed, 10 Mar 2021 19:29:35 +0100
From:   Willy Tarreau <w@....eu>
To:     Henneberg - Systemdesign <lists@...neberg-systemdesign.com>
Cc:     netdev@...r.kernel.org
Subject: Re: TIOCOUTQ implementation for sockets vs. tty

Hi,

On Wed, Mar 10, 2021 at 07:16:34PM +0100, Henneberg - Systemdesign wrote:
> Hi,
> 
> I have a question regarding the implementation of ioctl TIOCOUTQ for
> various sockets compared to the tty implementation.
> 
> For several sockets, e. g. AF_BLUETOOTH it is done like this
> 
> af_bluetooth.c:
> case TIOCOUTQ:
> 	if (sk->sk_state == BT_LISTEN)
> 		return -EINVAL;
> 
> 	amount = sk->sk_sndbuf - sk_wmem_alloc_get(sk);
> 	if (amount < 0)
> 		amount = 0;
> 	err = put_user(amount, (int __user *)arg);
> 	break;
> 
> so the ioctl returns the available space in the send queue if I
> understand the code correctly (this is also what I observed from tests).
> 
> The tty does this:
> 
> n_tty.c:
> case TIOCOUTQ:
> 	return put_user(tty_chars_in_buffer(tty), (int __user *) arg);
> 
> so it returns the used space in the send queue. This is also what I
> would expect from the manpage description.
> 
> Is this mismatch intentional?

At least both man pages (tty_ioctl and tcp(7)) mention that TIOCOUTQ
should return the number of byte in queue.

What I suspect for sockets is that sk_sndbuf grows with allocations
and that sk_wmem_alloc_get() in fact returns the number of unused
allocations thus the difference would be the amount queued. But I
could be wrong and I would tend to read the code the same way as you
did.

Willy