From: Brian Gerst <bgerst@didntduck.org>

Cleans up some leftovers from the old module loader:

- Remove unused defines from modules.h

- Remove unused file modsetver.h

From: Alex Goddard <agoddard@purdue.edu>

How to debug module loading problems.  The wording is a slightly changed
version of what Rusty said.

From: MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com>

I am testing PCI hot-plug in 2.6.2 kernel, but sometimes a struct resource
tree in kernel/resource.c was broken if multiple hot-plug requests are
issued at the same time.

The reason is lots of drivers call release_region() on hot removal, and
__release_region(), which is invoked by release_region() macro, changes the
tree without holding a writer lock for resource_lock.

I think __release_region() must hold a writer lock as well as
__request_region() does.

A following patch fixes the issue in my environment.

From: Tim Hockin <thockin@sun.com>

Remove the max_anon via dynamically allocation.  We also change the
idr_pre_get() interface to take a gfp mask, which should have always been
there.

From: Philippe Elie <phil.el@wanadoo.fr>

From: Will Cohen <wcohen@redhat.com>

Add oprofile support for Pentium Mobile (P6 core).  Pentium Mobile needs to
unmask LVPTC vector, since it doesn't hurt other P6 core based cpus we do
it unconditionally for all these.

This patch require userspace tools >= 0.8 (only in sourceforge cvs currently)

From: Philippe Elie <phil.el@wanadoo.fr>

From: Zwane Mwaikambo <zwane@arm.linux.org.uk>

This patch adds infrastructure code and enables ARM to utilise the timer
int oprofile driver.  There is PMU code under development for the XScale
but that is still forthcoming.  In the meantime you can use the timer int
driver with an updated Oprofile-CVS userspace (SF is a bit slow, please
allow 24hrs).

From: Philippe Elie <phil.el@wanadoo.fr>

From: Zwane Mwaikambo <zwane@arm.linux.org.uk>

The nmi_timer_int oprofile driver was enabling itself unconditionally if an
SMP kernel was being used on a UP system without an IOAPIC.

Tested on a P5 using NMI timer int driver and UP system using timer int
driver both running an SMP kernel.

2004-02-11  Zwane Mwaikambo <zwane@arm.linux.org.uk>

	* arch/i386/kernel/nmi.c: export nmi_active
	* arch/i386/oprofile/nmi_timer_int.c: use it to check if owe can use
	  an nmi interrupt

Some machines appear to have BIOS problems which are causing 3c59x adapters
to come up in a powered-off state when WOL and PM are enabled.

So bring back the 2.4 `enable_wol' module option which disables wake-on-lan
unless the user specifically asked for it.

From: Arjan van de Ven <arjanv@redhat.com>

I have 4Kb stacks + IRQ stacks working in my tree.  The biggest part of the
4K-stacks work is changing hardcoded 8Kb assumptions to the proper,
pre-existing define for this.  That part of the patch is appropriate in
general, even when 4Kb stacks might not be.

The recent change to /proc/partitions which prevents it from displaying
removeable media accidentally caused 128 NBD and 16 ramdisk partitions to
appear in /proc/partitions instead.

So add a specific gendisk flag which says "don't show me in /proc/partitions"
and use that.

From: Christoph Hellwig <hch@lst.de>

Don't try to display the per-cpu information for CPUs which aren't there.

From: Neil Brown <neilb@cse.unsw.edu.au>,

From: Miquel van Smoorenburg <miquels@cistron.nl>

While I was stress-testing NFS/XFS on 2.6.1/2.6.2-rc, I found that
sometimes my "dd" would exit with:

	#  dd if=/dev/zero bs=4096 > /mnt/file
	dd: writing `standard output': Invalid argument
	1100753+0 records in
	1100752+0 records out

After adding some debug printk's to the server and client code and some
tcpdump-ing, I found that the NFSERR_INVAL was returned by nfsd_commit on
the server.

Turns out that the "offset" argument is off_t instead of loff_t.  It isn't
used at all (unfortunately), but it _is_ checked for sanity, so that's
where the error came from.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

I falled again on the crash in con_do_write() with driver->data beeing
NULL.  It happens during boot, when userland is playing open/close games
with tty's, I was intentionally typing keys like mad during boot trying to
trigger another problem when this one poped up.

Looking at the code, I'm not sure how protected we are by the above (tty)
layer, paulus told me to not rely on anything like locking coming from
there, so I decided to extend the scope of the console semaphore one more
bit to cover races between calls to con_open, con_close and con_write.
Note that in con_do_write, I intentionally drop the semaphore to avoid
keeping it held when waiting on the local buffer, and I added some sanity
checks on tty->driver_data with some printk's in case we still have an open
race by the tty layer.  At least, now, the couple vc_allocated &
tty->driver_data should be protected though.

From: Kingsley Cheung <kingsley@aurema.com>

Is is possible to examine the data of tasks currently existing in the system
which are not threads of the same thread group.

For example, the only task in the group where init is group leader is itself:

gen2 02:50:44 ~: ls /proc/1/task
1

However, I can then read the contents of 'stat' for any other task in the
system:

gen2 02:49:45 ~: cat /proc/1/task/$$/stat
1669 (bash) S 1668 1669 1669 34816 1730 256 1480 6479 12 4 8 5 5 17 15 0 1 0
+8065 3252224 451 4294967295 134512640 134955932 3221225104 3221222840
+4294960144 0 65536 3686404 1266761467 3222442959 0 0 17 0 0 0

I had a look at fs/proc/base.c and found that the 'lookup' functions for
these directories were checking that the task in question existed, but
overlooked the following:

1.  In the function proc_pid_lookup, a check is required to ensure that
    the task in question is a thread group leader.  Without the check, any
    task can have its data retrieved accordingly.  Consider the following.
    There is a multithreaded process 1777.

gen2 23:22:47 /proc/1777: ls task
1777  1778  1779  1780  1781  1782  1783  1784  1785  1786  1787  1788

However, I can read the stat file for its thread 1778 as follows:

gen2 23:22:50 /proc/1777: cat /proc/1778/stat
1778 (multithreadtest) T 1777 1777 1672 34816 1672 64 0 0 0 0 14 17 0 0 15 0 12 0 8871 24727552 104 4294967295 134512640 134515104 3221222496 1077365276 4294960144 0 0 0 0 3222479248 0 0 -1 1 0 0

But 1778 is not meant to show up in /proc/, as intended right?:

gen2 23:22:56 /proc/1777: ls /proc/
1     1365  1661  1793  881        dma          kcore       scsi
10    1371  1662  18    9          driver       kmsg        self
1014  1372  1663  2     909        execdomains  loadavg     slabinfo
1032  14    1664  3     963        fb           locks       stat
1062  15    1665  4     966        filesystems  mdstat      swaps
1066  16    1666  5     buddyinfo  fs           meminfo     sys
1067  1605  1669  6     bus        ide          misc        sysrq-trigger
1087  1610  1670  7     cmdline    interrupts   modules     sysvipc
1095  1611  1671  736   cpuinfo    iomem        mounts      tty
11    1641  1672  8     crypto     ioports      mtrr        uptime
12    1658  17    807   devices    irq          net         version
13    1660  1777  810   diskstats  kallsyms     partitions  vmstat

2.  The other part of the bug is in the function proc_task_lookup.  Here
    there needs to be a check that the task X is indeed a thread of the
    thread group Y when we read /proc/<Y>/task/<X>.

Right now, this check does not exist, which allows for any existing
task to have its data read from another thread group directory.  The
following reads the stat directory of my bash shell from the thread
group 1.

gen2 23:28:07 ~: cd /proc/1
gen2 23:28:10 /proc/1: ls
auxv     cwd      exe  maps  mounts  stat   status  wchan
cmdline  environ  fd   mem   root    statm  task
gen2 23:28:11 /proc/1: ls task
1
gen2 23:28:27 /proc/1: cat task/$$/stat
1671 (bash) S 1670 1671 1671 34817 1802 256 1953 8101 12 4 10 6 9 26 15 0 1 0 5789 3252224 454 4294967295 134512640 134955932 3221225104 3221222840 4294960144 0 65536 3686404 1266761467 3222442959 0 0 17 0 0 0

From: Pratik Solanki <pratik.solanki@timesys.com>

- Fix include path for build.c so that it finds asm/boot.h.
  /usr/include/asm/boot.h may not be present when cross-compiling on a
  non-Linux machine.

- $(CONFIG_SHELL) instead of sh.

From: Dominik Brodowski <linux@dominikbrodowski.de>

Use do_div on 32-bit archs in cpufreq_scale, and native "/" on 64-bit
archs.

From: Werner Almesberger <werner@almesberger.net>

When passing too many unrecognized boot command line options (which become
arguments or environment variables), the 2.6 kernel panics (unlike 2.4,
which just ignores the extra items).  Unfortunately, this happens before
the console is initialized, so all you get is a kernel that dies quickly,
for no apparent reason.

This is particularly irritating if using UML with
init=something wi th a lot of ar gu men t s

The patch below delays the panic until after console_init.

(akpm: I mainly added this in because we have other places where the
panic-later-on machinery is needed).

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

The patch below removes a kernel 2.2 #ifdef from fs/adfs/adfs.h .

Note that this #ifdef was only present in the header, the implementation
of adfs_bmap was already removed.

From: Ryan Boder <icanoop@bitwiser.org>

Explains how to compile external modules in
Documentation/kbuild/modules.txt.

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

The patch below removeskernel 2.2 #ifdef's from {i,}stallion.h .

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

The patch below removes two #ifdef's for kernel 2.0 from OSS.

From: Joe Korty <joe.korty@ccur.com>

Rename bitmap_snprintf() to bitmap_scnprintf() and cpumask_snprintf() to
cpumask_scnprintf(), as these functions now belong to the scnprintf family
of functions.

Andi notes that the

	smp_call_function(foo);
	foo();

in there is incorrect on preemptible kernels.

Fix that by using on_each_cpu(), which takes care of such things.

Also, remove the open-coded timer from here.  We have
schedule_delayed_work().

And remove the `timerset' variable, which doesn't do anything.

From: Andi Kleen <ak@suse.de>

For various reasons non fatal Machine Checks can happen on Athlons (e.g.
we have reports that laptops like to trigger them on suspend/resume)

They are not necessarily fatal and often only minor hardware glitches.

But what's annoying is that they're KERN_EMERG and pollute your console and
scare the user into writing confused kernel bug reports.

This patch just replaces the KERN_EMERGs with KERN_INFO for now.  Longer
term I think it would be better to log this stuff into a separate log.

From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>

Fix up the 8259 ack handling for buggy SMM firmware.

See http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/0956.html

Apparently the embedded 8259A-compatible core is not fully functional.
This patch lets the I/O APIC-driven NMI watchdog to function correctly.
Credit to Ross Dickson for discovering this.

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.