linux-kernel - Re: [PATCH] aio: Add memcg accounting of user used data

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

Date:   Wed, 6 Dec 2017 16:13:15 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     axboe@...nel.dk, bcrl@...ck.org, tj@...nel.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-aio@...ck.org, jmoyer@...hat.com
Subject: Re: [PATCH] aio: Add memcg accounting of user used data

On 06.12.2017 15:43, Michal Hocko wrote:
> On Wed 06-12-17 15:36:56, Kirill Tkhai wrote:
>> On 06.12.2017 15:23, Michal Hocko wrote:
>>> On Tue 05-12-17 13:00:54, Kirill Tkhai wrote:
>>> [...]
>>>> This meets the problem in case of many containers
>>>> are used on the hardware node. Since aio_max_nr is
>>>> a global limit, any container may occupy the whole
>>>> available aio requests, and to deprive others the
>>>> possibility to use aio at all. The situation may
>>>> happen because of evil intentions of the container's
>>>> user or because of the program error, when the user
>>>> makes this occasionally
>>>
>>> I am sorry to beat more on this but finally got around to
>>> http://lkml.kernel.org/r/17b22d53-ad3d-1ba8-854f-fc2a43d86c44@virtuozzo.com
>>> and read the above paragraph once again. I can see how accounting to
>>> a memcg helps to reduce the memory footprint but I fail to see how it
>>> helps the above scenario. Could you clarify wow you set up a limit to
>>> prevent anybody from DoSing other containers by depleting aio_max_nr?
>> The memcg limit allows to increase aio_max_nr and the accounting guarantees
>> container can't exceed the limit. You may configure the limit and aio_max_nr
>> in the way, all containers requests in sum never reach aio_max_nr.
> 
> So you are essentially saying that you make aio_max_nr unlimited and
> rely on the memory consumption tracking by memcg, right?

Yes, and this is just the way the rest of similar allocated memory
such as pipes, dcache or page cache are accounted in the kernel.

If there are worries about accounting of every submitted request,
it should not be a problem to account page aligned request number only
(i.e., every PAGE_SIZE/sizeof(struct aio_kiocb) requests).
But I'm not sure primitives like memcg_kmem_charge() are allowed
outside mm subsystem.

> Are there any
> downsides (e.g. clog the AIO subsytem)?

Any new functionality affects the subsystem, where it's used :)
Just because of new processor instructions, though not only.
AIO is not something special in this way. But people,
who are not interested in the accounting, may just turn it off,
and the performance will remain the same.

If you are interested in some special benchmark results I should
to execute, please, point the benchmark, and I'll public the results.

> Please make sure that all this in the changelog

OK