From: James Bottomley <jejb@linux.ibm.com>
To: Bart Van Assche <bvanassche@acm.org>,
Simon Arlott <simon@octiron.net>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Jens Axboe <axboe@kernel.dk>
Cc: linux-scsi@vger.kernel.org, Merlijn Wajer <merlijn@archive.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] scsi: sr: Fix sr_probe() missing mutex_destroy
Date: Sat, 30 May 2020 09:41:11 -0700 [thread overview]
Message-ID: <1590856871.8207.6.camel@linux.ibm.com> (raw)
In-Reply-To: <48ed3e8c-6aed-c7bc-6330-18f2f64f8803@acm.org>
On Sat, 2020-05-30 at 09:24 -0700, Bart Van Assche wrote:
> On 2020-05-30 02:32, Simon Arlott wrote:
> > If the device minor cannot be allocated or the cdrom fails to be
> > registered then the mutex should be destroyed.
>
> Please add Fixes: and Cc: stable tags.
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.
James
next prev parent reply other threads:[~2020-05-30 16:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-30 9:32 [PATCH 1/2] scsi: sr: Fix sr_probe() missing mutex_destroy Simon Arlott
2020-05-30 9:33 ` [PATCH 2/2] scsi: sr: Fix sr_probe() missing deallocate of device minor Simon Arlott
2020-05-30 16:24 ` Bart Van Assche
2020-05-30 16:24 ` [PATCH 1/2] scsi: sr: Fix sr_probe() missing mutex_destroy Bart Van Assche
2020-05-30 16:41 ` James Bottomley [this message]
2020-05-30 18:14 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1590856871.8207.6.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=merlijn@archive.org \
--cc=simon@octiron.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox