From: Christoph Rohland <cr@sap.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Erik Andersen <andersee@debian.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Patch] sysinfo compatibility
Date: 21 Aug 2001 19:30:04 +0200 [thread overview]
Message-ID: <m34rr12ueb.fsf@linux.local> (raw)
In-Reply-To: <Pine.LNX.4.21.0108211137340.1320-100000@localhost.localdomain>
Hi Hugh,
On Tue, 21 Aug 2001, Hugh Dickins wrote:
> On 21 Aug 2001, Christoph Rohland wrote:
>>
>> sysinfo does use a new mem_unit field if ram+swap > MAX_ULONG. That
>> breaks 2.2 compatibility for a lot machines.
>>
>> I think it is more resonable to use the mem_unit field only if one
>> of ram or swap is bigger than MAX_ULONG. (And 2.2 was only broken
>> in that case)
>
> It's arguable. When I went there a few months back, I was a little
> surprised by the way it adds ram+swap (it mistakenly added in more
> before) to make that decision; but concluded it was helping callers
> who might well go on to add ram+swap, and felt no overriding reason
> to change that. But you can certainly argue that's inappropriate
> for the kernel to do, that it should only guard the validity of
> the actual numbers it returns to the caller. No strong feelings.
I think it's not the kernels task to fix simple user space errors by
breaking compatibility.
And I have somewhat harder feelings since we get a lot of bug reports
that our installer only detects 0M RAM when running on a 2.4 machine
while it works with the 2.2 kernel. We are talking about an ABI which
is directly imported into user space programs.
>> The appended patch implements that (and makes the logic a little
>> bit easier)
>
> Alan, please don't apply. The patch made the logic a lot easier,
> but sadly wrong: try what happens to totalswap 0x00120000 with
> mem_unit 0x1000 - wrong decision since 0x20000000 > 0x00120000.
Uh, oh. Try this one instead:
Greetings
Christoph
--- 8-ac8/kernel/info.c Tue Aug 21 09:54:02 2001
+++ u8-ac8/kernel/info.c Tue Aug 21 13:51:42 2001
@@ -16,6 +16,7 @@
asmlinkage long sys_sysinfo(struct sysinfo *info)
{
struct sysinfo val;
+ unsigned int mem_unit;
memset((char *)&val, 0, sizeof(struct sysinfo));
@@ -32,47 +33,36 @@
si_meminfo(&val);
si_swapinfo(&val);
- {
- unsigned long mem_total, sav_total;
- unsigned int mem_unit, bitcount;
-
- /* If the sum of all the available memory (i.e. ram + swap)
- * is less than can be stored in a 32 bit unsigned long then
- * we can be binary compatible with 2.2.x kernels. If not,
- * well, in that case 2.2.x was broken anyways...
- *
- * -Erik Andersen <andersee@debian.org> */
-
- mem_total = val.totalram + val.totalswap;
- if (mem_total < val.totalram || mem_total < val.totalswap)
- goto out;
- bitcount = 0;
- mem_unit = val.mem_unit;
- while (mem_unit > 1) {
- bitcount++;
- mem_unit >>= 1;
- sav_total = mem_total;
- mem_total <<= 1;
- if (mem_total < sav_total)
- goto out;
- }
-
- /* If mem_total did not overflow, multiply all memory values by
- * val.mem_unit and set it to 1. This leaves things compatible
- * with 2.2.x, and also retains compatibility with earlier 2.4.x
- * kernels... */
+ /*
+ * If the the available memory or swap is less than can be
+ * stored in a 32 bit unsigned long then we can be binary
+ * compatible with 2.2.x kernels. If not, well, in that case
+ * 2.2.x was broken anyways...
+ *
+ * -Erik Andersen <andersee@debian.org>
+ */
+
+ mem_unit = val.mem_unit;
+ if (val.totalram <= ULONG_MAX / mem_unit &&
+ val.totalswap <= ULONG_MAX / mem_unit) {
+
+ /*
+ * If mem_total did not overflow, multiply all memory
+ * values by val.mem_unit and set it to 1. This
+ * leaves things compatible with 2.2.x, and also
+ * retains compatibility with earlier 2.4.x kernels...
+ */
val.mem_unit = 1;
- val.totalram <<= bitcount;
- val.freeram <<= bitcount;
- val.sharedram <<= bitcount;
- val.bufferram <<= bitcount;
- val.totalswap <<= bitcount;
- val.freeswap <<= bitcount;
- val.totalhigh <<= bitcount;
- val.freehigh <<= bitcount;
+ val.totalram *= mem_unit;
+ val.freeram *= mem_unit;
+ val.sharedram *= mem_unit;
+ val.bufferram *= mem_unit;
+ val.totalswap *= mem_unit;
+ val.freeswap *= mem_unit;
+ val.totalhigh *= mem_unit;
+ val.freehigh *= mem_unit;
}
-out:
if (copy_to_user(info, &val, sizeof(struct sysinfo)))
return -EFAULT;
return 0;
next prev parent reply other threads:[~2001-08-21 17:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-21 8:03 [Patch] sysinfo compatibility Christoph Rohland
2001-08-21 10:59 ` Hugh Dickins
2001-08-21 13:50 ` Alan Cox
2001-08-21 17:30 ` Christoph Rohland
2001-08-21 18:40 ` Alan Cox
2001-08-22 6:40 ` Christoph Rohland
2001-08-21 17:30 ` Christoph Rohland [this message]
2001-08-21 17:46 ` Erik Andersen
2001-08-22 6:44 ` Christoph Rohland
2001-08-22 15:45 ` Erik Andersen
2001-08-22 16:04 ` Christoph Rohland
2001-08-21 18:40 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m34rr12ueb.fsf@linux.local \
--to=cr@sap.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andersee@debian.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox