lkml.org 
[lkml]   [2024]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 13/35] lib: add allocation tagging support for memory allocation profiling
    On Fri, Feb 16, 2024 at 12:50 AM Vlastimil Babka <vbabka@suse.cz> wrote:
    >
    > On 2/13/24 23:38, Kees Cook wrote:
    > > On Tue, Feb 13, 2024 at 02:35:29PM -0800, Suren Baghdasaryan wrote:
    > >> On Tue, Feb 13, 2024 at 2:29 PM Darrick J. Wong <djwong@kernelorg> wrote:
    > >> >
    > >> > On Mon, Feb 12, 2024 at 05:01:19PM -0800, Suren Baghdasaryan wrote:
    > >> > > On Mon, Feb 12, 2024 at 2:40 PM Kees Cook <keescook@chromium.org> wrote:
    > >> > > >
    > >> > > > On Mon, Feb 12, 2024 at 01:38:59PM -0800, Suren Baghdasaryan wrote:
    > >> > > > > Introduce CONFIG_MEM_ALLOC_PROFILING which provides definitions to easily
    > >> > > > > instrument memory allocators. It registers an "alloc_tags" codetag type
    > >> > > > > with /proc/allocinfo interface to output allocation tag information when
    > >> > > >
    > >> > > > Please don't add anything new to the top-level /proc directory. This
    > >> > > > should likely live in /sys.
    > >> > >
    > >> > > Ack. I'll find a more appropriate place for it then.
    > >> > > It just seemed like such generic information which would belong next
    > >> > > to meminfo/zoneinfo and such...
    > >> >
    > >> > Save yourself a cycle of "rework the whole fs interface only to have
    > >> > someone else tell you no" and put it in debugfs, not sysfs. Wrangling
    > >> > with debugfs is easier than all the macro-happy sysfs stuff; you don't
    > >> > have to integrate with the "device" model; and there is no 'one value
    > >> > per file' rule.
    > >>
    > >> Thanks for the input. This file used to be in debugfs but reviewers
    > >> felt it belonged in /proc if it's to be used in production
    > >> environments. Some distros (like Android) disable debugfs in
    > >> production.
    > >
    > > FWIW, I agree debugfs is not right. If others feel it's right in /proc,
    > > I certainly won't NAK -- it's just been that we've traditionally been
    > > trying to avoid continuing to pollute the top-level /proc and instead
    > > associate new things with something in /sys.
    >
    > Sysfs is really a "one value per file" thing though. /proc might be ok for a
    > single overview file.

    I'm preparing v4 and will keep the file it under /proc for now unless
    there are strong objections.

    \
     
     \ /
      Last update: 2024-05-27 15:06    [W:2.775 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site