This patch fixes an unload crash when no PCI drivers are loaded.

into kernel.bkbits.net:/home/davem/net-2.5

into kernel.bkbits.net:/home/davem/net-2.5

Based upon a report from Andrew Morton.

[NET]: Convert most tokenring drivers away from {init,register,unregister}_trdev, only ibmtr remains.

into home.transmeta.com:/home/torvalds/v2.5/linux

This adds a new interface to kernel/signal.c which allows signals to be
sent using preallocated sigqueue structures.  It also modifies
kernel/posix-timers.c to use this interface.

The current timer code may fail to deliver a timer expiry signal if
there are no sigqueue structures available at the time of the expiry.
The Posix specification is clear that the signal queuing resource should
be allocated at timer_create time.  This allows the error to be returned
to the application rather than silently losing the signal.

This patch does not change the sigqueue structure allocation policy.  I
hope to revisit that in another patch.

Here is the definition for the new interface:

struct sigqueue *sigqueue_alloc(void)
	Preallocate a sigqueue structure for use with the functions
	described below.

void sigqueue_free(struct sigqueue *q)
	Free a preallocated sigqueue structure.  If the sigqueue
	structure being freed is still queued, it will be removed
	from the queue.  I currently leave the signal pending.
	It may be delivered without the siginfo structure.

int send_sigqueue(int sig, struct sigqueue *q, struct task_struct *p)
	This function is equivalent to send_sig_info().  It queues
	a signal to the specified thread using  the supplied sigqueue
	structure.  The caller is expected to fill in the siginfo_t
	which is part of the sigqueue structure.

int send_group_sigqueue(int sig, struct sigqueue *q, struct task_struct *p)
	This function is equivalent to send_group_sig_info().  It queues
	the signal to a process allowing the system to select which thread
	will receive the signal in a multi-threaded process.
	Again, the sigqueue structure is used to queue the signal.

Both send_sigqueue() and send_group_sigqueue() return 0 if the signal
is queued. They return 1 if the signal was not queued because the
process is ignoring the signal.

Both versions include code to increment the si_overrun count if the
sigqueue entry is for a Posix timer and they are called while the
sigqueue entry is still queued.  Yes, I know that the current code
doesn't rearm the timer until the signal is delivered.  Having this
extra bit of code doesn't do any harm, and I plan to use it.

These routines do not check if there already is a legacy (non-realtime)
signal pending.  They always queue the signal.  This requires that
collect_signal() always checks if there is another matching siginfo
before clearing the signal bit.

From: Manfred Spraul <manfred@colorfullife.com>

SysV sem operations that involve multiple semaphores can fail in the
middle, and then sempid (pid of the last successful operation) must be
restored.  This happens with "sempid >>= 16" - broken due to the 32-bit pid
values.  The attached patch fixes that by reordering the updates of the
semaphore fields.

Additionally, the patch fixes the corruption of the sempid value that occurs
if a wait-for-zero operation fails.

The patch is more than two years old, and was in -dj and -ak kernels.

From: Tony Luck <tony.luck@intel.com>

/proc/kcore has been broken on some architectures for a long time.  Problems
surround the fact that some architectures allocate memory for vmalloc() and
thus modules at addresses below PAGE_OFFSET, which results in negative file
offsets in the virtual core file image provided by /proc/kcore.  There are
also pending problems for discontig memory systems as /proc/kcore just
pretends that there are no holes between "PAGE_OFFSET" and "high_memory", so
an unwary user (ok super-user) can read non-existant memory which may do bad
things.  There may also be kernel objects that would be nice to view in
/proc/kcore, but do not show up there.

A pending change on ia64 to allow booting on machines that don't have
physical memory in any convenient pre-determined place will make things even
worse, because the kernel itself won't show up in the current implementation
of /proc/kcore!

The patch attached provides enough hooks that each architecture should be
able to make /proc/kcore useful.  The patch is INCOMPLETE in that *use* of
those hooks is ONLY PROVIDED FOR IA64.

Here's how it works.  The default code in fs/proc/kcore.c doesn't set up any
"elf_phdr" sections ...  it is left to each architecture to make appropriate
calls to "kclist_add()" to specify a base address and size for each piece of
kernel virtual address space that needs to be made accessible through
/proc/kcore.  To get the old functionality, you'll need two calls that look
something like:

 kclist_add(&kcore_mem, __va(0),
             max_low_pfn * PAGE_SIZE);
 kclist_add(&kcore_vmem, (void *)VMALLOC_START,
             VMALLOC_END-VMALLOC_START);

The first makes all of memory visible (__i386__, __mc68000__ and __x86_64__
should use __va(PAGE_SIZE) to duplicate the original lack of access to page
0).  The second provides a single map for all "vmalloc" space (the code still
searches the vmlist to see what actually exists before accessing it).

Other blocks of kernel virtual space can be added as needed, and removed
again (with kclist_del()).  E.g.  discontiguous memory machines can add an
entry for each block of memory.  Architectures that allocate memory for
modules someplace outside of vmalloc-land can add/remove entries on module
insert and remove.

The second piece of abstraction is the kc_vaddr_to_offset() and
kc_offset_to_vaddr() macros.  These provide mappings from kernel virtual
addresses to offsets in the virtual file that /proc/kcore instantiates.  I
hope they are sufficient to avoid negative offset problems that plagued the
old /proc/kcore.  Default versions are provided for the old behaviour
(mapping simply adds/subtracts PAGE_OFFSET).  For ia64 I just need to use a
different offset as all kernel virtual allocations are in the high 37.5% of
the 64-bit virtual address space.  x86_64 was the other architecture with
this problem.  I don't know enough (anything) about the kernel memory map on
x86_64, so I hope these provide a big enough hook.  I'm hoping that you have
some low stuff, and some high stuff with a big hole in the middle ...  in
which case the macros might look something like:

#define kc_vaddr_to_offset(v) ((v) < 0x1000000000000000 ? (v) : \
                              ((v) - 0xF000000000000000))

But if you have interesting stuff scattered across *every* part of the
unsigned address range, then you won't be able to squeeze it all into a
signed file offset.

There are a couple of bug fixes too:
1) get_kcore_size() didn't account for the elf_prstatus, elf_prpsinfo
   and task_struct that are placed in the PT_NOTE section that is
   part of the header.  We were saved on most configurations by the
   round-up to PAGE_SIZE ... but it's possible that some architectures
   or machines corrupted memory beyond the space allocated for the
   header.

2) The size of the PT_NOTES section was incorrectly set to the size
   of the last note, rather than the sum of the sizes of all the notes.

If a buffer_head is outside i_size, block_write_full_page() will leave it
!buffer_mapped().  We shouldn't attach that buffer to the transaction for
writeout!

This bug has been in 2.5 for some time.

From: David Mosberger <davidm@napali.hpl.hp.com>

Basically, what the patch does is provide two hooks such that platforms
(and subplatforms) can provide time-interpolation in a way that guarantees
that two causally related gettimeofday() calls will never see time going
backwards (unless there is a settimeofday() call, of course).

There is some evidence that the current scheme does work: we use it on ia64
both for cycle-counter-based interpolation and the SGI folks use it with a
chipset-based high-performance counter.


It seems like enough platforms do this sort of thing to provide _some_
support in the core, especially because it's rather tricky to guarantee
that time never goes backwards (short of a settimeofday, of course).

This patch is based on something Jes Sorensen wrote for the SGI Itanium 2
platform (which has a chipset-internal high-res clock).  I adapted it so it
can be used for cycle-counter interpolation also.  The net effect is that
"last_time_offset" can be removed completely from the kernel.

The basic idea behind the patch is simply: every time you advance xtime by
N nanoseconds, you call update_wall_time_hook(NSEC).  Every time the time
gets set (i.e., discontinuity is OK), reset_wall_time_hook() is called.

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

Fix this:

drivers/mtd/maps/map_funcs.c: In function `simple_map_read64':
drivers/mtd/maps/map_funcs.c:38: warning: implicit declaration of
function `__raw_readll'

From: Andi Kleen <ak@suse.de>

Some recent subarch interface changes caused macro redefinition warnings
for GET_APIC_ID and APIC_ID_MASK with the generic subarchitecture.  Fixing
it properly required some reorganization by giving the generic arch a
mach_apicdef.h too.

From: Andi Kleen <ak@suse.de>

A brown paper bag bug, noticed by Ralf Baechle.

i386 needs to define STAT_HAVE_NSEC too, otherwise it won't copy
the nanosecond values to user space.

This /proc tunable sets the kupdate interval.  It has a couple of problems:

- No way to turn it off completely (userspace dirty memory management
  solutions require this).

- If it has been set to one hour and then the user resets it to five
  seconds, that resetting will not take effect for up to an hour.

Fix that up by providing a sysctl handler.  Setting the tunable to zero now
disables the kupdate function.

From: Andi Kleen <ak@suse.de>

John Stultz noticed that kirqd didn't start because of another logic error,
which broke irq balancing.  This was still a fallout from the generic
subarchitecture changes.

Actually it still refuses to balance anything on my test box, but perhaps
I'm just not able to generate enough interrupts.

Anyways, with this patch the thread is running again at least.

We end up inspecting this field in zap_page_range(), on the mmap error path.
Best initialise it to something...

From: Manfred Spraul <manfred@colorfullife.com>

We need to present more information in /proc/slabinfo now the magazine
layer has been added.

The slabinfo version has been updated to 2.0.

From: Manfred Spraul <manfred@colorfullife.com>

slab.c is not very efficient for passing objects between cpus.  Usually this
is a rare event, but with network routing and cpu-affine NICs it is possible
that nearly all allocation operations will occur on one cpu, and nearly all
free operations on another cpu.

This causes slab memory to be returned to slab's free page list rather than
being cached on behalf of the particular slab cache.

The attached patch solves that by adding an array of objects that is shared
by all cpus.  Instead of multiple linked list operations per object, object
pointers are now passed to/from the shared array (and thus between cpus) with
memcopy operations.  On uniprocessor, the default array size is 0, because
the shared array and the per-cpu head array are redundant.

Additionally, the patch exports more statistics in /proc/slabinfo and make
the array sizes tunable by writing to /proc/slabinfo.  Both changes break
backward compatibility, user space scripts must look at the slabinfo version
and act accordingly.

The size of the new shared array may be altered at runtime, by writing to
/proc/slabinfo.

The new parameters for writing to /proc/slabinfo are:

	#echo "cache-name limit batchcount shared" > /proc/slabinfo

For example "size-4096 120 60 8" improves the slab efficiency for network
routing, because the default values (24 12 8) are too small for the large
series generated due to irq mitigation.  Note that only root has write
permissions to /proc/slabinfo.

These changes provided an overall 12% speedup in Robert Olson's gigE
packet-formwarding testing on 2-way.

disk->minor_shift is not used anymore.  Remove it.

Fix various typos and and information about the new kconfig features.

This creates the configuration in the destination directory instead of
the current directory.

conf: better choice interface
      don't ask for unchangable symbols

mconf: mark unchangable symbols with '---'
       update exit text (from Sam Ravnborg <sam@ravnborg.org>)

qconf: update debug output

Add a number of warnings to avoid misuse of the previously added features
(most important check for recursive dependencies).

The 'range' keyword allows to define a lower and upper limit for integer
and hex symbols.

The 'select' keyword defines a lower limit for symbols and allows to
select other symbols when a symbol is selected, e.g.:

config JOLIET
	bool "Microsoft Joliet CDROM extensions"
	select NLS

This means when JOLIET is selected, NLS will be selected as well.

"default" accepts now not only a single symbol but also an expression
which can be assigned to boolean and tristate symbols.

Add the following new keywords: def_tristate, def_bool, def_boolean,
select, enable and range.

Add support for def_tristate and def_bool, which combines default and
bool/tristate into a single statement and a allows simpler definition
of derived symbols.

This changes P_ROOTMENU into a MENU_ROOT flag and also fixes some qconf
usability problems.

Some gconf fixes by Romain Lievin <roms@tilp.info>.

Remove old code and debugging macros which were used by the cml1->kconfig
converter.