Re: [PATCH] pipe: increase minimum default pipe size to 2 pages

["Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>]

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@yahoo.ca>
>> ---
> 
> 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.