* [PATCH] mm: zswap: fix kernel BUG in sg_init_one
@ 2024-03-18 23:00 Barry Song
2024-03-18 23:05 ` Yosry Ahmed
0 siblings, 1 reply; 4+ messages in thread
From: Barry Song @ 2024-03-18 23:00 UTC (permalink / raw)
To: hannes, yosryahmed, nphamcs, akpm, chrisl, v-songbaohua, linux-mm
Cc: linux-kernel, ira.weiny, syzbot+adbc983a1588b7805de3
From: Barry Song <v-songbaohua@oppo.com>
sg_init_one() relies on linearly mapped low memory for the safe
utilization of virt_to_page(). Consequently, we have two choices:
either employ kmap_to_page() alongside sg_set_page(), or resort to
copying high memory contents to a temporary buffer residing in low
memory. However, considering the introduction of the WARN_ON_ONCE
in commit ef6e06b2ef870 ("highmem: fix kmap_to_page() for
kmap_local_page() addresses"), which specifically addresses high
memory concerns, it appears that memcpy remains the sole viable
option.
Reported-and-tested-by: syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/000000000000bbb3d80613f243a6@google.com/
Fixes: 270700dd06ca ("mm/zswap: remove the memcpy if acomp is not sleepable")
Signed-off-by: Barry Song <v-songbaohua@oppo.com>
---
mm/zswap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 9dec853647c8..17bf6d87b274 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1080,7 +1080,8 @@ static void zswap_decompress(struct zswap_entry *entry, struct page *page)
mutex_lock(&acomp_ctx->mutex);
src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO);
- if (acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) {
+ if ((acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) ||
+ !virt_addr_valid(src)) {
memcpy(acomp_ctx->buffer, src, entry->length);
src = acomp_ctx->buffer;
zpool_unmap_handle(zpool, entry->handle);
@@ -1094,7 +1095,7 @@ static void zswap_decompress(struct zswap_entry *entry, struct page *page)
BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE);
mutex_unlock(&acomp_ctx->mutex);
- if (!acomp_ctx->is_sleepable || zpool_can_sleep_mapped(zpool))
+ if (src != acomp_ctx->buffer)
zpool_unmap_handle(zpool, entry->handle);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: zswap: fix kernel BUG in sg_init_one
2024-03-18 23:00 [PATCH] mm: zswap: fix kernel BUG in sg_init_one Barry Song
@ 2024-03-18 23:05 ` Yosry Ahmed
2024-03-18 23:12 ` Barry Song
0 siblings, 1 reply; 4+ messages in thread
From: Yosry Ahmed @ 2024-03-18 23:05 UTC (permalink / raw)
To: Barry Song
Cc: hannes, nphamcs, akpm, chrisl, v-songbaohua, linux-mm,
linux-kernel, ira.weiny, syzbot+adbc983a1588b7805de3
On Mon, Mar 18, 2024 at 4:00 PM Barry Song <21cnbao@gmail.com> wrote:
>
> From: Barry Song <v-songbaohua@oppo.com>
>
> sg_init_one() relies on linearly mapped low memory for the safe
> utilization of virt_to_page(). Consequently, we have two choices:
> either employ kmap_to_page() alongside sg_set_page(), or resort to
> copying high memory contents to a temporary buffer residing in low
> memory. However, considering the introduction of the WARN_ON_ONCE
> in commit ef6e06b2ef870 ("highmem: fix kmap_to_page() for
> kmap_local_page() addresses"), which specifically addresses high
> memory concerns, it appears that memcpy remains the sole viable
> option.
>
> Reported-and-tested-by: syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/000000000000bbb3d80613f243a6@google.com/
> Fixes: 270700dd06ca ("mm/zswap: remove the memcpy if acomp is not sleepable")
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> ---
> mm/zswap.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index 9dec853647c8..17bf6d87b274 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -1080,7 +1080,8 @@ static void zswap_decompress(struct zswap_entry *entry, struct page *page)
> mutex_lock(&acomp_ctx->mutex);
>
> src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO);
> - if (acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) {
> + if ((acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) ||
> + !virt_addr_valid(src)) {
Would it be better to explicitly check is_kmap_addr() here? I am
particularly worried about hiding a bug where the returned address
from zpool_map_handle() is not a kmap address, but also not a valid
linear mapping address.
If we use is_kmap_addr() here, then the virt_addr_valid() check in
sg_init_one() will catch any non-kmap non-linear mapping addresses.
WDYT? Am I being paranoid? :)
Also, I think a comment would be nice to explain the cases where we
need to use a temporary buffer since we have two different cases now.
>
> memcpy(acomp_ctx->buffer, src, entry->length);
> src = acomp_ctx->buffer;
> zpool_unmap_handle(zpool, entry->handle);
> @@ -1094,7 +1095,7 @@ static void zswap_decompress(struct zswap_entry *entry, struct page *page)
> BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE);
> mutex_unlock(&acomp_ctx->mutex);
>
> - if (!acomp_ctx->is_sleepable || zpool_can_sleep_mapped(zpool))
> + if (src != acomp_ctx->buffer)
> zpool_unmap_handle(zpool, entry->handle);
> }
>
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: zswap: fix kernel BUG in sg_init_one
2024-03-18 23:05 ` Yosry Ahmed
@ 2024-03-18 23:12 ` Barry Song
2024-03-18 23:16 ` Yosry Ahmed
0 siblings, 1 reply; 4+ messages in thread
From: Barry Song @ 2024-03-18 23:12 UTC (permalink / raw)
To: Yosry Ahmed
Cc: hannes, nphamcs, akpm, chrisl, v-songbaohua, linux-mm,
linux-kernel, ira.weiny, syzbot+adbc983a1588b7805de3
On Tue, Mar 19, 2024 at 12:06 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Mon, Mar 18, 2024 at 4:00 PM Barry Song <21cnbao@gmail.com> wrote:
> >
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > sg_init_one() relies on linearly mapped low memory for the safe
> > utilization of virt_to_page(). Consequently, we have two choices:
> > either employ kmap_to_page() alongside sg_set_page(), or resort to
> > copying high memory contents to a temporary buffer residing in low
> > memory. However, considering the introduction of the WARN_ON_ONCE
> > in commit ef6e06b2ef870 ("highmem: fix kmap_to_page() for
> > kmap_local_page() addresses"), which specifically addresses high
> > memory concerns, it appears that memcpy remains the sole viable
> > option.
> >
> > Reported-and-tested-by: syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/000000000000bbb3d80613f243a6@google.com/
> > Fixes: 270700dd06ca ("mm/zswap: remove the memcpy if acomp is not sleepable")
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > ---
> > mm/zswap.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index 9dec853647c8..17bf6d87b274 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -1080,7 +1080,8 @@ static void zswap_decompress(struct zswap_entry *entry, struct page *page)
> > mutex_lock(&acomp_ctx->mutex);
> >
> > src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO);
> > - if (acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) {
> > + if ((acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) ||
> > + !virt_addr_valid(src)) {
>
>
> Would it be better to explicitly check is_kmap_addr() here? I am
> particularly worried about hiding a bug where the returned address
> from zpool_map_handle() is not a kmap address, but also not a valid
> linear mapping address.
>
> If we use is_kmap_addr() here, then the virt_addr_valid() check in
> sg_init_one() will catch any non-kmap non-linear mapping addresses.
> WDYT? Am I being paranoid? :)
we have a possibility that a userspace buffer or vmalloc address is given to
sg_init_one, then it is non-kmap non-linear. but is it possible someday some
people return a vmalloc/vmap address from zpool_map_handle() in the future?
then we still need !virt_addr_valid().
>
> Also, I think a comment would be nice to explain the cases where we
> need to use a temporary buffer since we have two different cases now.
that makes sense.
>
> >
> > memcpy(acomp_ctx->buffer, src, entry->length);
> > src = acomp_ctx->buffer;
> > zpool_unmap_handle(zpool, entry->handle);
> > @@ -1094,7 +1095,7 @@ static void zswap_decompress(struct zswap_entry *entry, struct page *page)
> > BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE);
> > mutex_unlock(&acomp_ctx->mutex);
> >
> > - if (!acomp_ctx->is_sleepable || zpool_can_sleep_mapped(zpool))
> > + if (src != acomp_ctx->buffer)
> > zpool_unmap_handle(zpool, entry->handle);
> > }
> >
> > --
> > 2.34.1
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: zswap: fix kernel BUG in sg_init_one
2024-03-18 23:12 ` Barry Song
@ 2024-03-18 23:16 ` Yosry Ahmed
0 siblings, 0 replies; 4+ messages in thread
From: Yosry Ahmed @ 2024-03-18 23:16 UTC (permalink / raw)
To: Barry Song
Cc: hannes, nphamcs, akpm, chrisl, v-songbaohua, linux-mm,
linux-kernel, ira.weiny, syzbot+adbc983a1588b7805de3
On Mon, Mar 18, 2024 at 4:12 PM Barry Song <21cnbao@gmail.com> wrote:
>
> On Tue, Mar 19, 2024 at 12:06 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Mon, Mar 18, 2024 at 4:00 PM Barry Song <21cnbao@gmail.com> wrote:
> > >
> > > From: Barry Song <v-songbaohua@oppo.com>
> > >
> > > sg_init_one() relies on linearly mapped low memory for the safe
> > > utilization of virt_to_page(). Consequently, we have two choices:
> > > either employ kmap_to_page() alongside sg_set_page(), or resort to
> > > copying high memory contents to a temporary buffer residing in low
> > > memory. However, considering the introduction of the WARN_ON_ONCE
> > > in commit ef6e06b2ef870 ("highmem: fix kmap_to_page() for
> > > kmap_local_page() addresses"), which specifically addresses high
> > > memory concerns, it appears that memcpy remains the sole viable
> > > option.
> > >
> > > Reported-and-tested-by: syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com
> > > Closes: https://lore.kernel.org/all/000000000000bbb3d80613f243a6@google.com/
> > > Fixes: 270700dd06ca ("mm/zswap: remove the memcpy if acomp is not sleepable")
> > > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > > ---
> > > mm/zswap.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/zswap.c b/mm/zswap.c
> > > index 9dec853647c8..17bf6d87b274 100644
> > > --- a/mm/zswap.c
> > > +++ b/mm/zswap.c
> > > @@ -1080,7 +1080,8 @@ static void zswap_decompress(struct zswap_entry *entry, struct page *page)
> > > mutex_lock(&acomp_ctx->mutex);
> > >
> > > src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO);
> > > - if (acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) {
> > > + if ((acomp_ctx->is_sleepable && !zpool_can_sleep_mapped(zpool)) ||
> > > + !virt_addr_valid(src)) {
> >
> >
> > Would it be better to explicitly check is_kmap_addr() here? I am
> > particularly worried about hiding a bug where the returned address
> > from zpool_map_handle() is not a kmap address, but also not a valid
> > linear mapping address.
> >
> > If we use is_kmap_addr() here, then the virt_addr_valid() check in
> > sg_init_one() will catch any non-kmap non-linear mapping addresses.
> > WDYT? Am I being paranoid? :)
>
> we have a possibility that a userspace buffer or vmalloc address is given to
> sg_init_one, then it is non-kmap non-linear. but is it possible someday some
> people return a vmalloc/vmap address from zpool_map_handle() in the future?
> then we still need !virt_addr_valid().
Hmm I guess if zpool_map_handle() ever returns a vmalloc/vmap address
we would need to copy the data to the buffer in zswap code, at least
until we enlighten the code to deal with them directly. So I guess we
can keep virt_addr_valid(). Ideally the comment will clarify this.
Thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-03-18 23:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-18 23:00 [PATCH] mm: zswap: fix kernel BUG in sg_init_one Barry Song
2024-03-18 23:05 ` Yosry Ahmed
2024-03-18 23:12 ` Barry Song
2024-03-18 23:16 ` Yosry Ahmed
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.