linux-kernel - Re: [PATCH v2] sysinfo: include availram field in sysinfo struct

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]

Date:   Mon, 10 Jan 2022 11:11:21 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Pintu Agarwal <pintu.ping@...il.com>
Cc:     Pintu Kumar <quic_pintu@...cinc.com>,
        open list <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-mm <linux-mm@...ck.org>, ebiederm@...ssion.com,
        Christian Brauner <christian.brauner@...ntu.com>,
        sfr@...b.auug.org.au, legion@...nel.org, sashal@...nel.org,
        chris.hyser@...cle.com, Colin Cross <ccross@...gle.com>,
        Peter Collingbourne <pcc@...gle.com>, dave@...olabs.net,
        caoxiaofeng@...ong.com, david@...hat.com,
        Vlastimil Babka <vbabka@...e.cz>, linux-api@...r.kernel.org
Subject: Re: [PATCH v2] sysinfo: include availram field in sysinfo struct

On Sat, Jan 08, 2022 at 09:54:37PM +0530, Pintu Agarwal wrote:
> Thank you so much for your feedback...
> I had a need to get total/free/available memory in my application (on
> a memory constraint system).
> First I tried to parse these from /proc/meminfo but then I saw sysinfo
> already provides some information,
> however available field was missing. Just to get available field I
> need to again do all the file operations.
> 
> Then I saw, even the "free" command doing this redundant work.
> Use sysinfo system call to get "total" and "free" memory then again
> get "available" memory from /proc/meminfo.
> Yet again, I see, even in kernel its reading from two different places
> while populating the /proc/meminfo.
> Also, I am sure there are plenty of other applications where this can
> be improved with this.
> Moreover, I think with this field there is not much use of other ram
> fields in sysinfo.
> Thus I felt a need to introduce this field to ease some operations.

Thanks for explanation.

> 
> > Don't get me wrong please but such extension really need a strong
> > justification because they are part of UAPI and there is not that much
> > space left in sysinfo structure. We will _have_ to live with this new
> > field forever so I propose to not introduce anything new here until
> > we have no other choise or parsing meminfo become a really bottleneck.
> >
> My guess is that this situation might exist in other places as well ?
> How do we handle new field addition to existing system calls ?

If there is no space left in uapi structures then we simply can't extend
the syscall, since we're not allowed to break api. an option is to deprecate
old interface and introduce a new one but this is a painfull procedure that's
why i'm not convinced that we should extend sysinfo right now. but final
decision is up to mantainers of course.