Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753800AbcL0LJP (ORCPT ); Tue, 27 Dec 2016 06:09:15 -0500 Received: from mga02.intel.com ([134.134.136.20]:52182 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751667AbcL0LJH (ORCPT ); Tue, 27 Dec 2016 06:09:07 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,416,1477983600"; d="asc'?scan'208";a="43614199" From: Felipe Balbi To: Janusz Dziedzic , Baolin Wang Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org, broonie@kernel.org Subject: Re: [PATCH] usb: dwc3: gadget: Avoid race between dwc3 interrupt handler and irq thread handler In-Reply-To: References: <0d79eb1f34e409749a136173b68f365b545c4789.1482738764.git.baolin.wang@linaro.org> Date: Tue, 27 Dec 2016 13:07:25 +0200 Message-ID: <871swt3a1e.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2260 Lines: 62 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Janusz Dziedzic writes: > 2016-12-26 9:01 GMT+01:00 Baolin Wang : >> On some platfroms(like x86 platform), when one core is running the USB g= adget >> irq thread handler by dwc3_thread_interrupt(), meanwhile another core al= so can >> respond other interrupts from dwc3 controller and modify the event buffe= r by >> dwc3_interrupt() function, that will cause getting the wrong event count= in >> irq thread handler to make the USB function abnormal. >> >> We should add spin_lock/unlock() in dwc3_check_event_buf() to avoid this= race. >> > Interesting, I always think we mask interrupt in dwc3_interrupt() by sett= ing > DWC3_GEVNTSIZ_INTMASK > And unmask interrupt when we end dwc3_thread_interrupt(). > > So, we shouldn't get any IRQ from HW during dwc3_thread_interrupt(), > or I miss something? > Do you have some traces that indicate this masking will not work correctl= y? that's the very question I have. We are already masking interrupts from this controller. The only thing this could race with is usb_ep_queue(), but that gets nowhere close to anything we're doing in the top half handler, so there's really no danger of anything bad happening. I'd like to see traces as well. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlhiS20ACgkQzL64meEa mQawaQ//RvI/HlXtygh6Yc8zNO2g6CUGTR2ykdF1MoaUsueJrtd9pq9q+V0jf+D4 1e1qkUiOxJ3iWPvuwUx8aLjXDtHS15hC13kQdr0kL6uicNAsESrysSPuu8tEj5HX 3cn8/dfiQQS9tlFcP0sUR0tUJkdQf8J6+2K6BKMn0Kx5IbpU7qZcMNgUBhuKWWMG mZO2A55HweAyYsP5Baq3xixVmZJ8pfQtJCiE/qgDyA0p51dpNX7narYFgo0Of9Oi qu+HSWu447cGhYtUkT0Wign6mlNyQL1PEWNoim2lRO5jFUA6ybkQXw3eCjtJXK1A wJfGP3fawkxJXco2zK+wcalJ/26GRGHnTHY/Mj8UGUBaomnWIzoKt4MF2nbKRa6D zGqlZw8FM6mFAkN+qnciJEzESPlge6mCK/RRtQmp2rg2viQiW0Wh0h5rGQWo6sj4 9L0X7e02At9HObcSP+bg6mmreFG9W8ucDKrVbzuLxHcer6uz8ahSn4IxN+/pEP3o AHWH9b+sm/1jedrVm1loklnXOeZDAHJ3waRXQTGzoQxmX6m8CJjxw0NPHqHu/Wt2 b+zcbGq2HSc9a7wHOE/gUiVJEFuQi8oqBQcXjUu6iNFA0FRnDPnLB4jryLc1+9iU N3JMSbyH7Ypfdd5pMBCi7jeXu/p8jl9Rq/Oq0tXfJxErIOzPNIg= =FEz8 -----END PGP SIGNATURE----- --=-=-=--