From: Dominique Martinet <asmadeus@codewreck.org>
To: Tomas Bortoli <tomasbortoli@gmail.com>
Cc: lucho@ionkov.net, Dominique Martinet <dominique.martinet@cea.fr>,
ericvh@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, syzkaller@googlegroups.com,
v9fs-developer@lists.sourceforge.net, rminnich@sandia.gov,
davem@davemloft.net
Subject: Re: [V9fs-developer] [PATCH v2 2/2] 9p: Add refcount to p9_req_t
Date: Wed, 29 Aug 2018 06:43:16 +0200 [thread overview]
Message-ID: <20180829044316.GA11169@nautica> (raw)
In-Reply-To: <20180827230954.GA21513@nautica>
Dominique Martinet wrote on Tue, Aug 28, 2018:
> I think I've found why (see below), so I'll push a fixed version after
> some more testing and another thorough read -- at some point today, but
> this hasn't been 'approved' explicitely so please review! :)
While the issue I pointed at was real, it wasn't what was causing the
refcount leak I was observing -- the problem is that we didn't drop a
ref when the request was successfully cancelled (e.g. the reply to the
flush came and the original request didn't get replied to)
The reason for this was that there were multiple versions of the patch
which alternated between doing the put in client.c after the cancelled
callback inconditionally, and doing the put in each transport's
cancelled() function, but virtio does not have this callback so that
didn't get added in the final version (codeveloping is hard); so I've
added an else() close to just issue a put if there is no callback.
(In the end, it felt better to have the req_put in the transport because
trans_fd is making refcounting difficult with its list handling, and
separating the put from the list removal would be more confusing than is
gained by sharing code)
Anyway, that's starting to be quite different from the v2 so I'll send a
v3 keeping Tomas as the author -- please check my edits are alright with
you, Tomas.
Meanwhile I'll keep running tests, I'm now confident about virtio but
want to spend more time on other transports again, so delaying the push
to linux-next for a few more days...
--
Dominique
prev parent reply other threads:[~2018-08-29 4:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-14 17:43 [PATCH v2 1/2] WIP: 9p: rename p9_free_req() function Tomas Bortoli
2018-08-14 17:43 ` [PATCH v2 2/2] 9p: Add refcount to p9_req_t Tomas Bortoli
2018-08-27 23:09 ` Dominique Martinet
2018-08-28 1:07 ` [V9fs-developer] " piaojun
2018-08-28 1:57 ` Dominique Martinet
2018-08-29 4:43 ` Dominique Martinet [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=20180829044316.GA11169@nautica \
--to=asmadeus@codewreck.org \
--cc=davem@davemloft.net \
--cc=dominique.martinet@cea.fr \
--cc=ericvh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=rminnich@sandia.gov \
--cc=syzkaller@googlegroups.com \
--cc=tomasbortoli@gmail.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 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).