linux-kernel - Re: [PATCH 1/2 v2] MMC:Add support MMCIF for SuperH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <o2uaec7e5c31004292051yff981cebg3bd05e2684036ae4@mail.gmail.com>
Date:	Fri, 30 Apr 2010 12:51:37 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Yusuke Goda <yusuke.goda.sx@...esas.com>, ben@...adent.org.uk,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-sh@...r.kernel.org
Subject: Re: [PATCH 1/2 v2] MMC:Add support MMCIF for SuperH

Hi Andrew,

Thanks for your review!

On Wed, Apr 28, 2010 at 11:17 AM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Wed, 28 Apr 2010 14:06:08 +0900 Yusuke Goda <yusuke.goda.sx@...esas.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/