From: "Dāvis Mosāns" <davispuh@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: FMDF <fmdefrancesco@gmail.com>,
linux-fsdevel@vger.kernel.org,
BTRFS <linux-btrfs@vger.kernel.org>,
kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: How to debug stuck read?
Date: Mon, 7 Feb 2022 03:22:06 +0200 [thread overview]
Message-ID: <CAOE4rSy81hycALngZgCRj9vMR5rLU0Fq1F-g_N72bqvkVmpMsg@mail.gmail.com> (raw)
In-Reply-To: <YgBwet7Av2qkaMaJ@casper.infradead.org>
pirmd., 2022. g. 7. febr., plkst. 03:06 — lietotājs Matthew Wilcox
(<willy@infradead.org>) rakstīja:
[...]
>
> I can't think of a way to solve that. We can't know whether a dying task
> "was going to" unlock a page. So we have a locked page in the page cache
> that nobody will ever unlock. We can't remove it, because we don't know
> that task died. We can't start I/O on it again, because it looks like
> I/O is already in progress.
>
> I think the only answer is "Don't ignore stack dumps in dmesg".
So looks like this is the conclusion of current state.
> We can't remove it, because we don't know that task died.
This seems pretty bad, maybe if there was build time option that
enables logging (eg. PID and lock time) for locked pages it could help
with debugging this and maybe allow even to force unlock. But then
again since there should be stack dump and I guess this is very rare
case of happening maybe it's not worth it.
prev parent reply other threads:[~2022-02-07 1:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-02 17:15 How to debug stuck read? Dāvis Mosāns
2022-02-02 19:13 ` Matthew Wilcox
2022-02-02 21:50 ` Dāvis Mosāns
2022-02-06 11:01 ` FMDF
2022-02-06 12:48 ` Matthew Wilcox
2022-02-06 21:22 ` FMDF
2022-02-06 23:21 ` Dāvis Mosāns
2022-02-06 23:49 ` Matthew Wilcox
2022-02-07 0:07 ` Dāvis Mosāns
2022-02-07 1:06 ` Matthew Wilcox
2022-02-07 1:22 ` Dāvis Mosāns [this message]
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=CAOE4rSy81hycALngZgCRj9vMR5rLU0Fq1F-g_N72bqvkVmpMsg@mail.gmail.com \
--to=davispuh@gmail.com \
--cc=fmdefrancesco@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).