From: "Liang He" <windhl@126.com>
To: "Justin Tee" <justintee8345@gmail.com>
Cc: james.smart@broadcom.com, dick.kennedy@broadcom.com,
jejb@linux.ibm.com, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org
Subject: Re:Re: [PATCH] scsi: lpfc: Fix potential memory leak
Date: Tue, 28 Mar 2023 11:47:52 +0800 (CST) [thread overview]
Message-ID: <16832d4f.3373.18726545077.Coremail.windhl@126.com> (raw)
In-Reply-To: <CABPRKS9dqusoWNWSOE0B87VrrFR5JR9otydPVQRMRddXQCt-6A@mail.gmail.com>
At 2023-03-28 02:39:38, "Justin Tee" <justintee8345@gmail.com> wrote:
>Hi Liang,
>
>@@ -1200,6 +1200,11 @@ lpfc_bsg_hba_set_event(struct bsg_job *job)
> spin_unlock_irqrestore(&phba->ct_ev_lock, flags);
>
> if (&evt->node == &phba->ct_ev_waiters) {
>+
>+ spin_lock_irqsave(&phba->ct_ev_lock, flags);
>+ lpfc_bsg_event_unref(evt);
>+ spin_unlock_irqrestore(&phba->ct_ev_lock, flags);
>+
> /* no event waiting struct yet - first call */
> dd_data = kmalloc(sizeof(struct bsg_job_data), GFP_KERNEL);
> if (dd_data == NULL) {
>
>if (&evt->node == &phba->ct_ev_waiters) was true, then that means the
>ct_ev_waiters list was empty so the *evt ptr is not pointing to a real
>lpfc_bsg_event structure. I think we would even crash trying to
>decrement evt’s kref because evt is an uninitialized lpfc_bsg_event
>structure and not pointing to anything real. We’re about to kzalloc a
>new evt with lpfc_bsg_event_new in this same if statement clause
>anyways. I’m not clear on the reasoning behind the suggestion to call
>lpfc_bsg_event_unref(evt) there.
>
>
>@@ -1292,6 +1297,9 @@ lpfc_bsg_hba_get_event(struct bsg_job *job)
> * an error indicating that there isn't anymore
> */
> if (evt_dat == NULL) {
>+ spin_lock_irqsave(&phba->ct_ev_lock, flags);
>+ lpfc_bsg_event_unref(evt);
>+ spin_unlock_irqrestore(&phba->ct_ev_lock, flags);
> bsg_reply->reply_payload_rcv_len = 0;
> rc = -ENOENT;
> goto job_error;
>
>Similar argument here. If (evt_dat == NULL) was true, then that means
>there was nothing of interest in the ct_ev_waiters list or that the
>ct_ev_waiters list was empty. In either case, we shouldn’t call
>lpfc_bsg_event_unref(evt) because we would be decrementing the wrong
>reg_id evt’s kref or even crash if the ct_ev_waiters list was empty
>trying to kref_put an uninitialized lpfc_bsg_event structure.
>
>Regards,
>Justin
Hi, Justin,
Thanks for your kindly explaination.
My patch is indeed wrong, as I have not realized the semantic of "&evt->node == &phba->ct_ev_waiters".
Thanks and sorry for my trouble.
Liang
>
>On Thu, Mar 16, 2023 at 7:02 PM Liang He <windhl@126.com> wrote:
>>
>> In lpfc_bsg_hba_get_event() and lpfc_bsg_hba_set_event(), we
>> should keep the refcount balance when there is some error or
>> the *evt* will be replaced.
>>
>> Fixes: f1c3b0fcbb81 ("[SCSI] lpfc 8.3.4: Add bsg (SGIOv4) support for ELS/CT support")
>> Signed-off-by: Liang He <windhl@126.com>
>> ---
>> drivers/scsi/lpfc/lpfc_bsg.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c
>> index 852b025e2fec..aa535bc14758 100644
>> --- a/drivers/scsi/lpfc/lpfc_bsg.c
>> +++ b/drivers/scsi/lpfc/lpfc_bsg.c
>> @@ -1200,6 +1200,11 @@ lpfc_bsg_hba_set_event(struct bsg_job *job)
>> spin_unlock_irqrestore(&phba->ct_ev_lock, flags);
>>
>> if (&evt->node == &phba->ct_ev_waiters) {
>> +
>> + spin_lock_irqsave(&phba->ct_ev_lock, flags);
>> + lpfc_bsg_event_unref(evt);
>> + spin_unlock_irqrestore(&phba->ct_ev_lock, flags);
>> +
>> /* no event waiting struct yet - first call */
>> dd_data = kmalloc(sizeof(struct bsg_job_data), GFP_KERNEL);
>> if (dd_data == NULL) {
>> @@ -1292,6 +1297,9 @@ lpfc_bsg_hba_get_event(struct bsg_job *job)
>> * an error indicating that there isn't anymore
>> */
>> if (evt_dat == NULL) {
>> + spin_lock_irqsave(&phba->ct_ev_lock, flags);
>> + lpfc_bsg_event_unref(evt);
>> + spin_unlock_irqrestore(&phba->ct_ev_lock, flags);
>> bsg_reply->reply_payload_rcv_len = 0;
>> rc = -ENOENT;
>> goto job_error;
>> --
>> 2.25.1
>>
prev parent reply other threads:[~2023-03-28 4:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 1:56 [PATCH] scsi: lpfc: Fix potential memory leak Liang He
2023-03-27 18:39 ` Justin Tee
2023-03-28 3:47 ` Liang He [this message]
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=16832d4f.3373.18726545077.Coremail.windhl@126.com \
--to=windhl@126.com \
--cc=dick.kennedy@broadcom.com \
--cc=james.smart@broadcom.com \
--cc=jejb@linux.ibm.com \
--cc=justintee8345@gmail.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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