linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	jens.axboe@oracle.com
Subject: Re: [patch] pipe: add support for shrinking and growing pipes
Date: Sat, 22 May 2010 22:38:38 -0400	[thread overview]
Message-ID: <20100522223838.ebca396a.akpm@linux-foundation.org> (raw)
In-Reply-To: <AANLkTikkRywJSJ8HFsVhVU9dHz8cFGqlK9ZHXZuGQbb2@mail.gmail.com>

On Sun, 23 May 2010 07:30:01 +0200 Michael Kerrisk <mtk.manpages@gmail.com> 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
> <torvalds@linux-foundation.org> 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.

  reply	other threads:[~2010-05-23  2:38 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 16:45 [patch] pipe: add support for shrinking and growing pipes Miklos Szeredi
2010-05-19 16:49 ` Linus Torvalds
2010-05-19 18:05   ` Jens Axboe
2010-05-19 19:05     ` Jens Axboe
2010-05-20  8:33       ` Miklos Szeredi
2010-05-20  8:37         ` Jens Axboe
2010-05-20 17:42           ` Linus Torvalds
2010-05-20 17:48             ` Jens Axboe
2010-05-21 17:13               ` Rick Sherm
2010-05-23  5:30   ` Michael Kerrisk
2010-05-23  2:38     ` Andrew Morton [this message]
2010-05-23  5:52       ` Michael Kerrisk
2010-05-23  7:09         ` Jens Axboe
2010-05-23  9:24           ` Michael Kerrisk
2010-05-23 17:47             ` Jens Axboe
2010-05-24  1:43               ` OGAWA Hirofumi
2010-05-24  4:43                 ` Michael Kerrisk
2010-05-24  7:05                   ` Jens Axboe
2010-05-24  7:27                     ` Michael Kerrisk
2010-05-24 17:35                       ` Jens Axboe
2010-05-24 17:52                         ` Michael Kerrisk
2010-05-24 17:56                           ` Jens Axboe
2010-05-25  4:01                             ` Michael Kerrisk
2010-06-01  7:48                               ` Jens Axboe
2010-06-01 15:22                                 ` Linus Torvalds
2010-06-01 16:36                                   ` Loke, Chetan
2010-05-27  6:49                             ` Michael Kerrisk
2010-06-01  7:45                               ` Jens Axboe
2010-06-02 19:25                                 ` Michael Kerrisk
2010-06-03  6:10                                   ` Jens Axboe
2010-06-03  6:46                                     ` Michael Kerrisk
2010-06-03  7:01                                       ` Jens Axboe
2010-06-03  7:05                                         ` Michael Kerrisk
2010-06-03  7:48                                           ` Michael Kerrisk
2010-06-03  7:58                                             ` Michael Kerrisk
2010-06-03  8:29                                               ` Michael Kerrisk
2010-06-03  8:53                                                 ` Michael Kerrisk
2010-05-24  7:04                 ` Jens Axboe
2010-05-24  7:28                   ` Michael Kerrisk
2010-05-24  7:49                     ` OGAWA Hirofumi
2010-05-24 14:51                     ` Brian Bloniarz
2010-05-24 15:43                       ` Michael Kerrisk
2010-05-24  7:46                   ` OGAWA Hirofumi
2010-05-24 17:15                     ` Jens Axboe
2010-05-24 18:12                       ` OGAWA Hirofumi
2010-05-24 18:16                         ` Michael Kerrisk
2010-05-20 12:52 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100522223838.ebca396a.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mtk.manpages@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).