Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756704AbcCDHVQ (ORCPT ); Fri, 4 Mar 2016 02:21:16 -0500 Received: from mga02.intel.com ([134.134.136.20]:39257 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751080AbcCDHVO (ORCPT ); Fri, 4 Mar 2016 02:21:14 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,535,1449561600"; d="asc'?scan'208";a="663658879" From: Felipe Balbi To: "Felipe F. Tonello" , linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Michal Nazarewicz , Clemens Ladisch Subject: Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function In-Reply-To: <1456947640-20673-3-git-send-email-eu@felipetonello.com> References: <1456947640-20673-1-git-send-email-eu@felipetonello.com> <1456947640-20673-3-git-send-email-eu@felipetonello.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-pc-linux-gnu) Date: Fri, 04 Mar 2016 09:20:10 +0200 Message-ID: <87twkm676d.fsf@ti.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2225 Lines: 61 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 becaus= e 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 ca= se it > is used a spinlock since f_midi_transmit is also called by usb_request->c= omplete > callback in interrupt context. > > On benchmarks realized by me, spinlocks were more efficient then scheduli= ng > 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 ? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW2TcrAAoJEIaOsuA1yqREsAUQAJ0300Y4E7M90KzOf0H/GUaw dxMG7/Po1MnLnjk941TOeXCzLZRU/h8y0pABywkR1dVlrD8qHhBCd5U1taELk1bP g7ScRTrzQprP/dR8y7QP6qaVgXa7ytte29oyJI9h/RSOIK5AAH6XBvfi6WO9mKW+ /4rJdgFzbCLvHnQsH77kmvOt/ohvvEZRXmJ6EMnymE1Eb3m1V11ez66x9+V5vocE Av2aq1xrrbXfmXy2y/ZKG7HI4MA8YAM+2Rdomvt4uiTgTtxU3leSRJKJmtUEeeRg ihC4yslgZrzc+Ohd7GOEp7bfmZIS0z6uHAwCf2Ivs45LUTmson6suQUqg420oXGH 12fNaFTVHiRd2mIn0GBbeZKP+7wlA5vsl4gIW1OAPt7ar5uOow/t9sfCP9XRyT+c wlRzABeap0ITdwoKzywID7mez/CJYNy9w4KpkaPifyZEtv75LsTdxF29Tk/+gJc3 WYV/j/7Rk442LnY976KJcp8QPzDQ/UKG2gepaO/k/rMRK0fDC7T9tQxerDv/B8mc xCdZghMzzi0V9bDPVxfvPBOkIMPmCVnAjlP+z2EllQsDTowSuUsbY/ZqvbVj/bIB JiskRvDUYX0F1desvdUx5x1Gsxn8yB11Wy5BFnGtDfUw0AcPXzmb7ncjnQOKxvsX enP3XXunlG2PgWciHMl9 =bLQK -----END PGP SIGNATURE----- --=-=-=--