From patchwork Fri Jul 3 16:11:37 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Jones X-Patchwork-Id: 6716401 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 664EDC05AC for ; Fri, 3 Jul 2015 16:11:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6E5B620675 for ; Fri, 3 Jul 2015 16:11:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3DB0F2066C for ; Fri, 3 Jul 2015 16:11:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755656AbbGCQLr (ORCPT ); Fri, 3 Jul 2015 12:11:47 -0400 Received: from arcturus.aphlor.org ([188.246.204.175]:43204 "EHLO arcturus.aphlor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754936AbbGCQLp (ORCPT ); Fri, 3 Jul 2015 12:11:45 -0400 Received: from [209.6.119.210] (helo=wopr.kernelslacker.org) by arcturus.aphlor.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1ZB3Yw-0005iQ-1r for linux-scsi@vger.kernel.org; Fri, 03 Jul 2015 17:11:38 +0100 Received: by wopr.kernelslacker.org (Postfix, from userid 1000) id 01C2110092298; Fri, 3 Jul 2015 12:11:37 -0400 (EDT) Date: Fri, 3 Jul 2015 12:11:37 -0400 From: Dave Jones To: linux-scsi@vger.kernel.org Subject: blk-mq vs kmemleak Message-ID: <20150703161137.GA10438@codemonkey.org.uk> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Authenticated-User: davej@codemonkey.org.uk Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP After a fuzzing run recently, I noticed that the machine had oom'd, and killed everything, but there was still 3GB of memory still in use, that I couldn't even reclaim with /proc/sys/vm/drop_caches So I enabled kmemleak. After applying this.. otherwise it would disable itself within a minute of runtime. I notice now that I'm seeing a lot of traces like this.. unreferenced object 0xffff8800ba8202c0 (size 320): comm "kworker/u4:1", pid 38, jiffies 4294741176 (age 46887.690s) hex dump (first 32 bytes): 21 43 65 87 00 00 00 00 00 00 00 00 00 00 00 00 !Ce............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc+0x107/0x200 [] mempool_alloc_slab+0x1d/0x30 [] mempool_alloc+0x63/0x180 [] scsi_sg_alloc+0x4a/0x50 [] __sg_alloc_table+0x11e/0x180 [] scsi_alloc_sgtable+0x43/0x90 [] scsi_init_sgtable+0x31/0x80 [] scsi_init_io+0x4a/0x1c0 [] sd_init_command+0x59/0xe40 [] scsi_setup_cmnd+0xf1/0x160 [] scsi_queue_rq+0x57c/0x6a0 [] __blk_mq_run_hw_queue+0x1d8/0x390 [] blk_mq_run_hw_queue+0x9e/0x120 [] blk_mq_insert_requests+0xd4/0x1a0 [] blk_mq_flush_plug_list+0x123/0x140 unreferenced object 0xffff8800ba824800 (size 640): comm "trinity-c2", pid 3687, jiffies 4294843075 (age 46785.966s) hex dump (first 32 bytes): 21 43 65 87 00 00 00 00 00 00 00 00 00 00 00 00 !Ce............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc+0x107/0x200 [] mempool_alloc_slab+0x1d/0x30 [] mempool_alloc+0x63/0x180 [] scsi_sg_alloc+0x4a/0x50 [] __sg_alloc_table+0x11e/0x180 [] scsi_alloc_sgtable+0x43/0x90 [] scsi_init_sgtable+0x31/0x80 [] scsi_init_io+0x4a/0x1c0 [] sd_init_command+0x59/0xe40 [] scsi_setup_cmnd+0xf1/0x160 [] scsi_queue_rq+0x57c/0x6a0 [] __blk_mq_run_hw_queue+0x1d8/0x390 [] blk_mq_run_hw_queue+0x9e/0x120 [] blk_mq_insert_requests+0xd4/0x1a0 [] blk_mq_flush_plug_list+0x123/0x140 unreferenced object 0xffff8800a9fe6780 (size 2560): comm "kworker/1:1H", pid 171, jiffies 4294843118 (age 46785.923s) hex dump (first 32 bytes): 21 43 65 87 00 00 00 00 00 00 00 00 00 00 00 00 !Ce............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc+0x107/0x200 [] mempool_alloc_slab+0x1d/0x30 [] mempool_alloc+0x63/0x180 [] scsi_sg_alloc+0x4a/0x50 [] __sg_alloc_table+0x11e/0x180 [] scsi_alloc_sgtable+0x43/0x90 [] scsi_init_sgtable+0x31/0x80 [] scsi_init_io+0x4a/0x1c0 [] sd_init_command+0x59/0xe40 [] scsi_setup_cmnd+0xf1/0x160 [] scsi_queue_rq+0x57c/0x6a0 [] __blk_mq_run_hw_queue+0x1d8/0x390 [] blk_mq_run_work_fn+0x12/0x20 [] process_one_work+0x147/0x420 [] worker_thread+0x69/0x470 The sizes vary, but the hex dump is always the same. What's the usual completion path where these would get deallocated ? I'm wondering if there's just some annotation missing to appease kmemleak, because I'm seeing thousands of these. Or it could be a real leak, but it seems surprising no-one else is complaining. Dave --- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/mm/kmemleak.c b/mm/kmemleak.c index cf79f110157c..6dc18dbad9ec 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -553,8 +553,8 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size, object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp)); if (!object) { - pr_warning("Cannot allocate a kmemleak_object structure\n"); - kmemleak_disable(); + //pr_warning("Cannot allocate a kmemleak_object structure\n"); + //kmemleak_disable(); return NULL; }