Hi!

quoted

quoted

quoted

quoted

commit 47705c08465931923e2f2b506986ca0bdf80380d upstream.

When clearing up the channel context after client drivers are
done using channels, the configuration is currently not being
reset entirely. Ensure this is done to appropriately handle
issues where clients unaware of the context state end up calling
functions which expect a context.

quoted

+++ b/drivers/bus/mhi/core/init.c

@@ -544,6 +544,7 @@ void mhi_deinit_chan_ctxt(struct mhi_con
+	u32 tmp;

@@ -554,7 +555,19 @@ void mhi_deinit_chan_ctxt(struct mhi_con

...

quoted

+	tmp = chan_ctxt->chcfg;
+	tmp &= ~CHAN_CTX_CHSTATE_MASK;
+	tmp |= (MHI_CH_STATE_DISABLED << CHAN_CTX_CHSTATE_SHIFT);
+	chan_ctxt->chcfg = tmp;
+
+	/* Update to all cores */
+	smp_wmb();
 }

This is really interesting code; author was careful to make sure chcfg
is updated atomically, but C compiler is free to undo that. Plus, this
will make all kinds of checkers angry.

Does the file need to use READ_ONCE and WRITE_ONCE?

Thanks for looking into this.

I agree that the order could be mangled between chcfg read & write and
using READ_ONCE & WRITE_ONCE seems to be a good option.

Bhaumik, can you please submit a patch and tag stable?

quoted

Hemant and I went over this patch and we noticed this particular function is
already being called with the channel mutex lock held. This would take care
of
the atomicity and we also probably don't need the smp_wmb() barrier as the
mutex
unlock will implicitly take care of it.

okay

quoted

To the point of compiler re-ordering, we would need some help to understand
the
purpose of READ_ONCE()/WRITE_ONCE() for these dependent statements:

quoted

+	tmp = chan_ctxt->chcfg;
+	tmp &= ~CHAN_CTX_CHSTATE_MASK;
+	tmp |= (MHI_CH_STATE_DISABLED << CHAN_CTX_CHSTATE_SHIFT);
+	chan_ctxt->chcfg = tmp;

Since RMW operation means that the chan_ctxt->chcfg is copied to a local
variable (tmp) and the _same_ is being written back to chan_ctxt->chcfg, can
compiler reorder these dependent statements and cause a different result?

Well, I agree that there is a minimal guarantee with modern day CPUs on
not breaking the order of dependent memory accesses (like here tmp
variable is the one which gets read and written) but we want to make
sure that this won't break on future CPUs as well. So IMO using
READ_ONCE and WRITE_ONCE adds extra level of safety.

Umm, if this is protected by locking, already, we really should not
add READ_ONCE. Code should be clear, not having "extra safety levels".

I assumed it was running unlocked due to the way it was written.

Best regards,
    	       	    	      	     	 	       	      Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany