From: Andrey Borzenkov <arvidjaar@mail.ru>

devfs_mk_dir freed wrong de and incorrectly passed to devfsd already freed
de.  Besides it did not even check if entry found was actually directory.

From: Ramn Rey Vicente <ramon.rey@hispalinux.es>

Fix the config issue with the hotplug firmware loader.  The firmware loader
use hotplug, so this must be included as a dependency.

When we changed try_name() to handle new-style printable dev_t formatting we
broke lots of people's setups.  Lilo, grub, etc.

Fix that by trying new-style formatting first, then fall back to old-style.

People should generally use new-style %u:%u major:minor formatting in the
future.

From: Vinay K Nallamothu <vinay-rc@naturesoft.net>

The patch below fixes two pointer reference bugs (shows up as compile
time warnings given below) which wrongly take the address of "struct
usb_interface*".

	drivers/bluetooth/hci_usb.c: In function `hci_usb_probe':
	drivers/bluetooth/hci_usb.c:786: warning: assignment from incompatible pointer type
	drivers/bluetooth/hci_usb.c:810: warning: assignment from incompatible pointer type

From: Mikael Pettersson <mikpe@csd.uu.se>

This patch fixes ide-scsi.c for the ide_drive_t->queue type change
in 2.6.0-test3.

Without the patch you'll get these new warnings in -test3:

drivers/scsi/ide-scsi.c: In function `idescsi_abort':
drivers/scsi/ide-scsi.c:875: warning: passing arg 1 of `elv_queue_empty' from incompatible pointer type
drivers/scsi/ide-scsi.c: In function `idescsi_reset':
drivers/scsi/ide-scsi.c:902: warning: passing arg 1 of `elv_next_request' from incompatible pointer type

Bug 1065 (http://bugme.osdl.org/show_bug.cgi?id=1065) points out that there
is a risk that UDF will accidentally mount a reiserfs partition, which would
prevent a successful boot.

Andries points out that probing is unreliable and that users/admins should
always specify the root filesystem type on the kernel boot command line with
"rootfstype=resierfs".

But nobody does that, so we should be trying reiserfs before UDF.

From: Manfred Spraul <manfred@colorfullife.com>

(We think this might be the mystery bug which has been hanging about for
months)


We found a [the?] task struct refcount error: A task that dies sets
tsk->state to TASK_ZOMBIE.  The next scheduled task checks prev->state, and
if it's ZOMBIE, then it decrements the reference count of prev.  The
prev->state & _ZOMBIE test is not atomic with schedule, thus if prev is
scheduled again and dies between dropping the runqueue lock and checking
prev->state, then the reference it dropped twice.

This is possible with either preemption [schedule_tail is called by
ret_from_fork with preemption count 1, finish_arch_switch drops it to 0] or
profiling [profile_exit_mmap can sleep on profile_rwsem, called by
mmdrop()] enabled.

Several comparisons which can never be true because they're comparing u8's
with numbers which are greater than 255.

ic_servaddr is accessible after boot via /proc/net/pnp.  So it cannot be
__initdata.

davej says that other varibles there are treated the same way, so move them
all into the regular data section.

From: Paul Clements <Paul.Clements@SteelEye.com>

Here's the updated patch to fix several race conditions in nbd. It
requires reverting the already included (but incomplete)
nbd-race-fix.patch that's in -mm5.

This patch fixes the following race conditions:

1) adds an increment of req->ref_count to eliminate races between
do_nbd_request and nbd_end_request, which resulted in the freeing of
in-use requests -- there were races between send/receive, send/shutdown
(killall -9 nbd-client), and send/disconnect (nbd-client -d), which are
now all fixed

2) adds locking and properly orders the code in NBD_CLEAR_SOCK to
eliminate races with other code

3) adds an lo->sock check to nbd_clear_que to eliminate races between
do_nbd_request and nbd_clear_que, which resulted in the dequeuing of
active requests

4) adds an lo->sock check to NBD_DO_IT to eliminate races with
NBD_CLEAR_SOCK, which caused an Oops when "nbd-client -d" was called

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

The P4 thermal interrupt vector was only getting set on SMP builds.

From: Oleg Drokin <green@namesys.com>

This patch fixes a problem in reiserfs' handling of immutable attribute,
where every user (not just root) can unset it.  Also it adds "append-only"
attribute "support" (all the support is in VFS anyway, we only recognise the
bit now).  Also misleading comment in reiserfs_fs.h is removed.

From: Oleg Drokin <green@namesys.com>

There is a leftover kunmap in reiserfs_unprepare_pages() which was not
deleted after conversion to kmap_atomic.  This path is virtually never
executed, that's why it was not caught earlier.  Please apply.

The pipe code's mtime and ctime updates are causing writes to read-only
mounted filesystems.

Fix that up by teaching inode_update_time() to honour readonly mounts, and
call it from the pipe code.

From: Nick Piggin <piggin@cyberone.com.au>

Following patch seperates elevator noop, and allows it to be treated
like the other schedulers.

From: Mark Haverkamp <markh@osdl.org>

Properly implement elevator_t..elevator_requeue_req_fn for the anticipatory
scheduler.

This fixes some rarely-occurring oops in the IO scheduler.

From: Nick Piggin <piggin@cyberone.com.au>

Gets rid of the silly (and undocumented) trinary stateness of
ad->changed_batch.

Kernel style flags field could now save 20 bytes per asd (request queue) and
4 per arq.  But I figure that change can wait until I do autotuning...

From: Nick Piggin <piggin@cyberone.com.au>

The crazy HASH_VALID stuff now makes no difference now.  It was there to
try to enforce no merging over a barrier, but it turned out that requests
can just be reordered.  Jens picked this up a a while ago and fixed
deadline (and I AS) by simply dispatching all reqs on the queue on
encountering a barrier.  The hash valid stuff didn't get cleaned up.

From: Ingo Molnar <mingo@elte.hu>

It unifies the functionality of add_timer() and mod_timer(), and makes any
combination of the timer API calls completely SMP-safe.  del_timer() is still
not using the timer lock.

this patch fixes the only timer bug in 2.6 i'm aware of: the del_timer_sync()
+ add_timer() combination in kernel/itimer.c is buggy.  This was correct code
in 2.4, because there it was safe to do an add_timer() from the timer handler
itself, parallel to a del_timer_sync().

If we want to make this safe in 2.6 too (which i think we want to) then we
have to make add_timer() almost equivalent to mod_timer(), locking-wise.  And
once we are at this point i think it's much cleaner to actually make
add_timer() a variant of mod_timer().  (There's no locking cost for
add_timer(), only the cost of an extra branch.  And we've removed another
commonly used function from the icache.)

From: Albert Cahalan <albert@users.sourceforge.net>

This should improve timekeeping a bit @ 1000 HZ.

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

Fix "bio too big" problem with md

Whenever a device is attached to an md device, we make sure the sector
limits of the md device do not exceed those of the added device.

Alas, both POSIX and I got the fadvise() interface wrong.  It needs to take a
64-bit length, not a 32-bit one.  Because fadvise(POSIX_FADV_DONTNEED) on a
4TB file will require 1000 syscalls.  Silly.

There are glibc's in the wild which use the existing syscall, so we must
make a new one.

invalidate_mapping_pages() takes start/end, but fadvise is currently passing
it start/len.

This fixes the DMA interface to be backwards compatible with older
XFree86 versions, by looking at the I810_INIT_DMA parameters and
figuring out old version semantics.

CLONE_THREAD without CLONE_DETACHED will now return -EINVAL, and
for a while we will warn about anything that uses it (there are no
known users, but this will help pinpoint any problems if somebody
used to care about the invalid combination).

A part of the 64 bit kdev_t patch already got merged, and it changes the
format of /sys/block/<dev>/dev from %02x%02x to %u:%u.  The partition
could must also be changed.

e.g. cat /sys/block/hda/hda5/dev should return 3:5 instead of 0305

It was caused by improper IV calculation in loop.c

cryptoloop won't oops anymore if ECB mode is requested.

Just call them from the x86-64 entry code.

Also implement the x86-64 specific sys32_timer_create.

Add 32bit->64bit conversion functions for POSIX timers.

I kept timer_create architecture specific, because it does signal specific
stuff which is not portable enough for generic compat.

Add compat_sys_utimes for 32bit->64bit utimes conversion

Add compat_* functions for statfs64. The 32bit layout unfortunately
does not match x86-64.

This patch allows modules to work for ARM, and is the one thing which
prevents the standard tree from building for any ARM machine.

After reviewing the /proc/kcore and kclist issues, I've decided that I'm
no longer prepared to even _think_ about supporting /proc/kcore on ARM -
it just gets too ugly, and adds too much code to make it worth the effort,
the time or the energy to implement a solution to that problem.

/proc/kcore should probably go away, but in the meantime this just allows
ARM to ignore the issues.

makes 2.4->2.6 diff noticeable smaller

and add stripped down buffer_head variant (struct idetape_bh).

ide-tape is accessed by a char device (not a block one!),
it uses block layer only to queue requests.

also add missing Kconfig help entry from 2.4.x

- more locking fixes
- preserve gendev.parent of the old hwif in the new one

Noticed by Andries.Brouwer@cwi.nl.

Also:
- kill probe_lba_addressing() wrapper
- rename hwif->addressing to hwif->no_lba48

From Andries.Brouwer@cwi.nl.

- always use drive->capacity48 and kill drive->capacity

I've changed drive->capacity48 to drive->capacity64 to avoid confusion.