linux-kernel - Re: [PATCH v3] dma-buf/heaps: system

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: <ZDarxo2Q4cgFHdbh@dhcp22.suse.cz>
Date:   Wed, 12 Apr 2023 15:01:58 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Jaewon Kim <jaewon31.kim@...sung.com>
Cc:     "jstultz@...gle.com" <jstultz@...gle.com>,
        "tjmercier@...gle.com" <tjmercier@...gle.com>,
        "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
        "daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jaewon31.kim@...il.com" <jaewon31.kim@...il.com>
Subject: Re: [PATCH v3] dma-buf/heaps: system_heap: avoid too much allocation

On Wed 12-04-23 21:35:32, Jaewon Kim wrote:
> >On Wed 12-04-23 20:37:59, Jaewon Kim wrote:
> >> Limiting dmabuf memory may be required. But I think there
> >> is no nice and reasonable way so far.
> >
> >If that is really the way then the patch doesn't really add a big
> >benefit. It doesn't really prevent OOMs (or panics due to OOM) as the
> >allocator still allows to consume arbitrary amount of memory. The
> >provided check is not able to tell between buggy and legit calls.
> >-- 
> >Michal Hocko
> >SUSE Labs
> 
> Yes it could be. Though the buggy call is blocked by totalram_pages check,

It seems our definitions of buggy differ here. I do not see much
difference between totalram_pages +- PAGE_SIZE (or any epsilon for that
matter). Both would put the system down to its knees without a way out
other than panic.

> mm may suffer memory shortage due to the huge memory consumption through
> dma-buf system heap. We just hope Android LMKD or oomk kills the memory
> hoggers prior to oom panic.

You seem to be missing an important point. If the global OOM killer is
not able to find a victim the LMKD or oomk are highly unlikely as well
(unless they ignore OOM_SCORE_ADJ_MIN).

> IMO if possible mm should be able to track the dma-buf size as stat in
> mm_rss_stat for each process.

I do remember some proposals from the past and IIRC the main problem was
how to attribute those buffers to the actual owner.

I believe I have give you some arguments to consider. The rest is up to
you. As I've said I do not have any stakes in dmabuf. The patch itself
is not actively harmful, it is just adding an illusion of a fix while it
doesn't give much.
-- 
Michal Hocko
SUSE Labs