Found by the Stanford locking checker
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Found by the Stanford locking checker.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fix deadlock identified by the Stanford locking checker.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Lamely fix a straightforward deadlock in sb_audio.c.  Founf by the Stanford
locking checker.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fix deadlock identified by the Stanford locking checker.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Found by the new Stanford locking checker.

Minimal fix for a deadlock in sysvfs: get_branch() can take
read_lock(&pointers_lock), but one caller already has a write_lock.

Perhaps some of the "oh we raced, drop everything and try again" logic in
there can go away now, but this is enugh to fix the obvious deadlock.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

I did some simple benchmarking (time cat linux-2.6.7-mm5/MAINTAINERS)
between 2.4 and 2.6 and I am not satisfied with what I see (It's claimed
that fbdev-2.6 is faster than 2.4).  The reason for the claim:

2.4 putcs - draw small amounts of data a lot of times
2.6 putcs - draw larger amounts of data a fewer times

The way characters are drawn in 2.6 is optimal for accelerated drivers but
should also give a speed boost for drivers that rely on software drawing.
However the penaly incurred when preparing a large bitmap from a number of
small bitmaps is currently very high.  This is because of the following
reasons:

1 fb_move_buf_{aligned|unaligned} uses pixmap->{out|in}buf.  This is very
  expensive since outbuf and inbuf methods process only a byte or 2 of data
  at a time.

2 fb_sys_outbuf (the default method for pixmap->outbuf) uses memcpy().
  Not a good choice if moving only a few bytes.

3 fb_move_buf_unaligned (used for fonts such as 12x22) also involves a
  lot of bit operations + a lot of calls to outbuf/inbuf which
  proportionately increases the penaly.

So, I thought of separating fb_move_buf_* to fb_iomove_buf_* and
fb_sysmove_buf_*. 

	fb_iomove_buf_* - used if drivers specified outbuf and inbuf methods
	fb_sysmove_buf_* - used if drivers have no outbuf or inbuf methods

	*Most, if not all drivers fall in the second category.

Below is a table that show differences between 2.4, 2.6 and 2.6 +
abovementioned changes.  To reduce the effect of panning and
fillrect/copyarea, the scrollmode is forced to redraw.

=================================================================
Test Hardware: P4 2G nVidia GeForce2 MX 64
Scrollmode: redraw

time cat linux-2.6.7-mm5/MAINTAINERS

1024x768-8		1024x768-16		1024x768-32
=================================================================
8x16 noaccel (2.4)
real    0m5.490s	real    0m8.535s	real    0m15.388s
user    0m0.001s	user    0m0.000s	user    0m0.001s
sys     0m5.487s	sys     0m8.535s	sys     0m15.386s

8x16 noaccel (2.6)
real    0m5.166s	real    0m7.195s	real    0m12.177s
user    0m0.001s	user    0m0.000s	user    0m0.000s
sys     0m5.164s	sys     0m7.192s	sys     0m12.176s

8x16 noaccel+patch (2.6)
real    0m3.474s	real    0m5.496s	real    0m10.460s
user    0m0.001s	user    0m0.001s	user    0m0.001s
sys     0m5.492s	sys     0m5.492s	sys     0m10.454s
=================================================================
8x16 accel (2.4)
real    0m4.368s	real    0m9.420s	real    0m22.415s
user    0m0.001s	user    0m0.001s	user    0m0.001s
sys     0m4.019s	sys     0m9.384s	sys     0m22.312s

8x16 accel (2.6)
real    0m4.296s	real    0m4.339s	real    0m4.391s
user    0m0.001s	user    0m0.001s	user    0m0.000s
sys     0m4.280s	sys     0m4.336s	sys     0m4.389s

8x16 accel+patch (2.6)
real    0m2.536s	real    0m2.649s	real    0m2.799s
user    0m0.000s	user    0m0.000s	user    0m0.001s
sys     0m2.536s	sys     0m2.645s	sys     0m2.798s
=================================================================

1024x768-8		1024x768-16		1024x768-32
=================================================================
12x22 noaccel (2.4)
real    0m7.883s	real    0m12.175s	real    0m21.134s
user    0m0.000s	user    0m0.000s	user    0m0.001s
sys     0m7.882s	sys     0m12.174s	sys     0m21.129s

12x22 noaccel (2.6)
real    0m10.651s	real    0m13.550s	real    0m21.009s
user    0m0.001s	user    0m0.001s	user    0m0.000s	
sys     0m10.617s	sys     0m13.545s	sys     0m21.008s

12x22 noaccel+patch (2.6)
real    0m4.794s	real    0m7.718s	real    0m15.173s
user    0m0.002s	user    0m0.001s	user    0m0.000s
sys     0m4.792s	sys     0m7.715s	sys     0m15.170s
=================================================================
12x22 accel (2.4)
real    0m3.971s	real    0m9.030s	real    0m21.711s
user    0m0.000s	user    0m0.000s	user    0m0.000s
sys     0m3.950s	sys     0m8.983s	sys     0m21.602s

12x22 accel (2.6)
real    0m9.392s	real    0m9.486s	real    0m9.508s
user    0m0.000s	user    0m0.000s	user    0m0.001s
sys     0m9.392s	sys     0m9.484s	sys     0m9.484s

12x22 accel+patch (2.6)
real    0m3.570s	real    0m3.603s	real    0m3.848s
user    0m0.001s	user    0m0.000s	user    0m0.000s
sys     0m3.567s	sys     0m3.600s	sys     0m3.844s
=================================================================


Summary:

1 2.6 unaccelerated is a bit faster than 2.4 when handling 8x16 fonts,
  with a higher speed differential at high color depths.

2 2.4 unaccelerated is a bit faster than 2.6 when handling 12x22 fonts,
  with a smaller speed difference at high color depths (2.6 is actually a
  bit faster than 2.4 at 32bpp).

3 2.4 rivafb accelerated suffers at high color depths, even becoming
  slower than unaccelerated, possibly because of the 'draw few bytes many
  times' method.

4 2.6 rivafb accelerated has similar performance at any color depth,
  possibly because of 'draw lots of bytes a fewer times' method.

5 With the changes, there is a speed gain of ~1.7 seconds and ~5.7
  seconds with 8x16 and 12x22 fonts respectively indepependent of the color
  depth or acceleration used.  The speed gain is constant but significant.

Below is a patch against 2.6.7-mm5.  The effects will be very noticeable
with drivers that uses SCROLL_REDRAW, but one should still see some speed
gain even if SCROLL_YPAN/YWRAP is used.


Separated fb_sys_move_* into fb_iosys_move_* and fb_sysmove_* to reduce
penalty when constructing fb_image->data from character maps.  In my
testcase (1024x768 SCROLL_REDRAW), I get a ~1.7 second advantage with 'time
cat MAINTAINERS' using 8x16 fonts and ~5.7 seconds with 12x22 fonts.  The
speed gain is independent of acceleration or color depth.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

rmk's patch found a defined-but-unimplemented symbol
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It fixes a possible race between quotaoff and prune_icache.  The race could
lead to some forgotten pointers to quotas in inodes leading later to BUG
when invalidating quota structures.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Based on work from Bill Irwin <wli@holomorphy.com>

physnode_map[] needs to be signed so that pfn_to_nid() can return negative
values used to detect invalid pfn's.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch enables the Redwood 5 and Redwood 6 platforms to use the smc91x
ethernet driver.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We have a platform-specific function pointer on ppc64 for a function to log
errors detected by the platform, but it was never getting set.  This patch
sets it on pSeries (the only ppc64 platform which has an error logging
function).
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

From: Linas Vepstas <linas@austin.ibm.com>

This patch eliminates the usage of the deprecated ibm,fw-phb-id token for
idnetifying PCI bus heads in favor of the documented, offically supported
mechanism for obtaining this info.  Please note that some versions of
firmware may return incorrect values for the ibm,fw-phb-id token.
Signed-off-by: Linas Vepstas <linas@linas.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

gcc-2.95 chokes on this.

Cc: Anton Altaparmakov <aia21@cantab.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

SuSE discovered this problem with chown and ATTR_GID.  Make sure user
is authorized to change the group, CAN-2004-0497.

It's one of the rare files that has almost no includes
what-so-ever, so it actually never got NULL any other
way.

Two years ago, OGAWA Hirofumi removed some ugly code and
added a few simple tests to the FAT filesystem code,
intended to avoid recognizing non-FAT as FAT (for people who
fail to specify rootfstype=, forcing the kernel to guess).

That worked fairly well, until this year.

I have now seen a thread in Czech and a report from Holland that
involved the "FAT: bogus sectors-per-track value" error message.

The patch below removes this test again. The advantage is that
some real-life FAT filesystems can be mounted again.

The disadvantage that more non-FAT fss will be accepted as FAT.

Ferry van Steen <freaky@bananateam.nl> reports "the patch Andries
Brouwer gave me seems to work".
Signed-off-by: Andries Brouwer <aeb@cwi.nl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This fixes the the remaining 0 to NULL things that were found with 'make
allmodconfig' and 'make C=1 vmlinux'.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into cantab.net:/home/src/ntfs-2.6

into cantab.net:/home/src/ntfs-2.6

      enables the writing of page cache pages belonging to mst protected
      attributes like the index allocation attribute in directory indices
      and other indices like $Quota/$Q, etc.  This means that the quota is
      now marked out of date on all volumes rather than only on ones where
      the quota defaults entry is in the index root attribute of the
      $Quota/$Q index.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>

      page has buffers.  Otherwise we could end up with a dirty page
      without buffers and our set_page_dirty() would not mark the buffers
      dirty when they are created and thus they would not be written out
      and the dirty records would be lost.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>

Any proc entry with default proc_file_inode_operations allow unauthorized
attribute updates.  This is very dangerous for proc entries that rely
solely on file permissions for open/read/write.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

      buffers that are inside the ntfs record in the page dirty after which
      it sets the page dirty.  This allows ->writepage to only write the
      dirty index records rather than having to write all the records in
      the page.  Modify fs/ntfs/index.h::ntfs_index_entry_mark_dirty() to
      use this rather than __set_page_dirty_nobuffers().
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>

      It is simply set to __set_page_dirty_nobuffers() to make sure that
      running set_page_dirty() on a page containing mft/ntfs records will
      not affect the dirty state of the page buffers.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into kernel.bkbits.net:/home/davem/tg3-2.6

into ppc970.osdl.org:/home/torvalds/v2.6/linux

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

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

It can return with the lock held.

Found by the Stanford locking checker.
Signed-off-by: Andrew Morton <akpm@osdl.org>

into pobox.com:/spare/repo/net-drivers-2.6

Included is a patch for linux to add a PCI vendor/device ID for the
Radisys ENP-2611 board.  The ENP-2611 is a 64bit/66MHz PCI board which
hosts an Intel IXP2400 network processor, has three GigE interfaces,
runs linux and generally kicks ass.

(see http://www.radisys.com/oem_products/ds-page.cfm?productdatasheetsid=1147)
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Please review and apply the following patch if you find it agreeable.

This patch does not make any functional changes, but does improve
both performance and memory usage by rearranging structure elements.

The need for these changes became appearent during a code review of
the disassembly involving this structure. The memory footprint of this
structure is made smaller by grouping the byte fields next to each other.
The access of the list_head can be simplified by making it the first element
of the structure, thus avoiding a needless add-immediate without negatively
impacting any of the other accesses.
Signed-off-by: Linas Vepstas <linas@linas.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch fixes a null-pointer dereference when hot-plug operations
are performed on a machine that has virtual-io devices in it.
Virtual i/o devices to not have pci bridges associated with them.
It also corrects an ordering problem during hotplug remove.

This patch was previously reviewed/tested by Linda Xie, the current
rpaphp maintainer.
Signed-off-by: Linas Vepstas <linas@linas.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>