From: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
To: Eli Cohen <eli-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
Cc: Linux RDMA list
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
ewg <ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org>
Subject: Re: [ewg] [PATCH] IPoIB: synchronize timer deletion with completion handler
Date: Wed, 09 Dec 2009 14:39:49 -0800 [thread overview]
Message-ID: <adapr6npya2.fsf@roland-alpha.cisco.com> (raw)
In-Reply-To: <20091207172210.GA8441@mtls03> (Eli Cohen's message of "Mon, 7 Dec 2009 19:22:10 +0200")
> When calling del_timer_sync on priv->poll_timer, it is necessary to prevent
> farther arming of the timer which can be done by a completion handler. Though
> it is harmless since the timer will eventually stop being rearmed, it is better
> practice to avoid calling the timer function after it is deleted. This patch
> handles this by using a new flag that is checked before arming the timer.
have you seen this in practice? If it can happen then it's not
harmless, since the module could be unloaded with the timer pending.
However I don't see how it could happen, since we only seem to delete
the timer after we know that no more completions are coming (except for
the case where we decide that the hardware is wedged but it really only
takes a *long* time to respond at exactly the wrong time, and we somehow
get a completion between the del_timer_sync and the modify QP to reset
state -- which is so unlikely it seems not worth adding this extra
complexity for -- maybe we could add the del_timer_sync to after we
delete the CQ or something if you're really worried)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-12-09 22:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 17:22 [PATCH] IPoIB: synchronize timer deletion with completion handler Eli Cohen
2009-12-09 22:39 ` Roland Dreier [this message]
[not found] ` <adapr6npya2.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2009-12-10 11:37 ` Eli Cohen
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=adapr6npya2.fsf@roland-alpha.cisco.com \
--to=rdreier-fyb4gu1cfyuavxtiumwx3w@public.gmane.org \
--cc=eli-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org \
--cc=ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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