linux-kernel - Re: [SUGGESTION]: drop virtual merge accounting in I/O requests

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 21:19:44 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	mpatocka@...hat.com
Cc:	fujita.tomonori@....ntt.co.jp, 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

On Tue, 15 Jul 2008 08:09:53 -0400 (EDT)
Mikulas Patocka <mpatocka@...hat.com> wrote:

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

Are you talking about file system metadata corruption?

If your logic is correct, we hit the corruption every time a FC cable
(switch, or whatever) has a problem. Fortunately, we don't. modern
file systems can handle that.


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

Yeah, many of the old scsi drivers contatinas BUG_ON. They are not
likely to be used with IOMMUs. We don't care about them much. The
recent scsi drivers can handle this.
--
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/