Message-ID: <53d48954-3f7e-fd02-5e8e-2912c16565b3@quicinc.com>
Date:   Fri, 10 Feb 2023 11:52:23 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH] usb: gadget: u_serial: Add null pointer check in
 gserial_resume
Content-Language: en-US
To:     Alan Stern <stern@rowland.harvard.edu>
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>
References: <482f2c32-41d1-f07e-ee3f-3eb9aee76ac7@quicinc.com>
 <Y+QEQBxlr6FZ58DK@rowland.harvard.edu>
 <542ee8a6-598c-ca17-6d75-5eca2b34133a@quicinc.com>
 <Y+SaZrDmaqB0U2QA@kroah.com>
 <f32398bb-62f3-12fd-4b81-7ce7bdf4706a@quicinc.com>
 <e7dde0aa-c1e2-dd6c-94a1-1e9049f0a5fb@quicinc.com>
 <Y+UMkA9iaJTWVQ5u@rowland.harvard.edu>
 <5ad875be-079c-7f91-ede9-68f954cc7f34@quicinc.com>
 <Y+UZQvuh8KR4gE4P@rowland.harvard.edu>
 <71f624df-5302-8276-2a2a-96223d4ba3c7@quicinc.com>
 <Y+VgHdJjrd0ZvY33@rowland.harvard.edu>
From:   Prashanth K <quic_prashk@quicinc.com>
In-Reply-To: <Y+VgHdJjrd0ZvY33@rowland.harvard.edu>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10-02-23 02:35 am, Alan Stern wrote:
> On Thu, Feb 09, 2023 at 11:57:17PM +0530, Prashanth K wrote:
>>
>>
>> On 09-02-23 09:33 pm, Alan Stern wrote:
>>> 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
>> Hi Alan, instead of doing these and causing potential regressions, can we
>> just have the null pointer check which i suggested in the beginning? The
>> major concern was that port might become null after the null pointer check.
> 
> What you are describing is a data race: gserial_disconnect() can write
> to gser->ioport at the same time that gserial_resume() reads from it.
> Unless you're working on a fast path -- which this isn't -- you should
> strive to avoid data races by using proper locking.  That means adding
> the extra spinlock, or finding some other way to make these two accesses
> be mutually exclusive.
> 
> With a little care you can ensure there won't be any regressions.  Just
> do what I said above: Make sure the code never tries to acquire the
> global spinlock while already holding one of the per-port spinlocks.
> 
>> We mark gser->ioport as null pointer in gserial_disconnect, and in
>> gserial_resume we copy the gser->ioport to *port in the beginning.
>>
>> struct gs_port *port = gser->ioport;
>>
>> And hence it wont cause null pointer deref after the check as we don't
>> de-reference anything from gser->ioport afterwards. We only use the local
>> pointer *port afterwards.
> 
> You cannot depend on this to work the way you want.  The compiler will
> optimize your source code, and one of the optimizations might be to
> eliminate the "port" variable entirely and replace it with gser->ioport.
> 
> Alan Stern
Hi Alan, Thanks for the detailed info. I checked and included few cases 
here.

This would cause a deadlock if gserial_disconnect acquires port_lock and 
gserial_resume acquires static_lock.

gserial_disconnect {
	spin_lock(port)
	...
	spin_lock(static)

	gser->ioport = NULL;

	spin_unlock(static)
	...
	spin_unlock(port)
}

gserial_resume {
	struct gs_port *port = gser->ioport;

	spin_lock(static)
	if (!port)
		return
	spin_lock(port)
	spin_unlock(static)

	...
	spin_unlock(port)
}

------------------------------------------------------------------

This would cause additional races when gserial_disconnect releases 
port_lock and some other functions acquire it.

gserial_disconnect {
	spin_lock(port)
	...
	spin_unlock(port)
	spin_lock(static)

	gser->ioport = NULL;

	spin_unlock(static)
	spin_lock(port)
	...
	spin_unlock(port)
}

gserial_resume {
	struct gs_port *port = gser->ioport;

	spin_lock(static)
	if (!port)
		return
	spin_lock(port)
	spin_unlock(static)

	...
	spin_unlock(port)
}

------------------------------------------------------------------

And this seems like a viable option to me, what do you suggest?

gserial_disconnect {
	spin_lock(static)
	spin_lock(port)
	...
	gser->ioport = NULL;
	...	
	spin_lock(port)
	spin_unlock(static)

}

gserial_resume {
	struct gs_port *port = gser->ioport;

	spin_lock(static)
	if (!port)
		return
	spin_lock(port)

	...
	spin_unlock(port)
	spin_unlock(static)
}

Thanks,
Prashanth K