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]
Message-ID: <af62a2c2-3c01-408d-b694-aa7e95d23c18@suse.cz>
Date: Wed, 17 Sep 2025 09:38:43 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Suren Baghdasaryan <surenb@...gle.com>,
 Usama Arif <usamaarif642@...il.com>
Cc: akpm@...ux-foundation.org, kent.overstreet@...ux.dev, hannes@...xchg.org,
 rientjes@...gle.com, roman.gushchin@...ux.dev, harry.yoo@...cle.com,
 shakeel.butt@...ux.dev, 00107082@....com, pyyjason@...il.com,
 pasha.tatashin@...een.com, souravpanda@...gle.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] alloc_tag: mark inaccurate allocation counters in
 /proc/allocinfo output

On 9/17/25 00:26, Suren Baghdasaryan wrote:
> On Tue, Sep 16, 2025 at 9:52 PM Usama Arif <usamaarif642@...il.com> wrote:
> 
> Hmm. Missing a large allocation and not knowing about it can be a problem...
> I'll start sketching a patch to see if tracking such a global counter
> has any drawbacks and in the meantime I'm open to suggestions on how
> to expose it to the userspace.

Could it be made to look like an actual tag in the output?
e.g. lib/alloc_tag.c:1234 func:untracked_slab_objects

(probably some better name conveying it's uknown due to failure to allocate
objexts)

Maybe even implemented in a way that it's not a specially crafted output line.

> About concerns on the IOCTL interface, would it be more usable if we
> get the alloctop [1] or a similar tool which can be used to easily
> issue such commands into kernel/tools?
> 
> [1] https://android-review.git.corp.google.com/c/platform/system/memory/libmeminfo/+/3431860
> 
>>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ