From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20540383C93 for ; Fri, 31 Jul 2026 12:24:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785500689; cv=none; b=Uj345IHScBgpR1FnphbfrS78iu16WySVegZ/SXX/S2rOr9vtayBMg9SzOiFQZAzIycLlRFkBwXSvuzOtt4BixNmV3jn1snyMykxDJPMGgXs63GjJ8adiZQZgtcnnS4m1YbGQaMqJd42pl+jdT4x8UyBV0YzsD9cCYcFWyH97iuQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785500689; c=relaxed/simple; bh=z+h5F+UuNJxkW41csbYCLZ9pnqYEW5Qr62BAXVeLv00=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z4apH82L5tJ3+//A1ALgHTkFHbP+uEnmXrvyH4iuCavBfoM8XFCBF75rkHlJwvVyVQGb9QDCYZPu9Ynf/vkmmnCl3VKXt1RPljbs242zgEEgE/xS5SeLkKlnVWvvOrFqKhqo86fvyVAMCJw0Sio+1Y7veRh98ja4OzPKAyBjpD8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PqTt8fUe; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PqTt8fUe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2068A1F000E9; Fri, 31 Jul 2026 12:24:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1785500687; bh=PhXsZro+jPEhYJrUY2wgvJIFl5/X3sNHWBUN9sxSQJI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=PqTt8fUeA2jspjkoMA9ourdA2x+bTZL5tTbz437bwbH2JRNUVAX7Gn+kb4nx6CpaE /D0dmSIN4yKnt/d9VEO6azPAAJPf6Q4Z1UBdfyultPO5BeQb4zvSS9GhUaUru2oIly JOm1OJKHhqmUTl6d9xAsewI/vJYUUE2K6LvDk/qo= Date: Fri, 31 Jul 2026 14:24:33 +0200 From: Greg KH To: Eli Billauer Cc: arnd@arndb.de, linux-kernel@vger.kernel.org, corbet@lwn.net Subject: Re: [PATCH v3 1/7] char: xillybus: Improve control of execution flow with mutexes Message-ID: <2026073126-sandpaper-passcode-f739@gregkh> References: <20260724094302.50761-1-eli.billauer@gmail.com> <20260724094302.50761-2-eli.billauer@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260724094302.50761-2-eli.billauer@gmail.com> On Fri, Jul 24, 2026 at 11:42:56AM +0200, Eli Billauer wrote: > This commit addresses two issues by using mutexes: > > (1) Add a mutex to protect the fifo_buf_order global variable. The > purpose of this variable is avoid repeated failed calls to > __get_free_pages() for allocating FIFO memory, when the chunk > size was too big. However, if two drivers are initialized at the > same time, fifo_init() may run in parallel, and fifo_buf_order > may be reduced too much. This is a far-fetched scenario, now > completely prevented by fifo_buf_order_mutex. > > (2) setup_channels() acquires process_in_mutex to prevent > process_bulk_in() from accessing the xillyusb_dev struct. With > correctly working hardware, process_bulk_in() is never called while > setup_channels() runs, because the device has no reason to send data > in that phase. The mutex ensures that process_bulk_in() does not > touch the members that setup_channels() alters. > > There is no similar protection for data flow in the other direction, > because during the setup process, the only outbound data is the > BULK endpoint used for commands, and it remains untouched after its > initial setup. > > Assisted-by: Deepseek:v4-pro Kimi:K2.6 ChatGPT:GPT-5.5 Claude:Sonnet-4.6 > Signed-off-by: Eli Billauer > --- > > Notes: > Changes v2->v3: > -- Add Assisted-by tag to description > > No change on v1->v2. > > drivers/char/xillybus/xillyusb.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/char/xillybus/xillyusb.c b/drivers/char/xillybus/xillyusb.c > index 34e7ad3bcab3..a28e6416cb01 100644 > --- a/drivers/char/xillybus/xillyusb.c > +++ b/drivers/char/xillybus/xillyusb.c > @@ -50,6 +50,7 @@ MODULE_LICENSE("GPL v2"); > static const char xillyname[] = "xillyusb"; > > static unsigned int fifo_buf_order; > +static DEFINE_MUTEX(fifo_buf_order_mutex); > static struct workqueue_struct *wakeup_wq; > > #define USB_VENDOR_ID_XILINX 0x03fd > @@ -375,6 +376,8 @@ static int fifo_init(struct xillyfifo *fifo, > > unsigned int log2_fifo_buf_size; > > + guard(mutex)(&fifo_buf_order_mutex); Sashiko rightly complains that using guard() combined with goto in this function is ripe for disaster. Are you sure the compiler will work properly for this? thanks, greg k-h