Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A086C636D7 for ; Thu, 9 Feb 2023 16:03:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231574AbjBIQDT (ORCPT ); Thu, 9 Feb 2023 11:03:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231472AbjBIQDQ (ORCPT ); Thu, 9 Feb 2023 11:03:16 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id E0AE765640 for ; Thu, 9 Feb 2023 08:03:14 -0800 (PST) Received: (qmail 778313 invoked by uid 1000); 9 Feb 2023 11:03:14 -0500 Date: Thu, 9 Feb 2023 11:03:14 -0500 From: Alan Stern To: Prashanth K Cc: Greg Kroah-Hartman , Christophe JAILLET , Xiu Jianfeng , Pratham Pratap , Jack Pham , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: gadget: u_serial: Add null pointer check in gserial_resume Message-ID: References: <1675864487-18620-1-git-send-email-quic_prashk@quicinc.com> <482f2c32-41d1-f07e-ee3f-3eb9aee76ac7@quicinc.com> <542ee8a6-598c-ca17-6d75-5eca2b34133a@quicinc.com> <5ad875be-079c-7f91-ede9-68f954cc7f34@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ad875be-079c-7f91-ede9-68f954cc7f34@quicinc.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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