linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm+eric@npwt.net (Eric W. Biederman)
To: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
Cc: linux-mm@kvack.org
Subject: Re: Q: Swap Locking Reinstatement
Date: 27 May 1998 10:15:19 -0500	[thread overview]
Message-ID: <m13edv21a0.fsf@flinx.npwt.net> (raw)
In-Reply-To: "Stephen C. Tweedie"'s message of Tue, 19 May 1998 23:46:01 +0100

>>>>> "ST" == Stephen C Tweedie <sct@dcs.ed.ac.uk> writes:

ST> Hi,
ST> On 12 May 1998 20:57:05 -0500, ebiederm+eric@npwt.net (Eric
ST> W. Biederman) said:

>> Recently the swap lockmap has been readded.

>> Was that just as a low cost sanity check, to use especially while
>> there were bugs in some of the low level disk drivers?

>> Was there something that really needs the swap lockmap?

ST> Yes, there was a bug.  The problem occurs when:

ST> 	page X is owned by process A
ST> 	process B tries to swap out page X from A's address space
ST> 	process A exits or execs
ST> 	process B's swap IO completes.

ST> The IO completion is an interrupt (we perform async swaps where
ST> possible).  Now, if we dereference the swap entry belonging to page X
ST> at IO completion time, then the entry is protected against reuse while
ST> the IO is in flight.  However, that requires making the entire swap map
ST> interrupt safe.  It is much more efficient to keep the lock map separate
ST> and to use atomic bitops on it to allow us to do the IO completion
ST> unlock in an interrupt-safe manner.

ST> A similar race occurs when

ST> 	process B tries to swap out page X from A's address space
ST> 	process A tries to swap it back in
ST> 	process B's swap IO completes.

ST> Now process A may, or may not, get the right data from disk depending on
ST> the (undefined) ordering of the IOs submitted by A and B.

Here is how I'm going to code it.

I'm going to modify swap_out to never remove a page from the page
cache until I/O is complete on it.  This should only affect
asynchrounous pages.

I'm going to modify shrink_mmap and friends so that when they remove
a swapper page from the page cache they will decrement the swap use
count, of the page. (Via a new generic inode function).

This should both remove the need for the swap lock map, and increase
performance on the second race condition you mentioned (because it
doesn't have to read the page back in).

Hopefully when we get reverse pte maps working we can remove the swap
use counts as well, and only worry if a swap page is in use.

Eric

  reply	other threads:[~1998-05-27 15:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-13  1:57 Eric W. Biederman
1998-05-19 22:46 ` Stephen C. Tweedie
1998-05-27 15:15   ` Eric W. Biederman [this message]
1998-06-04  3:20   ` Eric W. Biederman

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=m13edv21a0.fsf@flinx.npwt.net \
    --to=ebiederm+eric@npwt.net \
    --cc=linux-mm@kvack.org \
    --cc=sct@dcs.ed.ac.uk \
    /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