linux-kernel - Re: [PATCH] procfs/dmabuf: Add /proc/<pid>/task/<tid>/dmabuf

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:   Wed, 27 Jan 2021 12:08:50 +0100
From:   Christian König <christian.koenig@....com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Kalesh Singh <kaleshsingh@...gle.com>, surenb@...gle.com,
        minchan@...nel.org, gregkh@...uxfoundation.org, hridya@...gle.com,
        jannh@...gle.com, kernel-team@...roid.com,
        Alexey Dobriyan <adobriyan@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Alexey Gladkov <gladkov.alexey@...il.com>,
        Szabolcs Nagy <szabolcs.nagy@....com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        Michel Lespinasse <walken@...gle.com>,
        Bernd Edlinger <bernd.edlinger@...mail.de>,
        Andrei Vagin <avagin@...il.com>,
        Yafang Shao <laoar.shao@...il.com>, Hui Su <sh_def@....com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-media@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
        linux-api@...r.kernel.org
Subject: Re: [PATCH] procfs/dmabuf: Add /proc/<pid>/task/<tid>/dmabuf_fds

Am 27.01.21 um 12:02 schrieb Michal Hocko:
> On Wed 27-01-21 11:53:55, Christian König wrote:
> [...]
>> In general processes are currently not held accountable for memory they
>> reference through their file descriptors. DMA-buf is just one special case.
> True
>
>> In other words you can currently do something like this
>>
>> fd = memfd_create("test", 0);
>> while (1)
>>      write(fd, buf, 1024);
>>
>> and the OOM killer will terminate random processes, but never the one
>> holding the memfd reference.
> memfd is just shmem under cover, no? And that means that the memory gets
> accounted to MM_SHMEMPAGES. But you are right that this in its own
> doesn't help much if the fd is shared and the memory stays behind a
> killed victim.

I think so, yes. But I just tested this and it doesn't seem to work 
correctly.

When I run the few lines above the OOM killer starts to terminate 
processes, but since my small test program uses very very little memory 
basically everything else gets terminated (including X, desktop, sshd 
etc..) before it is terminated as well.

Regards,
Christian.

> But I do agree with you that there are resources which are bound to a
> process life time but the oom killer has no idea about those as they are
> not accounted on a per process level and/or oom_badness doesn't take
> them into consideration.