From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF8E2CA9EAB for ; Fri, 18 Oct 2019 18:55:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7DB921897 for ; Fri, 18 Oct 2019 18:55:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571424917; bh=K/12HBOLREs70oPt0BZw/4JhTqL9elo+MXR7+xUsZpc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=mEbtJCuWoeGdVWTH4iMP44Ga5ycBqEzqpTgcPNzRnlnSYQYbNI7lP34mzTMmWXMl0 Aw3y3Rd7vLs+5fcvBcFYyntSIpgASdSUoobCmdbRQNtr1SbSpuP40g7dJx/t76txyw 1RGie8m5vmAEQ1Gbi4kqWXB8oBawFphuv4zOLL64= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2443110AbfJRSzQ (ORCPT ); Fri, 18 Oct 2019 14:55:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:55574 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726421AbfJRSzQ (ORCPT ); Fri, 18 Oct 2019 14:55:16 -0400 Received: from localhost (unknown [38.98.37.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6F60220640; Fri, 18 Oct 2019 18:55:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571424915; bh=K/12HBOLREs70oPt0BZw/4JhTqL9elo+MXR7+xUsZpc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lSZOPZ5s+y6I0QKlrMUyTBW6wCcQf+ClsnwoUbqkZ0ShgPjqSHXIqLI1ZUmD9voHo yVeGB/LPOjtZuCbmteO7cUk+fNre3cNoksos3d9qDvait1oTrFbG1ewzJq71c+lmx1 STz8i25nWbFnfehNscC5vHfMSPlSsNncz7Sd001g= Date: Fri, 18 Oct 2019 11:54:58 -0700 From: Greg Kroah-Hartman To: Johan Hovold Cc: Alan Stern , Oliver Neukum , "Paul E . McKenney" , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, stable Subject: Re: [PATCH RFC v2 2/2] USB: ldusb: fix ring-buffer locking Message-ID: <20191018185458.GA1191145@kroah.com> References: <20191018151955.25135-1-johan@kernel.org> <20191018151955.25135-3-johan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191018151955.25135-3-johan@kernel.org> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 18, 2019 at 05:19:55PM +0200, Johan Hovold wrote: > The custom ring-buffer implementation was merged without any locking > whatsoever, but a spinlock was later added by commit 9d33efd9a791 > ("USB: ldusb bugfix"). > > The lock did not cover the loads from the ring-buffer entry after > determining the buffer was non-empty, nor the update of the tail index > once the entry had been processed. The former could lead to stale data > being returned, while the latter could lead to memory corruption on > sufficiently weakly ordered architectures. Ugh. This almost looks sane, but what's the odds there is some other issue in here as well? Would it make sense to just convert the code to use the "standard" ring buffer code instead? thanks, greg k-h