linux-kernel - Re: [PATCH v2] workqueue.c: Increase workqueue name length

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]

Date: Wed, 10 Jan 2024 18:08:23 -0500
From: Rafael Aquini <aquini@...hat.com>
To: Rasmus Villemoes <rasmus.villemoes@...vas.dk>
Cc: Audra Mitchell <audra@...hat.com>, linux-kernel@...r.kernel.org,
	tj@...nel.org, jiangshanlai@...il.com,
	hirokazu.yamauchi.hk@...achi.com, ddouwsma@...hat.com,
	loberman@...hat.com, raquini@...hat.com
Subject: Re: [PATCH v2] workqueue.c: Increase workqueue name length

On Wed, Jan 10, 2024 at 11:52:38PM +0100, Rasmus Villemoes wrote:
> On 10/01/2024 23.31, Rafael Aquini wrote:
> > On Wed, Jan 10, 2024 at 11:06:22PM +0100, Rasmus Villemoes wrote:
> >> On 10/01/2024 22.52, Rafael Aquini wrote:
> 
> >>> The extra vsnprintf call is required because the return of the existing 
> >>> vsnprintf() is going to be already capped by sizeof(wq->name).
> >>
> >> No, it is not. vsnprintf() returns the length of the would-be-created
> >> string if the buffer was big enough. That is independent of whether one
> >> does a dummy NULL,0 call or just calls it with a real, but possibly too
> >> small, buffer.
> >>
> >> This is true for userspace (as required by posix) as well as the kernel
> >> implementation of vsnprintf(). What makes you think otherwise?
> >>
> > 
> > this snippet from PRINTF(3) man page
> > 
> > RETURN VALUE
> >        Upon successful return, these functions return the number of characters 
> >        printed (excluding the null byte used to end output to strings).
> > 
> 
> Assuming we have the same man pages installed, try reading the very next
> paragraph:
> 
>  The functions snprintf() and vsnprintf() do not write  more  than  size
>  bytes  (including the terminating null byte ('\0')).  If the output was
>  truncated due to this limit, then the return value  is  the  number  of
>  characters  (excluding the terminating null byte) which would have been
>  written to the final string if enough space had been available.   Thus,
>  a  return  value  of  size or more means that the output was truncated.
> 
> How else would you even expect the vsnprintf(NULL, 0, ...) thing to work?
>

OK, that's my bad! Sorry for the noise.
-- Rafael