All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Hugh Dickins <hughd@google.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH] mm/swap: abort swapoff after disk error
Date: Tue, 18 Dec 2012 13:40:15 +0400	[thread overview]
Message-ID: <50D039FF.5090006@openvz.org> (raw)
In-Reply-To: <alpine.LNX.2.00.1212171953070.5927@eggly.anvils>

Hugh Dickins wrote:
> On Fri, 14 Dec 2012, Konstantin Khlebnikov wrote:
>
>> Content of non-uptodate pages completely random, we cannot expose them into
>> userspace. This leads to information leak and will crash userspace for sure.
>
> Good find, yes, it's very wrong as is.  But, sorry, I don't like your fix
> - better than ignoring the issue as at present, but not the right answer.
>
>> Probably we can reuse hwpoison entries here, but tmpfs already too complex.
>
> HWpoison entries?  They're for when that page of RAM is bad, but this is
> quite a different case: the page is fine and can perfectly well be freed
> and reused - what's bad is the data currently in it.
>
>>
>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>> Original-patch-by: Alexey Kuznetsov<kuznet@ms2.inr.ac.ru>
>> Cc: Andrew Morton<akpm@linux-foundation.org>
>> Cc: Hugh Dickins<hughd@google.com>
>> Cc: Andi Kleen<andi@firstfloor.org>
>> ---
>>   mm/swapfile.c |   16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/mm/swapfile.c b/mm/swapfile.c
>> index e97a0e5..98fc2fd 100644
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -1127,6 +1127,22 @@ int try_to_unuse(unsigned int type, bool frontswap,
>>   		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
>
> try_to_unuse() is all about locating exactly where this page belongs;
> and if the user is lucky, the page in question won't even be needed again
> before the process exits, so nothing should be killed at this point.
>
>
>> +		 * variant remains: to stop swapoff() and allow someone
>> +		 * to kill processes to zap invalid pages.
>
> No, we should not abort swapoff: there's every reason to continue,
> to make sure that this unreliable area can be taken out of service.
>
>> +		 *
>> +		 * TODO replace page with hwpoison entry in pte and shmem.
>
> Instead of blindly going ahead and inserting ptes pointing to the
> !PageUptodate page, unuse_pte() and shmem_unuse_inode() should insert
> a substitute bad swapentry, to generate SIGBUS if it's accessed.
>
> swp_entry(1, 0) might serve, but there's probably a few mods needed
> here and there; and getting the details right (e.g. memcg charges)
> will need care.
>
> Not as straightforward as your block below, I admit.  I wonder if you
> posted that just to stir me to do better: or can you take it further?

I found this patch in our kernel tree. For some reason it wasn't sent
to mainline. So I decided to send it as is to not lose it for a few more
years. Using here hwpoison was just a guess. Your bad-swap-entry is much
more accurate solution. Seems like here is no rush, this bug was here from
the beginning, so I'll handle it. Thanks for your advice.

>
> Thanks,
> Hugh
>
>> +		 */
>> +		if (unlikely(!PageUptodate(page))) {
>> +			unlock_page(page);
>> +			page_cache_release(page);
>> +			retval = -EIO;
>> +			break;
>> +		}
>> +
>> +		/*
>>   		 * Remove all references to entry.
>>   		 */
>>   		swcount = *swap_map;

      reply	other threads:[~2012-12-18 10:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-14 11:01 [PATCH] mm/swap: abort swapoff after disk error Konstantin Khlebnikov
2012-12-18  4:24 ` Hugh Dickins
2012-12-18  9:40   ` Konstantin Khlebnikov [this message]

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=50D039FF.5090006@openvz.org \
    --to=khlebnikov@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.