public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	bgagnon@coradiant.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrea Arcangeli <andrea@novell.com>,
	davem@redhat.com
Subject: Re: Memory leak in 2.4.27 kernel, using mmap raw packet sockets
Date: Fri, 26 Nov 2004 00:13:14 +0100	[thread overview]
Message-ID: <20041125231313.GG5904@dualathlon.random> (raw)
In-Reply-To: <20041125171242.GL16633@logos.cnet>

On Thu, Nov 25, 2004 at 03:12:42PM -0200, Marcelo Tosatti wrote:
> get_user_pages() bails out if ! VM_IO. 
> 
> Is that what you mean with "VM_IO enforcement" ? 

yes. It bails out if VM_IO is set (not ! clear ;)

> I thought about the BUG() to catch potential offenders, but I was
> not sure if it was possible for a PG_reserved page to be part of VMA's 
> which was being get_user_pages'd.

Exactly, it's much safer to go with the real fix of fixing it in
get_user_pages. If something we should put a bugcheck there.

> Now you tell me it is possible, and thats only the ZERO page. Fine. 

Yes, and the ZERO_PAGE is actually the _only_ reserved page we must
allow to go through. Every other reserved page must be discarded (or
kernel-crash with BUG_ON if Alan feels confortable with the VM_IO
enforcement).

> This is what you suggests plus some extra hopefully useful debugging 
> 
> 
> --- memory.c.orig	2004-11-25 14:51:00.074508952 -0200
> +++ memory.c	2004-11-25 15:08:38.026675776 -0200
> @@ -454,8 +454,9 @@
>  int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned long start,
>  		int len, int write, int force, struct page **pages, struct vm_area_struct **vmas)
>  {
> -	int i;
> +	int i, s;
>  	unsigned int flags;
> +	struct vm_area_struct *savevma = NULL;
>  
>  	/*
>  	 * Require read or write permissions.
> @@ -463,7 +464,7 @@
>  	 */
>  	flags = write ? (VM_WRITE | VM_MAYWRITE) : (VM_READ | VM_MAYREAD);
>  	flags &= force ? (VM_MAYREAD | VM_MAYWRITE) : (VM_READ | VM_WRITE);
> -	i = 0;
> +	i = s = 0;
>  
>  	do {
>  		struct vm_area_struct *	vma;
> @@ -499,9 +500,13 @@
>  				/* FIXME: call the correct function,
>  				 * depending on the type of the found page
>  				 */
> -				if (!pages[i] || PageReserved(pages[i]))
> -					goto bad_page;
> -				page_cache_get(pages[i]);
> +				if (!pages[i] || PageReserved(pages[i])) {
> +					if (pages[i] != ZERO_PAGE(start)) {
> +						savevma = vma;
> +						goto bad_page;
> +					}
> +				} else
> +					page_cache_get(pages[i]);
>  			}
>  			if (vmas)
>  				vmas[i] = vma;
> @@ -520,9 +525,15 @@
>  	 */
>  bad_page:
>  	spin_unlock(&mm->page_table_lock);
> +	s = i;
>  	while (i--)
>  		page_cache_release(pages[i]);
> -	i = -EFAULT;
> +	/* catch bad uses of PG_reserved on !VM_IO vma's */
> +	printk(KERN_ERR "get_user_pages PG_reserved page on"
> +			"vma:%p flags:%lx page:%d\n", savevma,
> +			savevma->flags, s);
> +	BUG();
> +	i = -EFAULT;
>  	goto out;
>  }

Yes, however I wouldn't turn on the debugging code just in case some
driver forgets to set VM_IO and it doesn't use remap_page_range. There's
nothing fundamentally fatal in having a reserved page in a non VM_IO
vma (I mean, after fixing the above bit ;).

  reply	other threads:[~2004-11-27  7:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-14 14:50 Memory leak in 2.4.27 kernel, using mmap raw packet sockets bgagnon
2004-10-15 18:23 ` Marcelo Tosatti
2004-10-17  2:39   ` Alan Cox
2004-10-19 14:35     ` Marcelo Tosatti
2004-10-20 18:43       ` Alan Cox
2004-10-20 23:24         ` Andrea Arcangeli
2004-10-23 14:17           ` Marcelo Tosatti
2004-11-25 15:02     ` Marcelo Tosatti
2004-11-25 20:32       ` Andrea Arcangeli
2004-11-25 17:12         ` Marcelo Tosatti
2004-11-25 23:13           ` Andrea Arcangeli [this message]
2004-11-25 19:45             ` Marcelo Tosatti
2004-11-26  1:04               ` Andrea Arcangeli
2004-11-30  4:03                 ` David S. Miller
2004-11-30  4:16                   ` Andrea Arcangeli
2004-11-30  6:11                     ` David S. Miller
2004-11-30  6:19                     ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2004-10-21 13:39 O.Sezer
2004-10-21 14:26 ` Andrea Arcangeli

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=20041125231313.GG5904@dualathlon.random \
    --to=andrea@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andrea@novell.com \
    --cc=bgagnon@coradiant.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.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