linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-mm@kvack.org, "Stephen C. Tweedie" <sct@redhat.com>,
	Andrea Arcangeli <andrea@suse.de>,
	Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: filemap.c SMP bug in 2.4.0-test*
Date: Tue, 15 Aug 2000 20:26:37 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.10.10008152018100.3600-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0008151845550.2466-100000@duckman.distro.conectiva>


On Tue, 15 Aug 2000, Rik van Riel wrote:
> 
> The backtrace I got points to some place deep inside
> mm/filemap.c, in code I really didn't touch and I
> wouldn't want to touch if this bug wasn't here ;)
> 
> >>EIP; c012e370 <lru_cache_add+5c/d4>   <=====
> Trace; c021b33e <tvecs+1dde/19f60>
> Trace; c021b579 <tvecs+2019/19f60>
> Trace; c0127823 <add_to_page_cache_locked+cb/dc>
> Trace; c0130a3c <add_to_swap_cache+84/8c>
> Trace; c0130d00 <read_swap_cache_async+68/98>
> Trace; c0125c8b <handle_mm_fault+143/1c0>
> Trace; c0113d33 <do_page_fault+143/3f0>

Look at this back-trace again.

In particular, look at which page read_swap_cache_async() adds to the swap
cache.

The code is:

        /*
         * Look for the page in the swap cache.
         */
        found_page = lookup_swap_cache(entry);
        if (found_page)
                goto out_free_swap;

*****   new_page_addr = __get_free_page(GFP_USER);		*******
        if (!new_page_addr)
                goto out_free_swap;     /* Out of memory */
        new_page = virt_to_page(new_page_addr);

        /*
         * Check the swap cache again, in case we stalled above.
         */
        found_page = lookup_swap_cache(entry);
        if (found_page)
                goto out_free_page;
        /*
         * Add it to the swap cache and read its contents.
         */
        lock_page(new_page);
        add_to_swap_cache(new_page, entry);
        rw_swap_page(READ, new_page, wait);
        return new_page;

In short, read_swap_cache_async() allocates a new page that nobody else
has access to. There's no way in hell that page is going to be on any LRU
lists. 

(The page allocation and type switching is silly - it should really do
"new_page = page_cache_alloc()" and not have that "new_page_addr" thing
at all, but that's a silly inefficiency, not a bug).

The bug pretty much has to be in the new page flag handling. No, I don't
see anything wrong in your patch, but we're talking about a code-path that
has it's own very private page that cannot be shared unless there are some
pretty major bugs (if __get_free_page() returns a page that is still in
use somewhere, we're _soo_ screwed).

			Linus

--
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.eu.org/Linux-MM/

  parent reply	other threads:[~2000-08-16  3:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-15 22:10 Rik van Riel
2000-08-16  2:43 ` Linus Torvalds
2000-08-16  2:46   ` Rik van Riel
2000-08-16  3:26 ` Linus Torvalds [this message]
2000-08-16  3:40   ` Rik van Riel
2000-08-16  4:09     ` Rik van Riel

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=Pine.LNX.4.10.10008152018100.3600-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=andrea@suse.de \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.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