From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752100Ab0EWHJU (ORCPT ); Sun, 23 May 2010 03:09:20 -0400 Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:48252 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751074Ab0EWHJT (ORCPT ); Sun, 23 May 2010 03:09:19 -0400 Date: Sun, 23 May 2010 09:09:18 +0200 From: Jens Axboe To: mtk.manpages@gmail.com Cc: Andrew Morton , Linus Torvalds , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [patch] pipe: add support for shrinking and growing pipes 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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 indefinitely. > >> >> 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 buffers, 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 changes? > >> > >> The argument of the fcntl() operations is expressed in pages. I take > >> 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 mean > >> 8192 bytes, but will mean 32768 of ia64? That seems very weird. (And > >> 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().  But I agree - this interface is just > > asking (x86) people to write non-portable code. > > > > otoh, if the arg was in bytes, they'd just hard-code "8192".  They'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 approach > > to syscalls. > > 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. > And while there will be the silly users you mention above, smart users > 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. -- Jens Axboe