[PATCH 00/11] -stable review

[PATCH 00/11] -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.13.2 release.
There are 11 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 Sat Sep 17 01:00 2005 UTC.  Anything received
after that time, might be too late.

thanks,

the -stable release team
--

[PATCH 01/11] [PATCH] lost fput in 32bit ioctl on x86-64

[Chris Wright]

[-- Attachment #1: lost-fput-in-32bit-ioctl-on-x86-64.patch --]
[-- Type: text/plain, Size: 1873 bytes --]

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

This patch adds lost fput in 32bit tiocgdev ioctl on x86-64

I believe this is a security issues, since user can fget() file as
many times as he wants to. So file refcounter can be overlapped and
first fput() will free resources though there will be still structures
pointing to the file, mnt, dentry etc.  Also fput() sets f_dentry and
f_vfsmnt to NULL, so other file users will OOPS.

The oops can be done under files_lock and others, so this is really
exploitable DoS on SMP. Didn't checked it on practice actually.

(chrisw: Update to use fget_light/fput_light)

Signed-Off-By: Kirill Korotaev <dev@sw.ru>
Signed-Off-By: Maxim Giryaev <gem@sw.ru>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 arch/x86_64/ia32/ia32_ioctl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

Index: linux-2.6.13.y/arch/x86_64/ia32/ia32_ioctl.c
===================================================================
--- linux-2.6.13.y.orig/arch/x86_64/ia32/ia32_ioctl.c
+++ linux-2.6.13.y/arch/x86_64/ia32/ia32_ioctl.c
@@ -24,17 +24,26 @@
 static int tiocgdev(unsigned fd, unsigned cmd,  unsigned int __user *ptr) 
 { 
 
-	struct file *file = fget(fd);
+	struct file *file;
 	struct tty_struct *real_tty;
+	int fput_needed, ret;
 
+	file = fget_light(fd, &fput_needed);
 	if (!file)
 		return -EBADF;
+
+	ret = -EINVAL;
 	if (file->f_op->ioctl != tty_ioctl)
-		return -EINVAL; 
+		goto out;
 	real_tty = (struct tty_struct *)file->private_data;
 	if (!real_tty) 	
-		return -EINVAL; 
-	return put_user(new_encode_dev(tty_devnum(real_tty)), ptr); 
+		goto out;
+
+	ret = put_user(new_encode_dev(tty_devnum(real_tty)), ptr); 
+
+out:
+	fput_light(file, fput_needed);
+	return ret;
 } 
 
 #define RTC_IRQP_READ32	_IOR('p', 0x0b, unsigned int)	 /* Read IRQ rate   */

--

[PATCH 02/11] [PATCH] Lost sockfd_put() in routing_ioctl()

[Chris Wright]

[-- Attachment #1: lost-sockfd_put-in-32bit-compat-routing_ioctl.patch --]
[-- Type: text/plain, Size: 1359 bytes --]

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

This patch adds lost sockfd_put() in 32bit compat rounting_ioctl() on 
64bit platforms

I believe this is a security issues, since user can fget() file as many 
times as he wants to. So file refcounter can be overlapped and first 
fput() will free resources though there will be still structures 
pointing to the file, mnt, dentry etc.
Also fput() sets f_dentry and f_vfsmnt to NULL,
so other file users will OOPS.

The oops can be done under files_lock and others, so this can be an 
exploitable DoS on SMP. Didn't checked it on practice actually.

Signed-Off-By: Kirill Korotaev <dev@sw.ru>
Signed-Off-By: Maxim Giryaev <gem@sw.ru>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 fs/compat_ioctl.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

Index: linux-2.6.13.y/fs/compat_ioctl.c
===================================================================
--- linux-2.6.13.y.orig/fs/compat_ioctl.c
+++ linux-2.6.13.y/fs/compat_ioctl.c
@@ -798,13 +798,16 @@ static int routing_ioctl(unsigned int fd
 		r = (void *) &r4;
 	}
 
-	if (ret)
-		return -EFAULT;
+	if (ret) {
+		ret = -EFAULT;
+		goto out;
+	}
 
 	set_fs (KERNEL_DS);
 	ret = sys_ioctl (fd, cmd, (unsigned long) r);
 	set_fs (old_fs);
 
+out:
 	if (mysock)
 		sockfd_put(mysock);
 

--

[PATCH 03/11] [PATCH] forcedeth: Initialize link settings in every nv_open()

[Chris Wright]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: forcedeth-init-link-settings-in-nv_open.patch --]
[-- Type: text/plain, Size: 1441 bytes --]

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

R�diger found a bug in nv_open that explains some of the reports
with duplex mismatches:
nv_open calls nv_update_link_speed for initializing the hardware link speed
registers. If current link setting matches the values in np->linkspeed and
np->duplex, then the function does nothing.
Usually, doing nothing is the right thing, but not in nv_open: During
nv_open, the registers must be initialized because the nic was reset.

The attached patch fixes that by setting np->linkspeed to an invalid value
before calling nv_update_link_speed from nv_open.

Signed-Off-By: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 drivers/net/forcedeth.c |    3 +++
 1 files changed, 3 insertions(+)

Index: linux-2.6.13.y/drivers/net/forcedeth.c
===================================================================
--- linux-2.6.13.y.orig/drivers/net/forcedeth.c
+++ linux-2.6.13.y/drivers/net/forcedeth.c
@@ -1888,6 +1888,9 @@ static int nv_open(struct net_device *de
 		writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
 		dprintk(KERN_INFO "startup: got 0x%08x.\n", miistat);
 	}
+	/* set linkspeed to invalid value, thus force nv_update_linkspeed
+	 * to init hw */
+	np->linkspeed = 0; 
 	ret = nv_update_linkspeed(dev);
 	nv_start_rx(dev);
 	nv_start_tx(dev);

--

[PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte

[Chris Wright]

[-- Attachment #1: hpt366-write-dword-not-byte-for-ROM-resource.patch --]
[-- Type: text/plain, Size: 1302 bytes --]

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

This is one heck of a confused driver.  It uses a byte write to a dword
register to enable a ROM resource that it doesn't even seem to be using.

"Lost and wandering in the desert of confusion"

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 drivers/ide/pci/hpt366.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

Index: linux-2.6.13.y/drivers/ide/pci/hpt366.c
===================================================================
--- linux-2.6.13.y.orig/drivers/ide/pci/hpt366.c
+++ linux-2.6.13.y/drivers/ide/pci/hpt366.c
@@ -1334,9 +1334,13 @@ static int __devinit init_hpt366(struct 
 static unsigned int __devinit init_chipset_hpt366(struct pci_dev *dev, const char *name)
 {
 	int ret = 0;
-	/* FIXME: Not portable */
+
+	/*
+	 * FIXME: Not portable. Also, why do we enable the ROM in the first place?
+	 * We don't seem to be using it.
+	 */
 	if (dev->resource[PCI_ROM_RESOURCE].start)
-		pci_write_config_byte(dev, PCI_ROM_ADDRESS,
+		pci_write_config_dword(dev, PCI_ROM_ADDRESS,
 			dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
 
 	pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, (L1_CACHE_BYTES / 4));

--

[PATCH 05/11] Sun GEM ethernet: enable and map PCI ROM properly

[Chris Wright]

[-- Attachment #1: sungem-enable-and-map-pci-rom-properly.patch --]
[-- Type: text/plain, Size: 2432 bytes --]

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

This same patch was reported to fix the MAC address detection on sunhme
(next patch).  Most people seem to be running this on Sparcs or PPC
machines, where we get the MAC address from their respective firmware
rather than from the (previously broken) ROM mapping routines.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 drivers/net/sungem.c |   36 ++++++++++++++----------------------
 1 files changed, 14 insertions(+), 22 deletions(-)

Index: linux-2.6.13.y/drivers/net/sungem.c
===================================================================
--- linux-2.6.13.y.orig/drivers/net/sungem.c
+++ linux-2.6.13.y/drivers/net/sungem.c
@@ -2816,7 +2816,7 @@ static int gem_ioctl(struct net_device *
 
 #if (!defined(__sparc__) && !defined(CONFIG_PPC_PMAC))
 /* Fetch MAC address from vital product data of PCI ROM. */
-static void find_eth_addr_in_vpd(void __iomem *rom_base, int len, unsigned char *dev_addr)
+static int find_eth_addr_in_vpd(void __iomem *rom_base, int len, unsigned char *dev_addr)
 {
 	int this_offset;
 
@@ -2837,35 +2837,27 @@ static void find_eth_addr_in_vpd(void __
 
 		for (i = 0; i < 6; i++)
 			dev_addr[i] = readb(p + i);
-		break;
+		return 1;
 	}
+	return 0;
 }
 
 static void get_gem_mac_nonobp(struct pci_dev *pdev, unsigned char *dev_addr)
 {
-	u32 rom_reg_orig;
-	void __iomem *p;
-
-	if (pdev->resource[PCI_ROM_RESOURCE].parent == NULL) {
-		if (pci_assign_resource(pdev, PCI_ROM_RESOURCE) < 0)
-			goto use_random;
-	}
-
-	pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_reg_orig);
-	pci_write_config_dword(pdev, pdev->rom_base_reg,
-			       rom_reg_orig | PCI_ROM_ADDRESS_ENABLE);
+	size_t size;
+	void __iomem *p = pci_map_rom(pdev, &size);
 
-	p = ioremap(pci_resource_start(pdev, PCI_ROM_RESOURCE), (64 * 1024));
-	if (p != NULL && readb(p) == 0x55 && readb(p + 1) == 0xaa)
-		find_eth_addr_in_vpd(p, (64 * 1024), dev_addr);
+	if (p) {
+			int found;
 
-	if (p != NULL)
-		iounmap(p);
-
-	pci_write_config_dword(pdev, pdev->rom_base_reg, rom_reg_orig);
-	return;
+		found = readb(p) == 0x55 &&
+			readb(p + 1) == 0xaa &&
+			find_eth_addr_in_vpd(p, (64 * 1024), dev_addr);
+		pci_unmap_rom(pdev, p);
+		if (found)
+			return;
+	}
 
-use_random:
 	/* Sun MAC prefix then 3 random bytes. */
 	dev_addr[0] = 0x08;
 	dev_addr[1] = 0x00;

--

[PATCH 06/11] [stable] [ROM 3/3] Sun HME: enable and map PCI ROM properly

[Chris Wright]

[-- Attachment #1: sunhme-enable-and-map-pci-rom-properly.patch --]
[-- Type: text/plain, Size: 2599 bytes --]

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

This ports the Sun GEM ROM mapping/enable fixes it sunhme (which used
the same PCI ROM mapping code).

Without this, I get NULL MAC addresses for all 4 ports (it's a SUN QFE).
With it, I get the correct addresses (the ones printed on the label on
the card).

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 drivers/net/sunhme.c |   45 ++++++++++++++++++---------------------------
 1 files changed, 18 insertions(+), 27 deletions(-)

Index: linux-2.6.13.y/drivers/net/sunhme.c
===================================================================
--- linux-2.6.13.y.orig/drivers/net/sunhme.c
+++ linux-2.6.13.y/drivers/net/sunhme.c
@@ -2954,7 +2954,7 @@ static int is_quattro_p(struct pci_dev *
 }
 
 /* Fetch MAC address from vital product data of PCI ROM. */
-static void find_eth_addr_in_vpd(void __iomem *rom_base, int len, int index, unsigned char *dev_addr)
+static int find_eth_addr_in_vpd(void __iomem *rom_base, int len, int index, unsigned char *dev_addr)
 {
 	int this_offset;
 
@@ -2977,42 +2977,33 @@ static void find_eth_addr_in_vpd(void __
 
 			for (i = 0; i < 6; i++)
 				dev_addr[i] = readb(p + i);
-			break;
+			return 1;
 		}
 		index--;
 	}
+	return 0;
 }
 
 static void get_hme_mac_nonsparc(struct pci_dev *pdev, unsigned char *dev_addr)
 {
-	u32 rom_reg_orig;
-	void __iomem *p;
-	int index;
+	size_t size;
+	void __iomem *p = pci_map_rom(pdev, &size);
 
-	index = 0;
-	if (is_quattro_p(pdev))
-		index = PCI_SLOT(pdev->devfn);
-
-	if (pdev->resource[PCI_ROM_RESOURCE].parent == NULL) {
-		if (pci_assign_resource(pdev, PCI_ROM_RESOURCE) < 0)
-			goto use_random;
+	if (p) {
+		int index = 0;
+		int found;
+
+		if (is_quattro_p(pdev))
+			index = PCI_SLOT(pdev->devfn);
+
+		found = readb(p) == 0x55 &&
+			readb(p + 1) == 0xaa &&
+			find_eth_addr_in_vpd(p, (64 * 1024), index, dev_addr);
+		pci_unmap_rom(pdev, p);
+		if (found)
+			return;
 	}
 
-	pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_reg_orig);
-	pci_write_config_dword(pdev, pdev->rom_base_reg,
-			       rom_reg_orig | PCI_ROM_ADDRESS_ENABLE);
-
-	p = ioremap(pci_resource_start(pdev, PCI_ROM_RESOURCE), (64 * 1024));
-	if (p != NULL && readb(p) == 0x55 && readb(p + 1) == 0xaa)
-		find_eth_addr_in_vpd(p, (64 * 1024), index, dev_addr);
-
-	if (p != NULL)
-		iounmap(p);
-
-	pci_write_config_dword(pdev, pdev->rom_base_reg, rom_reg_orig);
-	return;
-
-use_random:
 	/* Sun MAC prefix then 3 random bytes. */
 	dev_addr[0] = 0x08;
 	dev_addr[1] = 0x00;

--

[PATCH 07/11] [NETFILTER]: Fix DHCP + MASQUERADE problem

[Chris Wright]

[-- Attachment #1: netfilter-fix-dhcp-masquerade-problem.patch --]
[-- Type: text/plain, Size: 1464 bytes --]

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

In 2.6.13-rcX the MASQUERADE target was changed not to exclude local
packets for better source address consistency. This breaks DHCP clients
using UDP sockets when the DHCP requests are caught by a MASQUERADE rule
because the MASQUERADE target drops packets when no address is configured
on the outgoing interface. This patch makes it ignore packets with a
source address of 0.

Thanks to Rusty for this suggestion.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 net/ipv4/netfilter/ipt_MASQUERADE.c |    6 ++++++
 1 files changed, 6 insertions(+)

Index: linux-2.6.13.y/net/ipv4/netfilter/ipt_MASQUERADE.c
===================================================================
--- linux-2.6.13.y.orig/net/ipv4/netfilter/ipt_MASQUERADE.c
+++ linux-2.6.13.y/net/ipv4/netfilter/ipt_MASQUERADE.c
@@ -95,6 +95,12 @@ masquerade_target(struct sk_buff **pskb,
 	IP_NF_ASSERT(ct && (ctinfo == IP_CT_NEW || ctinfo == IP_CT_RELATED
 	                    || ctinfo == IP_CT_RELATED + IP_CT_IS_REPLY));
 
+	/* Source address is 0.0.0.0 - locally generated packet that is
+	 * probably not supposed to be masqueraded.
+	 */
+	if (ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip == 0)
+		return NF_ACCEPT;
+
 	mr = targinfo;
 	rt = (struct rtable *)(*pskb)->dst;
 	newsrc = inet_select_addr(out, rt->rt_gateway, RT_SCOPE_UNIVERSE);

--

[PATCH 08/11] jfs: jfs_delete_inode must call clear_inode

[Chris Wright]

[-- Attachment #1: jfs_delete_inode-must-call-clear_inode.patch --]
[-- Type: text/plain, Size: 1456 bytes --]

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

> From Chuck Ebbert:
I'm submitting this patch for -stable:

  - it reportedly fixes an oops
  - it's already in 2.6.13-git

JFS: jfs_delete_inode should always call clear_inode.

Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 fs/jfs/inode.c |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

Index: linux-2.6.13.y/fs/jfs/inode.c
===================================================================
--- linux-2.6.13.y.orig/fs/jfs/inode.c
+++ linux-2.6.13.y/fs/jfs/inode.c
@@ -128,21 +128,21 @@ void jfs_delete_inode(struct inode *inod
 {
 	jfs_info("In jfs_delete_inode, inode = 0x%p", inode);
 
-	if (is_bad_inode(inode) ||
-	    (JFS_IP(inode)->fileset != cpu_to_le32(FILESYSTEM_I)))
-			return;
+	if (!is_bad_inode(inode) &&
+	    (JFS_IP(inode)->fileset == cpu_to_le32(FILESYSTEM_I))) {
 
-	if (test_cflag(COMMIT_Freewmap, inode))
-		jfs_free_zero_link(inode);
+		if (test_cflag(COMMIT_Freewmap, inode))
+			jfs_free_zero_link(inode);
 
-	diFree(inode);
+		diFree(inode);
 
-	/*
-	 * Free the inode from the quota allocation.
-	 */
-	DQUOT_INIT(inode);
-	DQUOT_FREE_INODE(inode);
-	DQUOT_DROP(inode);
+		/*
+		 * Free the inode from the quota allocation.
+		 */
+		DQUOT_INIT(inode);
+		DQUOT_FREE_INODE(inode);
+		DQUOT_DROP(inode);
+	}
 
 	clear_inode(inode);
 }

--

[PATCH 09/11] [PATCH] Fix MPOL_F_VERIFY

[Chris Wright]

[-- Attachment #1: fix-MPOL_F_VERIFY.patch --]
[-- Type: text/plain, Size: 1171 bytes --]

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

There was a pretty bad bug in there that the code would
always check the full VMA, not the range the user requested.

When the VMA to be checked was merged with the previous VMA this
could lead to spurious failures.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 mm/mempolicy.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletion(-)

Index: linux-2.6.13.y/mm/mempolicy.c
===================================================================
--- linux-2.6.13.y.orig/mm/mempolicy.c
+++ linux-2.6.13.y/mm/mempolicy.c
@@ -333,8 +333,13 @@ check_range(struct mm_struct *mm, unsign
 		if (prev && prev->vm_end < vma->vm_start)
 			return ERR_PTR(-EFAULT);
 		if ((flags & MPOL_MF_STRICT) && !is_vm_hugetlb_page(vma)) {
+			unsigned long endvma = vma->vm_end; 
+			if (endvma > end)
+				endvma = end;
+			if (vma->vm_start > start)
+				start = vma->vm_start;
 			err = check_pgd_range(vma->vm_mm,
-					   vma->vm_start, vma->vm_end, nodes);
+					   start, endvma, nodes);
 			if (err) {
 				first = ERR_PTR(err);
 				break;

--

[PATCH 10/11] Fix up more strange byte writes to the PCI_ROM_ADDRESS config word

[Chris Wright]

[-- Attachment #1: fix-more-byte-to-dword-writes-to-PCI_ROM_ADDRESS-config-word.patch --]
[-- Type: text/plain, Size: 1913 bytes --]

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

It's a dword thing, and the value we write is a dword.  Doing a byte
write to it is nonsensical, and writes only the low byte, which only
contains the enable bit.  So we enable a nonsensical address (usually
zero), which causes the controller no end of problems.

Trivial fix, but nasty to find.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 drivers/ide/pci/cmd64x.c |    2 +-
 drivers/ide/pci/hpt34x.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.13.y/drivers/ide/pci/cmd64x.c
===================================================================
--- linux-2.6.13.y.orig/drivers/ide/pci/cmd64x.c
+++ linux-2.6.13.y/drivers/ide/pci/cmd64x.c
@@ -608,7 +608,7 @@ static unsigned int __devinit init_chips
 
 #ifdef __i386__
 	if (dev->resource[PCI_ROM_RESOURCE].start) {
-		pci_write_config_byte(dev, PCI_ROM_ADDRESS, dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
+		pci_write_config_dword(dev, PCI_ROM_ADDRESS, dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
 		printk(KERN_INFO "%s: ROM enabled at 0x%08lx\n", name, dev->resource[PCI_ROM_RESOURCE].start);
 	}
 #endif
Index: linux-2.6.13.y/drivers/ide/pci/hpt34x.c
===================================================================
--- linux-2.6.13.y.orig/drivers/ide/pci/hpt34x.c
+++ linux-2.6.13.y/drivers/ide/pci/hpt34x.c
@@ -173,7 +173,7 @@ static unsigned int __devinit init_chips
 
 	if (cmd & PCI_COMMAND_MEMORY) {
 		if (pci_resource_start(dev, PCI_ROM_RESOURCE)) {
-			pci_write_config_byte(dev, PCI_ROM_ADDRESS,
+			pci_write_config_dword(dev, PCI_ROM_ADDRESS,
 				dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
 			printk(KERN_INFO "HPT345: ROM enabled at 0x%08lx\n",
 				dev->resource[PCI_ROM_RESOURCE].start);

--

[PATCH 11/11] USB: ftdi_sio: custom baud rate fix

[Chris Wright]

[-- Attachment #1: usb-ftdi_sio-baud-fix.patch --]
[-- Type: text/plain, Size: 968 bytes --]

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

ftdi_sio: I messed up the baud_base for custom baud rate support in
2.6.13.  The attached one-liner patch fixes it.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
 drivers/usb/serial/ftdi_sio.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.13.y/drivers/usb/serial/ftdi_sio.c
===================================================================
--- linux-2.6.13.y.orig/drivers/usb/serial/ftdi_sio.c
+++ linux-2.6.13.y/drivers/usb/serial/ftdi_sio.c
@@ -874,7 +874,7 @@ static void ftdi_determine_type(struct u
 	unsigned interfaces;
 
 	/* Assume it is not the original SIO device for now. */
-	priv->baud_base = 48000000 / 16;
+	priv->baud_base = 48000000 / 2;
 	priv->write_offset = 0;
 
 	version = le16_to_cpu(udev->descriptor.bcdDevice);

--

Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte

[David Lang]

didn't Linus find similar bugs in a couple of the other hpt drivers as 
well? if so can they be fixed at the same time?

David Lang

On Wed, 14 Sep 2005, Chris Wright wrote:

> Date: Wed, 14 Sep 2005 18:03:47 -0700
> From: Chris Wright <chrisw@osdl.org>
> To: linux-kernel@vger.kernel.org, stable@kernel.org
> Cc: Justin Forbes <jmforbes@linuxtx.org>,
>     Zwane Mwaikambo <zwane@arm.linux.org.uk>, Theodore Ts'o <tytso@mit.edu>,
>     Randy Dunlap <rdunlap@xenotime.net>,
>     Chuck Wolber <chuckw@quantumlinux.com>, torvalds@osdl.org, akpm@osdl.org,
>     alan@lxorguk.ukuu.org.uk, Linus Torvalds <torvalds@osdl.org>,
>     Chris Wright <chrisw@osdl.org>
> Subject: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address,
>     not just low 1 byte
> 
> -stable review patch.  If anyone has any objections, please let us know.
> ------------------
>
> This is one heck of a confused driver.  It uses a byte write to a dword
> register to enable a ROM resource that it doesn't even seem to be using.
>
> "Lost and wandering in the desert of confusion"
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> Signed-off-by: Chris Wright <chrisw@osdl.org>
> ---
> drivers/ide/pci/hpt366.c |    8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.13.y/drivers/ide/pci/hpt366.c
> ===================================================================
> --- linux-2.6.13.y.orig/drivers/ide/pci/hpt366.c
> +++ linux-2.6.13.y/drivers/ide/pci/hpt366.c
> @@ -1334,9 +1334,13 @@ static int __devinit init_hpt366(struct
> static unsigned int __devinit init_chipset_hpt366(struct pci_dev *dev, const char *name)
> {
> 	int ret = 0;
> -	/* FIXME: Not portable */
> +
> +	/*
> +	 * FIXME: Not portable. Also, why do we enable the ROM in the first place?
> +	 * We don't seem to be using it.
> +	 */
> 	if (dev->resource[PCI_ROM_RESOURCE].start)
> -		pci_write_config_byte(dev, PCI_ROM_ADDRESS,
> +		pci_write_config_dword(dev, PCI_ROM_ADDRESS,
> 			dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
>
> 	pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, (L1_CACHE_BYTES / 4));
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte

[Andrew Morton]

David Lang <dlang@digitalinsight.com> wrote:
>
> didn't Linus find similar bugs in a couple of the other hpt drivers as 
>  well? if so can they be fixed at the same time?

Adam Kropelin did a sweep and picked up four similar cases.  I queued the
patches and they should be considered for 2.6.13.3

Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address,not just low 1 byte

[David Lang]

On Wed, 14 Sep 2005, Andrew Morton wrote:

> David Lang <dlang@digitalinsight.com> wrote:
>>
>> didn't Linus find similar bugs in a couple of the other hpt drivers as
>>  well? if so can they be fixed at the same time?
>
> Adam Kropelin did a sweep and picked up four similar cases.  I queued the
> patches and they should be considered for 2.6.13.3
>

Thanks,

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte

[Chris Wright]

* David Lang (dlang@digitalinsight.com) wrote:
> didn't Linus find similar bugs in a couple of the other hpt drivers as 
> well? if so can they be fixed at the same time?

Yes, and they're in this series.  This patch does:

drivers/ide/pci/hpt366.c

And patch 10/11 does:

drivers/ide/pci/cmd64x.c
drivers/ide/pci/hpt34x.c

Additionally, the sungem (5/11) and sunhme (6/11) changes are fallout
from PCI_ROM fixes.

I believe the remainder of the PCI_ROM related patches were primarily
for consistency.

thanks,
-chris

Re: [PATCH 00/11] -stable review

[Alexander Nyberg]

On Wed, Sep 14, 2005 at 06:03:43PM -0700 Chris Wright wrote:

> This is the start of the stable review cycle for the 2.6.13.2 release.
> There are 11 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.
> 

This might be worth putting in too (has been hit by at least two people
in the real world etc.)

tree e3a704026e65bf6fea0c7747f0fb75a506f54127
parent 32a3658533c6f4c6bf370dd730213e802464ef9b
author Alexander Nyberg <alexn@telia.com> Wed, 14 Sep 2005 18:54:06 +0200
committer Linus Torvalds <torvalds@g5.osdl.org> Thu, 15 Sep 2005 00:26:34 -0700

[PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON

It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable
and can trigger due to the test itself being racy.

de_thread() does
 	while (atomic_read(&sig->count) > count) {
	}
	.....
	.....
	BUG_ON(!thread_group_empty(current));

but release_task does
	write_lock_irq(&tasklist_lock)
	__exit_signal
		(this is where atomic_dec(&sig->count) is run)
	__exit_sighand
	__unhash_process
		takes write lock on tasklist_lock
		remove itself out of PIDTYPE_TGID list
	write_unlock_irq(&tasklist_lock)

so there's a clear (although small) window between the
atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the
thread.

And actually there is no need for all threads to have exited at this
point, so we simply kill the BUG_ON.

Big thanks to Marc Lehmann who provided the test-case.

Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)

Signed-off-by: Alexander Nyberg <alexn@telia.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

 fs/exec.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -745,8 +745,8 @@ static inline int de_thread(struct task_
         }
 
 	/*
-	 * Now there are really no other threads at all,
-	 * so it's safe to stop telling them to kill themselves.
+	 * There may be one thread left which is just exiting,
+	 * but it's safe to stop telling the group to kill themselves.
 	 */
 	sig->flags = 0;
 
@@ -785,7 +785,6 @@ no_thread_group:
 			kmem_cache_free(sighand_cachep, oldsighand);
 	}
 
-	BUG_ON(!thread_group_empty(current));
 	BUG_ON(!thread_group_leader(current));
 	return 0;
 }

Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte

[Martin Mares]

Hello!

> This is one heck of a confused driver.  It uses a byte write to a dword
> register to enable a ROM resource that it doesn't even seem to be using.

Once upon a time when I was the PCI maintainer, I was arguing with Andre
Hedrick about this one and he kept asserting that enabling the ROM is
necessary to make the chip work. Not that I believe it :)

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Never make any mistaeks.

Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte

[David Lang]

On Wed, 14 Sep 2005, Chris Wright wrote:

> * David Lang (dlang@digitalinsight.com) wrote:
>> didn't Linus find similar bugs in a couple of the other hpt drivers as
>> well? if so can they be fixed at the same time?
>
> Yes, and they're in this series.  This patch does:
>
> drivers/ide/pci/hpt366.c
>
> And patch 10/11 does:
>
> drivers/ide/pci/cmd64x.c
> drivers/ide/pci/hpt34x.c
>
> Additionally, the sungem (5/11) and sunhme (6/11) changes are fallout
> from PCI_ROM fixes.
>
> I believe the remainder of the PCI_ROM related patches were primarily
> for consistency.

sorry about the noise, I read through all the descriptions looking for 
these, but I hadn't read all the patches.

David Lang

P.S. thanks to the kernel team for catching this before I got a chance to 
install .13 on my system that has a hpt374 controller :-)
-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [PATCH 00/11] -stable review

[Chris Wright]

* Alexander Nyberg (alexn@telia.com) wrote:
> This might be worth putting in too (has been hit by at least two people
> in the real world etc.)

Yes, I'd tagged it to ping you.  Thanks, added to -stable queue.
-chris

[PATCH 00/11] -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.16.20 release.
There are 11 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 Sun, June 4, 19:45 UTC.
Anything received after that time, might be too late.

thanks,

the -stable release team
--