Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <40f16530-304e-3916-e5f2-7556e2e9b7dd@quicinc.com>
Date:   Thu, 5 Jan 2023 08:56:02 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.0
Subject: Re: [PATCH 5/6] bus: mhi: ep: Move chan->lock to the start of
 processing queued ch ring
Content-Language: en-US
To:     Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
        <mhi@lists.linux.dev>
CC:     <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <stable@vger.kernel.org>
References: <20221228161704.255268-1-manivannan.sadhasivam@linaro.org>
 <20221228161704.255268-6-manivannan.sadhasivam@linaro.org>
From:   Jeffrey Hugo <quic_jhugo@quicinc.com>
In-Reply-To: <20221228161704.255268-6-manivannan.sadhasivam@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/28/2022 9:17 AM, Manivannan Sadhasivam wrote:
> There is a good chance that while the channel ring gets processed, the STOP
> or RESET command for the channel might be received from the MHI host. In
> those cases, the entire channel ring processing needs to be protected by
> chan->lock to prevent the race where the corresponding channel ring might
> be reset.
> 
> While at it, let's also add a sanity check to make sure that the ring is
> started before processing it. Because, if the STOP/RESET command gets
> processed while mhi_ep_ch_ring_worker() waited for chan->lock, the ring
> would've been reset.
> 
> Cc: <stable@vger.kernel.org> # 5.19
> Fixes: 03c0bb8ec983 ("bus: mhi: ep: Add support for processing channel rings")
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---

Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>