From: Jens Axboe <axboe@suse.de>

Move both request_queue and io_context allocation to a slab cache.

This is mainly a space-saving exercise.  Some setups have a lot of disks
and the kmalloc rounding-up can consume significant amounts of memory.

From: Warren Togami <wtogami@redhat.com>

From: Markus Lidel <Markus.Lidel@shadowconnect.com>

The patch converts i2o_proc to seq_file, thereby fixing a bug in the
i2o_proc.c module, where the kernel panics, if you access /proc/i2o/iop0/lct
and read more then 1024 bytes of it.

From: James Simmons <jsimmons@infradead.org>

It ports this driver to sysfs api and fixes a colormap issue.

From: Fabrice Menard <menard.fabrice@wanadoo.fr>

Trying to solve my latin1 char problems with the framebuffer console, I
found that fbcon doesn't set a unicode map.

From: James Simmons <jsimmons@infradead.org>

This is the new asiliant framebuffer driver.

From: Geert Uytterhoeven <geert@linux-m68k.org>

On Sun, 25 Apr 2004, James Simmons wrote:
> This patch migrates the Vesa Framebuffer driver over to the
> framebuffer_alloc/framebuffer_release api. It also fixes the error
> handling paths. The mtrr issue that Geert brought up has been fixed.
> With your approval Geert, Ben please apply this patch.

> +	/* Set video size according to vram boot option */
> +	if (vram && vram * 1024 * 1024 != vesafb_fix.smem_len)
> +		vesafb_fix.smem_len = vram * 1024 * 1024;

The second part of the test can be removed. The rest looks OK to me.

From: James Simmons <jsimmons@infradead.org>

This patch migrates the Vesa Framebuffer driver over to the
framebuffer_alloc/framebuffer_release api.  It also fixes the error
handling paths.  The mtrr issue that Geert brought up has been fixed.

From: James Simmons <jsimmons@infradead.org>

This is attempt 2 at the virtual framebuffer patch.  It migrates the driver
to the framebuffer_release/framebuffer_alloc api.  It doesn't enable the
driver by default.

From: Jim Hague <jim.hague@acm.org>

It fixes the NULL pointer dereference and also a problem in pm2fb_blank().

From: James Simmons <jsimmons@infradead.org>

Set the default access_align variable.  This variable tells us how much data
the hardware can handle in a single read/write cycle.  For example the epson
chipset can handle only 16 bit reads and writes to the framebuffer.

From: James Simmons <jsimmons@infradead.org>

Remove extra variable. We use i instead of rc.

From: James Simmons <jsimmons@infradead.org>

This patch removes the redundent calculation of p->vrows.  This is done in
fbcon_resize.

From: James Simmons <jsimmons@infradead.org>

This make the logo handling code easier to read.  Merged the two code blocks
since they test for the exact same condition.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

drivers/video/imsttfb.c:1089: warning: `imsttfb_load_cursor_image' defined but not used
drivers/video/imsttfb.c:1159: warning: `imstt_set_cursor' defined but not used

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

Fix this:

drivers/video/tdfxfb.c:1005: warning: `tdfxfb_cursor' defined but not used

and make the acceleration function selectable (like hgafb and tridentfb)

Geert says:

 tdfxfb_cursor() was not used before, causing a compiler warning. 
 tdfxfb_cursor() may work, but we don't know, so we didn't dare to enable it
 by default.  Now the user (he who has the hardware) can enable it, and tell
 us whether it works or not.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

Make HGA acceleration functions selectable in kernel config, fix these
warnings:

drivers/video/hgafb.c:452: warning: `hgafb_fillrect' defined but not used
drivers/video/hgafb.c:472: warning: `hgafb_copyarea' defined but not used
drivers/video/hgafb.c:502: warning: `hgafb_imageblit' defined but not used

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

Speaking with frame buffer people, we agree with this patch to fix the
warning:

drivers/video/tridentfb.c:455: warning: `tridentfb_fillrect' defined but not used
drivers/video/tridentfb.c:473: warning: `tridentfb_copyarea' defined but not used

From: James Simmons <jsimmons@infradead.org>

Here is a updated driver for the neomagic.

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

> My screen is still a bit garbeld after booting.
> Still like http://zodiac.dnsalias.org/images/garbage.jpg

Yes, usual boot-time x86 garbage. Well, let's imagine it's as simple
as clearing the framebuffer during boot :) Try this patch and let me
know. If that doesn't help, then the problem is definitely in fbcon.

From: <raven@themaw.net>

These are the ioctls that need to be added to the compatibility layer.

They are all esentially the same as the AUTOFS_IOC_PROTOVER in their 
requirements and so should be fine.

From: Ian Kent <raven@themaw.net>

The case where two process similtaneously trigger a mount in autofs4 can
cause multiple requests to the daemon for the same mount.  The daemon
handles this OK but it's possible an incorrect error to be returned.  For
this reason I believe it is better to change the spin lock to a semaphore
in waitq.c.  This makes the second and subsequent request wait on the q as
ther supposed to.

From: Ian Kent <raven@themaw.net>

Needed for support coming development plans.

From: Ian Kent <raven@themaw.net>

Add ioctl to find out if autofs mount can be umounted.  When the daemon
discovers this it's past the point of no return.

From: <raven@themaw.net>

Pushed changes in sys_chdir and sys_chroot into the revalidate/lookup by
using nameidata hint.

From: Ian Kent <raven@themaw.net>

a. Implement readdir and friends for directory lookup for late mounting.
   This is done largely by replacing a catch all condition in
   try_to_fill_dentry with appropriate cases.

b. Add path calc.  function in waitq.c to get extended path to return to
   daemon (for direct mounts).

c. Add revalidate calls to sys_chdir and sys_chroot so that pwd lookups
   work correctly.

d. Add ioctl to retrieve minor version for automount daemon (and me) to
   recognise module fix level.  Bumped minor version to 5.

From: Hugh Dickins <hugh@veritas.com>

  After chdir (or chroot) to non-existent directory on 2.6.5-mm5, you can no
  longer unmount filesystem holding working directory (or root).

From: <raven@themaw.net>

Patch to sync 2.6.6-rc2-mm2 with the result of my discussion with 
Christoph Hellwig.

Difference is that Christoph realised that merging may_umount_tree and
may_umount was not worth it. They are now seperate functions.

From: Ian Kent <raven@themaw.net>

This patch is the result of an e-mail discussion with Soni Maneesh.  He felt
that the use of reference counts in the expire module is unreliable (in the
presence of rcu) and suggested it should use standard VFS calls where
possible.  This has been done.  Once the boundary in autofs is reached we
have no choice but to resort using reference counts (but under the
vfsmount_lock).


After review by hch:

- renamed autofs4_may_umount to __may_umount_tree, made it static and moved
  it to namespace.c.

- added stub function may_umount_tree with description

- altered may_umount to use above stub function and added little description

- added may_umount_tree prototype to fs.h

- removed the EXPORT_SYMBOL for vfsmount_lock

- updated expire.c to suit

From: Ian Kent <raven@themaw.net>

Remove BKL from autofs4 module and add spinlock to serialise access to the
automount daemon communication waitq.

Locking requirements are different in 2.6 and so I'm seeking comments and
suggestions on this.  I have taken a rather heavy handed approach to this in
the patch.  For example, the VFS operations that directly change the
filesystem, such as autofs4_mkdir etc, hold the inode semaphore on entry so
the BKL has been removed.  I can't see why two locking mechanisms are needed.
 Rather than add locking all over the place, I'm looking for justification
it's needed, as I don't see it myself.

From: Ian Kent <raven@themaw.net>

- Correct text in DPRINTK messages and comments, a little reformating and
  correct URL location for autofs v4 in Kconfig message.

- Fix error-path memory leak in autofs4_fill_super()

From: Ian Kent <raven@themaw.net>

From: Jeff Mahoney <jeffm@suse.com>

I saw a recent bug report that showed when a process set up a dnotify
against the autofs root and then attempted an access(2) call inside the
autofs namespace on a mount that would fail, it would create a
signal/restart loop.

The cause is that the autofs code checks to see if any signals are pending
after it waits on a response from the autofs daemon.  If it finds any, it
assumes that autofs_wait was interrupted, and that it should return
-ERESTARTNOINTR.  The problem with this is that a signal_pending(current)
check will return true if *any* signals were received, not just if a signal
that interrupted the wait was received.  autofs_wait explicitly blocks all
signals except for SIGKILL, SIGQUIT, and SIGINT before calling
interruptible_sleep_on.

The effect is that if a dnotify is set against the autofs root, when the
autofs daemon creates the directory, a dnotify event will be sent to the
originating process.  Since the code in autofs_root_lookup doesn't check to
see what signals are actually pending, it bails early, telling the caller
to try again.  The loop goes on forever until interrupted via one of the
actual interrupting signals.

The following patch makes both autofs_root_lookup and autofs4_root_lookup
verify that one of its defined "shutdown" signals are pending before
bailing out early.  Any other signal should be delivered later, as
expected.  It doesn't matter if the signal occured outside of the sleep in
autofs_wait.  The calling process will either go away or try again.

From: Dave Jones <davej@redhat.com>

To catch accidental usage of floating point.  Has been in -mm for ages.

From: Nick Piggin <nickpiggin@yahoo.com.au>

From: Suresh Siddha <suresh.b.siddha@intel.com>

Node max rebalance interval is too large.  It is currently dependent on
number of online cpus.  For 16 cpu system, max node balance interval in
busy case is 32 seconds.  Agreed that it will use max 32 seconds only when
it doesn't find imbalance for a long time.  But this will lead to slow
response time in cases where load runs for a second with no imbalance and
suddently creates an imbalance.  My patch makes the busy max node rebalance
interval equal to the base [scheduler].

From: Nick Piggin <nickpiggin@yahoo.com.au>

Analysis and basic idea from Suresh Siddha <suresh.b.siddha@intel.com>

"This small change in load_balance() brings the performance back upto base
scheduler(infact I see a ~1.5% performance improvement now).  Basically
this fix removes the unnecessary double_lock.."

Workload is SpecJBB on 16-way Altix.

From: Nick Piggin <nickpiggin@yahoo.com.au>

Fine-tune the unsynched sched_clock handling.

Basically, you need to be careful about ensuring timestamps get correctly
adjusted when moving CPUs, and you *can't* look at your unadjusted
sched_clock() and a remote task's ->timestamp and try to come up with
anything meaningful.

I think this second problem will really hit hard in the activate_task path
on systems with unsynched sched_clock when you're waking up a remote task,
which happens very often.  Andi, I thought some Opterons have unsynched
tscs?  Maybe this is causing your unexplained bad interactivity?

Another problem is a fixup in pull_task.  When adjusting ->timestamp from
one processor to another, you must use timestamp_last_tick for the local
processor too.  Using sched_clock() will cause ->timestamp to creep
forward.

A final small fix is for sync wakeups.  They were using __activate_task for
some reason, thus they don't get credited for sleeping at all AFAIKS.

And another thing, do we want to #ifdef timestamp_last_tick so it doesn't
show on UP?

From: Nick Piggin <nickpiggin@yahoo.com.au>

"Siddha, Suresh B" <suresh.b.siddha@intel.com> noticed a problem in the
cpu_load averaging where the integer truncation could sometimes cause cpu_load
to never quite reach its target.

I'm not sure that you could demonstrate a real world problem, but I quite
like this fix.

Fix bug identified by Chris Mason.

If writeback_inodes is left holding a ref on the superblock's last inode then
the superblock list walk can race with umount and the superblock can be
released.

Take and put a ref against the superblock to fix that.

From: Adam Litke <agl@us.ibm.com>

Teach the x86 stack tracing code to use frame pointers, if they are available.
It eliminates all the false-positives in the normal stack traces.

This is a big improvement, and -fomit-frame-pointer seems to make no
difference at all to generated code size.  Maybe we should kill off
-fomit-frame-pointer.

This fixes a problem with multiple IDE controllers in a system.

The problem is that pcibios_fixups table (in arch/i386/pci/fixup.c) uses
the pci_fixup_ide_trash() quirk for Intel's ICH3 (my case specifically
8086:248b).  This clears any bogus BAR information set up by the BIOS.

In a system which has multiple ICH3's can't use any of the IDE
controllers beside the one on the first ICH3.

Anyhow, the fix is to make sure pci_fixup_ide_trash resets the BARs only
for first time being called, so the subsequent IDE controllers will use
the BIOS BARs.  This is better than "loosing" all these IDE controllers
in the case their BARs set right.

The issue discussed and agreed with Bartlomiej Zolnierkiewicz (see below).