Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759543AbcCDStn (ORCPT ); Fri, 4 Mar 2016 13:49:43 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:37356 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755989AbcCDStm (ORCPT ); Fri, 4 Mar 2016 13:49:42 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <87twkm676d.fsf@ti.com> References: <1456947640-20673-1-git-send-email-eu@felipetonello.com> <1456947640-20673-3-git-send-email-eu@felipetonello.com> <87twkm676d.fsf@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function From: Felipe Ferreri Tonello Date: Fri, 04 Mar 2016 18:49:36 +0000 To: Felipe Balbi , linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org, Michal Nazarewicz , Clemens Ladisch Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1662 Lines: 47 Hi Balbi, On March 4, 2016 7:20:10 AM GMT+00:00, Felipe Balbi wrote: > >Hi, > >"Felipe F. Tonello" writes: >> [ text/plain ] >> Since f_midi_transmit is called by both ALSA and USB frameworks, it >can >> potentially cause a race condition between both calls. This is bad >because the >> way f_midi_transmit is implemented can't handle concurrent calls. >This is due >> to the fact that the usb request fifo looks for the next element and >only if >> it has data to process it enqueues the request, otherwise re-uses it. >If both >> (ALSA and USB) frameworks calls this function at the same time, the >> kfifo_seek() will return the same usb_request, which will cause a >race >> condition. >> >> To solve this problem a syncronization mechanism is necessary. In >this case it >> is used a spinlock since f_midi_transmit is also called by >usb_request->complete >> callback in interrupt context. >> >> On benchmarks realized by me, spinlocks were more efficient then >scheduling >> the f_midi_transmit tasklet in process context and using a mutex to >> synchronize. Also it performs better then previous implementation >that >> allocated a usb_request for every new transmit made. > >behaves better in what way ? Also, previous implementation would not >suffer from this concurrency problem, right ? The spin lock is faster than allocating usb requests all the time, even if the udc uses da for it. That's true it wasn't necessary to put a spin lock in the gadget driver because the udc driver does it when allocating a new request. Felipe -- Sent from my Android device with K-9 Mail. Please excuse my brevity.