From: Minchan Kim <minchan@kernel.org>
To: Heesub Shin <heesub.shin@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Sunae Seo <sunae.seo@samsung.com>,
Sunghwan Yun <sunghwan.yun@samsung.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Sooyong Suk <s.suk@samsung.com>
Subject: Re: [PATCH] zsmalloc: fix fatal corruption due to wrong size class selection
Date: Wed, 25 Mar 2015 23:35:08 +0900 [thread overview]
Message-ID: <20150325143442.GA3814@blaptop> (raw)
In-Reply-To: <1427281092-10116-1-git-send-email-heesub.shin@samsung.com>
Hello Heesub,
On Wed, Mar 25, 2015 at 07:58:12PM +0900, Heesub Shin wrote:
> There is no point in overriding the size class below. It causes fatal
> corruption on the next chunk on the 3264-bytes size class, which is the
> last size class that is not huge.
>
> For example, if the requested size was exactly 3264 bytes, current
> zsmalloc allocates and returns a chunk from the size class of 3264
> bytes, not 4096. User access to this chunk may overwrite head of the
> next adjacent chunk.
>
> Here is the panic log captured when freelist was corrupted due to this:
>
> Kernel BUG at ffffffc00030659c [verbose debug info unavailable]
> Internal error: Oops - BUG: 96000006 [#1] PREEMPT SMP
> Modules linked in:
> exynos-snapshot: core register saved(CPU:5)
> CPUMERRSR: 0000000000000000, L2MERRSR: 0000000000000000
> exynos-snapshot: context saved(CPU:5)
> exynos-snapshot: item - log_kevents is disabled
> CPU: 5 PID: 898 Comm: kswapd0 Not tainted 3.10.61-4497415-eng #1
> task: ffffffc0b8783d80 ti: ffffffc0b71e8000 task.ti: ffffffc0b71e8000
> PC is at obj_idx_to_offset+0x0/0x1c
> LR is at obj_malloc+0x44/0xe8
> pc : [<ffffffc00030659c>] lr : [<ffffffc000306604>] pstate: a0000045
> sp : ffffffc0b71eb790
> x29: ffffffc0b71eb790 x28: ffffffc00204c000
> x27: 000000000001d96f x26: 0000000000000000
> x25: ffffffc098cc3500 x24: ffffffc0a13f2810
> x23: ffffffc098cc3501 x22: ffffffc0a13f2800
> x21: 000011e1a02006e3 x20: ffffffc0a13f2800
> x19: ffffffbc02a7e000 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000feb
> x15: 0000000000000000 x14: 00000000a01003e3
> x13: 0000000000000020 x12: fffffffffffffff0
> x11: ffffffc08b264000 x10: 00000000e3a01004
> x9 : ffffffc08b263fea x8 : ffffffc0b1e611c0
> x7 : ffffffc000307d24 x6 : 0000000000000000
> x5 : 0000000000000038 x4 : 000000000000011e
> x3 : ffffffbc00003e90 x2 : 0000000000000cc0
> x1 : 00000000d0100371 x0 : ffffffbc00003e90
>
> Reported-by: Sooyong Suk <s.suk@samsung.com>
> Signed-off-by: Heesub Shin <heesub.shin@samsung.com>
> Tested-by: Sooyong Suk <s.suk@samsung.com>
> Cc: Minchan Kim <minchan@kernel.org>
I am wondering how you encounter this error.
zRAM passes uncompressed page(ie, PAGE_SIZE) to zsmalloc
once it found result of compressed size is above than PAGE_SIZE * 3 /4.
Maybe, that's was a reason I couldn't see during testing.
Anyway, It's nice catch. Thanks, Heesub.
Acked-by: Minchan Kim <minchan@kernel.org>
--
Kind regards,
Minchan Kim
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Heesub Shin <heesub.shin@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Sunae Seo <sunae.seo@samsung.com>,
Sunghwan Yun <sunghwan.yun@samsung.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Sooyong Suk <s.suk@samsung.com>
Subject: Re: [PATCH] zsmalloc: fix fatal corruption due to wrong size class selection
Date: Wed, 25 Mar 2015 23:35:08 +0900 [thread overview]
Message-ID: <20150325143442.GA3814@blaptop> (raw)
In-Reply-To: <1427281092-10116-1-git-send-email-heesub.shin@samsung.com>
Hello Heesub,
On Wed, Mar 25, 2015 at 07:58:12PM +0900, Heesub Shin wrote:
> There is no point in overriding the size class below. It causes fatal
> corruption on the next chunk on the 3264-bytes size class, which is the
> last size class that is not huge.
>
> For example, if the requested size was exactly 3264 bytes, current
> zsmalloc allocates and returns a chunk from the size class of 3264
> bytes, not 4096. User access to this chunk may overwrite head of the
> next adjacent chunk.
>
> Here is the panic log captured when freelist was corrupted due to this:
>
> Kernel BUG at ffffffc00030659c [verbose debug info unavailable]
> Internal error: Oops - BUG: 96000006 [#1] PREEMPT SMP
> Modules linked in:
> exynos-snapshot: core register saved(CPU:5)
> CPUMERRSR: 0000000000000000, L2MERRSR: 0000000000000000
> exynos-snapshot: context saved(CPU:5)
> exynos-snapshot: item - log_kevents is disabled
> CPU: 5 PID: 898 Comm: kswapd0 Not tainted 3.10.61-4497415-eng #1
> task: ffffffc0b8783d80 ti: ffffffc0b71e8000 task.ti: ffffffc0b71e8000
> PC is at obj_idx_to_offset+0x0/0x1c
> LR is at obj_malloc+0x44/0xe8
> pc : [<ffffffc00030659c>] lr : [<ffffffc000306604>] pstate: a0000045
> sp : ffffffc0b71eb790
> x29: ffffffc0b71eb790 x28: ffffffc00204c000
> x27: 000000000001d96f x26: 0000000000000000
> x25: ffffffc098cc3500 x24: ffffffc0a13f2810
> x23: ffffffc098cc3501 x22: ffffffc0a13f2800
> x21: 000011e1a02006e3 x20: ffffffc0a13f2800
> x19: ffffffbc02a7e000 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000feb
> x15: 0000000000000000 x14: 00000000a01003e3
> x13: 0000000000000020 x12: fffffffffffffff0
> x11: ffffffc08b264000 x10: 00000000e3a01004
> x9 : ffffffc08b263fea x8 : ffffffc0b1e611c0
> x7 : ffffffc000307d24 x6 : 0000000000000000
> x5 : 0000000000000038 x4 : 000000000000011e
> x3 : ffffffbc00003e90 x2 : 0000000000000cc0
> x1 : 00000000d0100371 x0 : ffffffbc00003e90
>
> Reported-by: Sooyong Suk <s.suk@samsung.com>
> Signed-off-by: Heesub Shin <heesub.shin@samsung.com>
> Tested-by: Sooyong Suk <s.suk@samsung.com>
> Cc: Minchan Kim <minchan@kernel.org>
I am wondering how you encounter this error.
zRAM passes uncompressed page(ie, PAGE_SIZE) to zsmalloc
once it found result of compressed size is above than PAGE_SIZE * 3 /4.
Maybe, that's was a reason I couldn't see during testing.
Anyway, It's nice catch. Thanks, Heesub.
Acked-by: Minchan Kim <minchan@kernel.org>
--
Kind regards,
Minchan Kim
next prev parent reply other threads:[~2015-03-25 14:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 10:58 [PATCH] zsmalloc: fix fatal corruption due to wrong size class selection Heesub Shin
2015-03-25 10:58 ` Heesub Shin
2015-03-25 14:35 ` Minchan Kim [this message]
2015-03-25 14:35 ` Minchan Kim
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=20150325143442.GA3814@blaptop \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=heesub.shin@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=s.suk@samsung.com \
--cc=sunae.seo@samsung.com \
--cc=sunghwan.yun@samsung.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 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.