From: Jiri Slaby <jirislaby@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, scameron@beardog.cce.hp.com,
James.Bottomley@HansenPartnership.com, achiang@hp.com,
jens.axboe@oracle.com, mikem@beardog.cce.hp.com
Subject: Re: + hpsa-use-msleep-instead-of-schedule_timeout.patch added to -mm tree
Date: Wed, 09 Dec 2009 10:51:32 +0100 [thread overview]
Message-ID: <4B1F7324.9000402@gmail.com> (raw)
In-Reply-To: <20091208144419.af6298ba.akpm@linux-foundation.org>
On 12/08/2009 11:44 PM, Andrew Morton wrote:
> On Tue, 08 Dec 2009 23:25:05 +0100
> Jiri Slaby <jirislaby@gmail.com> wrote:
>
>> On 12/08/2009 11:04 PM, akpm@linux-foundation.org wrote:
>>> Subject: hpsa: use msleep() instead of schedule_timeout
>>> From: Stephen M. Cameron <scameron@beardog.cce.hp.com>
>>>
>>> Use msleep() instead of schedule_timeout
>>
>> The patch does more than that and moreover in a wrong manner, see below.
>>
>>> @@ -3262,8 +3262,8 @@ static int hpsa_pci_init(struct ctlr_inf
>>> if (!(readl(h->vaddr + SA5_DOORBELL) & CFGTBL_ChangeReq))
>>> break;
>>> /* delay and try again */
>>> - set_current_state(TASK_INTERRUPTIBLE);
>>> - schedule_timeout(10);
>>> + set_current_state(TASK_UNINTERRUPTIBLE);
>>> + msleep(10);
>>
>> Why do you change interruptible sleep to uninterruptible?
>
> Stealth bugfix ;)
>
> If the calling process (called "modprobe") has signal_pending()
> (someone ^C'ed it) then the TASK_INTERRUPTIBLE sleep will be a no-op
> and the driver will probably go and screw things up.
Ok, then it should have been in the changelog. The changelog was just
"Use msleep() instead of schedule_timeout". Apart it doesn't mention why
it is changed (it might be obvious for some that it's a cleanup), it
doesn't do merely that.
>>> diff -puN drivers/scsi/hpsa.h~hpsa-use-msleep-instead-of-schedule_timeout drivers/scsi/hpsa.h
>>> --- a/drivers/scsi/hpsa.h~hpsa-use-msleep-instead-of-schedule_timeout
>>> +++ a/drivers/scsi/hpsa.h
>> ...
>>> @@ -139,7 +139,7 @@ struct ctlr_info {
>>> #define HPSA_BOARD_READY_ITERATIONS \
>>> ((HPSA_BOARD_READY_WAIT_SECS * 1000) / \
>>> HPSA_BOARD_READY_POLL_INTERVAL_MSECS)
>>> -#define HPSA_POST_RESET_PAUSE (30 * HZ)
>>> +#define HPSA_POST_RESET_PAUSE_MSECS (3000)
>>
>> Ehm?
>
> 30 seconds would have sucked anyway ;)
Might be. But again, then it should be explained in the changelog. And
as this is totally separate thing, also in a separate patch.
At least I though this is the politics.
thanks,
--
js
next prev parent reply other threads:[~2009-12-09 9:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-08 22:04 + hpsa-use-msleep-instead-of-schedule_timeout.patch added to -mm tree akpm
2009-12-08 22:25 ` Jiri Slaby
2009-12-08 22:26 ` Jiri Slaby
2009-12-08 22:43 ` scameron
2009-12-08 22:44 ` Andrew Morton
2009-12-09 9:51 ` Jiri Slaby [this message]
2009-12-09 15:37 ` scameron
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=4B1F7324.9000402@gmail.com \
--to=jirislaby@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=achiang@hp.com \
--cc=akpm@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikem@beardog.cce.hp.com \
--cc=scameron@beardog.cce.hp.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.