mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Alexey Dobriyan <adobriyan@openvz.org>
Cc: Andrew Morton <akpm@osdl.org>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Richard Purdie <richard@openedhand.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Don't map random pages if swapoff errors
Date: Fri, 19 Jan 2007 18:08:20 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701191754020.10013@blonde.wat.veritas.com> (raw)
In-Reply-To: <20070119163030.GA12507@localhost.sw.ru>

On Fri, 19 Jan 2007, Alexey Dobriyan wrote:

> From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> 
> If read failed we cannot map not-uptodate page to user space.

Good point.

> Actually, we are in serious troubles, we do not even know what
> process to kill.

True, though we don't really want to kill anything yet: the process
may never need that page again.  Better to let it continue until it
exits, or hits Kirill's check in do_swap_page.  But sure, that's not
going to happen without us making some change here.

> So, the only variant remains: to stop swapoff()
> and allow someone to kill processes to zap invalid pages.

Simple as it is, no, I don't like this patch at all.
Getting an error there is all the more reason to proceed
with the swapoff, not to give up and break out of it.

Let me think a little.

CC'ed Richard, since he's also interested in bad swap, and this
reminds me to look at his patches (though he's been concerned with
when the writeout fails, rather than when the readin fails).

Hugh

> 
> Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Signed-off-by: Alexey Dobriyan <adobriyan@openvz.org>
> ---
> 
>  mm/swapfile.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -766,6 +766,19 @@ static int try_to_unuse(unsigned int typ
>  		lock_page(page);
>  		wait_on_page_writeback(page);
>  
> +		/* If read failed we cannot map not-uptodate page to
> +		 * user space. Actually, we are in serious troubles,
> +		 * we do not even know what process to kill. So, the only
> +		 * variant remains: to stop swapoff() and allow someone
> +		 * to kill processes to zap invalid pages.
> +		 */
> +		if (unlikely(!PageUptodate(page))) {
> +			unlock_page(page);
> +			page_cache_release(page);
> +			retval = -EIO;
> +			break;
> +		}
> +
>  		/*
>  		 * Remove all references to entry.
>  		 * Whenever we reach init_mm, there's no address space

  reply	other threads:[~2007-01-19 18:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-19 16:30 Alexey Dobriyan
2007-01-19 18:08 ` Hugh Dickins [this message]
2007-01-19 19:16   ` Alexey Kuznetsov

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.64.0701191754020.10013@blonde.wat.veritas.com \
    --to=hugh@veritas.com \
    --cc=adobriyan@openvz.org \
    --cc=akpm@osdl.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@openedhand.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

all inboxes | Powered by JetHome®