It is doing a set_fs(KERNEL_DS) for no obvious reason.

Spotted by margitsw@t-online.de (Margit Schubert-While)

Sometimes kjournald has to refile a huge number of buffers, because someone
else wrote them out beforehand - they are all clean.

This happens under a lock and scheduling latencies of 88 milliseconds on a
2.7GHx CPU were observed.

The patch forward-ports a little bit of the 2.4 low-latency patch to fix this
problem.

Worst-case on ext3 is now sub-half-millisecond, except for when the RCU
dentry reaping softirq cuts in :(

It calls __init functions anyway.

The cdrom driver does an order-4 allocation and the open will fail if that
allocation does not succeed.  This happened to me on an unstressed 900MB
machine.

So add the __GFP_REPEAT flag in there - this will cause the page allocator to
keep on freeing pages until the allocation succeeds.

It can in theory livelock but in practice I expect it is OK: the user should
just stop running dbench or whatever it is which is gobbling all the memory
and the mount/open will then succeed.

This tunable refers to the amount of free memory which the VM will attempt to
sustain.  It is mainly needed for atomic allocations (eg, networking
receive).

It is currently hardwired to 1024k, which is far too large for small machines
and too small for large machines.

Rework it to be 128k on tiny machines and 16M on huge machines.

It turns out that the int_sqrt() function in oom_kill.c gets it wrong.

But fb_sqrt() in fbmon.c gets its math right.  Move that function into
lib/int_sqrt.c, and consolidate.

(oom_kill.c fix from Thomas Schlichter <schlicht@uni-mannheim.de>)

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

I needed those for the G5 on ppc64, so here they are, I was only
able to test the SMBUS stuff though.

From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>

Attached is a patch that enables EFI boot-up support in ia32 kernels.

In order to continue to determine whether the kernel should initialize using
EFI tables, I've temporarily added a check on the LOADER_TYPE boot parameter.
 Although I haven't requested that elilo be assigned an id for this yet, I've
used this to determine whether the kernel should use the EFI initialization
path as well as a check to see if the EFI_SYSTAB boot parameter contains
anything.  If someone has a better suggestion for determining this, I'm
open...

This patch also uses the existing ioremapping functions to map the efi tables
into kernel virtual address space.  I've added an option such that I could
use Dave Hansen's boot_ioremap() before paging_init().  After paging_init, I
then remap the efi memmap using bt_ioremap for use later.  This has
eliminated the need for several functions...thanks for the suggestions and
thanks for your help Dave.  Still this could use a look-see.

From: long <tlnguyen@snoqualmie.dp.intel.com>


Add support for Message Signalled Interrupt delivery on ia32.

With a fix from Zwane Mwaikambo <zwane@arm.linux.org.uk>

           text    data     bss     dec     hex filename
Before:    4674    1040    4100    9814    2656 kernel/futex.o
After:     4098    1176    4100    9374    249e kernel/futex.o

From: Chris Wright <chrisw@osdl.org>

Fix for CAN-2003-0461: /proc/tty/driver/serial in Linux 2.4.x reveals the
exact number of characters used in serial links, which could allow local
users to obtain potentially sensitive information such as the length of
passwords.

From: Chris Wright <chrisw@osdl.org>

Fix for CAN-2003-0501: The /proc filesystem in Linux allows local users to
obtain sensitive information by opening various entries in /proc/self
before executing a setuid program, which causes the program to fail to
change the ownership and permissions of those entries.

From: Chris Wright <chrisw@osdl.org>

Fix for CAN-2003-0462:  A race condition in the way env_start and
env_end pointers are initialized in the execve system call and used in
fs/proc/base.c on Linux 2.4 allows local users to cause a denial of
service (crash).

From: Chris Wright <chrisw@osdl.org>

Use the new steal_locks helper to steal the locks from the old files struct
left from unshare_files() when the new unshared struct files gets used.

From: Chris Wright <chrisw@osdl.org>

Add steal_locks helper for use in conjunction with unshare_files to make
sure POSIX file lock semantics aren't broken due to unshare_files.

From: Chris Wright <chrisw@osdl.org>

Use unshare_files during binary loading to eliminate potential leak of
the binary's fd installed during execve().  As is, this breaks
binfmt_som.c

From: Chris Wright <chrisw@osdl.org>

Introduce unshare_files as a helper for use during execve to eliminate
potential leak of the execve'd binary's fd.

into home.osdl.org:/home/torvalds/v2.5/linux

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

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

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

Move some elements of task_struct into thread_info so that
these elements are locked into the TLB in the trap handlers
and thus will not cause a watchdog reset.

Use "sector_div()" to do the division, that's what it
exists for.

into nuts.ninka.net:/disk1/davem/BK/sparc-2.5

following my recent posts on libusb-devel and hidups, here's
a patch to disable hiddev support for MGE UPSs. It only
declares VID/PID as QUIRK_IGNORE in hid-core's blacklist.
This simply prevent hiddev to be loaded when plugging
an MGE UPS.

Adrian Bunk wrote:
> I observed the following small problem in 2.6:
>
> - MII depends on NET_ETHERNET
> - USB_PEGASUS and USB_USBNET select MII, but they depend only on NET
>
> The patch below lets USB_PEGASUS and USB_USBNET depend on NET_ETHERNET
> instead of NET to fix this issue.

Actually how about this one instead?  The PEGASUS bit is the same.
The difference is that MII (and CRC32) are only attributed to the
driver code that needs those ... AX8817X needs both, ZAURUS just
needs CRC32.  The core (which should eventually become a separate
module) shouldn't depend on those modules at all.

Also both CDCETHER and AX8817X are marked as non-experimental;
I recall Dave Hollis submitted a patch to do that for AX8817X,
and CDCETHER now seems to have gotten enough success reports too.

This patch just adds TC86c001 (goku) UDC support to
the "ether.c" gadget driver.  This hardware supports
a full speed CDC Ethernet interface.

Small updates:

   - support TC86c001 (goku_udc) controller
   - simplify the per-controller configuration
   - add two vendor requests to test control-OUT
   - some minor fixes

As more people have been using this API, the need for some
clarifications has (no surprise!) came up.

Most significant is the halt processing, needed to make
Alan's "File Storage Gadget" (mass storage class, talks
to usb-storage and Windows) handle fault cases cleanly.
Gadget drivers can't halt IN endpoints until the FIFO is
emptied by the host ...  virtually no hardware tries to
sequence the DATA and STALL packets by itself.

hiddev is mistakenly returning empty hiddev_event structures for report
events. According to Documentation/usb/hiddev.txt, report events are
only sent when HIDDEV_FLAG_REPORT and HIDDEV_FLAG_UREF are both set.
Currently, report events from hid cause hiddev to generate empty
hiddev_event events when HIDDEV_FLAG_UREF is not set.

into home.osdl.org:/home/torvalds/v2.5/linux

into redhat.com:/spare/repo/libata-2.5

into home.osdl.org:/home/torvalds/v2.5/linux

into redhat.com:/spare/repo/net-drivers-2.5

Kconfig:
   Reflect new watchdog Documentation directory.

[USB] hid blacklist addition:
   Add the Berkshire Products USB PC Watchdog to the hid blacklist.
   This to avoid problems with USB-Disconnects when the card feels it
   should reboot...

into kroah.com:/home/linux/BK/usb-new_drivers-2.6

The errors will be reported by the code that started the request,
and printing out "sector numbers" for special requests makes no
sense. 

Noted by Nick Piggin, fix based on a patch by Linus.

I've done some additional cleanups: fixed a compilation warning on UP
and cleaned up the goto pick_next_task code.  Moved the 'unlikely' to
the test as a whole.

I've tested this patch and the context-switch stats look OK.