linux-kernel - Re: Device loses barrier support (was: Fixed patch for simple barriers.)

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-next>] [day] [month] [year] [list]

Message-Id: <E1L8fIY-0001ui-DV@be1.7eggert.dyndns.org>
Date:	Fri, 05 Dec 2008 19:21:06 +0100
From:	Bodo Eggert <7eggert@....de>
To:	Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andi Kleen <andi@...stfloor.org>,
	Mikulas Patocka <mpatocka@...hat.com>,
	linux-kernel@...r.kernel.org, xfs@....sgi.com,
	Alasdair G Kergon <agk@...hat.com>,
	Andi Kleen <andi-suse@...stfloor.org>,
	Milan Broz <mbroz@...hat.com>
Subject: Re: Device loses barrier support (was: Fixed patch for simple barriers.)

Andi Kleen <andi@...stfloor.org> wrote:

>> Not when the fundamental design of the code is broken and trashes
>> performance.
> 
> Sorry but that's just not correct. There's nothing in late failing
> barriers that "trashes performance". The file system writers have 
> to be careful to handle it, but at least the current ones all do.

So let's keep requiring the "trashes performance" hacks, because they're
not directly in the barriers code? Hey, we nailed one foot to the ground,
and since it's not the nail's fault, let's do the same to the other foot?
It does not matter, since we can't move around right now, so it's a pretty
neat idea, isn't it?

> And also if someone writes a hypothetical fully asynchronously driven
> barrier based IO transaction system it would be still possible to handle
> the late failing barrier without too many complications.

You can just replace barriers with NOPs without too many complications,
because it only matters in cases of system failure. And even then,
it's only the difference between having a filesystem corruption and not
having it ... Who'd care?

> Also late failing barriers is pretty much the only sane way to implement
> barriers in software remapping schemes like DM and MD.

No, and seeing the same resubmit logic in more than one place should give
you the clue, even if you don't grasp that intermixing requests which
explicitely MUST NOT be intermixed is wrong.

The sane way is having a software barrier in DM and MD, going back to
sync if the new hardware does not support barriers in hardware. The
filesystems should not even need to know if barriers are supported, 
just use them and they'll DTRT in any case. Any other interface is
worse than useless.

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