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]
Date:   Tue, 22 Nov 2022 02:41:14 -0500
From:   William Breathitt Gray <william.gray@...aro.org>
To:     Fabrice Gasnier <fabrice.gasnier@...s.st.com>
Cc:     jic23@...nel.org, alexandre.torgue@...s.st.com,
        olivier.moysan@...s.st.com, linux-iio@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] counter: stm32-lptimer-cnt: fix the check on arr and cmp
 registers update

On Wed, Nov 23, 2022 at 03:56:31PM +0100, Fabrice Gasnier wrote:
> On 11/22/22 08:33, William Breathitt Gray wrote:
> > On Tue, Nov 22, 2022 at 02:27:50AM -0500, William Breathitt Gray wrote:
> >> On Wed, Nov 23, 2022 at 02:36:09PM +0100, Fabrice Gasnier wrote:
> >>> The ARR (auto reload register) and CMP (compare) registers are
> >>> successively written. The status bits to check the update of these
> >>> registers are polled together with regmap_read_poll_timeout().
> >>> The condition to end the loop may become true, even if one of the register
> >>> isn't correctly updated.
> >>> So ensure both status bits are set before clearing them.
> >>>
> >>> Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer")
> >>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@...s.st.com>
> >>> ---
> >>>  drivers/counter/stm32-lptimer-cnt.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/counter/stm32-lptimer-cnt.c b/drivers/counter/stm32-lptimer-cnt.c
> >>> index d6b80b6dfc28..8439755559b2 100644
> >>> --- a/drivers/counter/stm32-lptimer-cnt.c
> >>> +++ b/drivers/counter/stm32-lptimer-cnt.c
> >>> @@ -69,7 +69,7 @@ static int stm32_lptim_set_enable_state(struct stm32_lptim_cnt *priv,
> >>>  
> >>>  	/* ensure CMP & ARR registers are properly written */
> >>>  	ret = regmap_read_poll_timeout(priv->regmap, STM32_LPTIM_ISR, val,
> >>> -				       (val & STM32_LPTIM_CMPOK_ARROK),
> >>> +				       (val & STM32_LPTIM_CMPOK_ARROK) == STM32_LPTIM_CMPOK_ARROK,
> >>
> >> This is a reasonable fix, but I don't like seeing so much happening in
> >> an argument list -- it's easy to misunderstand what's going on which can
> >> lead to further bugs the future. Pull out this condition to a dedicated
> >> bool variable with a comment explaining why we need the equivalence
> >> check (i.e. to ensure both status bits are set and not just one).
> >>
> >> William Breathitt Gray
> > 
> > Alternatively, you could pull out just (val & STM32_LPTIM_CMPOK_ARROK)
> > to a separate variable and keep the equivalence condition inline if you
> > think it'll be clearer that way.
> 
> Hi William,
> 
> I'm not sure to fully understand your proposal here.
> Could you clarify ?
> 
> regmap_read_poll_timeout() macro requires:
> 
>  * @val: Unsigned integer variable to read the value into
>  * @cond: Break condition (usually involving @val)
> 
> So do you wish I introduce a macro that abstracts the condition check ?
> (val & STM32_LPTIM_CMPOK_ARROK) == STM32_LPTIM_CMPOK_ARROK
> 
> 
> Best regards,
> Fabrice

My apologies Fabrice, I realize now that regmap_read_poll_timeout() is a
macro. Abstracting out the conditional would probably be more confusing
than having it inline, so the way it is right now is probably fine after
all.

William Breathitt Gray

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ