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, 15 Jul 2008 08:09:53 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
cc:	davem@...emloft.net, andi@...stfloor.org,
	sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
	jens.axboe@...cle.com
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests

>> BTW. what should the block device driver do when it receives a mapping
>> error? (if it aborts the request and it was write request, there will be
>> data corruption).
>
> I'm not sure how a aborted request can corrupt data on disk.

Writes are done by an async daemon and no one checks for their completion 
status. If there are three writes to directory, inode table and inode 
bitmap and one of these writes fail, there's no code to undo the other 
two. So the filesystem will be corrupted on write failure.

>> Is it even legal to return IOMMU error in case where no
>> real hardware error or overflow happened?
>
> Of course, it's legal. It's a common event like kinda OOM. It's very
> possible with old IOMMUs that have the small I/O space. A SCSI driver
> retries a failed request later. But note that some drivers are still
> not able to handle that.
>
> http://marc.info/?l=linux-kernel&m=121300637114672&w=2

So should it return SCSI_MLQUEUE_HOST_BUSY? Or something other?

Unfortunatelly, many of the drivers contain BUG_ON or no check at all.

Mikulas
--
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