From: Joe Thornber <thornber@redhat.com>

I just noticed that bio_clone copies the BIO_SEG_VALID bit from the original
bio when it was set.  When we modify bi_idx or bi_vcnt afterwards the segment
counts are invalid and the bit must be dropped (though it is fairly unlikely
that it has already been set).  [Christophe Saout]

From: Joe Thornber <thornber@redhat.com>

Remove redundant spin lock in dec_pending()

From: Joe Thornber <thornber@redhat.com>

Add sanity check to dm_table_add_target() against zero length targets.
[Christophe Saout]

From: Joe Thornber <thornber@redhat.com>

For some reason dm_table_create() was allocating GFP_NOIO rather than
GFP_KERNEL.

From: Joe Thornber <thornber@redhat.com>

Tidy up the error path for alloc_dev()

From: Joe Thornber <thornber@redhat.com>

Make sure that we maintain ordering when deferring bios.

From: Joe Thornber <thornber@redhat.com>

Remove struct dm_deferred_io from dm.c.  [Christophe Saout]

From: Joe Thornber <thornber@redhat.com>

Move to_bytes() and to_sectors() into dm.h

From: Joe Thornber <thornber@redhat.com>

Export dm_vcalloc()

From: NeilBrown <neilb@cse.unsw.edu.au>

With this patch, md used two major numbers for arrays.

One Major is number 9 with name 'md' have unpartitioned md arrays, one per
minor number.

The other Major is allocated dynamically with name 'mdp' and had on array for
every 64 minors, allowing for upto 63 partitions.

The arrays under one major are completely separate from the arrays under the
other.

The preferred name for devices with the new major are of the form:

  /dev/md/d1p3  # partion 3 of device 1 - minor 67

When a paritioned md device is assembled, the partitions are not recognised
until after the whole-array device is opened again.  A future version of
mdadm will perform this open so that the need will be transparent.

From: NeilBrown <neilb@cse.unsw.edu.au>

Currently raid1 uses PAGE_SIZE read/write requests for resync, as it doesn't
know how to honour per-device restrictions.  This patch uses to bio_add_page
to honour those restrictions and ups the limit on request size to 64K.  This
has a measurable impact on rebuild speed (25M/s -> 60M/s)

From: NeilBrown <neilb@cse.unsw.edu.au>

For each resync request, we allocate a "r1_bio" which has a bio "master_bio"
attached that goes largely unused.  We also allocate a read_bio which is
used.  This patch removes the read_bio and just uses the master_bio instead.

This fixes a bug wherein bi_bdev of the master_bio wasn't being set, but was
being used.

We also introduce a new "sectors" field into the r1_bio as we can no-longer
rely in master_bio->bi_sectors.

From: NeilBrown <neilb@cse.unsw.edu.au>

next_r1 is never used, so it can just go.

read_bio isn't needed as we can easily use one of the pointers in the
write_bios array - write_bios[->read_disk].  So rename "write_bios" to "bios"
and store the pointer to the read bio in there.

From: NeilBrown <neilb@cse.unsw.edu.au>

The only time it is really needed is to differentiate a retry-on-fail from a
write-after-read-for-resync request to raid1d.  So we use a bit in 'state'
for that.

From: NeilBrown <neilb@cse.unsw.edu.au>

Instead of having a single end_request handler that must determine whether it
was a read or a write request, we have two separate handlers, which makes
each of them easier to follow.

From: NeilBrown <neilb@cse.unsw.edu.au>

The "START_ARRAY" ioctl depends on major/minor numbers (as stored in the raid
superblock) are stable over reboots, which is increasingly untrue.

There are better ways to start an array (e.g.  with mdadm) so we mark the
ioctl as deprecated for 2.6, and will remove it in 2.7.

From: NeilBrown <neilb@cse.unsw.edu.au>

From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 12 Sep 2003 11:31:06 -0700

NFS won't build w/o CONFIG_PROC_FS.  Looks like typo's (or a C++
programmer) in stats.h

From: NeilBrown <neilb@cse.unsw.edu.au>

From: shemminger@osdl.org Sat Sep  6 09:19:50 2003
Date: Fri, 5 Sep 2003 16:19:30 -0700

Converts /proc/net/rpc/nfs and /proc/net/rpc/nfsd to use the simpler
seq_file interface.

From: NeilBrown <neilb@cse.unsw.edu.au>

There is no way to return an error from a cache init routine, so instead we
make sure to pre-allocate the memory needed, and free it after the lookup
if the lookup failed.

From: NeilBrown <neilb@cse.unsw.edu.au>

When adding a item to a sunrpc/svc cache that contains kmalloced data it is
usefully to move the malloced data out of the key object into the new cache
object rather than copying (as then we would need to cope with kmalloc
failure and such).  This means modifying the original.

If the kmalloced data forms part of the key, then we must not move the data
out until after the key isn't needed any more.  So this patch moves the
call to "INIT" on a new item (which fills in the key) to *after* the item
has been found (or not), and also makes sure we only call the HASH function
once.

Thanks to "J.  Bruce Fields" <bfields@fieldses.org>

also

 1/ remove unnecessary assignment
 2/ fix comments that lag behind implementation.

From: NeilBrown <neilb@cse.unsw.edu.au>

We currently call cache_put, which can schedule(), under a spin_lock.  This
patch moves that call outside the spinlock.

From: Valdis.Kletnieks@vt.edu

15 changes of #if to #ifdef and 2 places CONFIG_FOO should be
defined(CONFIG_FOO).  This gets rid of spurious warnings if you build with
"-Wundef" so you get a warning if you have a preprocessor command like:

#if CONFIG_ETRAX_DS1302_RSTBIT == 27

and you'll be told if it's substituting a zero rather than silent
weirdness and unexpected code generation.

From: Ralf Baechle <ralf@linux-mips.org>

Three new MIPS-specific serial drivers.  ip22.c is derived from the sparc
zilog driver; guess we should write a generic Zilog driver somewhen ...

From: Andi Kleen <ak@muc.de>

Some x86-64 users were complaining that coredumps >2GB don't work.

This will enable large coredump for everybody.  Apparently the 32bit
gdb/binutils cannot handle them, but I hear the binutils people are working
on fixing that.  I doubt it will harm people - unreadable coredumps are not
worse than no coredump and it won't make any difference in space usage if
you get a 1.99GB or a 2.5GB coredump.  So just enable it unconditionally.
If it should be really a problem for 32bit the rlimit defaults in
resource.h could be changed.

For file systems that don't support O_LARGEFILE you should just get an
truncated coredumps for big address spaces.

From: Andrey Borzenkov <arvidjaar@mail.ru>

- use struct nameidata in devfs_d_revalidate_wait to detect when it is
  called without i_sem hold; take i_sem on parent in this case.  This
  prevents both deadlock with devfs_lookup by allowing it to drop i_sem
  consistently and oops in d_instantiate by ensuring that it always runs
  protected

- remove dead code that deals with major number allocation.  The only
  remaining user was devfs itself and patch changes it to

- use register_chardev to get device number for internal /dev/.devfsd and
  /dev/.statd.

- remove dead auto allocation flag as well

- remove code that does module get on dev open - it is handled by fops_get.
   Use init_special_inode consistently

- get rid of struct cdev_type and bdev_type - both have just single dev_t
  now

From: Juergen Quade <quade@hsnr.de>

Lots of places in the kernel are using [v]snprintf wrongly: they assume it
returns the number of characters copied.  It doesn't.  It returns the
number of characters which _would_ have been copied had the buffer not been
filled up.

So create new functions vscnprintf() and scnprintf() which have the
expected (sane) semaptics, and migrate callers over to using them.

We need to hold i_sem while running i_size_write().  But that seems like a
lot of fuss and deadlock potential.  So just write the dang thing.

The NGROUPS changes broke it, and we're not sure how to fixit, and nobody
appears to be working on or testing intermezzo.

From: Tim Hockin <thockin@sun.com>,
      Neil Brown <neilb@cse.unsw.edu.au>,
      me

New groups infrastructure.  task->groups and task->ngroups are replaced by
task->group_info.  Group)info is a refcounted, dynamic struct with an array
of pages.  This allows for large numbers of groups.  The current limit of
32 groups has been raised to 64k groups.  It can be raised more by changing
the NGROUPS_MAX constant in limits.h

From: Rusty Russell <rusty@rustcorp.com.au>

Jeff Garzik disliked the bonding driver knowing it was called "bond0".
Remove that alias, and revert documentation.

From: Rusty Russell <rusty@rustcorp.com.au>

New MODULE_ALIASes in:
1) arch/i386/kernel/microcode.c
2) drivers/char/genrtc.c
3) drivers/ide/ide-tape.c
4) drivers/net/bonding/bond_main.c
5) drivers/net/bsd_comp.c
6) drivers/net/ppp_deflate.c
7) drivers/net/ppp_generic.c

From: Rusty Russell <rusty@rustcorp.com.au>

Someone complained about the number of references to /etc/modules.conf in
the documentation.  While fixing them up (and examples where changed),
removed those which are redundant due to MODULE_ALIAS.

From: Adrian Bunk <bunk@fs.tum.de>

- AMD Elan is a different subarch, you can't configure a kernel that runs
  on both the AMD Elan and other i386 CPUs

- added optimizing CFLAGS for the AMD Elan

From: Adrian Bunk <bunk@fs.tum.de>

gcc 2.95 supports -march=k6 (no need for check_gcc)

From: Adrian Bunk <bunk@fs.tum.de>

add Pentium M and Pentium-4 M options:

- add MPENTIUMM (equivalent to PENTIUMIII except for a bigger
  X86_L1_CACHE_SHIFT)

- document that MPENTIUM4 is the right choice for a Pentium-4 M

From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>

The issue of exceedingly large hash tables has been discussed on the
mailing list a while back, but seems to slip through the cracks.

What we found is it's not a problem for x86 (and most other
architectures) because __get_free_pages won't be able to get anything
beyond order MAX_ORDER-1 (10) which means at most those hash tables are
4MB each (assume 4K page size).  However, on ia64, in order to support
larger hugeTLB page size, the MAX_ORDER is bumped up to 18, which now
means a 2GB upper limits enforced by the page allocator (assume 16K page
size).  PPC64 is another example that bumps up MAX_ORDER.

Last time I checked, the tcp ehash table is taking a whooping (insane!)
2GB on one of our large machine.  dentry and inode hash tables also take
considerable amount of memory.

Setting the size of these tables is difficult: they need to be constrained on
many-zone ia64 machines, but this could cause significant performance
problems when there are (for example) 100 million dentries in cache.
Large-memory machines which do not slice that memory up into huge numbers of
zones do not need to run the risk of this slowdown.

So the sizing algorithms remain essentially unchanged, and boot-time options
are provided which permit the tables to be scaled down.

From: Rusty Russell <rusty@rustcorp.com.au>

The cpu hotplug code actually provides two notifiers: CPU_UP_PREPARE
which preceeds the online and can fail, and CPU_ONLINE which can't.

Current usage is only done at boot, so this distinction doesn't
matter, but it's a bad example to set.  This also means that the
migration threads do not have to be higher priority than the
others, since they are ready to go before any CPU_ONLINE callbacks
are done.

This patch is experimental but fairly straight foward: I haven't been
able to test it since extracting it from the hotplug cpu code, so it's
possible I screwed something up.

From: Rusty Russell <rusty@rustcorp.com.au>

Three more removed CPU notifiers extracted from the hotplug CPU patch.

kernel/softirq.c: the tasklet cpu prepration callback is useless:
the vectors are already initialized to NULL.  Even with the hotplug
CPU patches, they're of little or no use.

fs/buffer.c: once again, they are already initialized to zero.

mm/page_alloc.c: once again, already initialized to zero.

From: Rusty Russell <rusty@rustcorp.com.au>

Move duplicated code to __queue_work(), and don't set the CPU for
queue_delayed_work() until the timer goes off.  The second one only has an
effect on CONFIG_HOTPLUG_CPU where the CPU goes down and the timer goes off
on a different CPU than it was scheduled on.

From: Rusty Russell <rusty@rustcorp.com.au>

Some well-meaning person put a notifier in for CPUs to update the kstat
structures in sched.c.  However, it does nothing, and even with the full
hotplug CPU patch, it still does nothing.

Simple counters very rarely need anything done when CPUs come up or go
down.  If you have per-cpu caches, or per-cpu threads, you need to do
something.  But very rarely for stats.