a cleanup of my previous patches wrt irq handling, and also fixes
a real bug (we used to ACK the io-apic outside the irq-controller lock,
which meant that the ack's we did and "ipi_pending[]" might have gotten
out of sync - which could certainly have resulted in bad behaviour).
This also re-enables the code that replays interrupts in enable_irq(),
because it should be ok now that the rest of the code is cleaned up.
People that had the earlier problem with locking up with floppies, please
test: if this re-introduces the lockup, please just #if 0 out all the code
inside trigger_pending_irqs(), and send me a note telling me that that
code still doesn't work.

                Linus

I just released a fairly small patch to 97 to bring it up to 98.

I've gotten a lot of patches in the mail for the last week, and I've been
ignoring most of them for obvious reasons. They aren't in any in-queue,
you can more-or-less consider them lost - but don't resend them all
immediately, because if I get another huge batch of patches then I'll just
have to ignore them again.

We're going slow and easy, and the plan is to not only keep me sane in the
midst of all the diapers, but I'll also at the same time take the
opportunity to actually enforce the feature-freeze. You've known about it
for a long time, _tough_.

Anyway, 2.1.98 _should_ fix:

 - the IDE/SCSI lockups. The irq enable/disable code was broken, and could
   do some really bad things. This tended to lock up the machine if you
   accessed your IDE disks heavily, or in particular if you had a mixture
   of IDE and SCSI and used them at the same time. Tell me if you still
   have problems - I'm sure there are still bugs left, and I want to hear
   about them.
 - memory management especially on small-memory machines. I think I made a
   good change to the allocation logic, and I'm hoping it will fix the bad
   bahevaiour on those wimpy machines that all you losers out there are
   using that have less than half a Gig of RAM. It certainly still works
   fine on my machine, and I'm certainly still too lazy to test it out on
   anything smaller.

There's a few other updates too: the asm constraints are fixed, so it
should compile again with other compiler versions than the particular one
I happen to be using. And some of the SCSI drivers have been updated a
bit.

There's been a lot of discussion and patches on capabilities, and I
haven't applied them yet, I'll let them simmer a bit. Similarly, I've seen
so many pathes to kmod that my head is spinning, and as I don't use
modules myself I'd really like to get feedback from users about the
different patches, so that maybe I'll get something that everybody can
agree on as acceptable. Right now I don't know which patch I should even
begin looking at.

                Linus

I made a 2.1.97 release, in order to synch up with some large patch-sets
I've gotten (non-x86 architecture updates). But due to the new baby this
really hasn't been through my usual exhaustive stress-test ("make bzImage"
+ "boot") so buyer beware.

                Linus

This is finally the kind of feature-freeze patch I like: it only contains
fixes for outright bugs. The fixes are:
 - SMP-safe disk drivers (more on this below)
 - various PCI fixes: /proc/bus/pci works again, and it should compile and
   work on Alpha with TGA.
 - parport interrupt detection uses the standard probe routines, and
   doesn't leave bogus "probe" entries hanging around to confuse people
   (and make other device registration fail)
 - the ever-popular PCI ne netdriver fix
 - the getcwd() system call works again.
 - "mb()" does the right thing on x86 too. Few drivers use it, but more of
   them should. Right now there are drivers that depend on luck making
   sure that the memory accesses will be in the same order outside the CPU
   as inside it.

The conceptually big one is the SMP-safe disk driver change: it's not a
very big patch, but it's fairly subtle. And it still requires help from
the disk drivers themselves, although all of them should be safe in UP,
and I made sure the BusLogic and the NCR driver are safe on SMP.
The change is really a change in locking defaults: we used to default to
no locking, and depended on the disk driver getting the locking right.
None of them did so on SMP, for understandable reasons (there really
wasn't any support for getting it right).

The new default is to do the locking for the driver, and the driver
actually has to do some work if it wants to do anything outside the lock.
This has the obvious advantage that it _defaults_ to being safe, and
people who know what they are doing can choose to thread the driver if
they want to.

The only change needed to drivers is to make sure they get the lock on an
interrupt, which usually involves just doing the following around the
low/level interrupt handler (the same handler that you register using
"request_irq()"):

        void handle_irq(int irq, void *dev, struct pt_regs *regs)
        {
+               unsigned long flags;
+               spin_lock_irqsave(&io_request_lock, flags);
                ... call to the proper action routines ...
+               spin_unlock_irqrestore(&io_request_lock, flags);
        }

which guarantees that everything inside the driver is correctly locked
from the outside world (with the exception of ioctl's etc things that the
driver traps - they need to be protected too).

                Linus

2.1.93 is out there. It is broken on other platforms than x86, because I
had to move some initialization code around, but this shoul dbe very easy
to fix (moving the device init code later makes a _lot_ of things easier:
the system is essentially up and running, and "kmalloc()" etc actually
works).

Now the PCI init code actually has the full SMP knowledge, which it needs
in order to get the interrupt mapping stuff right (for example - it might
eventually need it for other reasons too).

The PCI code has generally been cleaned up - thanks to Martin Mares (the
PCI cleanup is what forced me to do the other changes - anything else
would simply have been too ugly).

2.1.93 should also fix the stupid things in 92 (modules don't load due to
missing symbols, and NULL pointer dereferences in /proc under certain
circumstances etc).

The kernel should also be better at detecting the really low memory
circumstances, and eventually return NULL instead of just looping forever
trying to find a page that it won't ever find.

                        Linus

[tytso on ext2fs changes:]
These patches provide the following enhancements to ext2.
        * Fixed a bug where we weren't byte-swapping the feature set
                flags before checking EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER
        * Added Stephen Tweedie's patches to allow the number of file
                blocks which will be preallocated to be tuned (instead
                of being fixed at 8 blocks).
        * Added Stephen Tweedie's patches to allow directory blocks to
                be preallocated.  This change is only activated if the
                EXT2_FEATURE_COMPAT_DIR_PREALLOC is enabled.  (There
                will soon be a new release of e2fsprogs that will
                allow you to turn this on.)  The change is compatible
                with older kernels (that's why it's a COMPAT feature),
                but we need to flag it in the feature set because the
                e2fsck needs a few changes to support this.
        * Added future support for B-trees in directories.  I have a
                design in mind which is fully read/only compatible
                with the existing ext2 directories, which will make
                its debut in the 2.3 kernel series.  This patch will
                allow 2.2 kernels to mount filesystems with B-tree
                directories read-write; if a 2.2 kernel tries to
                modify a B-tree directory, the B-tree valid bit will
                be turned off, since the B-tree structures won't be
                updated by 2.2 kernels.  2.0 kernels will be able to
                mount filesystems with B-tree directories read-only.
                This defines a new feature, EXT2_FEATURE_RO_COMPAT_BTREE_DIR.
        * Added Jakub Jelinek's support for large files on 64-bit
                platforms.  On a 64-bit platform, the first time you
                expand a file past the 32-bit boundary, the
                EXT2_FEATURE_RO_COMPAT_LARGE_FILE is turned on.
                2.0 machines will be able to mount such filesystems
                read-only.  2.2 kernels on 32-bit platforms will be
                able such filesystems read-write, but they will only
                be able to see the first 2**32 bytes of the file, and
                any attempt to open a large file for read/write access
                will cause an EBIGF error.
        * Added support for storing the file type in the directory
                entry.  This optimization was added to BSD 4.4 and
                makes a very big difference for a number of
                operations, since application programs can avoid doing
                a stat in a number of situations.  Support for this is
                in the GNU user-land utilities, and is in glibc
                already.  Beyond this patch, we also need to implement
                a new getdents system call that will return the
                information all the way to libc.
                The reason why it's important to get this change into
                2.2 is that it requires "stealing" 8-bits from the
                name_len field of the directory entry.  Ext2fs limits
                you to 255 characters in a file name, so the high-byte
                of name_len is always zero.  However, older kernels
                look at both bytes of name_len, and will get confused
                if we try to store something there.  So we can only
                update the file type field if the feature
                EXT2_FEATURE_INCOMPAT_FILETYPE is enabled.
                I want to get this support into the 2.2 kernel, since
                even if it isn't used much (because people will want
                their filesystems to be compatible with 2.0 kernels),
                we will be able to migrate smoothly to using this
                feature by default in the future.

Ok, there's a fairly large patch out there, but as of 2.1.92 I think we
have a real feature-freeze, and we'll try to get a real code-freeze going
soon. There are known problems with the sound drivers etc, which is why a
code-freeze isn't the best suggestion right now, and there are probably
still bugs with some of the new code, but I'll freeze new features for the
upcoming 2.2 kernel.

Yes, some people will scream bloody murder, but others will be relieved
that it finally happened. Thanks especially to David Miller who has been
doing a great job of getting the TCP stack from its problems just a few
weeks ago to really shining new heights. That was my main worry about 2.2
not all that long ago, and was the main reason for having such a slushy
period for a while.

2.1.92 does:
 - ISDN updates
 - alpha update (yes, SMP finally works, although not really stable yet)
 - networking fixes
 - "getcwd()" system call (not very long, the dcache makes this so
   trivial it is scary)
 - the mm responsiveness updates (they were in 2.1.92-pre2, people seemed
   to have found them very effective)
 - some other (mainly driver updates)

Please do test it all out. Feature-freeze doesn't mean that it is supposed
to be bug-free yet, but it does mean that we should be moving into
bugfixing mode in quick order.
And no, this is not an April 1 thing. But this way I can use April 1 as an
excuse if something doesn't actually compile.

                Linus

I just made a real 91 on ftp.kernel.org, let's hope that this has all the
sillies gone. As usual, it is prefectly smooth on my machine, but this
time we also have a better chance of it being smooth on machines with less
memory too, as Rik has done some good work in testing the algorithms out.
So throw some problems at it to see just how good it is..

                Linus

  We should not send an ack if we don't have any pending
  (in which case the DACK timer will be set)     (Dave Miller)

- the first cut of my spinlock changes wrt the task lists (Linus)

seems to have found and fixed the TCP performance problem, which means
that the code-freeze for 2.2 is going to go into effect shortly..

pre-90 does a few other minor things, like for example getting rid of
kerneld because the new kmod thing is a lot simpler in many ways. Let's
see what the reaction to that is, but I'm fairly certain that this was a
major good thing: I've personally never liked kerneld, but kmod seems to
be a much nicer and more controlled way of handling the same issues that
kerneld tried to do. I'd actually almost be willing to use the thing
myself, something that was never true of kerneld.

This also moves the WD7000 SCSI driver to a working status again, thanks
to Miroslav Zagorac.

But the interesting and important part of the patches are the networking
fixes from David and Bill Hawes..

                Linus

Subject: Re: INN doesn't work on pre-2.1.89-4 (mmap problem ?)
From: Linus Torvalds <torvalds@transmeta.com>

I fixed _one_ silly bug wrt writeback to shared files in pre-5

It should fix the problem another way that I'm happier with (fixing that
problem also revealed a few other misuses of close_fp() due to historical
reasons - the uses really needed to be "fput()"s instead).
2.1.89-4 also uses "struct file" for mmap's, which means that the problem
that somebody was complaining about with mmap (that the mapping would
exist even after the last "release()" on that file, and thus the file
would still be active) are gone. As of -4 the kernel will guarantee that
it will call the file->f_op->release() onle after there really aren't any
uses of that file pointer any more..

                Linus

[sct] a patch against ipc/shm.c was missing from my swap patches,
      and another fix for spurious warnings about shared dirty pages.

[changelog pieced together by davej]

* 2.1.88, adds a bunch of new functionality to
  the swapper.  The main changes are:

* All swapping goes through the swap cache (aka. page cache) now.

* There is no longer a swap lock map.  Because we need to atomically
  test and create a new swap-cache page in order to do swap IO, it is
  sufficient just to lock the struct page itself.  Having only one
  layer of locking to deal with removes a number of races concerning
  swapping shared pages.

* We can swap shared pages, and still keep them shared when they are
  swapped back in!!!  Currently, only private shared pages (as in pages
  shared after a fork()) benefit from this, but the basic mechanism will
  be appropriate for MAP_ANONYMOUS | MAP_SHARED pages too
  (implementation to follow).  Pages will remain shared after a swapoff.

* The page cache is now quite happy dealing with swap-cache pages too.
  In particular, write-ahead and read-ahead of swap through the page
  cache will work fine (and in fact, write-ahead does get done already
  under certain circumstances with this patch --- that's essentially how
  the swapping of shared pages gets done).  Support code to perform
  asynchronous readahead of swap is included, but is not actually used
  anywhere yet.

  I've tested with a number of forked processes running with a shared
  working set larger than physical memory, and with SysV shared memory.
  I haven't found any problems with it so far.

Linus: I've also changed the way we consider us to need more memory in kswapd,
       but that was entirely orthogonal and did not impact these patches. ]

[Changelog pieced together by davej]

Ok, 2.1.87 is out there on ftp.kernel.org now, and it has the clever
PROT_NONE thing done. It seems to work for the little test-case I wrote,
and I also verified that swapping still works, so it seems to be all ok.
I'd still like people who have test programs or similar to actually check
it out,

                Linus

- Update makefile version (forgot to in .83)
- fixes a (very obscure, possibly never happens) autofs bug.
- fix missing ; compile error in mm/filemap.c
- MS_NODIRATIME support.

[changelog summary by davej]

I just made a pre-2.1.81 available on ftp.kernel.org.
This fixes the known problems of 2.1.80, and also makes the interrupt
routing by default look like it always used to look - everything goes
through the traditional external 8259A-compatible logic.
The code to handle IO-APIC interrupt routing is still there, but as no
interrupts are actually marked as io-apic interrupts you don't see it in
action yet. The advantage of this is that people who want to work on this
have a base that contains all the logic, and that we only need to figure
out how to reliably make all the IRQ routing decisions.

                Linus

This release should fix a few networking problems, and the NFS client is
hopefully fairly stable even under the kinds of loads we have here at
Transmeta.

The 2.1.80 release also contains some initial ARM support, and contains
Ingo Molnar's better SMP interrupt handling.

NOTE NOTE NOTE! The new SMP interrupt handling is currently not very good
at autodetection. This can be a real problem, and _before_ booting the
2.1.80 kernel as compiled for SMP you should probably try to figure out a
possible IRQ override line by doing:

        echo -n pirq=; echo `scanpci -f | grep T_L | cut -c56-` | sed 's/ /,/g'
which for me gives
        pirq=0x00,0x09,0x0b

Then, after doing the above, boot into 2.1.80 and see if it finds your PCI
interrupt lines correctly. If it does, everything is fine. If it doesn't,
you need to boot with the pirq setting that you determined earlier, by
giving the kernel the pirq data at the bootup command line or by using the
LILO "append=" feature (or similar features in other bootloaders).
We'll certainly have to make the autodetection work reliably, but in the
meantime the command-line approach at least gives us a way to test the
more fundamental impacts of better interrupt handling.

                Linus

 I just put a pre-2.1.80 on ftp.kernel.org that should fix the fat-related
problems. The reason I put it there is because I got several patches that
fixed the FAT problems _and_ something else, and they all obviously
clashed with each other so neither part got applied.

 So I'd ask people who sent me patches to maybe re-send the parts of the
patches that are still relevant,

                Linus