linux-kernel - Re: [PATCH] fs/proc: introduce /proc/stat2 file

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: <20181029212314.nwruqg6au23ebqlu@shells.gnugeneration.com>
Date:   Mon, 29 Oct 2018 14:23:14 -0700
From:   Vito Caputo <vcaputo@...garu.com>
To:     Waiman Long <longman@...hat.com>
Cc:     Davidlohr Bueso <dave@...olabs.net>, akpm@...ux-foundation.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH] fs/proc: introduce /proc/stat2 file

On Mon, Oct 29, 2018 at 04:59:03PM -0400, Waiman Long wrote:
> On 10/29/2018 04:38 PM, Davidlohr Bueso wrote:
> > On Mon, 29 Oct 2018, Waiman Long wrote:
> >
> >> BTW, since you are making stat2 compatible with stat, will that be
> >> easier from the user API perspective if we use a sysctl parameter to
> >> turn on and off IRQs reporting for /proc/stat, for example?
> >
> > For one /proc/stat is also common for debugging envs (ie: performance)
> > and I fear that if a tunnable modifies the behavior of the output, we
> > it might never be usable again (at least not without having users also
> > now consider the systctl parameter). Making it dynamic I think is not
> > worth it.
> >
> > Thanks,
> > Davidlohr
> 
> This is just a matter if it is easier for users to modify their code to
> use /proc/stat2 or turning on a sysctl parameter. Again, this will
> certainly depend on the circumstances.
> 

I wonder if it makes sense to introduce a more general mechanism for
toggling subfields in proc files.  Extended attributes could probably be
abused to key the subfields, write a 1 or 0 to well-known names for
toggling them on a per-fd basis via fsetxattr.

For this particular case the program would just have to add code like:

int	zero = 0;
fsetxattr(proc_stat_fd, "intr", &zero, sizeof(zero), XATTR_REPLACE);

Just putting it out there.  I've certainly wanted an ability to noop
fields before where I was polling proc frequently and skipping the bulk
of what was there but syscpu was still rather high.

I'm definitely not in favor of just adding another stat file that is the
same format as the existing one with the intrs zeroed out.  It's a dirty
hack; fine for your local needs but too gross for upstream IMHO.

Regards,
Vito Caputo