From: Tony Battersby <tonyb@cybernetics.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: James.Bottomley@HansenPartnership.com,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
dgilbert@interlog.com, hch@infradead.org,
linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/2] sg: fix races during device removal (v5)
Date: Wed, 21 Jan 2009 14:23:10 -0500 [thread overview]
Message-ID: <4977761E.3050705@cybernetics.com> (raw)
In-Reply-To: <497768B3.3050506@s5r6.in-berlin.de>
Stefan Richter wrote:
> Tony Battersby wrote:
>
>> I think BUG_ON is
>> the best way to go for this instead of printk/return because bugs
>> will be noticed and fixed instead of possibly going unnoticed.
>>
> ...
>
>> static void sg_rq_end_io(struct request *rq, int uptodate)
>> {
>>
> ...
>
>> + int result, resid, done = 1;
>> +
>> + BUG_ON(srp->done != 0);
>>
>
> AFAIU this is typically called in atomic context. If so, WARN_ON is
> preferred.
>
>
Good point. I think the following would be the best way then:
if (WARN_ON(srp->done != 0))
return;
> ...
>
>> + BUG_ON(sfp == NULL);
>> +
>> + sdp = sfp->parentdp;
>>
>
> This would bring up a NULL pointer dereference dump anyway.
>
Yes, and that would have the same problem as BUG_ON by killing the
machine. So I think WARN_ON()/return works best for this too.
Tony
next prev parent reply other threads:[~2009-01-21 19:23 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-05 19:07 [PATCH 0/2] sg: fix races during device removal (v2) Tony Battersby
2009-01-08 23:21 ` Douglas Gilbert
2009-01-10 17:26 ` FUJITA Tomonori
2009-01-12 21:09 ` Tony Battersby
2009-01-13 16:24 ` FUJITA Tomonori
2009-01-14 20:31 ` Tony Battersby
2009-01-14 21:39 ` Greg KH
2009-01-14 21:59 ` Tony Battersby
2009-01-14 22:33 ` Stefan Richter
2009-01-14 22:53 ` Tony Battersby
2009-01-14 23:47 ` Stefan Richter
2009-01-15 14:47 ` Tony Battersby
2009-01-15 16:22 ` Stefan Richter
2009-01-15 16:44 ` Stefan Richter
2009-01-15 18:17 ` Tony Battersby
2009-01-15 18:47 ` Stefan Richter
2009-01-15 19:14 ` Stefan Richter
2009-01-15 19:20 ` Tony Battersby
2009-01-15 20:43 ` Stefan Richter
2009-01-15 21:43 ` Tony Battersby
2009-01-15 21:58 ` Stefan Richter
2009-01-15 22:23 ` Tony Battersby
2009-01-15 23:24 ` Stefan Richter
2009-01-16 14:16 ` Tony Battersby
2009-01-16 0:53 ` Stefan Richter
2009-01-16 8:09 ` Stefan Richter
2009-01-19 6:57 ` FUJITA Tomonori
2009-01-19 15:02 ` Tony Battersby
2009-01-19 23:03 ` [PATCH 1/2] sg: fix races during device removal (v4) Tony Battersby
2009-01-20 1:06 ` FUJITA Tomonori
2009-01-20 21:58 ` [PATCH 1/2] sg: fix races during device removal (v5) Tony Battersby
2009-01-21 18:25 ` Stefan Richter
2009-01-21 19:23 ` Tony Battersby [this message]
2009-01-21 19:45 ` [PATCH 1/2] sg: fix races during device removal (v6) Tony Battersby
2009-01-25 12:46 ` FUJITA Tomonori
2009-01-26 13:57 ` Douglas Gilbert
2009-01-28 1:51 ` FUJITA Tomonori
2009-01-28 15:06 ` James Bottomley
2009-01-20 22:00 ` [PATCH 2/2] sg: fix races with ioctl(SG_IO) (v2) Tony Battersby
2009-01-25 12:46 ` FUJITA Tomonori
2009-01-19 23:06 ` [PATCH 2/2] sg: fix races with ioctl(SG_IO) Tony Battersby
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=4977761E.3050705@cybernetics.com \
--to=tonyb@cybernetics.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dgilbert@interlog.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
/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