lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210224100742.GT27945@work>
Date:   Wed, 24 Feb 2021 15:37:42 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Bhaumik Bhatt <bbhatt@...eaurora.org>
Cc:     linux-arm-msm@...r.kernel.org, hemantk@...eaurora.org,
        jhugo@...eaurora.org, linux-kernel@...r.kernel.org,
        loic.poulain@...aro.org
Subject: Re: [PATCH v6 5/8] bus: mhi: core: Check channel execution
 environment before issuing reset

On Thu, Feb 04, 2021 at 12:28:03PM -0800, Bhaumik Bhatt wrote:
> A client can attempt to unprepare certain channels for transfer even
> after the execution environment they are supposed to run in has changed.
> In the event that happens, the device need not be notified of the reset
> and the host can proceed with clean up for the channel context and
> memory allocated for it on the host as the device will no longer be able
> to respond to such a request.
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@...eaurora.org>
> Reviewed-by: Hemant Kumar <hemantk@...eaurora.org>

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>

Thanks,
Mani

> ---
>  drivers/bus/mhi/core/main.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 2f6fdb2..f511e3a 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1283,6 +1283,12 @@ static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
>  
>  	mutex_lock(&mhi_chan->mutex);
>  
> +	if (!(BIT(mhi_cntrl->ee) & mhi_chan->ee_mask)) {
> +		dev_dbg(dev, "Current EE: %s Required EE Mask: 0x%x\n",
> +			TO_MHI_EXEC_STR(mhi_cntrl->ee), mhi_chan->ee_mask);
> +		goto exit_unprepare_channel;
> +	}
> +
>  	/* no more processing events for this channel */
>  	ret = mhi_update_channel_state(mhi_cntrl, mhi_chan,
>  				       MHI_CH_STATE_TYPE_RESET);
> @@ -1290,6 +1296,11 @@ static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
>  		dev_err(dev, "%d: Failed to reset channel, still resetting\n",
>  			mhi_chan->chan);
>  
> +exit_unprepare_channel:
> +	write_lock_irq(&mhi_chan->lock);
> +	mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
> +	write_unlock_irq(&mhi_chan->lock);
> +
>  	if (!mhi_chan->offload_ch) {
>  		mhi_reset_chan(mhi_cntrl, mhi_chan);
>  		mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ