* [PATCH 01/11] [PATCH] lost fput in 32bit ioctl on x86-64
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 02/11] [PATCH] Lost sockfd_put() in routing_ioctl() Chris Wright
` (10 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable, Kirill Korotaev
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Chris Wright, Maxim Giryaev
[-- 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 */
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 02/11] [PATCH] Lost sockfd_put() in routing_ioctl()
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
2005-09-15 1:03 ` [PATCH 01/11] [PATCH] lost fput in 32bit ioctl on x86-64 Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 03/11] [PATCH] forcedeth: Initialize link settings in every nv_open() Chris Wright
` (9 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Kirill Korotaev,
Maxim Giryaev, 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);
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 03/11] [PATCH] forcedeth: Initialize link settings in every nv_open()
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
2005-09-15 1:03 ` [PATCH 01/11] [PATCH] lost fput in 32bit ioctl on x86-64 Chris Wright
2005-09-15 1:03 ` [PATCH 02/11] [PATCH] Lost sockfd_put() in routing_ioctl() Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte Chris Wright
` (8 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Daniel Drake, manfred,
Jeff Garzik, 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);
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (2 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 03/11] [PATCH] forcedeth: Initialize link settings in every nv_open() Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 2:18 ` David Lang
2005-09-15 10:28 ` Martin Mares
2005-09-15 1:03 ` [PATCH 05/11] Sun GEM ethernet: enable and map PCI ROM properly Chris Wright
` (7 subsequent siblings)
11 siblings, 2 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Linus Torvalds, 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));
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte
2005-09-15 1:03 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte Chris Wright
@ 2005-09-15 2:18 ` David Lang
2005-09-15 2:26 ` Andrew Morton
2005-09-15 6:11 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not " Chris Wright
2005-09-15 10:28 ` Martin Mares
1 sibling, 2 replies; 21+ messages in thread
From: David Lang @ 2005-09-15 2:18 UTC (permalink / raw)
To: Chris Wright
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Chuck Wolber, Linus Torvalds,
akpm, alan, Linus Torvalds
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte
2005-09-15 2:18 ` David Lang
@ 2005-09-15 2:26 ` Andrew Morton
2005-09-15 2:29 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address,not " David Lang
2005-09-15 6:11 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not " Chris Wright
1 sibling, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2005-09-15 2:26 UTC (permalink / raw)
To: David Lang
Cc: chrisw, linux-kernel, stable, jmforbes, zwane, tytso, rdunlap,
chuckw, torvalds, alan
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address,not just low 1 byte
2005-09-15 2:26 ` Andrew Morton
@ 2005-09-15 2:29 ` David Lang
0 siblings, 0 replies; 21+ messages in thread
From: David Lang @ 2005-09-15 2:29 UTC (permalink / raw)
To: Andrew Morton
Cc: chrisw, linux-kernel, stable, jmforbes, zwane, tytso, rdunlap,
chuckw, torvalds, alan
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte
2005-09-15 2:18 ` David Lang
2005-09-15 2:26 ` Andrew Morton
@ 2005-09-15 6:11 ` Chris Wright
2005-09-15 10:39 ` David Lang
1 sibling, 1 reply; 21+ messages in thread
From: Chris Wright @ 2005-09-15 6:11 UTC (permalink / raw)
To: David Lang
Cc: Chris Wright, linux-kernel, stable, Justin Forbes,
Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap, Chuck Wolber,
Linus Torvalds, akpm, alan
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte
2005-09-15 6:11 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not " Chris Wright
@ 2005-09-15 10:39 ` David Lang
0 siblings, 0 replies; 21+ messages in thread
From: David Lang @ 2005-09-15 10:39 UTC (permalink / raw)
To: Chris Wright
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Chuck Wolber, Linus Torvalds,
akpm, alan
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte
2005-09-15 1:03 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte Chris Wright
2005-09-15 2:18 ` David Lang
@ 2005-09-15 10:28 ` Martin Mares
1 sibling, 0 replies; 21+ messages in thread
From: Martin Mares @ 2005-09-15 10:28 UTC (permalink / raw)
To: Chris Wright
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Chuck Wolber, torvalds, akpm,
alan
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 05/11] Sun GEM ethernet: enable and map PCI ROM properly
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (3 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 04/11] hpt366: write the full 4 bytes of ROM address, not just low 1 byte Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 06/11] [stable] [ROM 3/3] Sun HME: " Chris Wright
` (6 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Linus Torvalds, 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;
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 06/11] [stable] [ROM 3/3] Sun HME: enable and map PCI ROM properly
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (4 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 05/11] Sun GEM ethernet: enable and map PCI ROM properly Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 07/11] [NETFILTER]: Fix DHCP + MASQUERADE problem Chris Wright
` (5 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Willy Tarreau, 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;
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 07/11] [NETFILTER]: Fix DHCP + MASQUERADE problem
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (5 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 06/11] [stable] [ROM 3/3] Sun HME: " Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 08/11] jfs: jfs_delete_inode must call clear_inode Chris Wright
` (4 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable, David S. Miller
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Patrick McHardy,
Netfilter Development Mailinglist, 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);
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 08/11] jfs: jfs_delete_inode must call clear_inode
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (6 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 07/11] [NETFILTER]: Fix DHCP + MASQUERADE problem Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 09/11] [PATCH] Fix MPOL_F_VERIFY Chris Wright
` (3 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Chuck Ebbert, Dave Kleikamp,
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);
}
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 09/11] [PATCH] Fix MPOL_F_VERIFY
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (7 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 08/11] jfs: jfs_delete_inode must call clear_inode Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 10/11] Fix up more strange byte writes to the PCI_ROM_ADDRESS config word Chris Wright
` (2 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Andi Kleen, 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;
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 10/11] Fix up more strange byte writes to the PCI_ROM_ADDRESS config word
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (8 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 09/11] [PATCH] Fix MPOL_F_VERIFY Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 1:03 ` [PATCH 11/11] USB: ftdi_sio: custom baud rate fix Chris Wright
2005-09-15 7:36 ` [PATCH 00/11] -stable review Alexander Nyberg
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, 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);
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 11/11] USB: ftdi_sio: custom baud rate fix
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (9 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 10/11] Fix up more strange byte writes to the PCI_ROM_ADDRESS config word Chris Wright
@ 2005-09-15 1:03 ` Chris Wright
2005-09-15 7:36 ` [PATCH 00/11] -stable review Alexander Nyberg
11 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 1:03 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Ian Abbott, Greg KH,
Greg Kroah-Hartman, 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);
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 00/11] -stable review
2005-09-15 1:03 [PATCH 00/11] -stable review Chris Wright
` (10 preceding siblings ...)
2005-09-15 1:03 ` [PATCH 11/11] USB: ftdi_sio: custom baud rate fix Chris Wright
@ 2005-09-15 7:36 ` Alexander Nyberg
2005-09-15 20:04 ` Chris Wright
11 siblings, 1 reply; 21+ messages in thread
From: Alexander Nyberg @ 2005-09-15 7:36 UTC (permalink / raw)
To: Chris Wright
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy Dunlap, Chuck Wolber, torvalds, akpm,
alan
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;
}
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 00/11] -stable review
2005-09-15 7:36 ` [PATCH 00/11] -stable review Alexander Nyberg
@ 2005-09-15 20:04 ` Chris Wright
0 siblings, 0 replies; 21+ messages in thread
From: Chris Wright @ 2005-09-15 20:04 UTC (permalink / raw)
To: Alexander Nyberg
Cc: Chris Wright, linux-kernel, stable, Justin Forbes,
Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap, Chuck Wolber,
torvalds, akpm, alan
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread