Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4167375imm; Mon, 18 Jun 2018 10:11:56 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIUu/G9Wg/yBCbNr/0Z9O9fpec369YuZKK0GJRa4WVdblN4NgD+yTAA+FuBiUn9JUXxnXV1 X-Received: by 2002:a62:fc8d:: with SMTP id e135-v6mr14451151pfh.208.1529341916189; Mon, 18 Jun 2018 10:11:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529341916; cv=none; d=google.com; s=arc-20160816; b=qOUy92QyYJa3EGPo9mmjFJamk9alQXyC+QPE+FgL86kpgMbT/wk3p0xxq1UzPuz5hw 1Bkm/AjGUabbWcdiQVhSVCNaL/aRSyVhVu0J2uLPzWJFI3s4Hak36ZUWm7ZjV9BmkElh 8FE30BNofMCYwGBh/XfpK9t5zD3/zfjqyDiC6dV8+SgQl58pOJVopwhfLWan/vFXSzat HmwxtKlgt3lkd9pWYNYNoRP31z/ESqLk9sueog819p/NmJiEdVLuqwerz9G3G1YROe5M 4TFqzvIHi3x9g9qzgb9T0BA5eyrncSjBfsiwz+gE6eeppbCjz46vl3ph33KHFtg1zkL8 6hsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:reply-to :arc-authentication-results; bh=LZZgzDPQ5nXahPP/G51QbWyuGntVp0JvmiS3Ws69p6A=; b=eL+pXxppemPHv0EQEtrSnMJo7aQqcUaiet0b+RmLkJLzQcNiEkw4/GOLzS0/09bQIU dfyWwoDq0v7wGcftnGuXRD9VHFnzgMjZfE7wPReXzF1j2CLuGfv48JhcMCKKfUH9SZPR RDGIya0yVvSzOlwCYGToRo8F35ozCF1l5yvjTIrXluNRRF/sBxaaH0qJWZhHQ+PgHk6I EeTbd/f09sZGk3VG8gfcY1lM6n6uRtQ83fWmWGZ8rkEq4UFBFvStrlS0kvMcuJ1PKXyc /YALNVqjEhK+bENLCOE080+CtFuYuTEJmJAVwdAYhV4fevTZz0P8xP0C13CKyQ9f1AA0 fOZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11-v6si12348710pgp.140.2018.06.18.10.11.42; Mon, 18 Jun 2018 10:11:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935260AbeFRRJm (ORCPT + 99 others); Mon, 18 Jun 2018 13:09:42 -0400 Received: from smtp.infotech.no ([82.134.31.41]:40110 "EHLO smtp.infotech.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755342AbeFRRJk (ORCPT ); Mon, 18 Jun 2018 13:09:40 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 1AC3C20423F; Mon, 18 Jun 2018 19:09:38 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeIam9yBhuH9; Mon, 18 Jun 2018 19:09:38 +0200 (CEST) Received: from [10.7.0.18] (unknown [10.7.0.18]) by smtp.infotech.no (Postfix) with ESMTPA id 7415A20418A; Mon, 18 Jun 2018 19:09:36 +0200 (CEST) Reply-To: dgilbert@interlog.com Subject: Re: [PATCH] scsi: scsi_debug: Fix memory leak on module unload To: Luis Henriques , "James E . J . Bottomley" , "Martin K . Petersen" Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20180618160803.11674-1-lhenriques@suse.com> From: Douglas Gilbert Message-ID: Date: Mon, 18 Jun 2018 13:09:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180618160803.11674-1-lhenriques@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-06-18 12:08 PM, Luis Henriques wrote: > Since commit 80c49563e250 ("scsi: scsi_debug: implement IMMED bit") there are > long delays in F_SYNC_DELAY and F_SSU_DELAY. This can cause a memory leak in > schedule_resp(), which can be invoked while unloading the scsi_debug module: > free_all_queued() had already freed all sd_dp and schedule_resp will alloc a new > one, which will never get freed. Here's the kmemleak report while running > xfstests generic/350: > > unreferenced object 0xffff88007d752b00 (size 128): > comm "rmmod", pid 26940, jiffies 4295816945 (age 7.588s) > hex dump (first 32 bytes): > 00 2b 75 7d 00 88 ff ff 00 00 00 00 00 00 00 00 .+u}............ > 00 00 00 00 00 00 00 00 8e 31 a2 34 5f 03 00 00 .........1.4_... > backtrace: > [<000000002abd83d0>] 0xffffffffa000705e > [<000000004c063fda>] scsi_dispatch_cmd+0xc7/0x1a0 > [<000000000c119a00>] scsi_request_fn+0x251/0x550 > [<000000009de0c736>] __blk_run_queue+0x3f/0x60 > [<000000001c4453c8>] blk_execute_rq_nowait+0x98/0xd0 > [<00000000d17ec79f>] blk_execute_rq+0x3a/0x50 > [<00000000a7654b6e>] scsi_execute+0x113/0x250 > [<00000000fd78f7cd>] sd_sync_cache+0x95/0x160 > [<0000000024dacb14>] sd_shutdown+0x9b/0xd0 > [<00000000e9101710>] sd_remove+0x5f/0xb0 > [<00000000c43f0d63>] device_release_driver_internal+0x13c/0x1f0 > [<00000000e8ad57b6>] bus_remove_device+0xe9/0x160 > [<00000000713a7b8a>] device_del+0x120/0x320 > [<00000000e5db670c>] __scsi_remove_device+0x115/0x150 > [<00000000eccbef30>] scsi_forget_host+0x20/0x60 > [<00000000cd5a0738>] scsi_remove_host+0x6d/0x120 > > Cc: stable@vger.kernel.org > Signed-off-by: Luis Henriques Acked-by: Douglas Gilbert Thanks. > --- > drivers/scsi/scsi_debug.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c > index 24d7496cd9e2..364e71861bfd 100644 > --- a/drivers/scsi/scsi_debug.c > +++ b/drivers/scsi/scsi_debug.c > @@ -5507,9 +5507,9 @@ static void __exit scsi_debug_exit(void) > int k = sdebug_add_host; > > stop_all_queued(); > - free_all_queued(); > for (; k; k--) > sdebug_remove_adapter(); > + free_all_queued(); > driver_unregister(&sdebug_driverfs_driver); > bus_unregister(&pseudo_lld_bus); > root_device_unregister(pseudo_primary); >