From a7cd9a170e2bebab9a034b825c94154c10490668 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 22 Jul 2008 14:48:02 -0700 Subject: [PATCH] more .25 patches added --- ...eclaration-to-be-big-endian-friendly.patch | 50 ++++++++++ ...ireless-hardware.c-fix-resource-leak.patch | 42 +++++++++ ...sdn_common.c-fix-small-resource-leak.patch | 44 +++++++++ ...ck-excutability-without-pt_gnu_stack.patch | 42 +++++++++ .../fbdev-bugfix-for-multiprocess-defio.patch | 70 ++++++++++++++ ...v7670-clean-up-ov7670_read-semantics.patch | 51 ++++++++++ ...apidio-fix-device-reference-counting.patch | 35 +++++++ ...ed-irq-rate-for-when-hpet-is-enabled.patch | 47 ++++++++++ ...x-oops-in-mptspi_dv_renegotiate_work.patch | 48 ++++++++++ ...0-sanity-check-nr_uarts-on-all-paths.patch | 42 +++++++++ queue-2.6.25/series | 12 +++ ...er-preempt-of-per-cpu-data-structure.patch | 92 +++++++++++++++++++ .../tpm-add-intel-tpm-tis-device-hid.patch | 34 +++++++ 13 files changed, 609 insertions(+) create mode 100644 queue-2.6.25/cifs-fix-wksidarr-declaration-to-be-big-endian-friendly.patch create mode 100644 queue-2.6.25/drivers-char-pcmcia-ipwireless-hardware.c-fix-resource-leak.patch create mode 100644 queue-2.6.25/drivers-isdn-i4l-isdn_common.c-fix-small-resource-leak.patch create mode 100644 queue-2.6.25/exec-fix-stack-excutability-without-pt_gnu_stack.patch create mode 100644 queue-2.6.25/fbdev-bugfix-for-multiprocess-defio.patch create mode 100644 queue-2.6.25/ov7670-clean-up-ov7670_read-semantics.patch create mode 100644 queue-2.6.25/rapidio-fix-device-reference-counting.patch create mode 100644 queue-2.6.25/rtc-fix-reported-irq-rate-for-when-hpet-is-enabled.patch create mode 100644 queue-2.6.25/scsi-mptspi-fix-oops-in-mptspi_dv_renegotiate_work.patch create mode 100644 queue-2.6.25/serial8250-sanity-check-nr_uarts-on-all-paths.patch create mode 100644 queue-2.6.25/slub-fix-use-after-preempt-of-per-cpu-data-structure.patch create mode 100644 queue-2.6.25/tpm-add-intel-tpm-tis-device-hid.patch diff --git a/queue-2.6.25/cifs-fix-wksidarr-declaration-to-be-big-endian-friendly.patch b/queue-2.6.25/cifs-fix-wksidarr-declaration-to-be-big-endian-friendly.patch new file mode 100644 index 00000000000..b0b31b35199 --- /dev/null +++ b/queue-2.6.25/cifs-fix-wksidarr-declaration-to-be-big-endian-friendly.patch @@ -0,0 +1,50 @@ +From stable-bounces@linux.kernel.org Sat Jul 12 14:40:34 2008 +From: Jeff Layton +Date: Sat, 12 Jul 2008 21:40:22 GMT +Subject: cifs: fix wksidarr declaration to be big-endian friendly +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807122140.m6CLeM73009272@hera.kernel.org> + +From: Jeff Layton + +commit 536abdb0802f3fac1b217530741853843d63c281 upstream + +The current definition of wksidarr works fine on little endian arches +(since cpu_to_le32 is a no-op there), but on big-endian arches, it fails +to compile with this error: + +error: braced-group within expression allowed only inside a function + +The problem is that this static declaration has cpu_to_le32 embedded +within it, and that expands into a function macro. We need to use +__constant_cpu_to_le32() instead. + +Signed-off-by: Jeff Layton +Cc: Steven French +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/cifsacl.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/fs/cifs/cifsacl.c ++++ b/fs/cifs/cifsacl.c +@@ -34,11 +34,11 @@ + static struct cifs_wksid wksidarr[NUM_WK_SIDS] = { + {{1, 0, {0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0} }, "null user"}, + {{1, 1, {0, 0, 0, 0, 0, 1}, {0, 0, 0, 0, 0} }, "nobody"}, +- {{1, 1, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(11), 0, 0, 0, 0} }, "net-users"}, +- {{1, 1, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(18), 0, 0, 0, 0} }, "sys"}, +- {{1, 2, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(32), cpu_to_le32(544), 0, 0, 0} }, "root"}, +- {{1, 2, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(32), cpu_to_le32(545), 0, 0, 0} }, "users"}, +- {{1, 2, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(32), cpu_to_le32(546), 0, 0, 0} }, "guest"} } ++ {{1, 1, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(11), 0, 0, 0, 0} }, "net-users"}, ++ {{1, 1, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(18), 0, 0, 0, 0} }, "sys"}, ++ {{1, 2, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(32), __constant_cpu_to_le32(544), 0, 0, 0} }, "root"}, ++ {{1, 2, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(32), __constant_cpu_to_le32(545), 0, 0, 0} }, "users"}, ++ {{1, 2, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(32), __constant_cpu_to_le32(546), 0, 0, 0} }, "guest"} } + ; + + diff --git a/queue-2.6.25/drivers-char-pcmcia-ipwireless-hardware.c-fix-resource-leak.patch b/queue-2.6.25/drivers-char-pcmcia-ipwireless-hardware.c-fix-resource-leak.patch new file mode 100644 index 00000000000..aebafefdf59 --- /dev/null +++ b/queue-2.6.25/drivers-char-pcmcia-ipwireless-hardware.c-fix-resource-leak.patch @@ -0,0 +1,42 @@ +From stable-bounces@linux.kernel.org Sat Jul 12 14:41:04 2008 +From: Darren Jenkins +Date: Sat, 12 Jul 2008 21:40:47 GMT +Subject: drivers/char/pcmcia/ipwireless/hardware.c fix resource leak +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807122140.m6CLelRF009386@hera.kernel.org> + +From: Darren Jenkins + +commit 43f77e91eadbc290eb76a08110a039c809dde6c9 upstream + +Coverity CID: 2172 RESOURCE_LEAK + +When pool_allocate() tries to enlarge a packet, if it can not allocate enough +memory, it returns NULL without first freeing the old packet. + +This patch just frees the packet first. + +Signed-off-by: Darren Jenkins +Acked-by: Jiri Kosina +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/pcmcia/ipwireless/hardware.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/char/pcmcia/ipwireless/hardware.c ++++ b/drivers/char/pcmcia/ipwireless/hardware.c +@@ -616,8 +616,10 @@ static struct ipw_rx_packet *pool_alloca + packet = kmalloc(sizeof(struct ipw_rx_packet) + + old_packet->length + minimum_free_space, + GFP_ATOMIC); +- if (!packet) ++ if (!packet) { ++ kfree(old_packet); + return NULL; ++ } + memcpy(packet, old_packet, + sizeof(struct ipw_rx_packet) + + old_packet->length); diff --git a/queue-2.6.25/drivers-isdn-i4l-isdn_common.c-fix-small-resource-leak.patch b/queue-2.6.25/drivers-isdn-i4l-isdn_common.c-fix-small-resource-leak.patch new file mode 100644 index 00000000000..bf86a1ceef3 --- /dev/null +++ b/queue-2.6.25/drivers-isdn-i4l-isdn_common.c-fix-small-resource-leak.patch @@ -0,0 +1,44 @@ +From stable-bounces@linux.kernel.org Sat Jul 12 14:40:58 2008 +From: Darren Jenkins +Date: Sat, 12 Jul 2008 21:40:43 GMT +Subject: drivers/isdn/i4l/isdn_common.c fix small resource leak +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807122140.m6CLehiD009362@hera.kernel.org> + +From: Darren Jenkins + +commit 4fc89e3911aa5357b55b85b60c4beaeb8a48a290 upstream + +Coverity CID: 1356 RESOURCE_LEAK + +I found a very old patch for this that was Acked but did not get applied +https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.html + +There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when +copy_from_user() returns an un-copied data length (length != 0). The below +patch should be a minimally invasive fix. + +Signed-off-by: Darren Jenkins +Acked-by: Karsten Keil +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/isdn/i4l/isdn_common.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/isdn/i4l/isdn_common.c ++++ b/drivers/isdn/i4l/isdn_common.c +@@ -1977,8 +1977,10 @@ isdn_writebuf_stub(int drvidx, int chan, + if (!skb) + return -ENOMEM; + skb_reserve(skb, hl); +- if (copy_from_user(skb_put(skb, len), buf, len)) ++ if (copy_from_user(skb_put(skb, len), buf, len)) { ++ dev_kfree_skb(skb); + return -EFAULT; ++ } + ret = dev->drv[drvidx]->interface->writebuf_skb(drvidx, chan, 1, skb); + if (ret <= 0) + dev_kfree_skb(skb); diff --git a/queue-2.6.25/exec-fix-stack-excutability-without-pt_gnu_stack.patch b/queue-2.6.25/exec-fix-stack-excutability-without-pt_gnu_stack.patch new file mode 100644 index 00000000000..f4841082b2f --- /dev/null +++ b/queue-2.6.25/exec-fix-stack-excutability-without-pt_gnu_stack.patch @@ -0,0 +1,42 @@ +From stable-bounces@linux.kernel.org Thu Jul 10 13:45:09 2008 +From: Hugh Dickins +Date: Thu, 10 Jul 2008 20:45:02 GMT +Subject: exec: fix stack excutability without PT_GNU_STACK +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807102045.m6AKj2lf019827@hera.kernel.org> + +From: Hugh Dickins + +commit 96a8e13ed44e380fc2bb6c711d74d5ba698c00b2 upstream + +Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32) +exec'ing an ELF without a PT_GNU_STACK program header should default to an +executable stack; but this got broken by the unlimited argv feature because +stack vma is now created before the right personality has been established: +so breaking old binaries using nested function trampolines. + +Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack +vm_flags used to be set, before the mprotect_fixup. Checking through +our existing VM_flags, none would have changed since insert_vm_struct: +so this seems safer than finding a way through the personality labyrinth. + +Reported-by: pageexec@freemail.hu +Signed-off-by: Hugh Dickins +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/exec.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/exec.c ++++ b/fs/exec.c +@@ -605,7 +605,7 @@ int setup_arg_pages(struct linux_binprm + bprm->exec -= stack_shift; + + down_write(&mm->mmap_sem); +- vm_flags = vma->vm_flags; ++ vm_flags = VM_STACK_FLAGS; + + /* + * Adjust stack execute permissions; explicitly enable for diff --git a/queue-2.6.25/fbdev-bugfix-for-multiprocess-defio.patch b/queue-2.6.25/fbdev-bugfix-for-multiprocess-defio.patch new file mode 100644 index 00000000000..562d64e339b --- /dev/null +++ b/queue-2.6.25/fbdev-bugfix-for-multiprocess-defio.patch @@ -0,0 +1,70 @@ +From stable-bounces@linux.kernel.org Sat Jul 12 14:40:51 2008 +From: Jaya Kumar +Date: Sat, 12 Jul 2008 21:40:37 GMT +Subject: fbdev: bugfix for multiprocess defio +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807122140.m6CLebBg009340@hera.kernel.org> + +From: Jaya Kumar + +commit f31ad92f34913043cf008d6e479e92dfbaf02df1 upstream + +This patch is a bugfix for how defio handles multiple processes manipulating +the same framebuffer. + +Thanks to Bernard Blackham for identifying this bug. + +It occurs when two applications mmap the same framebuffer and concurrently +write to the same page. Normally, this doesn't occur since only a single +process mmaps the framebuffer. The symptom of the bug is that the mapping +applications will hang. The cause is that defio incorrectly tries to add the +same page twice to the pagelist. The solution I have is to walk the pagelist +and check for a duplicate before adding. Since I needed to walk the pagelist, +I now also keep the pagelist in sorted order. + +Signed-off-by: Jaya Kumar +Cc: Bernard Blackham +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/video/fb_defio.c | 20 +++++++++++++++++++- + 1 file changed, 19 insertions(+), 1 deletion(-) + +--- a/drivers/video/fb_defio.c ++++ b/drivers/video/fb_defio.c +@@ -74,6 +74,7 @@ static int fb_deferred_io_mkwrite(struct + { + struct fb_info *info = vma->vm_private_data; + struct fb_deferred_io *fbdefio = info->fbdefio; ++ struct page *cur; + + /* this is a callback we get when userspace first tries to + write to the page. we schedule a workqueue. that workqueue +@@ -83,7 +84,24 @@ static int fb_deferred_io_mkwrite(struct + + /* protect against the workqueue changing the page list */ + mutex_lock(&fbdefio->lock); +- list_add(&page->lru, &fbdefio->pagelist); ++ ++ /* we loop through the pagelist before adding in order ++ to keep the pagelist sorted */ ++ list_for_each_entry(cur, &fbdefio->pagelist, lru) { ++ /* this check is to catch the case where a new ++ process could start writing to the same page ++ through a new pte. this new access can cause the ++ mkwrite even when the original ps's pte is marked ++ writable */ ++ if (unlikely(cur == page)) ++ goto page_already_added; ++ else if (cur->index > page->index) ++ break; ++ } ++ ++ list_add_tail(&page->lru, &cur->lru); ++ ++page_already_added: + mutex_unlock(&fbdefio->lock); + + /* come back after delay to process the deferred IO */ diff --git a/queue-2.6.25/ov7670-clean-up-ov7670_read-semantics.patch b/queue-2.6.25/ov7670-clean-up-ov7670_read-semantics.patch new file mode 100644 index 00000000000..9c44893b102 --- /dev/null +++ b/queue-2.6.25/ov7670-clean-up-ov7670_read-semantics.patch @@ -0,0 +1,51 @@ +From stable-bounces@linux.kernel.org Sat Jul 12 14:40:41 2008 +From: Andres Salomon +Date: Sat, 12 Jul 2008 21:40:27 GMT +Subject: ov7670: clean up ov7670_read semantics +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807122140.m6CLeR5u009288@hera.kernel.org> + +From: Andres Salomon + +commit bca5c2c550f16d2dc2d21ffb7b4712bd0a7d32a9 upstream + +Cortland Setlow pointed out a bug in ov7670.c where the result from +ov7670_read() was just being checked for !0, rather than <0. This made me +realize that ov7670_read's semantics were rather confusing; it both fills +in 'value' with the result, and returns it. This is goes against general +kernel convention; so rather than fixing callers, let's fix the function. + +This makes ov7670_read return <0 in the case of an error, and 0 upon +success. Thus, code like: + +res = ov7670_read(...); +if (!res) + goto error; + +.will work properly. + +Signed-off-by: Cortland Setlow +Signed-off-by: Andres Salomon +Acked-by: Jonathan Corbet +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/video/ov7670.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/media/video/ov7670.c ++++ b/drivers/media/video/ov7670.c +@@ -406,8 +406,10 @@ static int ov7670_read(struct i2c_client + int ret; + + ret = i2c_smbus_read_byte_data(c, reg); +- if (ret >= 0) ++ if (ret >= 0) { + *value = (unsigned char) ret; ++ ret = 0; ++ } + return ret; + } + diff --git a/queue-2.6.25/rapidio-fix-device-reference-counting.patch b/queue-2.6.25/rapidio-fix-device-reference-counting.patch new file mode 100644 index 00000000000..18f023c81f8 --- /dev/null +++ b/queue-2.6.25/rapidio-fix-device-reference-counting.patch @@ -0,0 +1,35 @@ +From stable-bounces@linux.kernel.org Fri Jul 11 11:40:15 2008 +From: Eugene Surovegin +Date: Fri, 11 Jul 2008 18:40:07 GMT +Subject: rapidio: fix device reference counting +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807111840.m6BIe7Ff002935@hera.kernel.org> + +From: Eugene Surovegin + +commit a7de3902edce099e4102c1272ec0ab569c1791f7 upstream + +Fix RapidIO device reference counting. + +Signed-of-by: Eugene Surovegin +Cc: Matt Porter +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/rapidio/rio-driver.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/rapidio/rio-driver.c ++++ b/drivers/rapidio/rio-driver.c +@@ -101,8 +101,8 @@ static int rio_device_probe(struct devic + if (error >= 0) { + rdev->driver = rdrv; + error = 0; ++ } else + rio_dev_put(rdev); +- } + } + return error; + } diff --git a/queue-2.6.25/rtc-fix-reported-irq-rate-for-when-hpet-is-enabled.patch b/queue-2.6.25/rtc-fix-reported-irq-rate-for-when-hpet-is-enabled.patch new file mode 100644 index 00000000000..4444d3c8a87 --- /dev/null +++ b/queue-2.6.25/rtc-fix-reported-irq-rate-for-when-hpet-is-enabled.patch @@ -0,0 +1,47 @@ +From stable-bounces@linux.kernel.org Fri Jul 11 11:40:15 2008 +From: Paul Gortmaker +Date: Fri, 11 Jul 2008 18:40:03 GMT +Subject: rtc: fix reported IRQ rate for when HPET is enabled +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807111840.m6BIe3sa002814@hera.kernel.org> + +From: Paul Gortmaker + +commit 61ca9daa2ca3022dc9cb22bd98e69c1b61e412ad upstream + +The IRQ rate reported back by the RTC is incorrect when HPET is enabled. + +Newer hardware that has HPET to emulate the legacy RTC device gets this value +wrong since after it sets the rate, it returns before setting the variable +used to report the IRQ rate back to users of the device -- so the set rate and +the reported rate get out of sync. + +Signed-off-by: Paul Gortmaker +Cc: Ingo Molnar +Cc: David Brownell +Cc: Thomas Gleixner +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/rtc.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/char/rtc.c ++++ b/drivers/char/rtc.c +@@ -677,12 +677,13 @@ static int rtc_do_ioctl(unsigned int cmd + if (arg != (1< +Date: Sat, 12 Jul 2008 21:40:51 GMT +Subject: SCSI: mptspi: fix oops in mptspi_dv_renegotiate_work() +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807122140.m6CLep0S009408@hera.kernel.org> + +From: James Bottomley + +commit 081a5bcb39b455405d58f79bb3c9398a9d4477ed upstream + +The problem here is that if the ioc faults too early in the bring up +sequence (as it usually does for an irq routing problem), ioc_reset gets +called before the scsi host is even allocated. This causes an oops when +it later schedules a renegotiation. Fix this by checking ioc->sh before +trying to renegotiate. + +Cc: "Moore, Eric" +Signed-off-by: James Bottomley +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/message/fusion/mptspi.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/drivers/message/fusion/mptspi.c ++++ b/drivers/message/fusion/mptspi.c +@@ -1266,13 +1266,18 @@ mptspi_dv_renegotiate(struct _MPT_SCSI_H + static int + mptspi_ioc_reset(MPT_ADAPTER *ioc, int reset_phase) + { +- struct _MPT_SCSI_HOST *hd = shost_priv(ioc->sh); + int rc; + + rc = mptscsih_ioc_reset(ioc, reset_phase); + +- if (reset_phase == MPT_IOC_POST_RESET) ++ /* only try to do a renegotiation if we're properly set up ++ * if we get an ioc fault on bringup, ioc->sh will be NULL */ ++ if (reset_phase == MPT_IOC_POST_RESET && ++ ioc->sh) { ++ struct _MPT_SCSI_HOST *hd = shost_priv(ioc->sh); ++ + mptspi_dv_renegotiate(hd); ++ } + + return rc; + } diff --git a/queue-2.6.25/serial8250-sanity-check-nr_uarts-on-all-paths.patch b/queue-2.6.25/serial8250-sanity-check-nr_uarts-on-all-paths.patch new file mode 100644 index 00000000000..5f3df9227d8 --- /dev/null +++ b/queue-2.6.25/serial8250-sanity-check-nr_uarts-on-all-paths.patch @@ -0,0 +1,42 @@ +From stable-bounces@linux.kernel.org Sat Jul 12 14:40:44 2008 +From: Eric W. Biederman +Date: Sat, 12 Jul 2008 21:40:32 GMT +Subject: serial8250: sanity check nr_uarts on all paths. +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807122140.m6CLeWMT009319@hera.kernel.org> + +From: Eric W. Biederman + +commit 05d81d2222beec7b63ac8c1c8cdb5bb4f82c2bad upstream + +I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird +mysterious crash in sysfs. After taking an in-depth look I realized that +CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of +the serial8250_ports array. + +Ouch!!! + +Don't let this happen to someone else. + +Signed-off-by: Eric W. Biederman +Acked-by: Alan Cox +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/serial/8250.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/serial/8250.c ++++ b/drivers/serial/8250.c +@@ -2564,6 +2564,9 @@ static struct console serial8250_console + + static int __init serial8250_console_init(void) + { ++ if (nr_uarts > UART_NR) ++ nr_uarts = UART_NR; ++ + serial8250_isa_init_ports(); + register_console(&serial8250_console); + return 0; diff --git a/queue-2.6.25/series b/queue-2.6.25/series index b303ac5a9f7..6f375356af2 100644 --- a/queue-2.6.25/series +++ b/queue-2.6.25/series @@ -27,3 +27,15 @@ md-ensure-all-blocks-are-uptodate-or-locked-when-syncing.patch textsearch-fix-boyer-moore-text-search-bug.patch netfilter-nf_conntrack_tcp-fixing-to-check-the-lower-bound-of-valid-ack.patch zd1211rw-add-id-for-airties-wus-201.patch +exec-fix-stack-excutability-without-pt_gnu_stack.patch +slub-fix-use-after-preempt-of-per-cpu-data-structure.patch +rtc-fix-reported-irq-rate-for-when-hpet-is-enabled.patch +rapidio-fix-device-reference-counting.patch +tpm-add-intel-tpm-tis-device-hid.patch +cifs-fix-wksidarr-declaration-to-be-big-endian-friendly.patch +ov7670-clean-up-ov7670_read-semantics.patch +serial8250-sanity-check-nr_uarts-on-all-paths.patch +fbdev-bugfix-for-multiprocess-defio.patch +drivers-isdn-i4l-isdn_common.c-fix-small-resource-leak.patch +drivers-char-pcmcia-ipwireless-hardware.c-fix-resource-leak.patch +scsi-mptspi-fix-oops-in-mptspi_dv_renegotiate_work.patch diff --git a/queue-2.6.25/slub-fix-use-after-preempt-of-per-cpu-data-structure.patch b/queue-2.6.25/slub-fix-use-after-preempt-of-per-cpu-data-structure.patch new file mode 100644 index 00000000000..4c4b2dcd09e --- /dev/null +++ b/queue-2.6.25/slub-fix-use-after-preempt-of-per-cpu-data-structure.patch @@ -0,0 +1,92 @@ +From stable-bounces@linux.kernel.org Thu Jul 10 18:20:09 2008 +From: Dmitry Adamushko +Date: Fri, 11 Jul 2008 01:20:02 GMT +Subject: slub: Fix use-after-preempt of per-CPU data structure +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807110120.m6B1K2LR017313@hera.kernel.org> + +From: Dmitry Adamushko + +commit bdb21928512a860a60e6a24a849dc5b63cbaf96a upstream + +Vegard Nossum reported a crash in kmem_cache_alloc(): + + BUG: unable to handle kernel paging request at da87d000 + IP: [] kmem_cache_alloc+0xc7/0xe0 + *pde = 28180163 *pte = 1a87d160 + Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC + Pid: 3850, comm: grep Not tainted (2.6.26-rc9-00059-gb190333 #5) + EIP: 0060:[] EFLAGS: 00210203 CPU: 0 + EIP is at kmem_cache_alloc+0xc7/0xe0 + EAX: 00000000 EBX: da87c100 ECX: 1adad71a EDX: 6b6b6b6b + ESI: 00200282 EDI: da87d000 EBP: f60bfe74 ESP: f60bfe54 + DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 + +and analyzed it: + + "The register %ecx looks innocent but is very important here. The disassembly: + + mov %edx,%ecx + shr $0x2,%ecx + rep stos %eax,%es:(%edi) <-- the fault + + So %ecx has been loaded from %edx... which is 0x6b6b6b6b/POISON_FREE. + (0x6b6b6b6b >> 2 == 0x1adadada.) + + %ecx is the counter for the memset, from here: + + memset(object, 0, c->objsize); + + i.e. %ecx was loaded from c->objsize, so "c" must have been freed. + Where did "c" come from? Uh-oh... + + c = get_cpu_slab(s, smp_processor_id()); + + This looks like it has very much to do with CPU hotplug/unplug. Is + there a race between SLUB/hotplug since the CPU slab is used after it + has been freed?" + +Good analysis. + +Yeah, it's possible that a caller of kmem_cache_alloc() -> slab_alloc() +can be migrated on another CPU right after local_irq_restore() and +before memset(). The inital cpu can become offline in the mean time (or +a migration is a consequence of the CPU going offline) so its +'kmem_cache_cpu' structure gets freed ( slab_cpuup_callback). + +At some point of time the caller continues on another CPU having an +obsolete pointer... + +Signed-off-by: Dmitry Adamushko +Reported-by: Vegard Nossum +Acked-by: Ingo Molnar +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/slub.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -1575,9 +1575,11 @@ static __always_inline void *slab_alloc( + void **object; + struct kmem_cache_cpu *c; + unsigned long flags; ++ unsigned int objsize; + + local_irq_save(flags); + c = get_cpu_slab(s, smp_processor_id()); ++ objsize = c->objsize; + if (unlikely(!c->freelist || !node_match(c, node))) + + object = __slab_alloc(s, gfpflags, node, addr, c); +@@ -1590,7 +1592,7 @@ static __always_inline void *slab_alloc( + local_irq_restore(flags); + + if (unlikely((gfpflags & __GFP_ZERO) && object)) +- memset(object, 0, c->objsize); ++ memset(object, 0, objsize); + + return object; + } diff --git a/queue-2.6.25/tpm-add-intel-tpm-tis-device-hid.patch b/queue-2.6.25/tpm-add-intel-tpm-tis-device-hid.patch new file mode 100644 index 00000000000..167df6e4e76 --- /dev/null +++ b/queue-2.6.25/tpm-add-intel-tpm-tis-device-hid.patch @@ -0,0 +1,34 @@ +From stable-bounces@linux.kernel.org Fri Jul 11 11:40:21 2008 +From: Marcin Obara +Date: Fri, 11 Jul 2008 18:40:10 GMT +Subject: tpm: add Intel TPM TIS device HID +To: jejb@kernel.org, stable@kernel.org +Message-ID: <200807111840.m6BIeAor002957@hera.kernel.org> + +From: Marcin Obara + +commit fb0e7e11d017beb5f0b1fa25bc51e49e65c46d67 upstream + +This patch adds Intel TPM TIS device HID: ICO0102 + +Signed-off-by: Marcin Obara +Acked-by: Marcel Selhorst +Acked-by: Rajiv Andrade +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/tpm/tpm_tis.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/char/tpm/tpm_tis.c ++++ b/drivers/char/tpm/tpm_tis.c +@@ -623,6 +623,7 @@ static struct pnp_device_id tpm_pnp_tbl[ + {"IFX0102", 0}, /* Infineon */ + {"BCM0101", 0}, /* Broadcom */ + {"NSC1200", 0}, /* National */ ++ {"ICO0102", 0}, /* Intel */ + /* Add new here */ + {"", 0}, /* User Specified */ + {"", 0} /* Terminator */ -- 2.47.3