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: <7dd33165-4fb9-a424-9b5e-08c69583c979@amd.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ