linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosryahmed@google.com>
To: Barry Song <21cnbao@gmail.com>
Cc: Nhat Pham <nphamcs@gmail.com>,
	 syzbot <syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com>,
	 akpm@linux-foundation.org, chengming.zhou@linux.dev,
	hannes@cmpxchg.org,  linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,  syzkaller-bugs@googlegroups.com,
	Barry Song <v-songbaohua@oppo.com>
Subject: Re: [syzbot] [mm?] kernel BUG in sg_init_one
Date: Mon, 18 Mar 2024 13:59:51 -0700	[thread overview]
Message-ID: <CAJD7tkaP_wfkJG_dfsp-jV7QP2JWyMFfNApTFPWbsqmTvfKyLw@mail.gmail.com> (raw)
In-Reply-To: <CAGsJ_4xyDm0BLYvbW0z9J-Q=sQPYrttva33g2mRFVXcJJ+wimw@mail.gmail.com>

[..]
> > > I guess that is because on arm32 , we have highmem but
> > > sg_init_one supports lowmem only. the below should be
> > > able to fix?
> > >
> > > diff --git a/mm/zswap.c b/mm/zswap.c
> > > index 9dec853647c8..47c0386caba2 100644
> > > --- a/mm/zswap.c
> > > +++ b/mm/zswap.c
> > > @@ -1086,7 +1086,8 @@ static void zswap_decompress(struct zswap_entry
> > > *entry, struct page *page)
> > >                 zpool_unmap_handle(zpool, entry->handle);
> > >         }
> > >
> > > -       sg_init_one(&input, src, entry->length);
> > > +       sg_init_table(&input, 1);
> > > +       sg_set_page(&input, kmap_to_page(src), entry->length,
> > > offset_in_page(src));
> >
> > Is this working around the debug check in sg_init_one()? IIUC, only
>
> I wouldn't characterize it as a workaround; it's more of a solution.

I assumed that the debug check in sg_set_buf() is because
sg_set_page() cannot handle highmem pages, sorry if that isn't the
case. Apparently we are hitting a warning with kmap_to_page() though
as syzbot just reported.

>
> > lowmem pages are supported. We may be passing in a highmem page to
> > sg_set_page() now, right?
>
> we can pass highmem to sg_set_page(). This is perfectly fine.

So the debug check is only because we are using virt_to_page() in sg_set_buf()?

>
> >
> > Also, it seems like if src is a lowmem address kmap_to_page() will be
> > doing unnecessary checks (assuming it's working correctly)?
>
> In practice, we consistently use kmap and kunmap even on systems with
> low memory.
> However, it's worth noting that for low memory scenarios, kmap
> essentially returns
> page_to_virt(page_address). Thus, the overhead of kmap_to_page shouldn't be
> significant on low memory systems, especially considering that it simplifies to
> virt_to_page().
>
> Another approach is to consistently employ page_to_virt() for low
> memory situations
> and reserve kmap for high memory scenarios. However, since we always
> utilize kmap
> regardless of whether the page is low or high memory, we don't need to concern
> ourselves with this distinction

I see. Thanks for elaborating.

>
> >
> > Would it be more robust to just use the temporary buffer if src is a
> > kmap address?
>
> I don't think so because we will need a memcpy then.

I thought that was necessary because sg_set_page() cannot take in
highmem pages, but you mentioned that this isn't the case.


  reply	other threads:[~2024-03-18 21:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18 16:58 syzbot
2024-03-18 18:00 ` Nhat Pham
2024-03-18 20:17   ` Yosry Ahmed
2024-03-18 21:09     ` Johannes Weiner
2024-03-18 21:15       ` Barry Song
2024-03-18 21:32         ` Johannes Weiner
2024-03-18 21:37           ` Barry Song
2024-03-18 21:18       ` Yosry Ahmed
2024-03-18 21:21         ` Barry Song
2024-03-18 20:25   ` Barry Song
2024-03-18 20:34     ` Yosry Ahmed
2024-03-18 20:50       ` Barry Song
2024-03-18 20:59         ` Yosry Ahmed [this message]
2024-03-18 21:12           ` Barry Song
2024-03-18 20:42 ` Barry Song
2024-03-18 20:52   ` syzbot
2024-03-18 21:03     ` Barry Song
2025-02-12 17:20       ` Yosry Ahmed
2025-02-22  0:48         ` Yosry Ahmed
2025-02-26 16:01           ` Ira Weiny
2025-02-26 16:45             ` Yosry Ahmed
2025-02-26 20:36               ` Ira Weiny
2024-03-18 22:27     ` Barry Song
2024-03-18 22:52       ` syzbot

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=CAJD7tkaP_wfkJG_dfsp-jV7QP2JWyMFfNApTFPWbsqmTvfKyLw@mail.gmail.com \
    --to=yosryahmed@google.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=syzbot+adbc983a1588b7805de3@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=v-songbaohua@oppo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox