From: "Jörn Engel" <joern@logfs.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>,
linux-kernel@vger.kernel.org,
target-devel <target-devel@vger.kernel.org>
Subject: Re: [PATCH v4] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race
Date: Tue, 19 Mar 2013 11:03:47 -0400 [thread overview]
Message-ID: <20130319150347.GA16558@logfs.org> (raw)
In-Reply-To: <20130319133852.GD24313@kroah.com>
On Tue, 19 March 2013 06:38:52 -0700, Greg Kroah-Hartman wrote:
> On Mon, Mar 18, 2013 at 11:58:03PM -0400, Jörn Engel wrote:
> >
> > It compiles. I don't have a good testcase, so the procedure is to
> > throw it into the test infrastructure and wait a week.
>
> Really? Please make a test cast to test it out properly.
So you are willing to reject a patch that clearly fixes a bug because
there is no testcase? And given that the bug is a race, any testcase
will still boil down to "run this for as long as it took to reproduce
the problem, then triple the time". I can reproduce the problem in
our test infrastructure maybe twice a week, so I could call that a
testcase just to provide you some formalistic argument to accept the
patch.
Of course the alternatives would be to stop using kref or to leave the
bug in. I really wish I wouldn't have to contemplate either of those.
> > The alternative would be to call local_irq_restore(flags); from
> > kref_put_spinlock_irqsave() and not pass the flags. Getting rid of
> > the extra parameter would be nice. But I'm not sure I want to prove
> > that
> > spin_unlock(lock);
> > local_irq_restore(flags);
> > is the same as
> > spin_unlock_irqrestore(lock, flags);
> > on all architectures and with all combinations of CONFIG options.
>
> It should be.
We agree then. I will change the patch and see how it behaves in our
setup.
Jörn
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan
next prev parent reply other threads:[~2013-03-19 16:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-18 22:28 [PATCH] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race Jörn Engel
2013-03-19 0:04 ` Greg Kroah-Hartman
2013-03-18 22:56 ` Jörn Engel
2013-03-19 0:27 ` Greg Kroah-Hartman
2013-03-18 23:11 ` [PATCH v2] " Jörn Engel
2013-03-18 23:34 ` [PATCH v3] " Jörn Engel
2013-03-19 1:53 ` Greg Kroah-Hartman
2013-03-19 3:31 ` [PATCH v4] " Jörn Engel
2013-03-19 5:09 ` Greg Kroah-Hartman
2013-03-19 3:58 ` Jörn Engel
2013-03-19 13:38 ` Greg Kroah-Hartman
2013-03-19 15:03 ` Jörn Engel [this message]
2013-03-19 2:11 ` [PATCH v3] " Nicholas A. Bellinger
2013-03-19 2:39 ` Greg Kroah-Hartman
2013-03-19 2:46 ` Nicholas A. Bellinger
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=20130319150347.GA16558@logfs.org \
--to=joern@logfs.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nab@linux-iscsi.org \
--cc=target-devel@vger.kernel.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