Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp1507435ybm; Sat, 30 May 2020 11:03:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx989CwQuHf/au+X/0lUOfZ08NQeExMRvlRtL+jYSHNujxB/SDTG2AOTeJjRfV8+L0a9IRB X-Received: by 2002:a17:906:e08a:: with SMTP id gh10mr13369242ejb.512.1590861831090; Sat, 30 May 2020 11:03:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590861831; cv=none; d=google.com; s=arc-20160816; b=nkq8r3GpOHvCLPGrVI7oh/baGC2Z2S42D/wcMFvxQJ0b1RAnLWU0QdksPX0+i8aw7k 6afwCpfnoX7WSHVkQWdaKeLa3SRjvLgiJupz3pEHbp2nesAHHoG0BqMevJxMjbfDRFAo qggBbel7JsuUDZLYNivnkHgAB21zJLc3LMDZkgs+hCeZEly3kItnxG8bp27JZSOUrjTN yD1PH1PyZnu5UcT9uwAr8dAqtBF1l0jE6p19+UuZF8nEA8VQKXUdNuDfA7rGOPP4tzbu +o7L3qt2sY3PPLvYLfKADXvGm2g1J9ldR0gFjkVURUEroNfigOgRXtDyKBs4jSadTAF6 Djnw== 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:mime-version:user-agent:date:message-id:cc:to :subject:from:dkim-signature:dkim-signature; bh=XQQ8+zcRJDT/XDN1huHV6gokNYNTsW08knhUgG2sq6I=; b=D9hphu/Bsxbqj9ejn57rouprjlL5Ur0Fbo3ktzkLiBIzEyVi2fkQ/y2tnhv8eshN0x 37zZVNmVbvNFxfCtCiTCPMXVTK+OojEbjd43VC2NVcYbIj6/hh8QGEuku5QtsD3OLoEa SIooIEhPNfcatzZVOs0SGm47uX8X2262pO3G2MirqzqSy5jXf7Xn8ltG3PMeSlfl9uoZ 5h2ESugdavw17KUWndUyFMyoIEPbcH8KuUIuspszNn03j6hStQX3ownAxSsHLOYPYJEN TDjQC4cvcbqDuY1n3eYfkLuFK9mkhERqVSG6nsyQNVYwRk99epkKuIoSTeTAMawg1zdU S08A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@octiron.net header.s=20180214 header.b=R3gdukll; dkim=pass header.i=@octiron.net header.s=20180214 header.b=mpdsT09h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=octiron.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g1si7246899edv.486.2020.05.30.11.02.52; Sat, 30 May 2020 11:03:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@octiron.net header.s=20180214 header.b=R3gdukll; dkim=pass header.i=@octiron.net header.s=20180214 header.b=mpdsT09h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=octiron.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729211AbgE3R6s (ORCPT + 99 others); Sat, 30 May 2020 13:58:48 -0400 Received: from fourecks.uuid.uk ([147.135.211.183]:53188 "EHLO fourecks.uuid.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729026AbgE3R6s (ORCPT ); Sat, 30 May 2020 13:58:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=octiron.net ; s=20180214; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XQQ8+zcRJDT/XDN1huHV6gokNYNTsW08knhUgG2sq6I=; b=R3gdukll2N2MNAe7B8EpznfcZk zCRv0Ijz+tCnYhZsYc8p/ypYFfJfTclEGfwysMvlZAhkM/JRmMrhPM7wiAFDptI4Za3wq1xpEersm YH2hbDaIdE+3QhjhNHC5bSodhNuCQ2aO7fAQOrUF3Br1uijRpqTu1h0WuTgYJj9tHBjR0SPXI1U1d SvcoIJ1+OLmVT4y7V7N2vCd13ZwdzjyTH1wXgY5T+2gPfipogjlawvkaYSfmDsjNVDcEd74Mb2eXz 2fBcDyaDM7y3Md5RaCo0poCheh2B3sTy6R9dAQROFkvEJCu6Wn5ZCPugw690varWx7CqKvQEaFaul lPzafEFA==; Received: by fourecks.uuid.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jf5kj-0008Cp-Vv; Sat, 30 May 2020 18:58:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=octiron.net ; s=20180214; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From; bh=XQQ8+zcRJDT/XDN1huHV6gokNYNTsW08knhUgG2sq6I=; b=mpdsT09hWoOABaBSp5gBUEhBmC eJUxlCve3+xep+Lxb5k68j/N74o1HPeRdmoO4HmeFmOf5gB1jIgahZorZ1J5I7JKsvrMEFkqVWCt7 bX/3X49WAV55V32jOtrov+5tIuNjMEhqoo2pgDOQ5nHkVqNS1vUob3ztCiSEypwleQs3Dr191dIWC xgYdppQPysI6dJ2/fnNR34izQaaic0dbvxvr2feNMDzEWQZHV3K+fIPl/cAjLQ8NnPVOLBOVlLQXG 3ispsrdsVWw3yRqUoYg2prVJBZgLd0bfLw9QtwY9uz3hANaEL6sEXJZpQ1WP/FMqxAJPUqaMrDAyr dQWsPh4g==; Received: by tsort.uuid.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jf5kY-0006Ut-6s; Sat, 30 May 2020 18:58:33 +0100 From: Simon Arlott Subject: [PATCH v2 1/2] scsi: sr: Fix sr_probe() missing mutex_destroy To: "Martin K . Petersen" , "James E.J. Bottomley" , Jens Axboe , Bart Van Assche Cc: linux-scsi@vger.kernel.org, Merlijn Wajer , Linux Kernel Mailing List Message-ID: <06e9de38-eeed-1cab-5e08-e889288935b3@0882a8b5-c6c3-11e9-b005-00805fc181fe> Date: Sat, 30 May 2020 18:58:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If the device minor cannot be allocated or the cdrom fails to be registered then the mutex should be destroyed. Signed-off-by: Simon Arlott Fixes: 51a858817dcd ("scsi: sr: get rid of sr global mutex") Cc: stable@vger.kernel.org --- On 30/05/2020 17:41, James Bottomley wrote: > On Sat, 2020-05-30 at 09:24 -0700, Bart Van Assche wrote: >> Please add Fixes: and Cc: stable tags. I've added a Fixes: tag and Cc:'d stable. > This isn't really a bug, is it? mutex_destroy is a nop unless lock > debugging is enabled in which case it checks the lock is unlocked and > marks it as unusable to detect a use after destroy. Since the > structure containing the mutex is kfree'd in the next statement, kasan > would also detect any use after free. That's not to say we shouldn't > do this to be fully correct ... just that it has no potential ever to > have user visible impact so there doesn't seem to be much point > cluttering up the stable process with it. If the current lock debugging implementation in stable will be ok with it then I'd agree there's no reason to put it in stable kernels, except that the commit this fixes was added to stable with this bug and one in sr_block_release (72655c0ebd1d). drivers/scsi/sr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c index d2fe3fa470f9..8d062d4f3ce0 100644 --- a/drivers/scsi/sr.c +++ b/drivers/scsi/sr.c @@ -817,6 +817,7 @@ static int sr_probe(struct device *dev) fail_put: put_disk(disk); + mutex_destroy(&cd->lock); fail_free: kfree(cd); fail: -- 2.17.1 -- Simon Arlott