All of lore.kernel.org
 help / color / mirror / Atom feed
From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rajagopal Ananthanarayanan <ananth@sgi.com>, linux-mm@kvack.org
Subject: Re: Oops in __free_pages_ok (pre7-1) (Long) (backtrace)
Date: Wed, 3 May 2000 09:08:53 -0700 (PDT)	[thread overview]
Message-ID: <200005031608.JAA87583@google.engr.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10005030117500.981-100000@penguin.transmeta.com> from "Linus Torvalds" at May 03, 2000 01:31:41 AM

> 
> 
> On Wed, 3 May 2000, Linus Torvalds wrote:
> > 
> > You may be right. The code certainly tries to be careful. However, I don't
> > trust "is_page_shared()" at all, _especially_ if there are people around
> > who play with the page state without locking the page. 
> > 
> > If "is_page_shared()" ends up ever getting the wrong value, I suspect we'd
> > be screwed. There may be other schenarios..
> 
> Kanoj, why couldn't this happen:
>  - CPU0 runs swapout
> 	- finds page which is a swap cache entry
> 	- does the swap_duplicate()
> 	- does __free_page() on it without locking it (it wasn't locked
> 	  before, either)
>  - CPU1 runs shrink_mmap
> 	- finds same page on the LRU list
> 	- locks it _just_ after CPU0 tested that it was unlocked
> 	- looks at the page countersand the swap cache counters to see if
> 	  it was shared ("is_page_shared()").
> 
>  - There is _no_ synchronization between the two, as far as I can tell.
>    "swap_duplicate()" on CPU0 will get the swap device lock, and
>    "is_page_shared()" will run with the page lock held, but there is no
>    common locking between the two at all that I can see.

FWIW, I think you are looking in the right direction, ie, shrink_mmap
previously used to run with lock_kernel, and not anymore, so there is a 
chance of shrink_mmap racing with try_to_swap_out. I thought about this 
though, but couldn't come up with an example ...

But, your example does not pull thru. Note that before shrink_mmap will
even touch the page, it does a 

                if (!page->buffers && page_count(page) > 1)
                        goto dispose_continue;

The page is question is guaranteed to have page_count(page) > 1, since 
try_to_swap_out has not dropped the user pte reference in your example.

Another thing to note is that shrink_mmap does not do a is_page_shared(),
it just checks for page-reference count to be 0 (the swapentry might have
references from other processes). Else, shrink_mmap will never be able
to free these pages ...

> 
> So "is_page_shared()" can be entirely crap. And can tell shrink_mmap()

Not really ... look at other places that call is_page_shared, they all
hold the pagelock. shrink_mmap does not bother with is_page_shared logic.

What is interesting is that people are reporting PageSwapEntry deletion
seems to fix this ...

Kanoj

> that the page cache entry can be freed. Now, I have no idea what that will
> actually result in, but I bet that we can just get the usage counters off
> by one here, and then at some later date we free page that we've already
> free'd - and that page may have been re-allocated for something else and
> isin the middle of a page-in right now (which is how we end up freeing a
> page that is locked).
> 
> Or something. The lack of any synchronization looks fishy to me. The page
> lock would act as synchronization, but so would the swap device lock.  And
> maybe I'm still barking up the wrong tree..
> 
> 		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/
> 

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

  reply	other threads:[~2000-05-03 16:08 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8ener4$6djpb$1@fido.engr.sgi.com>
2000-05-03  3:11 ` Oops in __free_pages_ok (pre7-1) (Long) (backtrace) Rajagopal Ananthanarayanan
2000-05-03  3:47   ` Linus Torvalds
2000-05-03  5:26     ` Kanoj Sarcar
2000-05-03  6:22       ` Rajagopal Ananthanarayanan
2000-05-03 16:11         ` Kanoj Sarcar
2000-05-03 16:19           ` Linus Torvalds
2000-05-03 16:35             ` Kanoj Sarcar
2000-05-03 17:16               ` Linus Torvalds
2000-05-03 17:31                 ` Kanoj Sarcar
2000-05-03 18:17                   ` Linus Torvalds
2000-05-03 18:37                     ` Rajagopal Ananthanarayanan
2000-05-03 18:37                     ` Kanoj Sarcar
2000-05-03 19:41                       ` Rajagopal Ananthanarayanan
2000-05-03 21:28                     ` Jeff Garzik
2000-05-03  8:11       ` Linus Torvalds
2000-05-03  8:31         ` Linus Torvalds
2000-05-03 16:08           ` Kanoj Sarcar [this message]
2000-05-03 16:14             ` Linus Torvalds
2000-05-03 16:24               ` Kanoj Sarcar
2000-05-04  1:38             ` Linus Torvalds
2000-05-04  2:44               ` Rajagopal Ananthanarayanan
2000-05-04  4:05                 ` Linus Torvalds
2000-05-04  3:16               ` Rajagopal Ananthanarayanan
2000-05-04  4:10                 ` Linus Torvalds
2000-05-05  4:46                   ` Rajagopal Ananthanarayanan
2000-05-04  7:42               ` Rajagopal Ananthanarayanan
2000-05-04 15:33                 ` Linus Torvalds
2000-05-04 15:57                   ` Rik van Riel
2000-05-04 17:19                   ` Rajagopal Ananthanarayanan
2000-05-04 17:41                     ` Rik van Riel
2000-05-04 18:18                       ` Rajagopal Ananthanarayanan
2000-05-04 18:43                         ` Linus Torvalds
2000-05-04 19:00                           ` Rik van Riel
2000-05-04 19:17                             ` Linus Torvalds
2000-05-04 21:16                               ` Rajagopal Ananthanarayanan
2000-05-04 21:51                                 ` Rik van Riel
2000-05-04 22:21                                 ` Linus Torvalds
2000-05-05  0:47                                   ` 7-4 VM killing (A solution) Rajagopal Ananthanarayanan
2000-05-05  1:30                                     ` Rik van Riel
2000-05-05  1:47                                       ` Rajagopal Ananthanarayanan
2000-05-05  5:13                                     ` Linus Torvalds
2000-05-05  6:44                                       ` Rajagopal Ananthanarayanan
2000-05-05  6:51                                         ` Linus Torvalds
2000-05-05 10:23                                           ` Rik van Riel
2000-05-04 20:40                   ` Oops in __free_pages_ok (pre7-1) (Long) (backtrace) Roger Larsson

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=200005031608.JAA87583@google.engr.sgi.com \
    --to=kanoj@google.engr.sgi.com \
    --cc=ananth@sgi.com \
    --cc=linux-mm@kvack.org \
    --cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.