From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [patch] pipe: add support for shrinking and growing pipes Date: Sun, 23 May 2010 09:09:18 +0200 Message-ID: <20100523070917.GO23411@kernel.dk> References: <20100522223838.ebca396a.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andrew Morton , Linus Torvalds , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: mtk.manpages@gmail.com Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, May 23 2010, Michael Kerrisk wrote: > On Sun, May 23, 2010 at 4:38 AM, Andrew Morton > wrote: > > On Sun, 23 May 2010 07:30:01 +0200 Michael Kerrisk wrote: > > > >> Hi all, > >> > >> I see that this patch has hit Linus's git, so some questions > >> > >> On Wed, May 19, 2010 at 6:49 PM, Linus Torvalds > >> wrote: > >> > > >> > > >> > On Wed, 19 May 2010, Miklos Szeredi wrote: > >> >> > >> >> One issue I see is that it's possible to grow pipes indefinitel= y. > >> >> Should this be restricted to privileged users? > >> > > >> > Yes. But perhaps only if it grows past the default (or perhaps "= default*2" > >> > or similar). That way a normal user could shrink the pipe buffer= s, and > >> > then grow them again if he wants to. > >> > > >> > Oh, and I think you need to also require that there be at least = two > >> > buffers. Otherwise we can't guarantee POSIX behavior, I think. > >> > >> Is there any documentation (e.g., a man-pages patch) for these cha= nges? > >> > >> The argument of the fcntl() operations is expressed in pages. I ta= ke > >> it that this means that the semantics of the argument will very > >> depending on the system page size? So for example, 2 on x86 will m= ean > >> 8192 bytes, but will mean 32768 of ia64? That seems very weird. (A= nd > >> what about architectures where the page size is switchable?) Such > >> changes in semantics should not be silent for the use, IMO. > > > > Well, there is getpagesize(). =A0But I agree - this interface is ju= st > > asking (x86) people to write non-portable code. > > > > otoh, if the arg was in bytes, they'd just hard-code "8192". =A0The= y're > > clever like that. > > > > But we have gone to some lengths to avoid exposing things like > > PAGE_SIZE and HZ in procfs, so it makes sense to take the same appr= oach > > to syscalls. >=20 > Quite. All of the other memory-related APIs that I can think of > require the user to express the info in bytes. (mlock(), > remap_file_pages(), mmap(), mremap(), mprotect(), shmget(), and so > on). Not doing the same for this interface is needlessly inconsistent= =2E > And while there will be the silly users you mention above, smart user= s > will know how to do the right thing with a consistently designed > interface. We can easily make F_GETPIPE_SZ return bytes, but I don't think passing in bytes to F_SETPIPE_SZ makes a lot of sense. The pipe array must be a power of 2 in pages. So the question is if that makes the API cleaner, passing in number of pages but returning bytes? Or pass in bytes all around, but have F_SETPIPE_SZ round to the nearest multiple of pow2 in pages if need be. Then it would return a size at least what was passed in, or error. --=20 Jens Axboe