From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752430Ab2HAMzU (ORCPT ); Wed, 1 Aug 2012 08:55:20 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:20509 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751644Ab2HAMzS (ORCPT ); Wed, 1 Aug 2012 08:55:18 -0400 X-Authority-Analysis: v=2.0 cv=StQSGYy0 c=1 sm=0 a=s5Htg7xnQOKvHEu9STBOug==:17 a=OpT9cpI26MMA:10 a=RmaQ9WyBXnAA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10 a=meVymXHHAAAA:8 a=ayC55rCoAAAA:8 a=20KFwNOVAAAA:8 a=iox4zFpeAAAA:8 a=VwQbUJbxAAAA:8 a=n8JlVaIRwISlDlM4lQcA:9 a=PUjeQqilurYA:10 a=jEp0ucaQiEUA:10 a=n9GBPR9yFnkA:10 a=LI9Vle30uBYA:10 a=s5Htg7xnQOKvHEu9STBOug==:117 X-Cloudmark-Score: 0 X-Originating-IP: 72.230.195.127 Message-ID: <1343825716.27983.84.camel@gandalf.stny.rr.com> Subject: Re: [ 00/73] 3.2.25-stable review From: Steven Rostedt To: Ben Hutchings , Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Jens Axboe , Tejun Heo , Vivek Goyal Date: Wed, 01 Aug 2012 08:55:16 -0400 In-Reply-To: <20120731044310.013763753@decadent.org.uk> References: <20120731044310.013763753@decadent.org.uk> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2012-07-31 at 05:43 +0100, Ben Hutchings wrote: > This is the start of the stable review cycle for the 3.2.25 release. > There are 73 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 2 10:00:00 UTC 2012. > Anything received after that time might be too late. > > A combined patch relative to 3.2.24 will be posted as an additional > response to this, and the diffstat can be found below. I tested this against configs I normally test against my own code, and I hit this bug: [ 37.030215] ============================================================================= [ 37.031170] BUG blkdev_queue: Poison overwritten [ 37.031170] ----------------------------------------------------------------------------- [ 37.031170] [ 37.031170] INFO: 0xffff8800757287b0-0xffff8800757287b0. First byte 0x6a instead of 0x6b [ 37.031170] INFO: Allocated in blk_alloc_queue_node+0x25/0x1fb age=3399 cpu=1 pid=1 [ 37.031170] __slab_alloc+0x2e4/0x365 [ 37.031170] kmem_cache_alloc_node+0x92/0x18d [ 37.031170] blk_alloc_queue_node+0x25/0x1fb [ 37.031170] blk_init_queue_node+0x24/0x5c [ 37.031170] blk_init_queue+0x11/0x13 [ 37.031170] floppy_init+0x78/0x5d9^M [ 37.031170] do_one_initcall+0x7f/0x140 [ 37.092043] kernel_init+0xc9/0x143 [ 37.092043] kernel_thread_helper+0x4/0x10 [ 37.092043] INFO: Freed in blk_release_queue+0x86/0x8b age=78 cpu=0 pid=1 [ 37.092043] __slab_free+0x38/0x377 [ 37.092043] kmem_cache_free+0xf7/0x155 [ 37.092043] blk_release_queue+0x86/0x8b [ 37.092043] kobject_cleanup+0xc4/0xeb [ 37.092043] kobject_release+0xd/0xf [ 37.092043] kobject_put+0x4a/0x4f [ 37.092043] blk_cleanup_queue+0x159/0x162 [ 37.092043] floppy_init+0x5b6/0x5d9 [ 37.092043] do_one_initcall+0x7f/0x140 [ 37.092043] kernel_init+0xc9/0x143 [ 37.092043] kernel_thread_helper+0x4/0x10 [ 37.092043] INFO: Slab 0xffffea0001d5ca00 objects=9 used=9 fp=0x (null) flags=0x100000000004080 [ 37.092043] INFO: Object 0xffff880075728000 @offset=0 fp=0xffff88007572e700 [...] [ 37.092043] Object ffff880075728b80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk [ 37.092043] Object ffff880075728b90: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk. [ 37.092043] Redzone ffff880075728b98: bb bb bb bb bb bb bb bb ........ [ 37.092043] Padding ffff880075728cd8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ [ 37.092043] Pid: 1, comm: swapper/0 Not tainted 3.2.0-test+ #1 [ 37.092043] Call Trace: [ 37.092043] [] ? print_section+0x3d/0x3f [ 37.092043] [] print_trailer+0x10a/0x113 [ 37.092043] [] check_bytes_and_report+0xb1/0xea [ 37.092043] [] check_object+0xc4/0x1fc [ 37.092043] [] ? blk_alloc_queue_node+0x25/0x1fb [ 37.092043] [] ? blk_alloc_queue_node+0x25/0x1fb [ 37.092043] [] alloc_debug_processing+0xa7/0x14a [ 37.092043] [] __slab_alloc+0x2e4/0x365 [ 37.092043] [] ? blk_alloc_queue_node+0x25/0x1fb [ 37.092043] [] ? trace_hardirqs_on+0xd/0xf [ 37.092043] [] kmem_cache_alloc_node+0x92/0x18d [ 37.092043] [] ? trace_hardirqs_on_caller+0x12f/0x166 [ 37.092043] [] ? blk_alloc_queue_node+0x25/0x1fb [ 37.092043] [] blk_alloc_queue_node+0x25/0x1fb [ 37.092043] [] blk_alloc_queue+0x11/0x13 [ 37.092043] [] brd_alloc+0x79/0x185 [ 37.092043] [] brd_init+0xc6/0x19c [ 37.092043] [] ? floppy_init+0x5d9/0x5d9 [ 37.092043] [] do_one_initcall+0x7f/0x140 [ 37.092043] [] kernel_init+0xc9/0x143 [ 37.092043] [] kernel_thread_helper+0x4/0x10 [ 37.092043] [] ? retint_restore_args+0x13/0x13 [ 37.092043] [] ? start_kernel+0x3af/0x3af [ 37.092043] [] ? gs_change+0x13/0x13 [ 37.092043] FIX blkdev_queue: Restoring 0xffff8800757287b0-0xffff8800757287b0=0x6b I then checked against 3.2.24 and it bugged too, as well as vanilla 3.2. I then checked against 3.3 and it did not bug. I kicked off a 'reverse' bisect with ktest (bad is good and good is bad) and found the fix: commit 3f9a5aabd0a9fe0e0cd308506f48963d79169aa7 Author: Vivek Goyal floppy: Cleanup disk->queue before caling put_disk() if add_disk() was never called I applied it against v3.2.24 and it solved the bug. I did not apply it against 25-rc1, but I'm pretty sure it should work for that too. I haven't checked 3.0 if that has an issue with my config. Anyway, please apply this patch to stable 3.2. Either for 25 or for 26. Thanks! -- Steve commit 3f9a5aabd0a9fe0e0cd308506f48963d79169aa7 Author: Vivek Goyal Date: Wed Feb 8 20:03:38 2012 +0100 floppy: Cleanup disk->queue before caling put_disk() if add_disk() was never called add_disk() takes gendisk reference on request queue. If driver failed during initialization and never called add_disk() then that extra reference is not taken. That reference is put in put_disk(). floppy driver allocates the disk, allocates queue, sets disk->queue and then relizes that floppy controller is not present. It tries to tear down everything and tries to put a reference down in put_disk() which was never taken. In such error cases cleanup disk->queue before calling put_disk() so that we never try to put down a reference which was never taken in first place. Reported-and-tested-by: Suresh Jayaraman Tested-by: Dirk Gouders Signed-off-by: Vivek Goyal Acked-by: Tejun Heo Signed-off-by: Jens Axboe diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 510fb10..401ba78 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -4368,8 +4368,14 @@ out_unreg_blkdev: out_put_disk: while (dr--) { del_timer_sync(&motor_off_timer[dr]); - if (disks[dr]->queue) + if (disks[dr]->queue) { blk_cleanup_queue(disks[dr]->queue); + /* + * put_disk() is not paired with add_disk() and + * will put queue reference one extra time. fix it. + */ + disks[dr]->queue = NULL; + } put_disk(disks[dr]); } return err;