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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 20 Sep 2011 14:58:52 +0530
From:	Murali Krishna Palnati <palnati.muralikrishna@...il.com>
To:	Ulf Hansson <ulf.hansson@...ricsson.com>
Cc:	Namjae Jeon <linkinjeon@...il.com>,
	"cjb@...top.org" <cjb@...top.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mmc : Use wait_for_completion_timeout() instead of
 wait_for_completion in case of write.

On Tue, Sep 20, 2011 at 1:09 PM, Ulf Hansson <ulf.hansson@...ricsson.com> wrote:
>
> Namjae Jeon wrote:
>>
>> host controller can not rise timeout interrupt in write not read in DMA status. because host can just know whether card is finish to program to use busy line. If unstable card is keep holding busy line while writing using DMA.
>> hang problem happen by wait_for_completion. so I think that mmc driver need some exception to avoid this problem.
>> I suggest to use wait_for_completion_timeout instead of wait_for_completion.
>>
>
> I see what you are trying to solve, but you can never calculate the timeout for this type of operation in such a way. Your timeout involves the entire data write operation, how can you ever know how long this will take?
>
> I think a much better approach is to make you host driver not using "busy signaling" (if that is possible), thus when the DMA job is done call mmc_request_done to finalize the data transfer. The mmc framework will then send a CMD13 (SEND_STATUS) to make sure the data is written before issuing the next request.
>
> BR
> Ulf Hansson


To add to what Hansson mentioned, the timeout mechanism should not be
implemented at the MMC core layer. If the core layer simply times out
like this, the host controller driver still remains in the same state
which is not right. If such a timeout mechanism is needed, it is best
to implement in the host controller driver layer and inform the core
layer by calling mmc_request_done() when the time out happens. This
will also give a chance to the host controller driver to do any
required clean up at the controller layer so that it is in a known
good state to handle further requests from the core layer.

Regards,
Murali Krishna
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ