Received-SPF: pass (google.com: domain of linux-kernel+bounces-106788-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240318230013.87543-1-21cnbao@gmail.com>
In-Reply-To: <20240318230013.87543-1-21cnbao@gmail.com>
From: Yosry Ahmed <yosryahmed@google.com>
Date: Mon, 18 Mar 2024 16:05:40 -0700
Message-ID: <CAJD7tkYVJHsWoaEkTiTigJRzSNBrRSg3YVAL3Q5Q96cLSNJZrQ@mail.gmail.com>
Subject: Re: [PATCH] mm: zswap: fix kernel BUG in sg_init_one
To: Barry Song <21cnbao@gmail.com>
Cc: hannes@cmpxchg.org, nphamcs@gmail.com, akpm@linux-foundation.org, 
	chrisl@kernel.org, v-songbaohua@oppo.com, linux-mm@kvack.org, 
	linux-kernel@vger.kernel.org, ira.weiny@intel.com, 
	syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2024 at 4:00=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot=
e:
>
> 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.c=
om/
> Fixes: 270700dd06ca ("mm/zswap: remove the memcpy if acomp is not sleepab=
le")
> 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 *en=
try, struct page *page)
>         mutex_lock(&acomp_ctx->mutex);
>
>         src =3D 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 =3D acomp_ctx->buffer;
>                 zpool_unmap_handle(zpool, entry->handle);
> @@ -1094,7 +1095,7 @@ static void zswap_decompress(struct zswap_entry *en=
try, struct page *page)
>         BUG_ON(acomp_ctx->req->dlen !=3D PAGE_SIZE);
>         mutex_unlock(&acomp_ctx->mutex);
>
> -       if (!acomp_ctx->is_sleepable || zpool_can_sleep_mapped(zpool))
> +       if (src !=3D acomp_ctx->buffer)
>                 zpool_unmap_handle(zpool, entry->handle);
>  }
>
> --
> 2.34.1
>