All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, akpm@linux-foundation.org, julia@diku.dk,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] FRV: Fix mmap2 error handling
Date: Thu, 27 Nov 2008 16:59:27 +0000	[thread overview]
Message-ID: <20081127165926.GM25548@parisc-linux.org> (raw)
In-Reply-To: <20081127151238.13728.34704.stgit@warthog.procyon.org.uk>

On Thu, Nov 27, 2008 at 03:12:38PM +0000, David Howells wrote:
> Fix the error handling in sys_mmap2().  Currently, if the pgoff check fails,
> fput() might have to be called (which it isn't), so do the pgoff check first,
> before fget() is called.

*sigh*.

My reaction was "Why do we have sys_mmap2 in every architecture?"  So I
started looking.  Oh dear, oh dear oh dear.

FRV:
        /* As with sparc32, make sure the shift for mmap2 is constant
           (12), no matter what PAGE_SIZE we have.... */
ia64:
Just uses PAGE_SIZE (currently supported values: 4k, 8k, 16k and 64k).

So what is poor userspace to do?  Check which architecture it's on and
figure out what PAGE_SIZE to use for mmap2 based on that?


How about we introduce a sys_mmap6() in common code which takes 'off'
in multiples of 4k.  Then FRV and other sane architectures can replace
their sys_mmap2 entries in their syscall tables with sys_mmap6.  ia64 has
to keep its insane sys_mmap2 entry, but it can add a sys_mmap6 entry too.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <matthew@wil.cx>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, akpm@linux-foundation.org, julia@diku.dk,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] FRV: Fix mmap2 error handling
Date: Thu, 27 Nov 2008 09:59:27 -0700	[thread overview]
Message-ID: <20081127165926.GM25548@parisc-linux.org> (raw)
In-Reply-To: <20081127151238.13728.34704.stgit@warthog.procyon.org.uk>

On Thu, Nov 27, 2008 at 03:12:38PM +0000, David Howells wrote:
> Fix the error handling in sys_mmap2().  Currently, if the pgoff check fails,
> fput() might have to be called (which it isn't), so do the pgoff check first,
> before fget() is called.

*sigh*.

My reaction was "Why do we have sys_mmap2 in every architecture?"  So I
started looking.  Oh dear, oh dear oh dear.

FRV:
        /* As with sparc32, make sure the shift for mmap2 is constant
           (12), no matter what PAGE_SIZE we have.... */
ia64:
Just uses PAGE_SIZE (currently supported values: 4k, 8k, 16k and 64k).

So what is poor userspace to do?  Check which architecture it's on and
figure out what PAGE_SIZE to use for mmap2 based on that?


How about we introduce a sys_mmap6() in common code which takes 'off'
in multiples of 4k.  Then FRV and other sane architectures can replace
their sys_mmap2 entries in their syscall tables with sys_mmap6.  ia64 has
to keep its insane sys_mmap2 entry, but it can add a sys_mmap6 entry too.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2008-11-27 16:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27 15:12 [PATCH] FRV: Fix mmap2 error handling David Howells
2008-11-27 16:59 ` Matthew Wilcox [this message]
2008-11-27 16:59   ` Matthew Wilcox
2008-11-29 11:24 ` David Howells
2008-11-29 11:24   ` David Howells

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=20081127165926.GM25548@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=julia@diku.dk \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.