linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	ebmunson@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-man@vger.kernel.org,
	mtk.manpages@gmail.com, randy.dunlap@oracle.com, rth@twiddle.net,
	ink@jurassic.park.msu.ru, linux-ia64@vger.kernel.org
Subject: Re: [PATCH] remove duplicate asm/mman.h files
Date: Mon, 21 Sep 2009 11:30:26 +0200	[thread overview]
Message-ID: <200909211130.26377.arnd@arndb.de> (raw)
In-Reply-To: <alpine.DEB.1.00.0909210208180.16086@chino.kir.corp.google.com>

On Monday 21 September 2009, David Rientjes wrote:
> > I tried not to change the ABI in any way in my patch, and there is
> > a theoretical possibility that some user space program on ia64 currently
> > depends on that definition.
> > 
> 
> I don't buy that as justification, if some userspace program uses it based 
> on the false belief that it actually does what it says, it's probably 
> better to break their build than perpetuating the lie that it's different 
> than ~MAP_GROWSDOWN.

It's more a matter of principle of my patches. I try to strictly separate
patches that move code around (like the one I sent) from those that
change contents (like yours, or the one before that adds MAP_STACK and
MAP_HUGETLB).

Removing a definition from an exported header file either requires
specific knowledge about why it is there to start with, or more
research on the topic than I wanted to do. For instance, a theoretical
program might have a helper function correctly doing

void *xmmap(void *addr, size_t length, int prot, int flags,
                  int fd, off_t offset)
{
	if (flags & MAP_GROWSUP) { /* MAP_GROWSUP is not supported */
		errno = -EINVAL;
		return MAP_FAILED;
	}

	return mmap(addr, length, prot, flags, fd, offset);
}

Of course, such a program would only work on ia64 currently, so
it should be safe to make ia64 behave like the other architectures
in this regard.

> ia64: remove definition for MAP_GROWSUP
> 
> MAP_GROWSUP is unused.
>
> Signed-off-by: David Rientjes <rientjes@google.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-09-21  9:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-25 11:14 [PATCH 0/3] Add pseudo-anonymous huge page mappings V4 Eric B Munson
2009-08-25 11:14 ` [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Eric B Munson
2009-08-25 11:14   ` [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Eric B Munson
2009-08-25 11:14     ` [PATCH 3/3] Add MAP_HUGETLB example Eric B Munson
2009-09-17 22:44     ` [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Andrew Morton
2009-09-18  0:46       ` Andrew Morton
2009-09-18 15:19         ` [PATCH] " Arnd Bergmann
2009-09-18 16:48           ` [PATCH] remove duplicate asm/mman.h files Arnd Bergmann
2009-09-18 19:37             ` David Rientjes
2009-09-21  8:31               ` Arnd Bergmann
2009-09-21  9:13                 ` David Rientjes
2009-09-21  9:30                   ` Arnd Bergmann [this message]
2009-09-21 12:02                   ` Hugh Dickins
2009-09-21 22:55                     ` David Rientjes
2009-09-21 23:25                       ` Luck, Tony
2009-09-21 23:46                         ` David Rientjes
2009-09-21 23:58                           ` Ulrich Drepper
2009-09-21 12:27             ` Eric B Munson
2009-09-21 12:25           ` [PATCH] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Eric B Munson
2009-08-26 19:34   ` [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount David Rientjes

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=200909211130.26377.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=ebmunson@us.ibm.com \
    --cc=fenghua.yu@intel.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mtk.manpages@gmail.com \
    --cc=randy.dunlap@oracle.com \
    --cc=rientjes@google.com \
    --cc=rth@twiddle.net \
    --cc=tony.luck@intel.com \
    /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