linux-kernel - Re: Local DoS through write heavy I/O on CFQ & Deadline

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]

Message-ID: <97166AE58C26A44D45569412@nimrod.local>
Date:	Sat, 13 Oct 2012 20:33:27 +0100
From:	Alex Bligh <alex@...x.org.uk>
To:	Hillf Danton <dhillf@...il.com>
cc:	LKML <linux-kernel@...r.kernel.org>, Alex Bligh <alex@...x.org.uk>
Subject: Re: Local DoS through write heavy I/O on CFQ & Deadline

--On 13 October 2012 21:53:09 +0800 Hillf Danton <dhillf@...il.com> wrote:

> Take a look at the "wait for writeback" problem please.
>
> 	Linux 3.0+ Disk performance problem - wrong pdflush behaviour
> 	https://lkml.org/lkml/2012/10/10/412

I'm guessing that's related but may not be the whole story. My
test case is rather simpler, and Viktor says that with the
patch causing his regression reverted, "After I've set the dirty_bytes
over the file size the writes are never blocked.". That suggests
to me that in order to avoid write blocking he needs dirty_bytes
larger than the file size. As the bytes written in my test case
exceed RAM, that's going to be be an issue as dirty_bytes is always
going to be hit; I think it Viktor's case he is trying to avoid
it being hit at all.

Or perhaps I have the wrong end of the stick.

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