linux-kernel - Re: [PATCH] usb: gadget: gadgetfs: correct dev state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1406051201040.1103-100000@iolanthe.rowland.org>
Date:	Thu, 5 Jun 2014 12:04:35 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Marcus Nutzinger <marcus.nutzinger@...obroma-systems.com>
cc:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: gadget: gadgetfs: correct dev state

On Thu, 5 Jun 2014, Marcus Nutzinger wrote:

> Hi Sergei,
> 
> On Jun 5, 2014, at 4:18 PM, Sergei Shtylyov <sergei.shtylyov@...entembedded.com> wrote:
> 
> >   Please also specify that commit's summary line in parens.
> 
> I'll resubmit the updated patch in a minute!
> 
> >> +	/* other endpoints were all decoupled from this device */
> >> +	spin_lock_irq(&dev->lock);
> >> +	dev->state = STATE_DEV_DISABLED;
> >> +	spin_unlock_irq(&dev->lock);
> > 
> >   Not sure I understand why you need spinlock here... isn't the assignment atomic already?
> 
> 
> Sure, an assignment might be atomic. However, following the policy of commit 7489d149
> (USB: gadgetfs cleanups) all ep0 state changes shall be protected by spinlocks.

Sometimes an assignment needs to be protected by a lock, even though 
the assignment itself is atomic.  This happens, for example, when some 
other code executes a lock-protected region that expects the variable 
not to change.

I don't know if that's the case here.  But this example shows that in
general, one sometimes needs locks in places where you wouldn't expect
them.

In fact, it may even be necessary to take and release a lock, without
doing anything in between!

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/