All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: Jens Axboe <axboe@kernel.dk>, Latchesar Ionkov <lucho@ionkov.net>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	linux-kernel@vger.kernel.org, Pengfei Xu <pengfei.xu@intel.com>,
	v9fs-developer@lists.sourceforge.net
Subject: Re: [V9fs-developer] [PATCH 0/5] Take 3 at async RPCs and no longer looping forever on signals
Date: Sun, 19 Mar 2023 20:53:46 +0900	[thread overview]
Message-ID: <ZBb3ynXntaom/0hg@codewreck.org> (raw)
In-Reply-To: <Y+ttlog6sth3vPHJ@codewreck.org>

It's been a while but I didn't forget...

Dominique Martinet wrote on Tue, Feb 14, 2023 at 08:16:38PM +0900:
> > Yes, apparently it tries to write dirty pages of the mapped file and keeps
> > hanging there [fs/9p/vfs_inode_dotl.c:586]:
> 
> Yeah, it'd help to get the trace of the thread actually trying to do the
> IO, if it still exists.
> I had some hangs in the check that there are no flush in flight at some
> point, and I thought I fixed that, but I can't really see anywhere else
> that'd start hanging with this... it'll be clearer if I can reproduce.

I couldn't reproduce this one, but manually inspecting
p9_client_wait_flush again I noticed the wait_event_interruptible was
waiting on req->flushed_req->wq but looking at req->status in the
condition; that was an error.
Also, we have a ref on req->flushed_req but not on req, so
req->flushed_req wasn't safe.

I've changed the code to add a variable directly on req->flushed_req and
use it consistently, I'm not sure that's the problem you ran into but it
might help.
It's been a while but do you remember if that hang was consistently
happening on shutdown, or was it a one time thing?

Either way, I'd appreciate if you could try my 9p-test branch again:
https://github.com/martinetd/linux/commits/9p-test


With that said, I expect that p9_client_wait_req will cause hangs on
broken servers.
If connection drops hopefully the reqs will just be marked as error and
free the thread, but I can see syzbot complaining about yet another
thread stuck.. Well it's interruptible at least, and bails out on
ERESTARTSYS.


> Anyway, I found another bug, just running ./configure on a random project
> (picked coreutils tarball) fails with interrupted system call ?!

That other bug was weird, I could reproduce it reliably until I rebooted
the host because of an unrelated nfs bug on the host, and after reboot I
couldn't reproduce anymore.
I'll chalk it down to buggy host/weird happenstance, but something to
watch for if random EINTR happen again :/

-- 
Dominique

  reply	other threads:[~2023-03-19 11:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-11  7:50 [PATCH 0/5] Take 3 at async RPCs and no longer looping forever on signals Dominique Martinet
2023-02-11  7:50 ` [PATCH 1/5] 9p/net: move code in preparation of async rpc Dominique Martinet
2023-02-13 17:46   ` Christian Schoenebeck
2023-02-11  7:50 ` [PATCH 2/5] 9p/net: share pooled receive buffers size exception in p9_tag_alloc Dominique Martinet
2023-02-13 18:06   ` Christian Schoenebeck
2023-02-11  7:50 ` [PATCH 3/5] 9p/net: implement asynchronous rpc skeleton Dominique Martinet
2023-02-11  7:50 ` [PATCH 4/5] 9p/net: add async clunk for retries Dominique Martinet
2023-02-11  7:50 ` [PATCH 5/5] 9p/net: make flush asynchronous Dominique Martinet
2023-02-11  8:05 ` [PATCH 0/5] Take 3 at async RPCs and no longer looping forever on signals Dominique Martinet
2023-02-13 18:26 ` Christian Schoenebeck
2023-02-13 18:45   ` Christian Schoenebeck
2023-02-13 22:37     ` Dominique Martinet
2023-02-14  9:34       ` Christian Schoenebeck
2023-02-14 11:16         ` Dominique Martinet
2023-03-19 11:53           ` Dominique Martinet [this message]
2023-03-23 15:58             ` [V9fs-developer] " Christian Schoenebeck
2023-03-25 12:45               ` Christian Schoenebeck

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=ZBb3ynXntaom/0hg@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=axboe@kernel.dk \
    --cc=ericvh@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=pengfei.xu@intel.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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 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.