[PATCH 1/3] revoke: misc fixes

[PATCH 1/3] revoke: misc fixes

[Pekka J Enberg]

From: Pekka Enberg <penberg@cs.helsinki.fi>

This is a rollup patch of the following fixes to address some of Andrew's
review comments:

  - Fix return value type of system calls to long
  - Add comment for vma->vm_flag barrier
  - No need for GFP_NOFS for inode allocation, use GFP_KERNEL instead
  - Remove unnecessary line break before EXPORT_SYMBOL

Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
 fs/revoke.c              |    9 +++++----
 include/linux/syscalls.h |    4 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

Index: uml-2.6/fs/revoke.c
===================================================================
--- uml-2.6.orig/fs/revoke.c	2007-03-16 08:58:31.000000000 +0200
+++ uml-2.6/fs/revoke.c	2007-03-16 09:00:37.000000000 +0200
@@ -167,7 +167,9 @@ static int revoke_vma(struct vm_area_str
 	end_addr = vma->vm_end;
 
 	/*
- 	 * Not holding ->mmap_sem here.
+ 	 * Not holding ->mmap_sem here but we must watch out for page
+ 	 * faults and after the shared mappings have been taken down
+ 	 * and sys_mmap() trying to remap the revoked range.
 	 */
 	vma->vm_flags |= VM_REVOKED;
 	smp_mb();
@@ -455,7 +457,7 @@ 	int err = 0;
 	return err;
 }
 
-asmlinkage int sys_revokeat(int dfd, const char __user * filename)
+asmlinkage long sys_revokeat(int dfd, const char __user * filename)
 {
 	struct nameidata nd;
 	int err;
@@ -499,7 +501,6 @@ int generic_file_revoke(struct file *fil
   out:
 	return err;
 }
-
 EXPORT_SYMBOL(generic_file_revoke);
 
 /*
@@ -510,7 +511,7 @@ static struct inode *revokefs_alloc_inod
 {
 	struct revokefs_inode_info *info;
 
-	info = kmem_cache_alloc(revokefs_inode_cache, GFP_NOFS);
+	info = kmem_cache_alloc(revokefs_inode_cache, GFP_KERNEL);
 	if (!info)
 		return NULL;
 
Index: uml-2.6/include/linux/syscalls.h
===================================================================
--- uml-2.6.orig/include/linux/syscalls.h	2007-03-16 08:58:30.000000000 +0200
+++ uml-2.6/include/linux/syscalls.h	2007-03-16 08:59:59.000000000 +0200
@@ -605,7 +605,7 @@ asmlinkage long sys_getcpu(unsigned __us
 
 int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
 
-asmlinkage int sys_revokeat(int dfd, const char __user *filename);
-asmlinkage int sys_frevoke(unsigned int fd);
+asmlinkage long sys_revokeat(int dfd, const char __user *filename);
+asmlinkage long sys_frevoke(unsigned int fd);
 
 #endif

Re: [PATCH 1/3] revoke: misc fixes

[Nick Piggin]

Pekka J Enberg wrote:
> From: Pekka Enberg <penberg@cs.helsinki.fi>
> 
> This is a rollup patch of the following fixes to address some of Andrew's
> review comments:
> 
>   - Fix return value type of system calls to long
>   - Add comment for vma->vm_flag barrier
>   - No need for GFP_NOFS for inode allocation, use GFP_KERNEL instead
>   - Remove unnecessary line break before EXPORT_SYMBOL
> 
> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
> ---
>  fs/revoke.c              |    9 +++++----
>  include/linux/syscalls.h |    4 ++--
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> Index: uml-2.6/fs/revoke.c
> ===================================================================
> --- uml-2.6.orig/fs/revoke.c	2007-03-16 08:58:31.000000000 +0200
> +++ uml-2.6/fs/revoke.c	2007-03-16 09:00:37.000000000 +0200
> @@ -167,7 +167,9 @@ static int revoke_vma(struct vm_area_str
>  	end_addr = vma->vm_end;
>  
>  	/*
> - 	 * Not holding ->mmap_sem here.
> + 	 * Not holding ->mmap_sem here but we must watch out for page
> + 	 * faults and after the shared mappings have been taken down
> + 	 * and sys_mmap() trying to remap the revoked range.
>  	 */
>  	vma->vm_flags |= VM_REVOKED;
>  	smp_mb();
> @@ -455,7 +457,7 @@ 	int err = 0;

You're still modifying vm_flags without down_write mmap_sem, so this will
corrupt vm_flags.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH 1/3] revoke: misc fixes

[Pekka J Enberg]

Pekka J Enberg wrote:
> > 	/*
> > - 	 * Not holding ->mmap_sem here.
> > + 	 * Not holding ->mmap_sem here but we must watch out for page
> > + 	 * faults and after the shared mappings have been taken down
> > + 	 * and sys_mmap() trying to remap the revoked range.
> >   */
> >   vma->vm_flags |= VM_REVOKED;
> >   smp_mb();
> > @@ -455,7 +457,7 @@ 	int err = 0;

On Fri, 16 Mar 2007, Nick Piggin wrote:
> You're still modifying vm_flags without down_write mmap_sem, so this will
> corrupt vm_flags.

Uhm, you're right, two concurrent writes and we can lose some bits so a 
barrier doesn't work. Too bad as we're under mapping->i_mmap_lock here and 
thus cannot take ->mmap_sep...

Re: [PATCH 1/3] revoke: misc fixes

[Nick Piggin]

Pekka J Enberg wrote:
> Pekka J Enberg wrote:
> 
>>>	/*
>>>- 	 * Not holding ->mmap_sem here.
>>>+ 	 * Not holding ->mmap_sem here but we must watch out for page
>>>+ 	 * faults and after the shared mappings have been taken down
>>>+ 	 * and sys_mmap() trying to remap the revoked range.
>>>  */
>>>  vma->vm_flags |= VM_REVOKED;
>>>  smp_mb();
>>>@@ -455,7 +457,7 @@ 	int err = 0;
> 
> 
> On Fri, 16 Mar 2007, Nick Piggin wrote:
> 
>>You're still modifying vm_flags without down_write mmap_sem, so this will
>>corrupt vm_flags.
> 
> 
> Uhm, you're right, two concurrent writes and we can lose some bits so a 
> barrier doesn't work. Too bad as we're under mapping->i_mmap_lock here and 
> thus cannot take ->mmap_sep...
> 

Could you try something like walk the i_mmap lists to find mms with vmas that
haven't need revoking, then each time you find one, take a ref on the mm, drop
i_mmap_lock, take mmap_sem, and walk all its vmas looking for any that reference
the inode?

Bit of a roundabout way to go, but it might work.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH 1/3] revoke: misc fixes

[Pekka J Enberg]

Hi Nick,

On Fri, 16 Mar 2007, Nick Piggin wrote:
> Could you try something like walk the i_mmap lists to find mms with vmas that
> haven't need revoking, then each time you find one, take a ref on the mm, drop
> i_mmap_lock, take mmap_sem, and walk all its vmas looking for any that
> reference the inode?

Yes, that would work. What I am cooking up now is dropping 
->i_mmap_lock, restarting the scan after each revoke_vma() and skipping 
vmas that are VM_REVOKED.

			Pekka

Re: [PATCH 1/3] revoke: misc fixes

[Nick Piggin]

Pekka J Enberg wrote:
> Hi Nick,
> 
> On Fri, 16 Mar 2007, Nick Piggin wrote:
> 
>>Could you try something like walk the i_mmap lists to find mms with vmas that
>>haven't need revoking, then each time you find one, take a ref on the mm, drop
>>i_mmap_lock, take mmap_sem, and walk all its vmas looking for any that
>>reference the inode?
> 
> 
> Yes, that would work. What I am cooking up now is dropping 
> ->i_mmap_lock, restarting the scan after each revoke_vma() and skipping 
> vmas that are VM_REVOKED.

Of course you can't take a reference to a vma, so to pin a vma you need
the mmap_sem, and to do that you need to drop i_mmap_lock, which means
your vma might go away ;)

So I think you really do need to get back to the mm, and then search its
vmas.

Also, a down_write_trylock attempt inside i_mmap_lock should be a valid
optimisation.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH 1/3] revoke: misc fixes

[Pekka J Enberg]

On Fri, 16 Mar 2007, Nick Piggin wrote:
> So I think you really do need to get back to the mm, and then search its
> vmas.

You're right.

Re: [PATCH 1/3] revoke: misc fixes

[Pekka Enberg]

On 3/16/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Also, a down_write_trylock attempt inside i_mmap_lock should be a valid
> optimisation.

I am not sure what you're thinking here. down_write_trylock acquires
->mmap_sem which can deadlock with ->i_mmap_lock, no?

[PATCH 1/3] revoke: misc fixes

[Pekka J Enberg]

From: Pekka Enberg <penberg@cs.helsinki.fi>

This is a rollup patch of the following fixes to address some of Andrew's
review comments:

  - Fix return value type of system calls to long
  - No need for GFP_NOFS for inode allocation, use GFP_KERNEL instead
  - Remove unnecessary line break before EXPORT_SYMBOL

Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
 fs/revoke.c              |    9 +++++----
 include/linux/syscalls.h |    4 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

Index: uml-2.6/fs/revoke.c
===================================================================
--- uml-2.6.orig/fs/revoke.c	2007-03-16 08:58:31.000000000 +0200
+++ uml-2.6/fs/revoke.c	2007-03-16 09:00:37.000000000 +0200
-asmlinkage int sys_revokeat(int dfd, const char __user * filename)
+asmlinkage long sys_revokeat(int dfd, const char __user * filename)
 {
 	struct nameidata nd;
 	int err;
@@ -499,7 +501,6 @@ int generic_file_revoke(struct file *fil
   out:
 	return err;
 }
-
 EXPORT_SYMBOL(generic_file_revoke);
 
 /*
@@ -510,7 +511,7 @@ static struct inode *revokefs_alloc_inod
 {
 	struct revokefs_inode_info *info;
 
-	info = kmem_cache_alloc(revokefs_inode_cache, GFP_NOFS);
+	info = kmem_cache_alloc(revokefs_inode_cache, GFP_KERNEL);
 	if (!info)
 		return NULL;
 
Index: uml-2.6/include/linux/syscalls.h
===================================================================
--- uml-2.6.orig/include/linux/syscalls.h	2007-03-16 08:58:30.000000000 +0200
+++ uml-2.6/include/linux/syscalls.h	2007-03-16 08:59:59.000000000 +0200
@@ -605,7 +605,7 @@ asmlinkage long sys_getcpu(unsigned __us
 
 int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
 
-asmlinkage int sys_revokeat(int dfd, const char __user *filename);
-asmlinkage int sys_frevoke(unsigned int fd);
+asmlinkage long sys_revokeat(int dfd, const char __user *filename);
+asmlinkage long sys_frevoke(unsigned int fd);
 
 #endif

Re: [PATCH 1/3] revoke: misc fixes

[Nick Piggin]

Pekka Enberg wrote:
> On 3/16/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>> Also, a down_write_trylock attempt inside i_mmap_lock should be a valid
>> optimisation.
> 
> 
> I am not sure what you're thinking here. down_write_trylock acquires
> ->mmap_sem which can deadlock with ->i_mmap_lock, no?

You need hold and wait for a deadlock. So long as you don't block
(on mmap_sem) while holding i_mmap_lock, then you won't deadlock.

So you could just attempt a trylock, and if it works, then you
could revoke the vma right then and there. OTOH, the patch you
subsequently posted looks fine, so unless this is performance
critical then I wouldn't bother ;)

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH 1/3] revoke: misc fixes

[Pekka J Enberg]

On Mon, 19 Mar 2007, Nick Piggin wrote:
> So you could just attempt a trylock, and if it works, then you
> could revoke the vma right then and there. OTOH, the patch you
> subsequently posted looks fine, so unless this is performance
> critical then I wouldn't bother ;)

The patch in -mm uses trylock.

			Pekka