Subject: Incompatable Linux 2.0.30 changes!

From: Russell King <[email-masked]>
Date: Sun, 24 Aug 1997 16:08:12 +0100 (BST)

Hiya.

I've got a mail here from someone trying to use Linux on an 8MB machine.
It seems to stall when mke2fsing a 1GB partition.

The machine has 64MB swap file on it, and the kernel message is:
Adding Swap: 63316k (priority 27200).

I presume that at this priority, it wouldn't get used?  The next message
is 'Could not get a free page....'

During my investigation, I came across the following problem:

It appears that the swapon call arguments have been modified with little
protection on the values that passed in the new arguments.

Someone's extremely basic test, that should not have been put in even IMO as
it stood does very little to guard against this, especially as the syscall
number hasn't changed!

This means that if anyone uses an old version of the swapon binary for example,
and the fact that swapon is still prototyped as swapon (const char *) in the
header files, it's very likely that this change is going to cause me a lot of
grief and probably many other people as well using different ports.

His test is basically:
        if (swap_flags & SWAP_FLAG_PREFER) {
                p->prio =
                  (swap_flags & SWAP_FLAG_PRIO_MASK)>>SWAP_FLAG_PRIO_SHIFT;
        } ...

A 1 bit test!  An absolute turkey!  This means that I'm going to have to
modify the RedHat installer yet again.  There is a good example of how do
do this change in the kernel - the mount syscall:

 * NOTE! As old versions of mount() didn't use this setup, the flags
 * has to have a special 16-bit magic number in the hight word:
 * 0xC0ED. If this magic word isn't present, the flags and data info
 * isn't used, as the syscall assumes we are talking to an older
 * version that didn't understand them.

A better solution would have been to pass the second argument to swapon
as a magic number, and the third as the priority, or even change the syscall
number and have a backward-compatability function in the architecture
specific code!

Obviously this isn't up for debate at this time, so I'm going to have to
change the binaries, and the people who have downloaded ARM Linux (around
50GB or so of downloads so far) to redownload a few MB each (which would
equal a total of 126 manhours of downloading time)!

I'd like Linus to know about this particular bit of grief so that he can
check for this sort of thing, to help prevent it from happening again!  I'm
not moaning - I'd just like to make sure that something like this doesn't
lay dormant for several months before it becomes apparant!  (Sound's just
like a virus doesn't it)!

This has come about because the RedHat 4.0 installer uses swapon (device)
and not swapon (device, priority).  This means that the priority argument
to the newly changed swapon routine can be anything. (RH4.0 uses Linux 2.0
isn't it?).

I'll let people know once the new code is up on the FTP site.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       Russell King        [email-masked]         --- ---
  | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Mon, 25 Aug 1997 13:37:56 -0000

>grief and probably many other people as well using different ports.

Just a thought (and I haven't checked this) - it's possible that we're 
starting to see the ill effects of using libc-4.  For Linux 2.0 libc-5 has been 
the standard C library, and it may be that they have a newer swapon().  
Granted, that doesn't make the change any safer, but it may explain why nobody 
has noticed before now. 

The kernel people are starting to talk about filing libc-4 firmly under "dead 
and buried" for 2.2.

BTW, on a different subject, I'm working on integrating the PIC support with
binutils at the moment.  Once that's done supporting ELF shouldn't be too hard.
Unfortunately I'm a bit busy with other work right now, so it may take a few 
weeks.
 
p.

---

From: Russell King <[email-masked]>
Date: Mon, 25 Aug 1997 22:55:02 +0100 (BST)

> Granted, that doesn't make the change any safer, but it may explain why nobody 

Nope - those are the libc5 header files!  The reason that no one has noticed it
is probably something to do with the way the arguments are passed to the kernel.
On i386, the second register may always contain a certain value on entry to this
kernel syscall, and therefore the problem will never be seen.

> The kernel people are starting to talk about filing libc-4 firmly under "dead 

Well, until we get ELF... (Richard Earnshaw hasn't replied to my latest mails).

> Unfortunately I'm a bit busy with other work right now, so it may take a few 

Yipppeee! Some news about some work on ELF ;) ;) ;)
   _____