From: Jeff Garzik <jeff@garzik.org>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: hail-devel@vger.kernel.org
Subject: Re: [tabled patch] abstract out TCP-write code
Date: Thu, 23 Sep 2010 00:32:09 -0400 [thread overview]
Message-ID: <4C9AD849.8030404@garzik.org> (raw)
In-Reply-To: <20100922203741.48a2b8e6@lembas.zaitcev.lan>
On 09/22/2010 10:37 PM, Pete Zaitcev wrote:
> On Wed, 22 Sep 2010 21:26:13 -0400
> Jeff Garzik<jeff@garzik.org> wrote:
>
>>> So, we go a longer route and re-hook the list of completions
>>> to a per-server global instead of a client. The patch is straight-
>>> forward. The only thing we need to be careful is to make sure
>>> that no outstanding completions are left in the queue before
>>> freeing a client struct. This is ensured by force-running completions.
>
>> Looking at this change again, I don't see how this avoids
>> use-after-free. If completions exist after state change function leads
>> one to cli_evt_dispose() -> cli_free(), then cli_write_run_compl() still
>> calls cli_write_free() with the stale 'cli' pointer.
>
> We run completions before freeing in all cases. My patch was correct.
Logically, if completions are run before freeing in all cases, there is
no need to make write_compl_q global. That was a red herring, which by
side effect avoided the bug with the stale 'cli' pointer.
Jeff
next prev parent reply other threads:[~2010-09-23 4:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 0:09 [tabled patch] abstract out TCP-write code Jeff Garzik
2010-09-23 0:28 ` Pete Zaitcev
2010-09-23 1:26 ` Jeff Garzik
2010-09-23 2:37 ` Pete Zaitcev
2010-09-23 4:32 ` Jeff Garzik [this message]
2010-09-23 13:57 ` Pete Zaitcev
2010-09-23 15:28 ` Jim Meyering
2010-09-23 23:48 ` Jeff Garzik
2010-09-23 16:47 ` Jeff Garzik
2010-09-23 23:51 ` Jeff Garzik
2010-09-23 21:09 ` [tabled patch v2] " Jeff Garzik
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=4C9AD849.8030404@garzik.org \
--to=jeff@garzik.org \
--cc=hail-devel@vger.kernel.org \
--cc=zaitcev@redhat.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 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.