[patch 00/19] 2.6.17-stable review

[patch 00/19] 2.6.17-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.17.14 release.
There are 19 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc:
line.  If you wish to be a reviewer, please email stable@kernel.org to
add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Thursday, Octover 12, 18:00:00 UTC.
Anything received after that time might be too late.

thanks,

the -stable release team

[patch 01/19] dvb-core: Proper handling ULE SNDU length of 0 (CVE-2006-4623)

[Greg KH]

[-- Attachment #1: dvb-core-proper-handling-ule-sndu-length-of-0.patch --]
[-- Type: text/plain, Size: 1369 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Ang Way Chuang <wcang@nrg.cs.usm.my>

ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that allows an attacker to send a malformed ULE packet
with SNDU length of 0 and bring down the receiving machine. This patch
fix the bug and has been tested on version 2.6.17.11. This bug is 100%
reproducible and the modified source code (GPL) used to produce this bug
will be posted on http://nrg.cs.usm.my/downloads.htm shortly.  The
kernel will produce a dump during CRC32 checking on faulty ULE packet.


Signed-off-by: Ang Way Chuang <wcang@nrg.cs.usm.my>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/dvb/dvb-core/dvb_net.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.17.13.orig/drivers/media/dvb/dvb-core/dvb_net.c
+++ linux-2.6.17.13/drivers/media/dvb/dvb-core/dvb_net.c
@@ -492,7 +492,8 @@ static void dvb_net_ule( struct net_devi
 				} else
 					priv->ule_dbit = 0;
 
-				if (priv->ule_sndu_len > 32763) {
+				if (priv->ule_sndu_len > 32763 ||
+				    priv->ule_sndu_len < ((priv->ule_dbit) ? 4 : 4 + ETH_ALEN)) {
 					printk(KERN_WARNING "%lu: Invalid ULE SNDU length %u. "
 					       "Resyncing.\n", priv->ts_count, priv->ule_sndu_len);
 					priv->ule_sndu_len = 0;

--

[patch 02/19] NFS: Fix a potential deadlock in nfs_release_page

[Greg KH]

[-- Attachment #1: nfs-fix-a-potential-deadlock-in-nfs_release_page.patch --]
[-- Type: text/plain, Size: 1107 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Nikita Danilov <nikita@clusterfs.com>

nfs_wb_page() waits on request completion and, as a result, is not safe to be
called from nfs_release_page() invoked by VM scanner as part of GFP_NOFS
allocation. Fix possible deadlock by analyzing gfp mask and refusing to
release page if __GFP_FS is not set.

Signed-off-by: Nikita Danilov <danilov@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/nfs/file.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.17.13.orig/fs/nfs/file.c
+++ linux-2.6.17.13/fs/nfs/file.c
@@ -325,7 +325,13 @@ static void nfs_invalidate_page(struct p
 
 static int nfs_release_page(struct page *page, gfp_t gfp)
 {
-	return !nfs_wb_page(page->mapping->host, page);
+	if (gfp & __GFP_FS)
+		return !nfs_wb_page(page->mapping->host, page);
+	else
+		/*
+		 * Avoid deadlock on nfs_wait_on_request().
+		 */
+		return 0;
 }
 
 struct address_space_operations nfs_file_aops = {

--

[patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Greg KH]

[-- Attachment #1: sunrpc-avoid-choosing-an-ipmi-port-for-rpc-traffic.patch --]
[-- Type: text/plain, Size: 1014 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Chuck Lever <chuck.lever@oracle.com>

Some hardware uses port 664 for its hardware-based IPMI listener.  Teach
the RPC client to avoid using that port by raising the default minimum port
number to 665.

Test plan:
Find a mainboard known to use port 664 for IPMI; enable IPMI; mount NFS
servers in a tight loop.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/linux/sunrpc/xprt.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/include/linux/sunrpc/xprt.h
+++ linux-2.6.17.13/include/linux/sunrpc/xprt.h
@@ -37,7 +37,7 @@ extern unsigned int xprt_max_resvport;
 
 #define RPC_MIN_RESVPORT	(1U)
 #define RPC_MAX_RESVPORT	(65535U)
-#define RPC_DEF_MIN_RESVPORT	(650U)
+#define RPC_DEF_MIN_RESVPORT	(665U)
 #define RPC_DEF_MAX_RESVPORT	(1023U)
 
 /*

--

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Jan Engelhardt]

>Some hardware uses port 664 for its hardware-based IPMI listener.  Teach
>the RPC client to avoid using that port by raising the default minimum port
>number to 665.

Eh, that does look more like a quick hack. What if there were enough
manufacturers around to use various parts, like manuf. A using 664, B using 800
and C using 1000? Then the port range would have to be cut down again and
again.


	-`J'
-- 
[A

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Trond Myklebust]

On Tue, 2006-10-10 at 20:59 +0200, Jan Engelhardt wrote:
> >Some hardware uses port 664 for its hardware-based IPMI listener.  Teach
> >the RPC client to avoid using that port by raising the default minimum port
> >number to 665.
> 
> Eh, that does look more like a quick hack. What if there were enough
> manufacturers around to use various parts, like manuf. A using 664, B using 800
> and C using 1000? Then the port range would have to be cut down again and
> again.
> 
> 
> 	-`J'

Feel free to tell the board manufacturers that they are idiots, and
should not design boards that hijack specific ports without providing
the O/S with any means of detecting this, but in the meantime, it _is_
the case that they are doing this.

Cheers,
  Trond

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Alan Cox]

Ar Mer, 2006-10-11 am 19:45 -0400, ysgrifennodd Trond Myklebust:
> Feel free to tell the board manufacturers that they are idiots, and
> should not design boards that hijack specific ports without providing
> the O/S with any means of detecting this, but in the meantime, it _is_
> the case that they are doing this.

Then their hardware is faulty and should be specifically blacklisted not
make everyone have to deal with silly unmaintainable hacks.

Alan

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Trond Myklebust]

On Thu, 2006-10-12 at 02:12 +0100, Alan Cox wrote:
> Ar Mer, 2006-10-11 am 19:45 -0400, ysgrifennodd Trond Myklebust:
> > Feel free to tell the board manufacturers that they are idiots, and
> > should not design boards that hijack specific ports without providing
> > the O/S with any means of detecting this, but in the meantime, it _is_
> > the case that they are doing this.
> 
> Then their hardware is faulty and should be specifically blacklisted not
> make everyone have to deal with silly unmaintainable hacks.

They are not hacks. The actual range of ports used by the RPC client is
set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
broken motherboards can override the default range, which is all that we
are changing here.

To be fair, the motherboard manufacturers have actually registered these
ports with IANA:

asf-rmcp        623/tcp    ASF Remote Management and Control Protocol
asf-rmcp        623/udp    ASF Remote Management and Control Protocol

asf-secure-rmcp 664/tcp    ASF Secure Remote Management and Control Protocol
asf-secure-rmcp 664/udp    ASF Secure Remote Management and Control Protocol

but the problem remains that we have no way to actually detect a
motherboard that uses those ports.

Interestingly, Linux is not the only OS that has been hit by this
problem:

  http://blogs.sun.com/shepler/entry/port_623_or_the_mount

Cheers,
  Trond

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Matt Domsch]

On Wed, Oct 11, 2006 at 06:35:05PM -0700, Trond Myklebust wrote:
> On Thu, 2006-10-12 at 02:12 +0100, Alan Cox wrote:
> > Ar Mer, 2006-10-11 am 19:45 -0400, ysgrifennodd Trond Myklebust:
> > > Feel free to tell the board manufacturers that they are idiots, and
> > > should not design boards that hijack specific ports without providing
> > > the O/S with any means of detecting this, but in the meantime, it _is_
> > > the case that they are doing this.
> > 
> > Then their hardware is faulty and should be specifically blacklisted not
> > make everyone have to deal with silly unmaintainable hacks.
> 
> They are not hacks. The actual range of ports used by the RPC client is
> set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
> broken motherboards can override the default range, which is all that we
> are changing here.
> 
> To be fair, the motherboard manufacturers have actually registered these
> ports with IANA:
> 
> asf-rmcp        623/tcp    ASF Remote Management and Control Protocol
> asf-rmcp        623/udp    ASF Remote Management and Control Protocol
> 
> asf-secure-rmcp 664/tcp    ASF Secure Remote Management and Control Protocol
> asf-secure-rmcp 664/udp    ASF Secure Remote Management and Control Protocol
> 
> but the problem remains that we have no way to actually detect a
> motherboard that uses those ports.

My hackish solution was to create a fake xinetd service listening on
those ports.

http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html

For the one Dell server affected, we could DMI list
it; likewise for others.


-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Trond Myklebust]

On Wed, 2006-10-11 at 20:53 -0500, Matt Domsch wrote:
> My hackish solution was to create a fake xinetd service listening on
> those ports.
> 
> http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html
> 
> For the one Dell server affected, we could DMI list
> it; likewise for others.

Right, but that requires prior knowledge that the board in question is
afflicted. Several people that were affected by the bug were unaware of
the motherboard behaviour.
The daemon solution also fails to provide any guarantees on a NFSROOT
setup.

In any case, as I said, these are just defaults which may be overridden
by the user at runtime.

Cheers,
  Trond

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Alan Cox]

Ar Mer, 2006-10-11 am 19:04 -0700, ysgrifennodd Trond Myklebust:
> The daemon solution also fails to provide any guarantees on a NFSROOT
> setup.

You know the ports that will be used at NFSroot setup time and they
won't currently get near the broken box problem ports. Also NFS root is
pretty much obsoleted by the initrd/pivot_root stuff.


Alan

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Alan Cox]

Ar Mer, 2006-10-11 am 20:53 -0500, ysgrifennodd Matt Domsch:
> > > Then their hardware is faulty and should be specifically blacklisted not
> > > make everyone have to deal with silly unmaintainable hacks.
> > 
> > They are not hacks. The actual range of ports used by the RPC client is
> > set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
> > broken motherboards can override the default range, which is all that we
> > are changing here.

No.. you have it backwards. The tiny tiny number of people with broken
boards can either set it themselves, use DMI, or ram the offending board
somewhere dark belonging to whoever sold it to them

> > To be fair, the motherboard manufacturers have actually registered these
> > ports with IANA:

This is irrelevant, they are stealing bits out of the incoming network
stream. That's not just rude its dangerous - they should have their own
MAC and IP stack for this. Port assignments are courtesy numbering to
avoid collisions on your own stack. They have no more right to steal
packets from that port than CERN does to claim all port 80 traffic on
the internet.

Why do I say dangerous - because they steal the data *before* your Linux
firewalling and feed it to an unauditable binary firmware which has
controlling access to large parts of the system without the OS even
seeing it.

Not a good idea IMHO on any box facing even a slightly insecure port.
 
> For the one Dell server affected, we could DMI list
> it; likewise for others.

This should be done with DMI I agree.

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Trond Myklebust]

On Thu, 2006-10-12 at 11:15 +0100, Alan Cox wrote:
> Ar Mer, 2006-10-11 am 20:53 -0500, ysgrifennodd Matt Domsch:
> > > > Then their hardware is faulty and should be specifically blacklisted not
> > > > make everyone have to deal with silly unmaintainable hacks.
> > > 
> > > They are not hacks. The actual range of ports used by the RPC client is
> > > set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
> > > broken motherboards can override the default range, which is all that we
> > > are changing here.
> 
> No.. you have it backwards. The tiny tiny number of people with broken
> boards can either set it themselves, use DMI, or ram the offending board
> somewhere dark belonging to whoever sold it to them

:-)

The main problem with that approach is that the offending boardmakers
tend to hide these details deep in technical docs that are not bundled
with the motherboard, and which consequently nobody actually reads.
Instead they see that NFS doesn't work, and conclude to waste NFS
community's time in debugging it.

We're still leaving a fairly large range of ports for the NFS client to
use: there should be 373 that are rife for the taking.

> > > To be fair, the motherboard manufacturers have actually registered these
> > > ports with IANA:
> 
> This is irrelevant, they are stealing bits out of the incoming network
> stream. That's not just rude its dangerous - they should have their own
> MAC and IP stack for this. Port assignments are courtesy numbering to
> avoid collisions on your own stack. They have no more right to steal
> packets from that port than CERN does to claim all port 80 traffic on
> the internet.
> 
> Why do I say dangerous - because they steal the data *before* your Linux
> firewalling and feed it to an unauditable binary firmware which has
> controlling access to large parts of the system without the OS even
> seeing it.
> 
> Not a good idea IMHO on any box facing even a slightly insecure port.

No arguments with this.

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Jan Engelhardt]

>Interestingly, Linux is not the only OS that has been hit by this
>problem:
>
>  http://blogs.sun.com/shepler/entry/port_623_or_the_mount

There is more to it. On a machine I had set up a second,
experimental, apache on port 880. And it randomly failed to start on
a boot because mountd had taken the port first.
Man, this RPC stuff should go and use fixed ports.


	-`J'
-- 

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Bernd Petrovitsch]

On Thu, 2006-10-12 at 09:58 +0200, Jan Engelhardt wrote:
> >Interestingly, Linux is not the only OS that has been hit by this
> >problem:
> >
> >  http://blogs.sun.com/shepler/entry/port_623_or_the_mount
> 
> There is more to it. On a machine I had set up a second,
> experimental, apache on port 880. And it randomly failed to start on
> a boot because mountd had taken the port first.

FWIW I had the same experience several times with port 631 (aka "IPP")
taken by some RPC service and CUPS simply didn't worked.

> Man, this RPC stuff should go and use fixed ports.

Hmm, starting the portmapper as late as possible so that other services
get the chance to use their ports?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Jan Engelhardt]

>> Man, this RPC stuff should go and use fixed ports.
>
>Hmm, starting the portmapper as late as possible so that other services
>get the chance to use their ports?

The SUN-TCP / SUN-UDP port mapping is a relic of old times.


	-`J'
-- 

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Trond Myklebust]

On Thu, 2006-10-12 at 09:58 +0200, Jan Engelhardt wrote:
> >Interestingly, Linux is not the only OS that has been hit by this
> >problem:
> >
> >  http://blogs.sun.com/shepler/entry/port_623_or_the_mount
> 
> There is more to it. On a machine I had set up a second,
> experimental, apache on port 880. And it randomly failed to start on
> a boot because mountd had taken the port first.
> Man, this RPC stuff should go and use fixed ports.

man 8 mountd and check out the '-p' option. statd has a similar one.
Even the in-kernel lockd daemon's can be set to listen to fixed ports.

So there really shouldn't be any problems nailing down your RPC ports.

Cheers,
  Trond

Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

[Jan Engelhardt]

>man 8 mountd and check out the '-p' option. statd has a similar one.
>Even the in-kernel lockd daemon's can be set to listen to fixed ports.
>
>So there really shouldn't be any problems nailing down your RPC ports.

Thank you for the hint. However, poking /etc/init.d/nfsserver to use
the -p option is probably just as bad as adding "mountd 49500/tcp" to
/etc/services I am currently doing -- both get reverted on a distro
upgrade. Switching to CIFS will probably solve it all - one port
instead of three/four (and a fixed one), much more firewall- and
initscript-friendly.


	-`J'
-- 

[patch 04/19] LOCKD: Fix a deadlock in nlm_traverse_files()

[Greg KH]

[-- Attachment #1: lockd-fix-a-deadlock-in-nlm_traverse_files.patch --]
[-- Type: text/plain, Size: 1546 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Trond Myklebust <Trond.Myklebust@netapp.com>

nlm_traverse_files() is not allowed to hold the nlm_file_mutex while calling
nlm_inspect file, since it may end up calling nlm_release_file() when
releaseing the blocks.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/lockd/svcsubs.c |   15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

--- linux-2.6.17.13.orig/fs/lockd/svcsubs.c
+++ linux-2.6.17.13/fs/lockd/svcsubs.c
@@ -238,19 +238,22 @@ static int
 nlm_traverse_files(struct nlm_host *host, int action)
 {
 	struct nlm_file	*file, **fp;
-	int		i;
+	int i, ret = 0;
 
 	mutex_lock(&nlm_file_mutex);
 	for (i = 0; i < FILE_NRHASH; i++) {
 		fp = nlm_files + i;
 		while ((file = *fp) != NULL) {
+			file->f_count++;
+			mutex_unlock(&nlm_file_mutex);
+
 			/* Traverse locks, blocks and shares of this file
 			 * and update file->f_locks count */
-			if (nlm_inspect_file(host, file, action)) {
-				mutex_unlock(&nlm_file_mutex);
-				return 1;
-			}
+			if (nlm_inspect_file(host, file, action))
+				ret = 1;
 
+			mutex_lock(&nlm_file_mutex);
+			file->f_count--;
 			/* No more references to this file. Let go of it. */
 			if (!file->f_blocks && !file->f_locks
 			 && !file->f_shares && !file->f_count) {
@@ -263,7 +266,7 @@ nlm_traverse_files(struct nlm_host *host
 		}
 	}
 	mutex_unlock(&nlm_file_mutex);
-	return 0;
+	return ret;
 }
 
 /*

--

[patch 05/19] NFS: More page cache revalidation fixups

[Greg KH]

[-- Attachment #1: nfs-more-page-cache-revalidation-fixups.patch --]
[-- Type: text/plain, Size: 1968 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Trond Myklebust <Trond.Myklebust@netapp.com>

Whenever the directory changes, we want to make sure that we always
invalidate its page cache. Fix up update_changeattr() and
nfs_mark_for_revalidate() so that they do so.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/nfs/nfs4proc.c      |   10 +++++-----
 include/linux/nfs_fs.h |    6 +++++-
 2 files changed, 10 insertions(+), 6 deletions(-)

--- linux-2.6.17.13.orig/fs/nfs/nfs4proc.c
+++ linux-2.6.17.13/fs/nfs/nfs4proc.c
@@ -185,15 +185,15 @@ static void renew_lease(const struct nfs
 	spin_unlock(&clp->cl_lock);
 }
 
-static void update_changeattr(struct inode *inode, struct nfs4_change_info *cinfo)
+static void update_changeattr(struct inode *dir, struct nfs4_change_info *cinfo)
 {
-	struct nfs_inode *nfsi = NFS_I(inode);
+	struct nfs_inode *nfsi = NFS_I(dir);
 
-	spin_lock(&inode->i_lock);
-	nfsi->cache_validity |= NFS_INO_INVALID_ATTR;
+	spin_lock(&dir->i_lock);
+	nfsi->cache_validity |= NFS_INO_INVALID_ATTR|NFS_INO_REVAL_PAGECACHE|NFS_INO_INVALID_DATA;
 	if (cinfo->before == nfsi->change_attr && cinfo->atomic)
 		nfsi->change_attr = cinfo->after;
-	spin_unlock(&inode->i_lock);
+	spin_unlock(&dir->i_lock);
 }
 
 struct nfs4_opendata {
--- linux-2.6.17.13.orig/include/linux/nfs_fs.h
+++ linux-2.6.17.13/include/linux/nfs_fs.h
@@ -234,8 +234,12 @@ static inline int nfs_caches_unstable(st
 
 static inline void nfs_mark_for_revalidate(struct inode *inode)
 {
+	struct nfs_inode *nfsi = NFS_I(inode);
+
 	spin_lock(&inode->i_lock);
-	NFS_I(inode)->cache_validity |= NFS_INO_INVALID_ATTR | NFS_INO_INVALID_ACCESS;
+	nfsi->cache_validity |= NFS_INO_INVALID_ATTR|NFS_INO_INVALID_ACCESS;
+	if (S_ISDIR(inode->i_mode))
+		nfsi->cache_validity |= NFS_INO_REVAL_PAGECACHE|NFS_INO_INVALID_DATA;
 	spin_unlock(&inode->i_lock);
 }
 

--

[patch 06/19] Backport: Old IDE, fix SATA detection for cabling

[Greg KH]

[-- Attachment #1: backport-old-ide-fix-sata-detection-for-cabling.patch --]
[-- Type: text/plain, Size: 1184 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------

From: Michael-Luke Jones <mlj28@cam.ac.uk>

This patch is identical to that introduced in
1a1276e7b6cba549553285f74e87f702bfff6fac to the Linus' 2.6 development tree 
by Alan Cox.

'This is based on the proposed patches flying around but also checks that
the device in question is new enough to have word 93 rather thanb blindly
assuming word 93 == 0 means SATA (see ATA-5, ATA-7)' -- Alan Cox

Required for my SATA drive on an Asus Pundit-R to operate above 33MBps.
 
Signed-off-by: Michael-Luke Jones <mlj28@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ide/ide-iops.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-2.6.17.13.orig/drivers/ide/ide-iops.c
+++ linux-2.6.17.13/drivers/ide/ide-iops.c
@@ -597,6 +597,10 @@ u8 eighty_ninty_three (ide_drive_t *driv
 {
 	if(HWIF(drive)->udma_four == 0)
 		return 0;
+
+    /* Check for SATA but only if we are ATA5 or higher */
+    if (drive->id->hw_config == 0 && (drive->id->major_rev_num & 0x7FE0))
+        return 1;
 	if (!(drive->id->hw_config & 0x6000))
 		return 0;
 #ifndef CONFIG_IDEDMA_IVB

--

[patch 07/19] invalidate_complete_page() race fix

[Greg KH]

[-- Attachment #1: invalidate_complete_page-race-fix.patch --]
[-- Type: text/plain, Size: 1435 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Andrew Morton <akpm@osdl.org>

If a CPU faults this page into pagetables after invalidate_mapping_pages()
checked page_mapped(), invalidate_complete_page() will still proceed to remove
the page from pagecache.  This leaves the page-faulting process with a
detached page.  If it was MAP_SHARED then file data loss will ensue.

Fix that up by checking the page's refcount after taking tree_lock.

Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/truncate.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

--- linux-2.6.17.13.orig/mm/truncate.c
+++ linux-2.6.17.13/mm/truncate.c
@@ -68,10 +68,10 @@ invalidate_complete_page(struct address_
 		return 0;
 
 	write_lock_irq(&mapping->tree_lock);
-	if (PageDirty(page)) {
-		write_unlock_irq(&mapping->tree_lock);
-		return 0;
-	}
+	if (PageDirty(page))
+		goto failed;
+	if (page_count(page) != 2)	/* caller's ref + pagecache ref */
+		goto failed;
 
 	BUG_ON(PagePrivate(page));
 	__remove_from_page_cache(page);
@@ -79,6 +79,9 @@ invalidate_complete_page(struct address_
 	ClearPageUptodate(page);
 	page_cache_release(page);	/* pagecache ref */
 	return 1;
+failed:
+	write_unlock_irq(&mapping->tree_lock);
+	return 0;
 }
 
 /**

--

Re: [patch 07/19] invalidate_complete_page() race fix

[Hugh Dickins]

On Tue, 10 Oct 2006, Greg KH wrote:

> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> From: Andrew Morton <akpm@osdl.org>
> 
> If a CPU faults this page into pagetables after invalidate_mapping_pages()
> checked page_mapped(), invalidate_complete_page() will still proceed to remove
> the page from pagecache.  This leaves the page-faulting process with a
> detached page.  If it was MAP_SHARED then file data loss will ensue.
> 
> Fix that up by checking the page's refcount after taking tree_lock.

I may have lost the plot, but I think this patch has already proved
to cause problems for NFS in 2.6.18: not good to put it into 2.6.17
stable while it's awaiting refinement for 2.6.18 stable.

Hugh

Re: [stable] [patch 07/19] invalidate_complete_page() race fix

[Greg KH]

On Tue, Oct 10, 2006 at 07:12:54PM +0100, Hugh Dickins wrote:
> On Tue, 10 Oct 2006, Greg KH wrote:
> 
> > -stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > From: Andrew Morton <akpm@osdl.org>
> > 
> > If a CPU faults this page into pagetables after invalidate_mapping_pages()
> > checked page_mapped(), invalidate_complete_page() will still proceed to remove
> > the page from pagecache.  This leaves the page-faulting process with a
> > detached page.  If it was MAP_SHARED then file data loss will ensue.
> > 
> > Fix that up by checking the page's refcount after taking tree_lock.
> 
> I may have lost the plot, but I think this patch has already proved
> to cause problems for NFS in 2.6.18: not good to put it into 2.6.17
> stable while it's awaiting refinement for 2.6.18 stable.

Ok, I've dropped it now.

thanks,

greg k-h

Re: [stable] [patch 07/19] invalidate_complete_page() race fix

[Andrew Morton]

On Tue, 10 Oct 2006 12:14:18 -0700
Greg KH <greg@kroah.com> wrote:

> On Tue, Oct 10, 2006 at 07:12:54PM +0100, Hugh Dickins wrote:
> > On Tue, 10 Oct 2006, Greg KH wrote:
> > 
> > > -stable review patch.  If anyone has any objections, please let us know.
> > > 
> > > ------------------
> > > From: Andrew Morton <akpm@osdl.org>
> > > 
> > > If a CPU faults this page into pagetables after invalidate_mapping_pages()
> > > checked page_mapped(), invalidate_complete_page() will still proceed to remove
> > > the page from pagecache.  This leaves the page-faulting process with a
> > > detached page.  If it was MAP_SHARED then file data loss will ensue.
> > > 
> > > Fix that up by checking the page's refcount after taking tree_lock.
> > 
> > I may have lost the plot, but I think this patch has already proved
> > to cause problems for NFS in 2.6.18: not good to put it into 2.6.17
> > stable while it's awaiting refinement for 2.6.18 stable.
> 
> Ok, I've dropped it now.
> 

It needs invalidate_inode_pages2-ignore-page-refcounts.patch as well.

This patch (invalidate_complete_page() race fix) fixes a cramfs unmount
race and, iirc, a pagefault-vs-invalidate race which Nick was seeing.
So applying both patches would make 2.6.17 a better place, but we could live
without them.

[patch 08/19] ext3 sequential read regression fix

[Greg KH]

[-- Attachment #1: ext3-sequential-read-regression-fix.patch --]
[-- Type: text/plain, Size: 1487 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Badari Pulavarty <pbadari@us.ibm.com>

ext3-get-blocks support caused ~20% degrade in Sequential read
performance (tiobench). Problem is with marking the buffer boundary
so IO can be submitted right away. Here is the patch to fix it.

2.6.18-rc6:
-----------
# ./iotest
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 75.2726 seconds, 57.1 MB/s

real    1m15.285s
user    0m0.276s
sys     0m3.884s


2.6.18-rc6 + fix:
-----------------
[root@elm3a241 ~]# ./iotest
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 62.9356 seconds, 68.2 MB/s


The boundary block check in ext3_get_blocks_handle needs to be adjusted
against the count of blocks mapped in this call, now that it can map
more than one block.

Signed-off-by: Suparna Bhattacharya <suparna@in.ibm.com>
Tested-by: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 fs/ext3/inode.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/fs/ext3/inode.c
+++ linux-2.6.17.13/fs/ext3/inode.c
@@ -926,7 +926,7 @@ int ext3_get_blocks_handle(handle_t *han
 	set_buffer_new(bh_result);
 got_it:
 	map_bh(bh_result, inode->i_sb, le32_to_cpu(chain[depth-1].key));
-	if (blocks_to_boundary == 0)
+	if (count > blocks_to_boundary)
 		set_buffer_boundary(bh_result);
 	err = count;
 	/* Clean up and exit */

--

[patch 09/19] sysfs: remove duplicated dput in sysfs_update_file

[Greg KH]

[-- Attachment #1: sysfs-remove-duplicated-dput-in-sysfs_update_file.patch --]
[-- Type: text/plain, Size: 2337 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

Following function can drops d_count twice against one reference
by lookup_one_len.

<SOURCE>
/**
 * sysfs_update_file - update the modified timestamp on an object attribute.
 * @kobj: object we're acting for.
 * @attr: attribute descriptor.
 */
int sysfs_update_file(struct kobject * kobj, const struct attribute * attr)
{
        struct dentry * dir = kobj->dentry;
        struct dentry * victim;
        int res = -ENOENT;

        mutex_lock(&dir->d_inode->i_mutex);
        victim = lookup_one_len(attr->name, dir, strlen(attr->name));
        if (!IS_ERR(victim)) {
                /* make sure dentry is really there */
                if (victim->d_inode &&
                    (victim->d_parent->d_inode == dir->d_inode)) {
                        victim->d_inode->i_mtime = CURRENT_TIME;
                        fsnotify_modify(victim);

                        /**
                         * Drop reference from initial sysfs_get_dentry().
                         */
                        dput(victim);
                        res = 0;
                } else
                        d_drop(victim);

                /**
                 * Drop the reference acquired from sysfs_get_dentry() above.
                 */
                dput(victim);
        }
        mutex_unlock(&dir->d_inode->i_mutex);

        return res;
}
</SOURCE>

PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of
this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/*
have negative d_count value.

This patch removes unnecessary dput().

Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/sysfs/file.c |    5 -----
 1 file changed, 5 deletions(-)

--- linux-2.6.17.13.orig/fs/sysfs/file.c
+++ linux-2.6.17.13/fs/sysfs/file.c
@@ -483,11 +483,6 @@ int sysfs_update_file(struct kobject * k
 		    (victim->d_parent->d_inode == dir->d_inode)) {
 			victim->d_inode->i_mtime = CURRENT_TIME;
 			fsnotify_modify(victim);
-
-			/**
-			 * Drop reference from initial sysfs_get_dentry().
-			 */
-			dput(victim);
 			res = 0;
 		} else
 			d_drop(victim);

--

[patch 10/19] Video: Fix msp343xG handling regression

[Greg KH]

[-- Attachment #1: video-fix-msp343xg-handling-regression.patch --]
[-- Type: text/plain, Size: 2352 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Hans Verkuil <hverkuil@xs4all.nl>

The msp3430G and msp3435G models cannot do Automatic Standard Detection,
so these should be forced to BTSC. These chips are early production
versions for the msp34xxG series and are quite rare.

Due to broken handling of the 'standard' option in 2.6.17, there is
no workaround possible.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/msp3400-driver.c   |    2 ++
 drivers/media/video/msp3400-driver.h   |    1 +
 drivers/media/video/msp3400-kthreads.c |    7 ++++---
 3 files changed, 7 insertions(+), 3 deletions(-)

--- linux-2.6.17.13.orig/drivers/media/video/msp3400-driver.c
+++ linux-2.6.17.13/drivers/media/video/msp3400-driver.c
@@ -942,6 +942,8 @@ static int msp_attach(struct i2c_adapter
 	state->has_virtual_dolby_surround = msp_revision == 'G' && msp_prod_lo == 1;
 	/* Has Virtual Dolby Surround & Dolby Pro Logic: only in msp34x2 */
 	state->has_dolby_pro_logic = msp_revision == 'G' && msp_prod_lo == 2;
+	/* The msp343xG supports BTSC only and cannot do Automatic Standard Detection. */
+	state->force_btsc = msp_family == 3 && msp_revision == 'G' && msp_prod_hi == 3;
 
 	state->opmode = opmode;
 	if (state->opmode == OPMODE_AUTO) {
--- linux-2.6.17.13.orig/drivers/media/video/msp3400-driver.h
+++ linux-2.6.17.13/drivers/media/video/msp3400-driver.h
@@ -64,6 +64,7 @@ struct msp_state {
 	u8 has_sound_processing;
 	u8 has_virtual_dolby_surround;
 	u8 has_dolby_pro_logic;
+	u8 force_btsc;
 
 	int radio;
 	int opmode;
--- linux-2.6.17.13.orig/drivers/media/video/msp3400-kthreads.c
+++ linux-2.6.17.13/drivers/media/video/msp3400-kthreads.c
@@ -949,11 +949,12 @@ int msp34xxg_thread(void *data)
 
 		/* setup the chip*/
 		msp34xxg_reset(client);
-		state->std = state->radio ? 0x40 : msp_standard;
-		if (state->std != 1)
-			goto unmute;
+		state->std = state->radio ? 0x40 :
+			(state->force_btsc && msp_standard == 1) ? 32 : msp_standard;
 		/* start autodetect */
 		msp_write_dem(client, 0x20, state->std);
+		if (state->std != 1)
+			goto unmute;
 
 		/* watch autodetect */
 		v4l_dbg(1, msp_debug, client, "started autodetect, waiting for result\n");

--

[patch 11/19] Video: cx24123: fix PLL divisor setup

[Greg KH]

[-- Attachment #1: video-cx24123-fix-pll-divisor-setup.patch --]
[-- Type: text/plain, Size: 1336 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Yeasah Pell <yeasah@schwide.net>

The cx24109 datasheet says: "NOTE: if A=0, then N=N+1"

The current code is the result of a misinterpretation of the datasheet to
mean exactly the opposite of the requirement -- The actual value of N is 1 greater than the value written when A is 0, so 1 needs to be *subtracted*
from it to compensate.

Signed-off-by: Yeasah Pell <yeasah@schwide.net>
Signed-off-by: Steven Toth <stoth@hauppauge.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/dvb/frontends/cx24123.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17.13.orig/drivers/media/dvb/frontends/cx24123.c
+++ linux-2.6.17.13/drivers/media/dvb/frontends/cx24123.c
@@ -579,8 +579,8 @@ static int cx24123_pll_calculate(struct 
 	ndiv = ( ((p->frequency * vco_div * 10) / (2 * XTAL / 1000)) / 32) & 0x1ff;
 	adiv = ( ((p->frequency * vco_div * 10) / (2 * XTAL / 1000)) % 32) & 0x1f;
 
-	if (adiv == 0)
-		ndiv++;
+	if (adiv == 0 && ndiv > 0)
+		ndiv--;
 
 	/* control bits 11, refdiv 11, charge pump polarity 1, charge pump current, ndiv, adiv */
 	state->pllarg = (3 << 19) | (3 << 17) | (1 << 16) | (pump << 14) | (ndiv << 5) | adiv;

--

[patch 12/19] SPARC64: Fix serious bug in sched_clock() on sparc64

[Greg KH]

[-- Attachment #1: sparc64-fix-serious-bug-in-sched_clock-on-sparc64.patch --]
[-- Type: text/plain, Size: 1160 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: David S. Miller <davem@davemloft.net>

[SPARC64]: Fix sched_clock() wrapping every ~17 seconds.

Unfortunately, sparc64 doesn't have an easy way to do a "64 X 64 -->
128" bit multiply like PowerPC and IA64 do.  We were doing a
"64 X 64 --> 64" bit multiple which causes overflow very quickly with
a 30-bit quotient shift.

So use a quotientshift count of 10 instead of 30, just like x86 and
ARM do.

This also fixes the wrapping of printk timestamp values every ~17
seconds.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/sparc64/kernel/time.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/arch/sparc64/kernel/time.c
+++ linux-2.6.17.13/arch/sparc64/kernel/time.c
@@ -1105,7 +1105,7 @@ static struct time_interpolator sparc64_
 };
 
 /* The quotient formula is taken from the IA64 port. */
-#define SPARC64_NSEC_PER_CYC_SHIFT	30UL
+#define SPARC64_NSEC_PER_CYC_SHIFT	10UL
 void __init time_init(void)
 {
 	unsigned long clock = sparc64_init_timers();

--

[patch 13/19] Fix sparc64 ramdisk handling

[Greg KH]

[-- Attachment #1: fix-sparc64-ramdisk-handling.patch --]
[-- Type: text/plain, Size: 1547 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: David S. Miller <davem@davemloft.net>

[SPARC64]: Kill bogus check from bootmem_init().

There is an ancient and totally incorrect sanity check being
done on the ramdisk location.  The check assumes that the
kernel is always loaded to physical address zero, which is
wrong.  It was trying to validate the ramdisk value by saying that
if it fell within the kernel image address range it must be wrong.

Anyways, kill this because it actually creates problems.  The
'ramdisk_image' should always be adjusted down by KERNBASE.
SILO can easily put the ramdisk in a location which causes
this test to trigger, breaking things.

[ Based almost entirely upon a patch from Ben Collins. ]

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/sparc64/mm/init.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.17.13.orig/arch/sparc64/mm/init.c
+++ linux-2.6.17.13/arch/sparc64/mm/init.c
@@ -902,8 +902,7 @@ static unsigned long __init bootmem_init
 	if (sparc_ramdisk_image || sparc_ramdisk_image64) {
 		unsigned long ramdisk_image = sparc_ramdisk_image ?
 			sparc_ramdisk_image : sparc_ramdisk_image64;
-		if (ramdisk_image >= (unsigned long)_end - 2 * PAGE_SIZE)
-			ramdisk_image -= KERNBASE;
+		ramdisk_image -= KERNBASE;
 		initrd_start = ramdisk_image + phys_base;
 		initrd_end = initrd_start + sparc_ramdisk_size;
 		if (initrd_end > end_of_phys_memory) {

--

[patch 14/19] PKT_SCHED: cls_basic: Use unsigned int when generating handle

[Greg KH]

[-- Attachment #1: pkt_sched-cls_basic-use-unsigned-int-when-generating-handle.patch --]
[-- Type: text/plain, Size: 781 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: David Miller <davem@davemloft.net>

Prevents filters from being added if the first generated
handle already exists.

Signed-off-by: Kim Nordlund <kim.nordlund@nokia.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/sched/cls_basic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17.13.orig/net/sched/cls_basic.c
+++ linux-2.6.17.13/net/sched/cls_basic.c
@@ -197,7 +197,7 @@ static int basic_change(struct tcf_proto
 	if (handle)
 		f->handle = handle;
 	else {
-		int i = 0x80000000;
+		unsigned int i = 0x80000000;
 		do {
 			if (++head->hgenerator == 0x7FFFFFFF)
 				head->hgenerator = 1;

--

[patch 15/19] xirc2ps_cs: Cannot reset card in atomic context

[Greg KH]

[-- Attachment #1: xirc2ps_cs-cannot-reset-card-in-atomic-context.patch --]
[-- Type: text/plain, Size: 2567 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Joerg Ahrens <joerg@hydrops.han.de>

I am using a Xircom CEM33 pcmcia NIC which has occasional hardware problems.
If the netdev watchdog detects a transmit timeout, do_reset is called which
msleeps - this is illegal in atomic context.

This patch schedules the timeout handling as a workqueue item.

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/pcmcia/xirc2ps_cs.c |   18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

--- linux-2.6.17.13.orig/drivers/net/pcmcia/xirc2ps_cs.c
+++ linux-2.6.17.13/drivers/net/pcmcia/xirc2ps_cs.c
@@ -345,6 +345,7 @@ typedef struct local_info_t {
     void __iomem *dingo_ccr; /* only used for CEM56 cards */
     unsigned last_ptr_value; /* last packets transmitted value */
     const char *manf_str;
+    struct work_struct tx_timeout_task;
 } local_info_t;
 
 /****************
@@ -352,6 +353,7 @@ typedef struct local_info_t {
  */
 static int do_start_xmit(struct sk_buff *skb, struct net_device *dev);
 static void do_tx_timeout(struct net_device *dev);
+static void xirc2ps_tx_timeout_task(void *data);
 static struct net_device_stats *do_get_stats(struct net_device *dev);
 static void set_addresses(struct net_device *dev);
 static void set_multicast_list(struct net_device *dev);
@@ -589,6 +591,7 @@ xirc2ps_probe(struct pcmcia_device *link
 #ifdef HAVE_TX_TIMEOUT
     dev->tx_timeout = do_tx_timeout;
     dev->watchdog_timeo = TX_TIMEOUT;
+    INIT_WORK(&local->tx_timeout_task, xirc2ps_tx_timeout_task, dev);
 #endif
 
     return xirc2ps_config(link);
@@ -1341,17 +1344,24 @@ xirc2ps_interrupt(int irq, void *dev_id,
 /*====================================================================*/
 
 static void
-do_tx_timeout(struct net_device *dev)
+xirc2ps_tx_timeout_task(void *data)
 {
-    local_info_t *lp = netdev_priv(dev);
-    printk(KERN_NOTICE "%s: transmit timed out\n", dev->name);
-    lp->stats.tx_errors++;
+    struct net_device *dev = data;
     /* reset the card */
     do_reset(dev,1);
     dev->trans_start = jiffies;
     netif_wake_queue(dev);
 }
 
+static void
+do_tx_timeout(struct net_device *dev)
+{
+    local_info_t *lp = netdev_priv(dev);
+    lp->stats.tx_errors++;
+    printk(KERN_NOTICE "%s: transmit timed out\n", dev->name);
+    schedule_work(&lp->tx_timeout_task);
+}
+
 static int
 do_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {

--

[patch 16/19] Add PIIX4 APCI quirk for the 440MX chipset too

[Greg KH]

[-- Attachment #1: add-piix4-apci-quirk-for-the-440mx-chipset-too.patch --]
[-- Type: text/plain, Size: 1915 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Linus Torvalds <torvalds@osdl.org>

This is confirmed to fix a hang due to PCI resource conflicts with
setting up the Cardbus bridge on old laptops with the 440MX chipsets.
Original report by Alessio Sangalli, lspci debugging help by Pekka
Enberg, and trial patch suggested by Daniel Ritz:

  "From the docs available i would _guess_ this thing is really similar
   to the 82443BX/82371AB combination.  at least the SMBus base address
   register is hidden at the very same place (32bit at 0x90 in function
   3 of the "south" brigde)"

The dang thing is largely undocumented, but the patch was corroborated
by Asit Mallick:

  "I am trying to find the register information. 440MX is an integration of
   440BX north-bridge without AGP and PIIX4E (82371EB).  PIIX4 quirk
   should cover the ACPI and SMBus related I/O registers."

and verified to fix the problem by Alessio.

Cc: Daniel Ritz <daniel.ritz-ml@swissonline.ch>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>
Tested-by: Alessio Sangalli <alesan@manoweb.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/pci/quirks.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.17.13.orig/drivers/pci/quirks.c
+++ linux-2.6.17.13/drivers/pci/quirks.c
@@ -390,6 +390,7 @@ static void __devinit quirk_piix4_acpi(s
 	piix4_io_quirk(dev, "PIIX4 devres J", 0x7c, 1 << 20);
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82371AB_3,	quirk_piix4_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82443MX_3,	quirk_piix4_acpi );
 
 /*
  * ICH4, ICH4-M, ICH5, ICH5-M ACPI: Three IO regions pointed to by longwords at

--

[patch 17/19] MMC: Always use a sector size of 512 bytes

[Greg KH]

[-- Attachment #1: mmc-always-use-a-sector-size-of-512-bytes.patch --]
[-- Type: text/plain, Size: 2664 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Pierre Ossman <drzeus@drzeus.cx>

Both MMC and SD specifications specify (although a bit unclearly in the MMC
case) that a sector size of 512 bytes must always be supported by the card.

Cards can report larger "native" size than this, and cards >= 2 GB even
must do so. Most other readers use 512 bytes even for these cards. We should
do the same to be compatible.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Cc: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/mmc/mmc_block.c |   49 +++---------------------------------------------
 1 file changed, 4 insertions(+), 45 deletions(-)

--- linux-2.6.17.13.orig/drivers/mmc/mmc_block.c
+++ linux-2.6.17.13/drivers/mmc/mmc_block.c
@@ -325,52 +325,11 @@ static struct mmc_blk_data *mmc_blk_allo
 	md->read_only = mmc_blk_readonly(card);
 
 	/*
-	 * Figure out a workable block size.  MMC cards have:
-	 *  - two block sizes, one for read and one for write.
-	 *  - may support partial reads and/or writes
-	 *    (allows block sizes smaller than specified)
+	 * Both SD and MMC specifications state (although a bit
+	 * unclearly in the MMC case) that a block size of 512
+	 * bytes must always be supported by the card.
 	 */
-	md->block_bits = card->csd.read_blkbits;
-	if (card->csd.write_blkbits != card->csd.read_blkbits) {
-		if (card->csd.write_blkbits < card->csd.read_blkbits &&
-		    card->csd.read_partial) {
-			/*
-			 * write block size is smaller than read block
-			 * size, but we support partial reads, so choose
-			 * the smaller write block size.
-			 */
-			md->block_bits = card->csd.write_blkbits;
-		} else if (card->csd.write_blkbits > card->csd.read_blkbits &&
-			   card->csd.write_partial) {
-			/*
-			 * read block size is smaller than write block
-			 * size, but we support partial writes.  Use read
-			 * block size.
-			 */
-		} else {
-			/*
-			 * We don't support this configuration for writes.
-			 */
-			printk(KERN_ERR "%s: unable to select block size for "
-				"writing (rb%u wb%u rp%u wp%u)\n",
-				mmc_card_id(card),
-				1 << card->csd.read_blkbits,
-				1 << card->csd.write_blkbits,
-				card->csd.read_partial,
-				card->csd.write_partial);
-			md->read_only = 1;
-		}
-	}
-
-	/*
-	 * Refuse to allow block sizes smaller than 512 bytes.
-	 */
-	if (md->block_bits < 9) {
-		printk(KERN_ERR "%s: unable to support block size %u\n",
-			mmc_card_id(card), 1 << md->block_bits);
-		ret = -EINVAL;
-		goto err_kfree;
-	}
+	md->block_bits = 9;
 
 	md->disk = alloc_disk(1 << MMC_SHIFT);
 	if (md->disk == NULL) {

--

[patch 18/19] ahci: do not fail softreset if PHY reports no device

[Greg KH]

[-- Attachment #1: ahci-do-not-fail-softreset-if-phy-reports-no-device.patch --]
[-- Type: text/plain, Size: 1052 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Tejun Heo <htejun@gmail.com>

All softreset methods are responsible for detecting device presence
and succeed softreset in such cases.  AHCI didn't use to check for
device presence before proceeding with softreset and this caused
unnecessary reset retrials during probing.  This patch adds presence
detection to AHCI softreset.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Cc: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/scsi/ahci.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- linux-2.6.17.13.orig/drivers/scsi/ahci.c
+++ linux-2.6.17.13/drivers/scsi/ahci.c
@@ -548,6 +548,12 @@ static int ahci_softreset(struct ata_por
 
 	DPRINTK("ENTER\n");
 
+	if (!sata_dev_present(ap)) {
+		DPRINTK("PHY reports no device\n");
+		*class = ATA_DEV_NONE;
+		return 0;
+	}
+
 	/* prepare for SRST (AHCI-1.1 10.4.1) */
 	rc = ahci_stop_engine(ap);
 	if (rc) {

--

[patch 19/19] Input: logips2pp - fix button mapping for MX300

[Greg KH]

[-- Attachment #1: input-logips2pp-fix-button-mapping-for-mx300.patch --]
[-- Type: text/plain, Size: 1187 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Roberto Castagnola <roberto.castagnola@gmail.com>

MX300 does not have an EXTRA_BTN - it is a simple wheel mouse with
an additional task-switcher button, which is reported as side button
(and not task button).

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/input/mouse/logips2pp.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.17.13.orig/drivers/input/mouse/logips2pp.c
+++ linux-2.6.17.13/drivers/input/mouse/logips2pp.c
@@ -238,8 +238,7 @@ static struct ps2pp_info *get_model_info
 		{ 100,	PS2PP_KIND_MX,					/* MX510 */
 				PS2PP_WHEEL | PS2PP_SIDE_BTN | PS2PP_TASK_BTN |
 				PS2PP_EXTRA_BTN | PS2PP_NAV_BTN },
-		{ 111,  PS2PP_KIND_MX,					/* MX300 */
-				PS2PP_WHEEL | PS2PP_EXTRA_BTN | PS2PP_TASK_BTN },
+		{ 111,  PS2PP_KIND_MX,	PS2PP_WHEEL | PS2PP_SIDE_BTN },	/* MX300 reports task button as side */
 		{ 112,	PS2PP_KIND_MX,					/* MX500 */
 				PS2PP_WHEEL | PS2PP_SIDE_BTN | PS2PP_TASK_BTN |
 				PS2PP_EXTRA_BTN | PS2PP_NAV_BTN },

--

Re: [stable] [patch 00/19] 2.6.17-stable review

[Greg KH]

On Tue, Oct 10, 2006 at 10:13:50AM -0700, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.17.14 release.
> There are 19 patches in this series, all will be posted as a response to
> this one.  If anyone has any issues with these being applied, please let
> us know.  If anyone is a maintainer of the proper subsystem, and wants
> to add a Signed-off-by: line to the patch, please respond with it.
> 
> These patches are sent out with a number of different people on the Cc:
> line.  If you wish to be a reviewer, please email stable@kernel.org to
> add your name to the list.  If you want to be off the reviewer list,
> also email us.
> 
> Responses should be made by Thursday, Octover 12, 18:00:00 UTC.
> Anything received after that time might be too late.

An all-in-one patch for this can be found at:
	http://www.kernel.org/pub/linux/kernel/people/gregkh/stable/patch-2.6.17.14-rc1.gz
if anyone wants to test this out that way.

Also, this is probably going to be the last 2.6.17-stable release,
unless there is something major that we are missing here in this one.

thanks,

greg k-h