From: Greg Kroah-Hartman Date: Tue, 20 Feb 2007 23:43:32 +0000 (-0800) Subject: more patches added to queues X-Git-Tag: v2.6.18.8~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=25e2ff60f478c6eaa23f7a27bbc634d888f3e7fc;p=thirdparty%2Fkernel%2Fstable-queue.git more patches added to queues --- diff --git a/queue-2.6.18/series b/queue-2.6.18/series index 26da5d26d05..6769c9598cc 100644 --- a/queue-2.6.18/series +++ b/queue-2.6.18/series @@ -13,3 +13,4 @@ V4L-Fix-quickcam-communicator-driver-for-big-endian-architectures.patch V4L-fix-ks0127-status-flags.patch V4L-tveeprom-autodetect-LG-TAPC-G701D-as-tuner-type-37.patch V4L-buf_qbuf-fix-videobuf_queue-stream-corruption-and-lockup.patch +x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch diff --git a/queue-2.6.18/x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch b/queue-2.6.18/x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch new file mode 100644 index 00000000000..641c15619cc --- /dev/null +++ b/queue-2.6.18/x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch @@ -0,0 +1,48 @@ +From stable-bounces@linux.kernel.org Wed Feb 14 18:42:06 2007 +From: "Paolo 'Blaisorblade' Giarrusso" +Date: Thu, 15 Feb 2007 03:34:23 +0100 +Subject: x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted +To: Andrew Morton , stable@kernel.org +Cc: Jeff Dike , Andi Kleen , user-mode-linux-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org +Message-ID: <11715068631914-git-send-email-blaisorblade@yahoo.it> + + +Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and +forced by binary compatibility. UML/32bit breaks because of this - since it is wise +enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host +kernels. + +Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had: + + default: + return sys_ptrace(request, pid, addr, data); + +Instead here we have: + case PTRACE_GET_THREAD_AREA: + case ...: + return sys_ptrace(request, pid, addr, data); + + default: + return -EINVAL; + +This change was a style change - when a case is added, it must be explicitly +tested this way. In this case, not enough testing was done. + +Cc: Andi Kleen +Signed-off-by: Paolo 'Blaisorblade' Giarrusso +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86_64/ia32/ptrace32.c | 1 + + 1 file changed, 1 insertion(+) + +--- linux-2.6.18.7.orig/arch/x86_64/ia32/ptrace32.c ++++ linux-2.6.18.7/arch/x86_64/ia32/ptrace32.c +@@ -239,6 +239,7 @@ asmlinkage long sys32_ptrace(long reques + case PTRACE_SINGLESTEP: + case PTRACE_DETACH: + case PTRACE_SYSCALL: ++ case PTRACE_OLDSETOPTIONS: + case PTRACE_SETOPTIONS: + return sys_ptrace(request, pid, addr, data); + diff --git a/queue-2.6.19/aio-fix-buggy-put_ioctx-call-in-aio_complete-v2.patch b/queue-2.6.19/aio-fix-buggy-put_ioctx-call-in-aio_complete-v2.patch new file mode 100644 index 00000000000..23b59ed46c6 --- /dev/null +++ b/queue-2.6.19/aio-fix-buggy-put_ioctx-call-in-aio_complete-v2.patch @@ -0,0 +1,152 @@ +From stable-bounces@linux.kernel.org Sat Feb 3 01:15:36 2007 +From: "Ken Chen" +Date: Sat, 03 Feb 2007 01:13:45 -0800 +Subject: aio: fix buggy put_ioctx call in aio_complete - v2 +To: torvalds@linux-foundation.org +Cc: suparna@in.ibm.com, zach.brown@oracle.com, jmoyer@redhat.com, bcrl@kvack.org, pbadari@us.ibm.com, kenchen@google.com, akpm@linux-foundation.org, stable@kernel.org +Message-ID: <200702030913.l139DjuJ005657@shell0.pdx.osdl.net> + + +From: "Ken Chen" + +An AIO bug was reported that sleeping function is being called in softirq +context: + +BUG: warning at kernel/mutex.c:132/__mutex_lock_common() +Call Trace: + [] __mutex_lock_slowpath+0x640/0x6c0 + [] mutex_lock+0x20/0x40 + [] flush_workqueue+0xb0/0x1a0 + [] __put_ioctx+0xc0/0x240 + [] aio_complete+0x2f0/0x420 + [] finished_one_bio+0x200/0x2a0 + [] dio_bio_complete+0x1c0/0x200 + [] dio_bio_end_aio+0x60/0x80 + [] bio_endio+0x110/0x1c0 + [] __end_that_request_first+0x180/0xba0 + [] end_that_request_chunk+0x30/0x60 + [] scsi_end_request+0x50/0x300 [scsi_mod] + [] scsi_io_completion+0x200/0x8a0 [scsi_mod] + [] sd_rw_intr+0x330/0x860 [sd_mod] + [] scsi_finish_command+0x100/0x1c0 [scsi_mod] + [] scsi_softirq_done+0x230/0x300 [scsi_mod] + [] blk_done_softirq+0x160/0x1c0 + [] __do_softirq+0x200/0x240 + [] do_softirq+0x70/0xc0 + +See report: http://marc.theaimsgroup.com/?l=linux-kernel&m=116599593200888&w=2 + +flush_workqueue() is not allowed to be called in the softirq context. +However, aio_complete() called from I/O interrupt can potentially call +put_ioctx with last ref count on ioctx and triggers bug. It is simply +incorrect to perform ioctx freeing from aio_complete. + +The bug is trigger-able from a race between io_destroy() and aio_complete(). +A possible scenario: + +cpu0 cpu1 +io_destroy aio_complete + wait_for_all_aios { __aio_put_req + ... ctx->reqs_active--; + if (!ctx->reqs_active) + return; + } + ... + put_ioctx(ioctx) + + put_ioctx(ctx); + __put_ioctx + bam! Bug trigger! + +The real problem is that the condition check of ctx->reqs_active in +wait_for_all_aios() is incorrect that access to reqs_active is not +being properly protected by spin lock. + +This patch adds that protective spin lock, and at the same time removes +all duplicate ref counting for each kiocb as reqs_active is already used +as a ref count for each active ioctx. This also ensures that buggy call +to flush_workqueue() in softirq context is eliminated. + +Signed-off-by: "Ken Chen" +Cc: Zach Brown +Cc: Suparna Bhattacharya +Cc: Benjamin LaHaise +Cc: Badari Pulavarty +Acked-by: Jeff Moyer +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman + +--- + fs/aio.c | 20 +++++++++----------- + 1 file changed, 9 insertions(+), 11 deletions(-) + +--- linux-2.6.19.4.orig/fs/aio.c ++++ linux-2.6.19.4/fs/aio.c +@@ -298,17 +298,23 @@ static void wait_for_all_aios(struct kio + struct task_struct *tsk = current; + DECLARE_WAITQUEUE(wait, tsk); + ++ spin_lock_irq(&ctx->ctx_lock); + if (!ctx->reqs_active) +- return; ++ goto out; + + add_wait_queue(&ctx->wait, &wait); + set_task_state(tsk, TASK_UNINTERRUPTIBLE); + while (ctx->reqs_active) { ++ spin_unlock_irq(&ctx->ctx_lock); + schedule(); + set_task_state(tsk, TASK_UNINTERRUPTIBLE); ++ spin_lock_irq(&ctx->ctx_lock); + } + __set_task_state(tsk, TASK_RUNNING); + remove_wait_queue(&ctx->wait, &wait); ++ ++out: ++ spin_unlock_irq(&ctx->ctx_lock); + } + + /* wait_on_sync_kiocb: +@@ -425,7 +431,6 @@ static struct kiocb fastcall *__aio_get_ + ring = kmap_atomic(ctx->ring_info.ring_pages[0], KM_USER0); + if (ctx->reqs_active < aio_ring_avail(&ctx->ring_info, ring)) { + list_add(&req->ki_list, &ctx->active_reqs); +- get_ioctx(ctx); + ctx->reqs_active++; + okay = 1; + } +@@ -538,8 +543,6 @@ int fastcall aio_put_req(struct kiocb *r + spin_lock_irq(&ctx->ctx_lock); + ret = __aio_put_req(ctx, req); + spin_unlock_irq(&ctx->ctx_lock); +- if (ret) +- put_ioctx(ctx); + return ret; + } + +@@ -795,8 +798,7 @@ static int __aio_run_iocbs(struct kioctx + */ + iocb->ki_users++; /* grab extra reference */ + aio_run_iocb(iocb); +- if (__aio_put_req(ctx, iocb)) /* drop extra ref */ +- put_ioctx(ctx); ++ __aio_put_req(ctx, iocb); + } + if (!list_empty(&ctx->run_list)) + return 1; +@@ -1014,14 +1016,10 @@ put_rq: + /* everything turned out well, dispose of the aiocb. */ + ret = __aio_put_req(ctx, iocb); + +- spin_unlock_irqrestore(&ctx->ctx_lock, flags); +- + if (waitqueue_active(&ctx->wait)) + wake_up(&ctx->wait); + +- if (ret) +- put_ioctx(ctx); +- ++ spin_unlock_irqrestore(&ctx->ctx_lock, flags); + return ret; + } + diff --git a/queue-2.6.19/net-smc911x-match-up-spin-lock-unlock.patch b/queue-2.6.19/net-smc911x-match-up-spin-lock-unlock.patch new file mode 100644 index 00000000000..678faa3a43c --- /dev/null +++ b/queue-2.6.19/net-smc911x-match-up-spin-lock-unlock.patch @@ -0,0 +1,46 @@ +From stable-bounces@linux.kernel.org Sat Feb 3 01:15:25 2007 +From: Peter Korsgaard +Date: Sat, 03 Feb 2007 01:13:50 -0800 +Subject: net/smc911x: match up spin lock/unlock +To: torvalds@linux-foundation.org +Cc: jacmet@sunsite.dk, akpm@linux-foundation.org, stable@kernel.org, jeff@garzik.org +Message-ID: <200702030913.l139DoIn005666@shell0.pdx.osdl.net> + +From: Peter Korsgaard + +smc911x_phy_configure's error handling unconditionally unlocks the +spinlock even if it wasn't locked. Patch fixes it. + +Signed-off-by: Peter Korsgaard +Cc: Jeff Garzik +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/smc911x.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- linux-2.6.19.4.orig/drivers/net/smc911x.c ++++ linux-2.6.19.4/drivers/net/smc911x.c +@@ -965,11 +965,11 @@ static void smc911x_phy_configure(void * + * We should not be called if phy_type is zero. + */ + if (lp->phy_type == 0) +- goto smc911x_phy_configure_exit; ++ goto smc911x_phy_configure_exit_nolock; + + if (smc911x_phy_reset(dev, phyaddr)) { + printk("%s: PHY reset timed out\n", dev->name); +- goto smc911x_phy_configure_exit; ++ goto smc911x_phy_configure_exit_nolock; + } + spin_lock_irqsave(&lp->lock, flags); + +@@ -1038,6 +1038,7 @@ static void smc911x_phy_configure(void * + + smc911x_phy_configure_exit: + spin_unlock_irqrestore(&lp->lock, flags); ++smc911x_phy_configure_exit_nolock: + lp->work_pending = 0; + } + diff --git a/queue-2.6.19/rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch b/queue-2.6.19/rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch new file mode 100644 index 00000000000..2d35f2f6ca9 --- /dev/null +++ b/queue-2.6.19/rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch @@ -0,0 +1,145 @@ +From stable-bounces@linux.kernel.org Sat Feb 3 06:18:09 2007 +From: Atsushi Nemoto +Date: Sat, 03 Feb 2007 23:16:36 +0900 (JST) +Subject: rtc-pcf8563: detect polarity of century bit automatically +To: akpm@linux-foundation.org +Cc: jean-baptiste.maneyrol@teamlog.com, a.zummo@towertech.it, dbrownell@users.sourceforge.net, torvalds@linux-foundation.org, stable@kernel.org +Message-ID: <20070203.231636.41198366.anemo@mba.ocn.ne.jp> + + +From: Atsushi Nemoto + +The usage of the century bit was inverted on 2.6.19 following to PCF8563's +description, but it was not match to usage suggested by RTC8564's +datasheet. Anyway what MO_C=1 means can vary on each platform. This patch +is to detect its polarity in get_datetime routine. The default value of +c_polarity is 0 (MO_C=1 means 19xx) so that this patch does not change +current behavior even if get_datetime was not called before set_datetime. + +Signed-off-by: Atsushi Nemoto +Cc: Jean-Baptiste Maneyrol +Cc: David Brownell +Cc: Alessandro Zummo +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/rtc/rtc-pcf8563.c | 40 ++++++++++++++++++++++++++++++++++------ + 1 file changed, 34 insertions(+), 6 deletions(-) + +--- linux-2.6.19.4.orig/drivers/rtc/rtc-pcf8563.c ++++ linux-2.6.19.4/drivers/rtc/rtc-pcf8563.c +@@ -53,6 +53,25 @@ I2C_CLIENT_INSMOD; + #define PCF8563_SC_LV 0x80 /* low voltage */ + #define PCF8563_MO_C 0x80 /* century */ + ++struct pcf8563 { ++ struct i2c_client client; ++ /* ++ * The meaning of MO_C bit varies by the chip type. ++ * From PCF8563 datasheet: this bit is toggled when the years ++ * register overflows from 99 to 00 ++ * 0 indicates the century is 20xx ++ * 1 indicates the century is 19xx ++ * From RTC8564 datasheet: this bit indicates change of ++ * century. When the year digit data overflows from 99 to 00, ++ * this bit is set. By presetting it to 0 while still in the ++ * 20th century, it will be set in year 2000, ... ++ * There seems no reliable way to know how the system use this ++ * bit. So let's do it heuristically, assuming we are live in ++ * 1970...2069. ++ */ ++ int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */ ++}; ++ + static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind); + static int pcf8563_detach(struct i2c_client *client); + +@@ -62,6 +81,7 @@ static int pcf8563_detach(struct i2c_cli + */ + static int pcf8563_get_datetime(struct i2c_client *client, struct rtc_time *tm) + { ++ struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client); + unsigned char buf[13] = { PCF8563_REG_ST1 }; + + struct i2c_msg msgs[] = { +@@ -94,8 +114,12 @@ static int pcf8563_get_datetime(struct i + tm->tm_mday = BCD2BIN(buf[PCF8563_REG_DM] & 0x3F); + tm->tm_wday = buf[PCF8563_REG_DW] & 0x07; + tm->tm_mon = BCD2BIN(buf[PCF8563_REG_MO] & 0x1F) - 1; /* rtc mn 1-12 */ +- tm->tm_year = BCD2BIN(buf[PCF8563_REG_YR]) +- + (buf[PCF8563_REG_MO] & PCF8563_MO_C ? 0 : 100); ++ tm->tm_year = BCD2BIN(buf[PCF8563_REG_YR]); ++ if (tm->tm_year < 70) ++ tm->tm_year += 100; /* assume we are in 1970...2069 */ ++ /* detect the polarity heuristically. see note above. */ ++ pcf8563->c_polarity = (buf[PCF8563_REG_MO] & PCF8563_MO_C) ? ++ (tm->tm_year >= 100) : (tm->tm_year < 100); + + dev_dbg(&client->dev, "%s: tm is secs=%d, mins=%d, hours=%d, " + "mday=%d, mon=%d, year=%d, wday=%d\n", +@@ -114,6 +138,7 @@ static int pcf8563_get_datetime(struct i + + static int pcf8563_set_datetime(struct i2c_client *client, struct rtc_time *tm) + { ++ struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client); + int i, err; + unsigned char buf[9]; + +@@ -135,7 +160,7 @@ static int pcf8563_set_datetime(struct i + + /* year and century */ + buf[PCF8563_REG_YR] = BIN2BCD(tm->tm_year % 100); +- if (tm->tm_year < 100) ++ if (pcf8563->c_polarity ? (tm->tm_year >= 100) : (tm->tm_year < 100)) + buf[PCF8563_REG_MO] |= PCF8563_MO_C; + + buf[PCF8563_REG_DW] = tm->tm_wday & 0x07; +@@ -248,6 +273,7 @@ static struct i2c_driver pcf8563_driver + + static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind) + { ++ struct pcf8563 *pcf8563; + struct i2c_client *client; + struct rtc_device *rtc; + +@@ -260,11 +286,12 @@ static int pcf8563_probe(struct i2c_adap + goto exit; + } + +- if (!(client = kzalloc(sizeof(struct i2c_client), GFP_KERNEL))) { ++ if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) { + err = -ENOMEM; + goto exit; + } + ++ client = &pcf8563->client; + client->addr = address; + client->driver = &pcf8563_driver; + client->adapter = adapter; +@@ -301,7 +328,7 @@ exit_detach: + i2c_detach_client(client); + + exit_kfree: +- kfree(client); ++ kfree(pcf8563); + + exit: + return err; +@@ -309,6 +336,7 @@ exit: + + static int pcf8563_detach(struct i2c_client *client) + { ++ struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client); + int err; + struct rtc_device *rtc = i2c_get_clientdata(client); + +@@ -318,7 +346,7 @@ static int pcf8563_detach(struct i2c_cli + if ((err = i2c_detach_client(client))) + return err; + +- kfree(client); ++ kfree(pcf8563); + + return 0; + } diff --git a/queue-2.6.19/series b/queue-2.6.19/series index 6aa7bd58416..bdbb9b0073f 100644 --- a/queue-2.6.19/series +++ b/queue-2.6.19/series @@ -3,3 +3,7 @@ V4L-Fix-quickcam-communicator-driver-for-big-endian-architectures.patch V4L-fix-ks0127-status-flags.patch V4L-tveeprom-autodetect-LG-TAPC-G701D-as-tuner-type-37.patch V4L-buf_qbuf-fix-videobuf_queue-stream-corruption-and-lockup.patch +net-smc911x-match-up-spin-lock-unlock.patch +rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch +aio-fix-buggy-put_ioctx-call-in-aio_complete-v2.patch +x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch diff --git a/queue-2.6.19/x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch b/queue-2.6.19/x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch new file mode 100644 index 00000000000..ad758eafac3 --- /dev/null +++ b/queue-2.6.19/x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch @@ -0,0 +1,48 @@ +From stable-bounces@linux.kernel.org Wed Feb 14 18:42:06 2007 +From: "Paolo 'Blaisorblade' Giarrusso" +Date: Thu, 15 Feb 2007 03:34:23 +0100 +Subject: x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted +To: Andrew Morton , stable@kernel.org +Cc: Jeff Dike , Andi Kleen , user-mode-linux-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org +Message-ID: <11715068631914-git-send-email-blaisorblade@yahoo.it> + + +Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and +forced by binary compatibility. UML/32bit breaks because of this - since it is wise +enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host +kernels. + +Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had: + + default: + return sys_ptrace(request, pid, addr, data); + +Instead here we have: + case PTRACE_GET_THREAD_AREA: + case ...: + return sys_ptrace(request, pid, addr, data); + + default: + return -EINVAL; + +This change was a style change - when a case is added, it must be explicitly +tested this way. In this case, not enough testing was done. + +Cc: Andi Kleen +Signed-off-by: Paolo 'Blaisorblade' Giarrusso +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86_64/ia32/ptrace32.c | 1 + + 1 file changed, 1 insertion(+) + +--- linux-2.6.19.4.orig/arch/x86_64/ia32/ptrace32.c ++++ linux-2.6.19.4/arch/x86_64/ia32/ptrace32.c +@@ -243,6 +243,7 @@ asmlinkage long sys32_ptrace(long reques + case PTRACE_SINGLESTEP: + case PTRACE_DETACH: + case PTRACE_SYSCALL: ++ case PTRACE_OLDSETOPTIONS: + case PTRACE_SETOPTIONS: + case PTRACE_SET_THREAD_AREA: + case PTRACE_GET_THREAD_AREA: