From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63751C433EF for ; Mon, 10 Jan 2022 14:55:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7FDF6B0073; Mon, 10 Jan 2022 09:55:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D2F9C6B0074; Mon, 10 Jan 2022 09:55:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD1B16B0075; Mon, 10 Jan 2022 09:55:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id ADAC96B0073 for ; Mon, 10 Jan 2022 09:55:20 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6DFA98248D52 for ; Mon, 10 Jan 2022 14:55:20 +0000 (UTC) X-FDA: 79014675600.25.DEE9442 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf09.hostedemail.com (Postfix) with ESMTP id E47A6140008 for ; Mon, 10 Jan 2022 14:55:19 +0000 (UTC) Received: by mail-yb1-f178.google.com with SMTP id c6so36647065ybk.3 for ; Mon, 10 Jan 2022 06:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dEL+PwUNJ7VeDav8Vkg9ZEihg+obXr9BMf+UZGECSME=; b=WMmkNgc4gd0Com5/mH7FQrgGMn6uv9XH3VFL4H6JkCFziFz7n7vr/ThIe9LF7iNK9l x/F3Rhn09XlmkvucTt0lqtsAVsw6kcIhfJM8cSMpuafwVc6/YUgtVEDpTkuW+p6BmuJ6 MNdiXaNftD7MnCMfFz5Ft9Wi2jh22JspVyDpqb01naJBxK1LgGpMFKoeL011q/QHNzHp Bpm+ZhgRQHgDhGSzcAoX0EBCYfTY0hKWpI+vauCSKbvgQzwqp2CLOQMHgUAzAu/7lIE/ IDBx77XRa09Oq/cnWxyjiW/tzn6vwI/tsAkDH84Eu3UVwSER/dy8nFhvglkmxNK88QTn 1MsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dEL+PwUNJ7VeDav8Vkg9ZEihg+obXr9BMf+UZGECSME=; b=ioRbqgOxTej//P3LVa19S9K3VgbdzsjdbVQcEaAEFEyT+jsgn/1mHfjtecGDsBI5Zw vLeH+B5UkDHY/CQ5+wR8tAutLwOnQawOHnlKpIWsXZBx689mlRAiFl4slEW75UivoUYg i7V/GXFj1gDl84olR+zXep5rDH9sEk+qvxo6xVgbGshap52nqmuV1n1QcepNXUO6GXH3 Adchb9gvwvErAwLCiTHJTpub2BU7ZFis/EEHWHTz3fbUEhJ+4aJNVqy7saKH8DAx+R57 Vta4SXNhaMNxnDAe2gO89XWfMgWUF7ViHOviZwUJ3j+tk15s0GgAaq4oTmb/hyNKKMSz ZPAw== X-Gm-Message-State: AOAM531e2gMdTQa9c0+lFu6KvdrXVLyk9I1ODjD+N1rFHdUJRYNjvxMl cDByqjoyx4oik4SyxkFEol8mAz32G8ME+/XScUs= X-Google-Smtp-Source: ABdhPJycNKY8aWsJngqsCoXDYCvWAp/H3WkDOYKEoF7w0cRVsqvGaw4y822DqflQ0PMlIrF/yCHekML/FrBGNfrNq2E= X-Received: by 2002:a25:98c6:: with SMTP id m6mr4482853ybo.494.1641826519183; Mon, 10 Jan 2022 06:55:19 -0800 (PST) MIME-Version: 1.0 References: <1641483250-18839-1-git-send-email-quic_pintu@quicinc.com> <1641578854-14232-1-git-send-email-quic_pintu@quicinc.com> <19cce51e24584c2a8090b618c580a0bd@AcuMS.aculab.com> <5aa1e8c55cf84436b35ee5557a508e8d@AcuMS.aculab.com> In-Reply-To: <5aa1e8c55cf84436b35ee5557a508e8d@AcuMS.aculab.com> From: Pintu Agarwal Date: Mon, 10 Jan 2022 20:25:07 +0530 Message-ID: Subject: Re: [PATCH v2] sysinfo: include availram field in sysinfo struct To: David Laight Cc: Pintu Kumar , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "ebiederm@xmission.com" , "christian.brauner@ubuntu.com" , "sfr@canb.auug.org.au" , "legion@kernel.org" , "sashal@kernel.org" , "gorcunov@gmail.com" , "chris.hyser@oracle.com" , "ccross@google.com" , "pcc@google.com" , "dave@stgolabs.net" , "caoxiaofeng@yulong.com" , "david@redhat.com" , "vbabka@suse.cz" , "linux-api@vger.kernel.org" , "dhowells@redhat.com" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E47A6140008 X-Stat-Signature: 9r7su9a7p5jpb7tstso1gkw5qdgyjq6i Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WMmkNgc4; spf=pass (imf09.hostedemail.com: domain of pintu.ping@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=pintu.ping@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam10 X-HE-Tag: 1641826519-137966 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, 9 Jan 2022 at 04:05, David Laight wrote: > > From: Pintu Agarwal > > Sent: 08 January 2022 16:53 > > > > On Sat, 8 Jan 2022 at 03:52, David Laight wrote: > > > > > > From: Pintu Kumar > > > > Sent: 07 January 2022 18:08 > > > > > > > > The sysinfo member does not have any "available ram" field and > > > > the bufferram field is not much helpful either, to get a rough > > > > estimate of available ram needed for allocation. > > > > > > > > One needs to parse MemAvailable field separately from /proc/meminfo > > > > to get this info instead of directly getting if from sysinfo itself. > > > > > > > > Thus, this patch introduce a new field as availram in sysinfo > > > > so that all the info total/free/available can be retrieved from > > > > one place itself. > > > > > > > ... > > > > diff --git a/include/uapi/linux/sysinfo.h b/include/uapi/linux/sysinfo.h > > > > index 435d5c2..fe84c6a 100644 > > > > --- a/include/uapi/linux/sysinfo.h > > > > +++ b/include/uapi/linux/sysinfo.h > > > > @@ -19,7 +19,8 @@ struct sysinfo { > > > > __kernel_ulong_t totalhigh; /* Total high memory size */ > > > > __kernel_ulong_t freehigh; /* Available high memory size */ > > > > __u32 mem_unit; /* Memory unit size in bytes */ > > > > - char _f[20-2*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses this.. */ > > > > > > There are 4 pad bytes here on most 64bit architectures. > > > > > > > + __kernel_ulong_t availram; /* Memory available for allocation */ > > > > + char _f[20-3*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses this.. */ > > > > }; > > > > > > You've not compile-time tested the size of the structure. > > > > > With "32" instead of "20" in padding I get these size of sysinfo: > > In x86-64 kernel, with app 64-bit: Size of sysinfo = 128 > > In x86-64 kernel, with app 32-bit:: Size of sysinfo = 76 > > In arm-64 kernel, with app 32-bit: Size of sysinfo = 76 > > You need to compare the sizes before and after your patch > to ensure it doesn't change on any architecture. Without the changes: On 32-bit, the size of structure = 64 On 64-bit, the size of structure = 112 With the addition of my new field (availram) if I try to fix the size issue on one arch, the other arch gets disturbed. I could fix the same size issue on 64-bit with below changes: __kernel_ulong_t freeswap; /* swap space still available */ __u16 procs; /* Number of current processes */ __u16 pad; /* Explicit padding for m68k */ + __u32 mem_unit; /* Memory unit size in bytes */ ============> Move the mem_unit up to adjust the padding __kernel_ulong_t totalhigh; /* Total high memory size */ __kernel_ulong_t freehigh; /* Available high memory size */ - __u32 mem_unit; /* Memory unit size in bytes */ + __kernel_ulong_t availram; /* Memory available for allocation */ ========> Add the new field here - char _f[20-2*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses this.. */ + char _f[28-3*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses this.. */ ====> Increase the size to 28 (thus _f becomes 0 like original) + //char _f[4]; }; Output with 64-bit build: $ gcc test-sysinfo.c ; ./a.out Total RAM: 32715804 kB Free RAM: 1111296 kB Size of sysinfo = 112 Size of sysinfo uptime = 8 Size of sysinfo loads = 24 Size of sysinfo totalram = 8 Size of sysinfo pad = 2 Size of sysinfo memunit = 4 Size of sysinfo _f = 0 Output with 32-bit build: $ gcc test-sysinfo.c -m32 ; ./a.out Total RAM: 7987 kB Free RAM: 271 kB Size of sysinfo = 72 Size of sysinfo uptime = 4 Size of sysinfo loads = 12 Size of sysinfo totalram = 4 Size of sysinfo pad = 2 Size of sysinfo memunit = 4 Size of sysinfo _f = 12 Are there any more suggestions/ideas to experiment with padding changes before we give-up ? Can we handle it using : __arch64__ check ? Or, the only option is to add one more, say: sysinfo64 ? > > Okay the sys robot reported some issue in 64-bit build. > > {{{ > > >> include/uapi/linux/sysinfo.h:23:14: error: size of array '_f' is too large > > >> 23 | char _f[20-3*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses > > this.. */ > > >> | ^~ > > }}} > > > > Also, I got the same issue while building for arm64, so I tried to > > adjust like this: > > char _f[32-3*sizeof(__kernel_ulong_t)-sizeof(__u32)]; > > > > With this the build works on both 32/64 but output fails when running > > 32-bit program on 64-bit kernel. > > Also, the free command on 64-bit reports "stack smashing error".. > > > > How do we resolve this issue to make it work on both arch ? > > Also, I don't really understand the significance of that number "20" > > in padding ? > > My guess is that someone added a char _f[20] pad to allow for expansion. > Then two __kernel_ulong_t and one __u32 field were added, so the > size of the pad was reduced. > When __kernel_ulong_t is 64bit then it seems to be char _f[0] > - which might generate a compile warning since you are supposed > to use char _f[] to indicate an extensible structure. > There is, however, 4 bytes of pad after the _f[] on most 64bit > architectures. > Thanks, yes even I guessed the same. > So actually there isn't enough space to anything useful at all. > Is this problem does not exist in other UAPI structures ? Seems like nothing can be done to allow future expansion without breaking existing things and without developing the new one. Thanks, Pintu