From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FBA63043BE for ; Fri, 6 Feb 2026 07:20:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770362456; cv=none; b=QzU5WNfzxwL0H+598Ddx5UVIsycOAlVoJQFzYn2G7v1OySwWCdpUkmkc9i7x1YghqBA/9aBdcZ7W7YiXklXR86lzhi41602e+ecSmEF5zMygu1z+tOoLFbnPm2Bu2AbmMUnzMCEr1fBqdO8GHroYyr5hS1tM2ZMvF+Vh/PlZUvk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770362456; c=relaxed/simple; bh=Jrm4Ma/v+IaVgMg41NUATuqbPrO/dRmuxqslx6LV7p0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lj7LMa8J3CaOwmMzUXj4cIZqOslbyOgbft7jQ8j/mkALV/hile0W4ojIhsK8I/Phz7wvYruJ6Xr92oWaePHR+u+fGRHOw3W1SErjerAB2HbHlxSoUQBBsGFVqm006Hx5cSD1lh0Ox17UOJ6cpPTYWmsuhVKfG6LQUXkuUdX8994= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=NfWE3B9c; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="NfWE3B9c" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4806b43beb6so3544745e9.3 for ; Thu, 05 Feb 2026 23:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1770362455; x=1770967255; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=rDqn64e4F5pKd1HvFqedoy+PkTst5qOy46EJEd/J7Ks=; b=NfWE3B9cgx6Fg5Iw9WAKxa3Fx2R0h6ZJFMEP2BGEeFXdzxomnj+OB1Y29waWYjeaz1 KqPrxVLu1bkzi6Ql2GOrWSknnmD2u3n6/6y5oEi10K3l9mfxn99usxOGMnyM0XwR5QYz M8JCRGfHT5CGVPfTgXQR6KvlSL6fsLaM/oVdBFlS0MMKV504QxTnbqjU8pMdpfVQNF0y AxWuhR0vbAc6wrOQiCj1P4aLoaCvBZ6RXaQILsCJPcdwxFQIFP5DsFg5j4MFOJ99wM9P UaJa5XZn+ao69zn9PVw/zK3PivpvmJ8HYTR/KCAPsOlHuch2YVmCv13EgfXtIbt6Hxv/ wKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770362455; x=1770967255; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rDqn64e4F5pKd1HvFqedoy+PkTst5qOy46EJEd/J7Ks=; b=vjNcJsrz3av39Kaf6s5d0Dq2ytk5+BBibaaLSv5avOIOTM1NzWBNyc3lmg+wyDKSD/ o3KydS7Ye4NQuI0MisLv5jf16d/HAReAJbE5WXIXQTzFtuUzKBGnAUWWJdDk0fIy09fL Z1I3yu4JWyKswcrjjy/23418KCJanr1VKFcG4TVTp2YTL52GlcQGJtyKk1RWVH6ZeK7S 32rDKdx0j8tKdlGhF0R9UQHx8hVXV+vdOe9tPyKkA2VgFznCBcvqQIG04LrbBqfBYluC RmZ0mpMgFeDIuzJU4eesrZ7Ie4huapWOp7n/PRs2e9OuQ8qK/G8etXp21tKK64I1Tluv gj6g== X-Forwarded-Encrypted: i=1; AJvYcCWVPne+IBlALLOdIXv/YSBcHj/w68cjgkT0YXsApIzH/LBCzlg1SwJ9IxrDyjeqCIKTHAsCAd5L1eHsGmA=@vger.kernel.org X-Gm-Message-State: AOJu0YyEC6RbBIgJXSDGHgtx0Qrpb0fi7z2t9q7bcEQfZZ93w5Ho6+3I PbkT8vLPA+kKvO1E3L5aPm0I/L2sF0zhvwzD3uBGHkViAQJcRgytdHG5GD5WIzKcugw= X-Gm-Gg: AZuq6aLHoFbIP6l2J7CvVSwP0NAs5f6nGJdqOmMihd5PiLIYfJLDzROA81AEWQnbHIb BN+5xjvcgZ3sKCHp6+K+1kF151aizZ9ifvNsBpVu6aV+KuucWiHcZvU2xI0yqUOfuxZRgLkrcD1 QRnCEgpEVlERaqLGQmgVtYvPOyTZszMP4UjZ+s8I7iSrCJlSvUSyFYoVpmHthLAXmEuK25EKaFx UtjtQ9bqeIs5HBm1+TUnu+Kh2TNmMPb9MjJeVdT2nsz5wpJisR6mNiQr5iblBY/I0qCRPdRaeFL vNBnMUkQDnZt0gSVIIssrgvx2VAwTylCSPm+uu0rSEpuQ0Fq259WJkThqrootKQmbDowRIkpssc LwNKRTW0ncBb3dI2sOD5HS0C3Igj0hrH+02n7EWNJi0b/A5/fUVfgd23E/pxnBE4BDYHfKSwvSb aveJ/oQ1fHYVbcj6Rb X-Received: by 2002:a05:600c:46d5:b0:480:1a3a:5ce6 with SMTP id 5b1f17b1804b1-483201e4bcamr22234895e9.14.1770362454701; Thu, 05 Feb 2026 23:20:54 -0800 (PST) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48320719b8fsm33987255e9.9.2026.02.05.23.20.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 23:20:54 -0800 (PST) Date: Fri, 6 Feb 2026 10:20:51 +0300 From: Dan Carpenter To: Minu Jin Cc: parthiban.veerasooran@microchip.com, christian.gromm@microchip.com, gregkh@linuxfoundation.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging: most: dim2: fix a race condition in complete_all_mbos() Message-ID: References: <20260205160231.1543828-1-s9430939@naver.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: <20260205160231.1543828-1-s9430939@naver.com> On Fri, Feb 06, 2026 at 01:02:31AM +0900, Minu Jin wrote: > The current implementation of complete_all_mbos() repeatedly acquires > and releases the spinlock in loop. This causes lock contention. > > This patch refactors the function to use list_replace_init(), moving all > entries to a local list. This removes the loop-based locking approach > and significantly reduces lock contention. > > Signed-off-by: Minu Jin The subject talks about race conditions but the commit message talks about reducing lock contention. It does obviously reduce lock contention (althought I don't think anyone has benchmarked it to see if it matters) but does it prevent a race condition? Let's review: This complete_all_mbos() function is called when we do a most_stop_channel() and we ->poison_channel(). The list heads are &hdm_ch->started_list and &hdm_ch->pending_list. I feel like if we add something to the list while we are also freeing items from the list then we are toasted. In service_done_flag(), we delete items from the list but deleting items is fine in this context. We add things to the ->pending_list in enqueue() and service_done_flag(). We move things from the ->pending_list to the ->started_list in try_start_dim_transfer(). So if any of those three functions can be run at the same time as complete_all_mbos() we are in trouble. The hdm_enqueue_thread() function calls enqueue() until kthread_should_stop(). The most_stop_channel() function calls kthread_stop(c->hdm_enqueue_task) before doing the ->poison_channel() so that's fine. The service_done_flag() and try_start_dim_transfer() functions are called from dim2_task_irq(). When do we stop taking interrupts? To be honest, I don't know. I thought we had to call disable_irq()? So that's the question, when do we disable IRQs in this driver? I would have assumed it was in most_stop_channel() but I can't see it, but I'm also not very familiar with this code. Let's answer this question and then either add a Fixes tag or say that there doesn't appear to be a race condition. regards, dan carpenter