[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <201487e9-235c-8604-50f2-02bd1170d8e8@infradead.org>
Date: Thu, 14 Sep 2017 09:57:12 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: mtk.manpages@...il.com, Joe Lawrence <joe.lawrence@...hat.com>
Cc: lkml <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
Mikulas Patocka <mpatocka@...hat.com>
Subject: Re: [PATCH RFC 0/3] A few round_pipe_size() and pipe-max-size fixups
On 09/14/17 06:26, Michael Kerrisk (man-pages) wrote:
> Hello Joe,
>
> On 5 September 2017 at 16:44, Joe Lawrence <joe.lawrence@...hat.com> wrote:
>> While backporting Michael's "pipe: fix limit handling" [1] patchset to a
>> distro-kernel, Mikulas noticed that current upstream pipe limit handling
>> contains a few problems:
>>
>> 1 - round_pipe_size() nr_pages overflow on 32bit: this would
>> subsequently try roundup_pow_of_two(0), which is undefined.
Hi,
Sorry I missed the initial posting of this.
The man page for F_SETPIPE_SZ (http://man7.org/linux/man-pages/man2/fcntl.2.html)
says:
"Attempts to set the pipe capacity below the page size are
silently rounded up to the page size."
That implies to me that setting pipe size to 0 would round up to PAGE_SIZE.
Doesn't patch 1/3 change that to return -EINVAL?
Otherwise all 3 patches look good to me.
thanks,
--
~Randy
Powered by blists - more mailing lists