From: Alan Stern <stern@rowland.harvard.edu>
To: Prashanth K <quic_prashk@quicinc.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Xiu Jianfeng <xiujianfeng@huawei.com>,
Pratham Pratap <quic_ppratap@quicinc.com>,
Jack Pham <quic_jackp@quicinc.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: u_serial: Add null pointer check in gserial_resume
Date: Thu, 9 Feb 2023 11:03:14 -0500 [thread overview]
Message-ID: <Y+UZQvuh8KR4gE4P@rowland.harvard.edu> (raw)
In-Reply-To: <5ad875be-079c-7f91-ede9-68f954cc7f34@quicinc.com>
On Thu, Feb 09, 2023 at 09:13:37PM +0530, Prashanth K wrote:
>
>
> On 09-02-23 08:39 pm, Alan Stern wrote:
> > You should consider having _two_ spinlocks: One in the gs_port structure
> > (the way it is now) and a separate global lock. The first would be used
> > in situations where you know you have a valid pointer. The second would
> > be used in situations where you don't know if the pointer is non-NULL
> > or where you are changing the pointer's value.
> Lets say we replaced the existing spinlock in gserial_resume and
> gserial_disconnect with a new static spinlock, and kept the spinlocks in
> other functions unchanged. In that case, wouldn't it cause additional race
> conditions as we are using 2 different locks.
Not race conditions, but possibilities for deadlock.
Indeed, you would have to be very careful about avoiding deadlock
scenarios. In particular, you would have to ensure that the code never
tries to acquire the global spinlock while already holding one of the
per-port spinlocks.
Alan Stern
next prev parent reply other threads:[~2023-02-09 16:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 13:54 [PATCH] usb: gadget: u_serial: Add null pointer check in gserial_resume Prashanth K
2023-02-08 14:54 ` Greg Kroah-Hartman
2023-02-08 15:45 ` Prashanth K
2023-02-08 20:21 ` Alan Stern
2023-02-09 5:01 ` Prashanth K
2023-02-09 7:01 ` Greg Kroah-Hartman
2023-02-09 7:03 ` Prashanth K
2023-02-09 14:07 ` Prashanth K
2023-02-09 15:09 ` Alan Stern
2023-02-09 15:43 ` Prashanth K
2023-02-09 16:03 ` Alan Stern [this message]
2023-02-09 18:27 ` Prashanth K
2023-02-09 21:05 ` Alan Stern
2023-02-10 6:22 ` Prashanth K
2023-02-10 6:56 ` Prashanth K
2023-02-10 15:47 ` Alan Stern
2023-02-11 6:25 ` Prashanth K
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=Y+UZQvuh8KR4gE4P@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=christophe.jaillet@wanadoo.fr \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=quic_jackp@quicinc.com \
--cc=quic_ppratap@quicinc.com \
--cc=quic_prashk@quicinc.com \
--cc=xiujianfeng@huawei.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