Excerpts from Greg KH's message of August 5, 2021 4:35 am:
> On Wed, Aug 04, 2021 at 08:04:35PM -0400, Alex Xu (Hello71) wrote:
>> Before this patch, the following program prints 4096 and hangs.
>> Afterwards, it prints 8192 and exits successfully. Note that you may
>> need to increase your RLIMIT_NOFILE before running the program.
>>
>> int main() {
>> int pipefd[2];
>> for (int i = 0; i < 1025; i++)
>> if (pipe(pipefd) == -1)
>> return 1;
>> size_t bufsz = fcntl(pipefd[1], F_GETPIPE_SZ);
>> printf("%zd\n", bufsz);
>> char *buf = calloc(bufsz, 1);
>> write(pipefd[1], buf, bufsz);
>> read(pipefd[0], buf, bufsz-1);
>> write(pipefd[1], buf, 1);
>> }
>>
>> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@xxxxxxxx>
>> ---
>
> Is this due to the changes that happened in 5.5? If so, a cc: stable
> and a fixes tag would be nice to have :)
>
>> See discussion at https://lore.kernel.org/lkml/1628086770.5rn8p04n6j.none@localhost/.
>
> This can go up in the changelog text too.
>
> thanks,
>
> greg k-h
>
I tested 5.4 and it exhibits the same problem as master using this
non-racy program. I think the problem goes back to v4.5, the first
release with 759c01142a ("pipe: limit the per-user amount of pages
allocated in pipes"). The issue likely become more apparent with the
improvement in pipe performance from v5.5, whereas before that, pipes
were too slow for the issue to manifest in racy environments.
I'll send a new patch with #include lines and a Fixes: 759c01142a. I'm
not 100% sure that it actually goes back that far, but the worst thing
that can plausibly happen is that applications opening very large
numbers of pipes suddenly use slightly more memory. I certainly hope
nobody is relying on pipes randomly blocking roughly 1/4096 of the
time.
Regards,
Alex.
