linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dan Streetman <ddstreet@ieee.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>, Alexandr <sss123next@list.ru>,
	Seth Jennings <sjenning@redhat.com>,
	Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	bugzilla-daemon@bugzilla.kernel.org,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] zswap: change BUG to WARN in zswap_writeback_entry
Date: Thu, 19 Jan 2017 10:36:51 -0500	[thread overview]
Message-ID: <CALZtONA9k6UOYzCr=SxXz8Dfu+nzdx0N8GTc92fmmpSVhxezvA@mail.gmail.com> (raw)
In-Reply-To: <20170119051503.GB2046@jagdpanzerIV.localdomain>

On Thu, Jan 19, 2017 at 12:15 AM, Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
> On (01/18/17 23:20), Dan Streetman wrote:
>> Change the BUG calls to WARN, and return error.
>>
>> There's no need to call BUG from this function, as it can safely return
>> the error.  The only caller of this function is the zpool that zswap is
>> using, when zswap is trying to reduce the zpool size.  While the error
>> does indicate a bug, as none of the WARN conditions should ever happen,
>> the zpool implementation can recover by trying to evict another page
>> or zswap will recover by sending the new page to the swap disk.
>>
>> This was reported in kernel bug 192571:
>> https://bugzilla.kernel.org/show_bug.cgi?id=192571

Andrew, please ignore this patch (for now at least)...it won't address this bug.

>>
>> Reported-by: Gluzskiy Alexandr <sss123next@list.ru>
>> Signed-off-by: Dan Streetman <ddstreet@ieee.org>
>> ---
>>  mm/zswap.c | 14 +++++++++++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> index 067a0d6..60c4e6f 100644
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -787,7 +787,10 @@ static int zswap_writeback_entry(struct zpool *pool, unsigned long handle)
>>               return 0;
>>       }
>>       spin_unlock(&tree->lock);
>> -     BUG_ON(offset != entry->offset);
>> +     if (WARN_ON(offset != entry->offset)) {
>> +             ret = -EINVAL;
>> +             goto fail;
>> +     }
>>
>>       /* try to allocate swap cache page */
>>       switch (zswap_get_swap_cache_page(swpentry, &page)) {
>> @@ -813,8 +816,13 @@ static int zswap_writeback_entry(struct zpool *pool, unsigned long handle)
>>               put_cpu_ptr(entry->pool->tfm);
>>               kunmap_atomic(dst);
>>               zpool_unmap_handle(entry->pool->zpool, entry->handle);
>> -             BUG_ON(ret);
>> -             BUG_ON(dlen != PAGE_SIZE);
>> +             if (WARN(ret, "error decompressing page: %d\n", ret))
>> +                     goto fail;
>> +             if (WARN(dlen != PAGE_SIZE,
>> +                      "decompressed page only %x bytes\n", dlen)) {
>> +                     ret = -EINVAL;
>> +                     goto fail;
>> +             }
>>
>>               /* page is up to date */
>>               SetPageUptodate(page);
>
>
> + zswap_frontswap_load() I suppose.

So my initial comment before that it was safe to switch to WARN was
right for zswap_writeback_entry(), but not right for
zswap_frontswap_load() - it was late and I didn't read the trace
correctly :(

At the BUG point in zswap_frontswap_load(), we have found the page in
the rb tree (via zswap_entry_find_get) so we know that we did accept
the page for storage, so we're the only place who has a copy of it
(assuming frontswap_writethrough isn't enabled).  If we can't
decompress it, then we only have 2 choices - BUG or return error.  If
we return error, frontswap will try any other frontswap backends it
has registered (none, I assume, or if so they should not have this
swap offset's entry, since we found a match).  After frontswap can't
recover the page from any of its backends, it will return error, and
swap_readpage() will then assume the page is actually stored on the
swap disk, and read it back.  However, the page wasn't written to the
swap disk (since we stored it in zswap), and whatever is read back
from the disk is not what was originally in the page - leading to
memory corruption.  So it's better to BUG at this point.

As to why it can't decompress the page, we should at least add info
about the error value.  Maybe the zpool storage encountered a bug and
provided the wrong compressed data to us...

>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index 067a0d62f318..e2743687a202 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -1023,13 +1023,13 @@ static int zswap_frontswap_load(unsigned type, pgoff_t offset,
>         put_cpu_ptr(entry->pool->tfm);
>         kunmap_atomic(dst);
>         zpool_unmap_handle(entry->pool->zpool, entry->handle);
> -       BUG_ON(ret);
> +       WARN(ret, "error decompressing page: %d\n", ret);
>
>         spin_lock(&tree->lock);
>         zswap_entry_put(tree, entry);
>         spin_unlock(&tree->lock);
>
> -       return 0;
> +       return ret;
>  }
>

--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-01-19 15:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-192571-27@https.bugzilla.kernel.org/>
     [not found] ` <bug-192571-27-qFfm1cXEv4@https.bugzilla.kernel.org/>
2017-01-17 20:22   ` [Bug 192571] zswap + zram enabled BUG Andrew Morton
2017-01-18  1:39     ` Sergey Senozhatsky
2017-01-18  5:58       ` Alexandr
2017-01-19  2:56         ` Dan Streetman
2017-01-24  0:03           ` Alexandr
2017-01-24 20:16             ` Dan Streetman
2017-01-25  4:02               ` Chulmin Kim
2017-01-26 17:09                 ` Dan Streetman
2017-01-25  6:42               ` Alexandr
2017-01-18 13:17       ` Michal Hocko
2017-01-19  1:36         ` Dan Streetman
2017-01-19  3:00           ` Sergey Senozhatsky
2017-01-19  4:20             ` [PATCH] zswap: change BUG to WARN in zswap_writeback_entry Dan Streetman
2017-01-19  5:15               ` Sergey Senozhatsky
2017-01-19 15:36                 ` Dan Streetman [this message]
2017-01-19  4:42             ` [Bug 192571] zswap + zram enabled BUG Dan Streetman

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='CALZtONA9k6UOYzCr=SxXz8Dfu+nzdx0N8GTc92fmmpSVhxezvA@mail.gmail.com' \
    --to=ddstreet@ieee.org \
    --cc=akpm@linux-foundation.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sjenning@redhat.com \
    --cc=sss123next@list.ru \
    /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