Prev: PM: suspend_block: Abort task freezing if a suspend_blocker is active.
Next: drivers/staging/dt3155: Integrate 3 badly styled files into 1 clean file
From: Andrew Morton on 28 Apr 2010 01:20
On Wed, 28 Apr 2010 14:06:08 +0900 Yusuke Goda <yusuke.goda.sx(a)renesas.com> wrote:

> + time = wait_event_interruptible_timeout(host->intr_wait,
> + host->wait_int == 1 ||
> + host->sd_error == 1, host->timeout);
> + if (host->wait_int != 1 && (time == 0 || host->sd_error != 0))
> + return sh_mmcif_error_manage(host);

wait_event_interruptible_timeout() will return early with -ERESTARTSYS
if the calling process gets signalled (eg, ^C was hit).

The driver uses wait_event_interruptible_timeout() rather a lot and the
two sites I looked at seem to handle the signal_pending() case
correctly.

But incorrectly handling signals with interruptible waits is a
frequently-occurring error in drivers. Did you deliberately cater for
this case, and have you runtime tested it?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Magnus Damm on 30 Apr 2010 13:10
Hi Andrew,

Thanks for your review!

On Wed, Apr 28, 2010 at 11:17 AM, Andrew Morton
<akpm(a)linux-foundation.org> wrote:
> On Wed, 28 Apr 2010 14:06:08 +0900 Yusuke Goda <yusuke.goda.sx(a)renesas.com> wrote:
>
>> + � � time = wait_event_interruptible_timeout(host->intr_wait,
>> + � � � � � � � � � � host->wait_int == 1 ||
>> + � � � � � � � � � � host->sd_error == 1, host->timeout);
>> + � � if (host->wait_int != 1 && (time == 0 || host->sd_error != 0))
>> + � � � � � � return sh_mmcif_error_manage(host);
>
> wait_event_interruptible_timeout() will return early with -ERESTARTSYS
> if the calling process gets signalled (eg, ^C was hit).
>
> The driver uses wait_event_interruptible_timeout() rather a lot and the
> two sites I looked at seem to handle the signal_pending() case
> correctly.
>
> But incorrectly handling signals with interruptible waits is a
> frequently-occurring error in drivers. �Did you deliberately cater for
> this case, and have you runtime tested it?

My plan is to use this driver on SH-Mobile ARM (sh7372), and I'd be
happy to fix up the driver to become a bit less non-standard wrt
blocking compared to the other MMC host drivers. Is it possible that
Goda-san fixes up whatever minor bits that need rework and that you
pick up at that point?

I'd like to rework the MMCIF blocking code and perhaps also add
dmaengine support as feature patches on top of Goda-sans work if
that's ok with you. Better PM is also on the TODO. Not sure if any of
these features will make it in time for the 2.6.35 merge window
though.

It would be very useful to have the MMCIF driver as-is in 2.6.35
mainline to begin with if possible. Or do you think the driver needs
to be reworked more before that can happen?

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: PM: suspend_block: Abort task freezing if a suspend_blocker is active.
Next: drivers/staging/dt3155: Integrate 3 badly styled files into 1 clean file