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>] [day] [month] [year] [list]
Message-ID: <4FAA5F3F.8060906@ammonit.com>
Date:	Wed, 09 May 2012 14:12:47 +0200
From:	Steffen Kühn <sk@...onit.com>
To:	"ludovic.desroches" <ludovic.desroches@...el.com>
CC:	Chris Ball <cjb@...top.org>, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: [PATCH] mmc: atmel-mci: fix deadlock

Hi Ludovic,

my hardware is a multiprocessor system by which the access to the card
is shared between two processors. Because of this changes happen really
frequently.

I have observed that the deadlock only occurs when the card is
desappearing and there are errors like 'end_request: I/O error, dev
mmcblk0, sector XXX'. A process has to read permanently from the card.

The problem seems to be that the driver waits for finishing the
transfer, but this comes never because the card is unavailable. Maybe a
new state machine solves this in a better way as my workaround.

Regards
Steffen

Am 09.05.2012 12:45, schrieb ludovic.desroches:
> Hi Steffen,
> 
> Le 05/09/2012 11:23 AM, Steffen Kühn a écrit :
>> solves a deadlock problem which appears when a mmc card is
>> removing and a process is reading from the card at the same time.
>> ---
>>   drivers/mmc/host/atmel-mci.c |    4 +++-
>>   1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
>> index e94476b..effdc36 100644
>> --- a/drivers/mmc/host/atmel-mci.c
>> +++ b/drivers/mmc/host/atmel-mci.c
>> @@ -1499,8 +1499,10 @@ static void atmci_tasklet_func(unsigned long priv)
>> 			}
>>
>> 			if (!atmci_test_and_clear_pending(host,
>> -						EVENT_XFER_COMPLETE))
>> +						EVENT_XFER_COMPLETE)) {
>> +				host->stop_transfer(host);
>> 				break;
>> +            }
>>
>> 			atmci_set_completed(host, EVENT_XFER_COMPLETE);
>> 			prev_state = state = STATE_DATA_BUSY;
>> --
>> 1.7.2.5
> 
> Even if it solves your issue, I am not sure about the consequences of
> this fix even if it is working well in your case and with your hardware.
> 
> This condition allows to wait for the end of a transfer. The
> EVENT_XFER_COMPLETE flag is set when the dma transfer is complete (or pdc).
> If the transfer is not complete you will ask to stop it. I understand it
> could solve your issue but I am afraid it can also stop a transfer
> before its normal completion.
> 
> I am currently working on atmel-mci and the state machine would be
> changed.  So I prefer to wait the new atmel-mci version to take this
> patch. I will add your issue to my test cases.
> 
> 
> By the way, can you give me more details about your issue because I
> can't reproduce it on my side. If I remove the card while a process is
> reading from it, I also have I/O errors but I have no issue to detect a
> new card insertion.
> 
> 
> Regards
> 
> Ludovic
--
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