linux-kernel - Re: [PATCH v2] mm: oom_kill: add trace logs in process

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:   Mon, 19 Sep 2022 16:43:04 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Pratyush Brahma <quic_pbrahma@...cinc.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, quic_charante@...cinc.com,
        quic_pkondeti@...cinc.com
Subject: Re: [PATCH v2] mm: oom_kill: add trace logs in process_mrelease()
 system call

On Wed 17-08-22 12:17:22, Pratyush Brahma wrote:
> 
> On 17-08-2022 06:05, Andrew Morton wrote:
> > On Tue, 16 Aug 2022 11:30:17 +0530 Pratyush Brahma <pbrahma@....qualcomm.com> wrote:
> > 
> > > The process_mrelease() system call[1] is used to release the memory of
> > > a dying process from the context of the caller, which is similar to and
> > > uses the functions of the oom reaper logic. There exists trace logs for
> > > a process when reaped by the oom reaper. Just extend the same to when
> > > done by the process_mrelease() system call.
> > Why?  Please describe in full detail the end-user value of this change.
> 
> This patch provides information on how much memory is freed from a process
> which is being reaped. Adding trace events in the process_mrelease() path when
> process is being reaped would enable more holistic debug as it happens in
> oom_reap_task_mm() currently.
> 
> This extends the debug functionality for the events as described in [1] to
> the process_mrelease() system call. Now the coverage of trace events is complete.

Yes this is all nice but why it is needed to extend process_mrelease to
be in par with the oom path? OOM path happens out of direct control of
while this is under direct control of the caller. So why do we need more
debugging data from the kernel? The information dumped by the tracing
can be queried already by other means and much more extensibly.
 
> [1]
> https://lore.kernel.org/all/20170530185231.GA13412@castle/T/#u

-- 
Michal Hocko
SUSE Labs