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 03344CA9EA0 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 C933D21897 for ; Fri, 18 Oct 2019 18:55:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571424916; bh=K/12HBOLREs70oPt0BZw/4JhTqL9elo+MXR7+xUsZpc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=D3f+QRdNi3MbgbHhDh8iPmvMjoV8ClTeOq9FrreBh5S2ndXMuTGKY1/MG9iJGX8mI DZvRPqESAfLlYu8gyXOOkvOpP2LR0SmLm+MOVd8vPZb2RY2DmFGgyOvOW30MCT3wn8 U7zXXs+ORy3j0ZEitRZYchJWDqNh7jzbUTKFpLpc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394764AbfJRSzQ (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: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@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