From: Nhat Pham <nphamcs@gmail.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Yosry Ahmed <yosry.ahmed@linux.dev>,
akpm@linux-foundation.org, chengming.zhou@linux.dev,
linux-mm@kvack.org, kernel-team@meta.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] page_io: zswap: do not crash the kernel on decompression failure
Date: Mon, 3 Mar 2025 15:28:33 -0800 [thread overview]
Message-ID: <CAKEwX=O_EHud_6SUJmxP7cwoi0NUcLPjUqz+s5=PTdukCxQrhA@mail.gmail.com> (raw)
In-Reply-To: <20250303231654.GE120597@cmpxchg.org>
On Mon, Mar 3, 2025 at 3:17 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Mon, Mar 03, 2025 at 10:34:46PM +0000, Yosry Ahmed wrote:
> > On Mon, Mar 03, 2025 at 04:55:24PM -0500, Johannes Weiner wrote:
> > > pr_alert_ratelimited("Decompression error from zswap (%d:%lu %s %u->%d)\n",
> > > swptype, swpoffset, name, clen, dlen);
> >
> > Yeah this looks much more concise. It's a bit harder to parser the dmesg
> > as you have to cross check the code, but hopefully this is something
> > that people rarely have to do.
> >
> > I don't feel strongly about adding a helper in this case, unless we want
> > to add local variables (like Johannes did above), in which case a helper
> > would be a good way to hide them.
>
> pr_alert_ratelimited("Decompression error from zswap (%d:%lu %s %u->%d)\n",
> swp_type(entry->swpentry), swp_offset(entry->swpentry),
> entry->pool->tfm_name, entry->length, acomp_ctx->req->dlen);
>
> Seriously, this does not warrant another function.
>
> It's also valuable to keep warnings inside the problem context instead
> of socking them away somewhere. It makes it clear that decompression
> failure is a serious situation. We also expect this to trigger almost
> never and it won't be tested routinely, so the best chance to fight
> bitrot is to keep all those derefs close by. Imagine if this triggers
> and the data is misleading or it crashes the system because some rules
> around entry, acomp_ctx, the pool or whatever changed. Or if the work
> involved in decompression changed and this is incomplete/unhelpful.
I was actually thinking along the line of Yosry's, but you make some
good points.
Anyway, let's just keep the printing in the OG function. Let's not
overthink one print function call. :)
(sorry for the duplicate email, Johannes. I accidentally sent this
email to you and not cc-ing the rest lol. Resending it)
next prev parent reply other threads:[~2025-03-03 23:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 20:06 Nhat Pham
2025-03-03 21:21 ` Yosry Ahmed
2025-03-03 21:55 ` Johannes Weiner
2025-03-03 22:34 ` Yosry Ahmed
2025-03-03 23:16 ` Johannes Weiner
2025-03-03 23:28 ` Nhat Pham [this message]
2025-03-04 0:05 ` Yosry Ahmed
2025-03-03 23:22 ` Nhat Pham
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='CAKEwX=O_EHud_6SUJmxP7cwoi0NUcLPjUqz+s5=PTdukCxQrhA@mail.gmail.com' \
--to=nphamcs@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=yosry.ahmed@linux.dev \
/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