From: Rajagopal Ananthanarayanan <ananth@sgi.com>
To: Kanoj Sarcar <kanoj@google.engr.sgi.com>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-mm@kvack.org
Subject: Re: Oops in __free_pages_ok (pre7-1) (Long) (backtrace)
Date: Tue, 02 May 2000 23:22:46 -0700 [thread overview]
Message-ID: <390FC5B6.211AB236@sgi.com> (raw)
In-Reply-To: <200005030526.WAA59352@google.engr.sgi.com>
Kanoj Sarcar wrote:
> >
> > Wow.
> >
> > That code definitely looks buggy.
> >
> > Looking at the whole try_to_swap_out() in this light shows how it messes
> > with a _lot_ of page information without holding the page lock. I thought
> > we fixed this once already, but maybe not.
> >
> > In try_to_swap_out(), earlier it does a
> >
> > if (PageLocked(page))
> > goto out_failed;
> >
> > and that really is wrong - it should do a
> >
> > if (TryLockPage(page))
> > goto out_failed;
>
> Umm, I am not saying this is not a good idea, but maybe code that
> try_to_swap_out() invokes (like filemap_swapout etc) need to be
> taught that the incoming page has already been locked.
Dunno. I tend to agree with Linus. Fundamentally, how can any
code examine & change page state (flags, etc). if the code
does not hold the page lock?
>
> Nonetheless, unless you show me a possible scenario that will lead
> to the observed panic, I am skeptical that this is the real problem.
Look at trace I sent out. Basically it goes swap_out() -> swap_out_mm() ->
swap_out_vma() -> try_to_swap_out() -> __free_pages_ok().
1. swap_out select process & vm area within the process to swapout.
2. swap_out_mm selects an "address" within the mm.
3. swap_out_vma converts address to pgd.
4. try_to_swap_out takes pgd looks at the "software" state in "struct page".
Step 2 is about the earliest you can lock the victim page;
it isn't locked there. Step 3 doesn't lock it either. Step 4
as pointed out, explicitly avoids pages which are locked,
but doesn't lock the page!
Some more clarifications below:
>
> Lets just talk about swapcache pages (since the problem happened with
> that type), and lets forget swapfile deletion, I am pretty sure Ananth
> was not trying that. [ ... ]
No, I didn't try to remove swap.
> Anyway, I will try to think if there are more race conditions possible.
> Ananth, was there shared memory programs in your test suite? Also, if you
> have any success in reproducing this, let us know.
I don't think there were any shm stuff in the tests I was running
(again, AFAICT, diff was the only thing running; previous pages
in memory weren't likely from any shm segments). I haven't
reproduced it even a second time. Will let you know.
OTOH, if try_to_swap_out is so broken why aren't we seeing
these problems more often? Or, from other reports in l-k are we?
ananth.
--
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/
next prev parent reply other threads:[~2000-05-03 6:22 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 ` Rajagopal Ananthanarayanan
2000-05-03 3:47 ` Linus Torvalds
2000-05-03 5:26 ` Kanoj Sarcar
2000-05-03 6:22 ` Rajagopal Ananthanarayanan [this message]
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
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=390FC5B6.211AB236@sgi.com \
--to=ananth@sgi.com \
--cc=kanoj@google.engr.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox