[PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Kirill A. Shutemov]

If SHM_MAP_NOT_FIXED specified and shmaddr is not NULL, then the kernel takes
shmaddr as a hint about where to place the mapping. The address of the mapping
is returned as the result of the call.

It's similar to mmap() without MAP_FIXED.

Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/shm.h |    2 ++
 ipc/shm.c           |    7 ++++---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/linux/shm.h b/include/linux/shm.h
index eca6235..fd288eb 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -55,6 +55,8 @@ struct shmid_ds {
 #define	SHM_RND		020000	/* round attach address to SHMLBA boundary */
 #define	SHM_REMAP	040000	/* take-over region on attach */
 #define	SHM_EXEC	0100000	/* execution access */
+#define	SHM_MAP_NOT_FIXED 0200000 /* interpret attach address as a search
+				   * hint */
 
 /* super user shmctl commands */
 #define SHM_LOCK 	11
diff --git a/ipc/shm.c b/ipc/shm.c
index e77ec69..54f3c61 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -819,7 +819,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
 	if (shmid < 0)
 		goto out;
 	else if ((addr = (ulong)shmaddr)) {
-		if (addr & (SHMLBA-1)) {
+		if (!(shmflg & SHM_MAP_NOT_FIXED) && (addr & (SHMLBA-1))) {
 			if (shmflg & SHM_RND)
 				addr &= ~(SHMLBA-1);	   /* round down */
 			else
@@ -828,7 +828,8 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
 #endif
 					goto out;
 		}
-		flags = MAP_SHARED | MAP_FIXED;
+		flags = MAP_SHARED |
+				(shmflg & SHM_MAP_NOT_FIXED ? 0 : MAP_FIXED);
 	} else {
 		if ((shmflg & SHM_REMAP))
 			goto out;
@@ -892,7 +893,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
 	sfd->vm_ops = NULL;
 
 	down_write(&current->mm->mmap_sem);
-	if (addr && !(shmflg & SHM_REMAP)) {
+	if (addr && !(shmflg & (SHM_REMAP|SHM_MAP_NOT_FIXED))) {
 		err = -EINVAL;
 		if (find_vma_intersection(current->mm, addr, addr + size))
 			goto invalid;
-- 
1.5.6.5.GIT

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[KOSAKI Motohiro]

> If SHM_MAP_NOT_FIXED specified and shmaddr is not NULL, then the kernel takes
> shmaddr as a hint about where to place the mapping. The address of the mapping
> is returned as the result of the call.
>
> It's similar to mmap() without MAP_FIXED.

ummm

Sorry, no.
This description still doesn't explain why this interface is needed.

The one of the points is this interface is used by another person or not.
You should explain how large this interface benefit has.

Andi kleen explained this interface _can_  be used another one.
but nobody explain who use it actually.

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Andi Kleen]

> Sorry, no.
> This description still doesn't explain why this interface is needed.
> 
> The one of the points is this interface is used by another person or not.
> You should explain how large this interface benefit has.
> 
> Andi kleen explained this interface _can_  be used another one.
> but nobody explain who use it actually.

Anyone who doesn't want to use fixed addresses. 

-Andi

-- 
ak@linux.intel.com

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[KOSAKI Motohiro]

>> Sorry, no.
>> This description still doesn't explain why this interface is needed.
>>
>> The one of the points is this interface is used by another person or not.
>> You should explain how large this interface benefit has.
>>
>> Andi kleen explained this interface _can_  be used another one.
>> but nobody explain who use it actually.
>
> Anyone who doesn't want to use fixed addresses.

yup.
however, almost application doesn't use new flag because almost
application want to works on cross platform. (or merely lazy)
then, this explain isn't enough, imo.

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Andi Kleen]

On Wed, Oct 08, 2008 at 06:38:07AM +0900, KOSAKI Motohiro wrote:
> >> Sorry, no.
> >> This description still doesn't explain why this interface is needed.
> >>
> >> The one of the points is this interface is used by another person or not.
> >> You should explain how large this interface benefit has.
> >>
> >> Andi kleen explained this interface _can_  be used another one.
> >> but nobody explain who use it actually.
> >
> > Anyone who doesn't want to use fixed addresses.
> 
> yup.
> however, almost application doesn't use new flag because almost
> application want to works on cross platform. (or merely lazy)
> then, this explain isn't enough, imo.

You're arguing that there shouldn't be any Linux extensions
to system calls ever because it would break compatibility? 

You're at least 15 years too late with that. Linux extensions
are there all over.

-Andi

-- 
ak@linux.intel.com

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

On Tue, 7 Oct 2008 23:10:38 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> > Sorry, no.
> > This description still doesn't explain why this interface is needed.
> > 
> > The one of the points is this interface is used by another person or not.
> > You should explain how large this interface benefit has.
> > 
> > Andi kleen explained this interface _can_  be used another one.
> > but nobody explain who use it actually.
> 
> Anyone who doesn't want to use fixed addresses. 

Can use shm_open and mmap to get POSIX standard shm behaviour via a sane
interface without adding more crap to the sys3 shm madness. 

Sorry this patch is completely bogus - introduce the user programs
involved to 1990s technology. They have to be updated to use such a
change as is proposed anyway so they might as well use shm_open/mmap at
which point no kernel changes are needed.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Andi Kleen]

On Wed, Oct 08, 2008 at 12:05:18AM +0100, Alan Cox wrote:
> On Tue, 7 Oct 2008 23:10:38 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
> 
> > > Sorry, no.
> > > This description still doesn't explain why this interface is needed.
> > > 
> > > The one of the points is this interface is used by another person or not.
> > > You should explain how large this interface benefit has.
> > > 
> > > Andi kleen explained this interface _can_  be used another one.
> > > but nobody explain who use it actually.
> > 
> > Anyone who doesn't want to use fixed addresses. 
> 
> Can use shm_open and mmap to get POSIX standard shm behaviour via a sane

I don't think shm_open can attach to SYSV shared segments. Or are you
proposing to add "sysvshmfs" to make that possible? 

> interface without adding more crap to the sys3 shm madness. 
> 
> Sorry this patch is completely bogus - introduce the user programs
> involved to 1990s technology. 

As already listed in an earlier email, but here again:

- There are legacy interfaces that cannot be really changed who use sysv shm
(e.g. X shm and others -- just do a ipcs on your system) 
- An system call emulation as in qemu obviously has to implement the
existing system call semantics.

-Andi

-- 
ak@linux.intel.com

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

> > Can use shm_open and mmap to get POSIX standard shm behaviour via a sane
> 
> I don't think shm_open can attach to SYSV shared segments. Or are you
> proposing to add "sysvshmfs" to make that possible? 

Actually you can do so. As it stands today the SYS3 SHM interface code
does the following

	create a char array in the form SYS%08ld, key
	open it on shmfs

> - There are legacy interfaces that cannot be really changed who use sysv shm
> (e.g. X shm and others -- just do a ipcs on your system) 

They can be changed and nobody is wanting to map those at fixed addresses.

> - An system call emulation as in qemu obviously has to implement the
> existing system call semantics.

Which it can do perfectly well using shm_open to create its SYS3
SHM objects. In fact theoertically we could bin the whole of SYS3 shm and
push it into glibc emulation if we wanted.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Andi Kleen]

On Wed, Oct 08, 2008 at 12:40:30AM +0100, Alan Cox wrote:
> > > Can use shm_open and mmap to get POSIX standard shm behaviour via a sane
> > 
> > I don't think shm_open can attach to SYSV shared segments. Or are you
> > proposing to add "sysvshmfs" to make that possible? 
> 
> Actually you can do so. As it stands today the SYS3 SHM interface code
> does the following
> 
> 	create a char array in the form SYS%08ld, key
> 	open it on shmfs

Perhaps I'm confused but my /dev/shm doesn't have any such files,
but I see a variety of shm segments in ipcs.

What would the path passed to shm_open look like?

> 
> > - There are legacy interfaces that cannot be really changed who use sysv shm
> > (e.g. X shm and others -- just do a ipcs on your system) 
> 
> They can be changed 

You want to break the X interface? And who knows who else
is using it.

> and nobody is wanting to map those at fixed addresses.

You're saying it should always use the address as a search hint?

Just changing the semantics unconditionally would seem risky to me. After 
all as you point out they are primarily for compatibility and for that keeping
old semantics would seem better to me.

-Andi
-- 
ak@linux.intel.com

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

> Perhaps I'm confused but my /dev/shm doesn't have any such files,
> but I see a variety of shm segments in ipcs.
> 
> What would the path passed to shm_open look like?

Well right now they don't get exposed as they are created unlinked but
that is a trivial tweak to mm/shmem.c.

> > and nobody is wanting to map those at fixed addresses.
> 
> You're saying it should always use the address as a search hint?

Nothing of the sort. I'm pointing out that mmap and shm_open already
provide all the needed interfaces for this for real world applications
today.
> 
> Just changing the semantics unconditionally would seem risky to me. After 
> all as you point out they are primarily for compatibility and for that keeping
> old semantics would seem better to me.

We don't need to change any semantics, there is a perfectly good
alternative standards based interface. At most you might want to make the
sys3 shared memory segments appear in /dev/shm/ somewhere.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

Oh and as a PS you can also (for the hint case) do this:

	shmat giving an address
	if error
		shmat giving no address

from user space.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Andi Kleen]

On Wed, Oct 08, 2008 at 09:34:24AM +0100, Alan Cox wrote:
> Oh and as a PS you can also (for the hint case) do this:
> 
> 	shmat giving an address
> 	if error
> 		shmat giving no address
> 
> from user space.

No you can't here because shmat() starts searching from the wrong
start address.

The only way would be to search manually in /proc/self/maps
and handle the races, but I hope you're not advocating that.

-Andi

-- 
ak@linux.intel.com

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

> > 	shmat giving an address
> > 	if error
> > 		shmat giving no address
> > 
> > from user space.
> 
> No you can't here because shmat() starts searching from the wrong
> start address.

If you are only hinting a desired address then that by the very meaning
of the word "hint" means you will accept a different one.

> The only way would be to search manually in /proc/self/maps
> and handle the races, but I hope you're not advocating that.

Gak, mmap a range to find a space and then shmat over the top of that.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Andi Kleen]

On Wed, Oct 08, 2008 at 09:58:51AM +0100, Alan Cox wrote:
> > > 	shmat giving an address
> > > 	if error
> > > 		shmat giving no address
> > > 
> > > from user space.
> > 
> > No you can't here because shmat() starts searching from the wrong
> > start address.
> 
> If you are only hinting a desired address then that by the very meaning
> of the word "hint" means you will accept a different one.

The point is to be able to let the search start below the range
the kernel would normally start. It doesn't say that it has
to be at address X.

Yes hint is a little misleading, search hint is better.

> 
> > The only way would be to search manually in /proc/self/maps
> > and handle the races, but I hope you're not advocating that.
> 
> Gak, mmap a range to find a space and then shmat over the top of that.

That is racy when multi threaded because shmat() doesn't replace, so you 
would need to munmap() inbetween and someone else could steal the area
then. Yes you could stick a loop around it. It could livelock.
No, it's not a good interface I would advocate.

BTW the only alternative I would possiblye consider for the qemu case is to
force compat_shmat() to always allocate in 4GB (right now it relies
on the personality) and then let 64bit qemu use the int 0x80 entry point
for that.  But it's more hackish than the imho cleaner and more 
general flag.

-Andi

-- 
ak@linux.intel.com

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

> That is racy when multi threaded because shmat() doesn't replace, so you 
> would need to munmap() inbetween and someone else could steal the area
> then. Yes you could stick a loop around it. It could livelock.
> No, it's not a good interface I would advocate.

You could just use pthread mutexes in your application. The rA'le of the
kernel is not to provide nappies for people who think programming is too
hard but to provide services that can be used to build applications.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Andi Kleen]

On Wed, Oct 08, 2008 at 11:20:37AM +0100, Alan Cox wrote:
> > That is racy when multi threaded because shmat() doesn't replace, so you 
> > would need to munmap() inbetween and someone else could steal the area
> > then. Yes you could stick a loop around it. It could livelock.
> > No, it's not a good interface I would advocate.
> 
> You could just use pthread mutexes in your application. The role of the

malloc() can call mmap, so that would require putting a mutex around
each malloc(). Good luck finding them all.

> kernel is not to provide nappies for people who think programming is too
> hard but to provide services that can be used to build applications.

Outsourcing kernel locking to user space is not the way to go.

-Andi

-- 
ak@linux.intel.com

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

> > kernel is not to provide nappies for people who think programming is too
> > hard but to provide services that can be used to build applications.
> 
> Outsourcing kernel locking to user space is not the way to go.

You mean like say flock, O_APPEND  ...

Putting stuff in user space is good, it means we don't carry tons of
never used app specific crap in the kernel, in every users kernel,
unpageable and basically unused.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Alan Cox]

On Tue,  7 Oct 2008 19:15:17 +0300
"Kirill A. Shutemov" <kirill@shutemov.name> wrote:

> If SHM_MAP_NOT_FIXED specified and shmaddr is not NULL, then the kernel takes
> shmaddr as a hint about where to place the mapping. The address of the mapping
> is returned as the result of the call.
> 
> It's similar to mmap() without MAP_FIXED.

NAK

This is a pointless API extension tacked onto a historic interface that
isn't well designed.

Use shm_open, and mmap and you get the functionality required using
modern posix interfaces with *NO* Linux extensions involved.

Alan

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Michael Kerrisk]

Kirill,

On Tue, Oct 7, 2008 at 6:15 PM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> If SHM_MAP_NOT_FIXED specified and shmaddr is not NULL, then the kernel takes
> shmaddr as a hint about where to place the mapping. The address of the mapping
> is returned as the result of the call.
>
> It's similar to mmap() without MAP_FIXED.

Please CC linux-api@vger.kernel.org on patches that change the
kernel-userspace interface.

Cheers,

Michael

> Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Arjan van de Ven <arjan@infradead.org>
> Cc: Hugh Dickins <hugh@veritas.com>
> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: Ulrich Drepper <drepper@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
>  include/linux/shm.h |    2 ++
>  ipc/shm.c           |    7 ++++---
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/shm.h b/include/linux/shm.h
> index eca6235..fd288eb 100644
> --- a/include/linux/shm.h
> +++ b/include/linux/shm.h
> @@ -55,6 +55,8 @@ struct shmid_ds {
>  #define        SHM_RND         020000  /* round attach address to SHMLBA boundary */
>  #define        SHM_REMAP       040000  /* take-over region on attach */
>  #define        SHM_EXEC        0100000 /* execution access */
> +#define        SHM_MAP_NOT_FIXED 0200000 /* interpret attach address as a search
> +                                  * hint */
>
>  /* super user shmctl commands */
>  #define SHM_LOCK       11
> diff --git a/ipc/shm.c b/ipc/shm.c
> index e77ec69..54f3c61 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -819,7 +819,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
>        if (shmid < 0)
>                goto out;
>        else if ((addr = (ulong)shmaddr)) {
> -               if (addr & (SHMLBA-1)) {
> +               if (!(shmflg & SHM_MAP_NOT_FIXED) && (addr & (SHMLBA-1))) {
>                        if (shmflg & SHM_RND)
>                                addr &= ~(SHMLBA-1);       /* round down */
>                        else
> @@ -828,7 +828,8 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
>  #endif
>                                        goto out;
>                }
> -               flags = MAP_SHARED | MAP_FIXED;
> +               flags = MAP_SHARED |
> +                               (shmflg & SHM_MAP_NOT_FIXED ? 0 : MAP_FIXED);
>        } else {
>                if ((shmflg & SHM_REMAP))
>                        goto out;
> @@ -892,7 +893,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
>        sfd->vm_ops = NULL;
>
>        down_write(&current->mm->mmap_sem);
> -       if (addr && !(shmflg & SHM_REMAP)) {
> +       if (addr && !(shmflg & (SHM_REMAP|SHM_MAP_NOT_FIXED))) {
>                err = -EINVAL;
>                if (find_vma_intersection(current->mm, addr, addr + size))
>                        goto invalid;
> --
> 1.5.6.5.GIT
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/ Found a documentation bug?
http://www.kernel.org/doc/man-pages/reporting_bugs.html

--
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>

Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Wed, Oct 08, 2008 at 10:57:21AM +0200, Michael Kerrisk wrote:
> Kirill,
> 
> On Tue, Oct 7, 2008 at 6:15 PM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> > If SHM_MAP_NOT_FIXED specified and shmaddr is not NULL, then the kernel takes
> > shmaddr as a hint about where to place the mapping. The address of the mapping
> > is returned as the result of the call.
> >
> > It's similar to mmap() without MAP_FIXED.
> 
> Please CC linux-api@vger.kernel.org on patches that change the
> kernel-userspace interface.

Ok, I will.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]