[PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Xu Yang]

There are potential problems when states are set as following:

    tcpm_set_state(A, 0)
    tcpm_set_state(B, X)

As long as the state A is set and the state_machine work is queued
successfully, state_machine work will be scheduled soon after. Before
running into tcpm_state_machine_work(), there is a chance to set state
B again. If it does occur:

either (X = 0)
    port->state = B and state_machine work is queued again, then work
    will be executed twice.
or (X != 0)
    port->state = A and port->delayed_state = B, then work will be
    executed once but timer is still running.

For this situation, tcpm should only handle the most recent state change
as if only one state is set just now. Therefore, if the state_machine work
has already been queued, it can't be queued again before running into
tcpm_state_machine_work().

The state_machine_running flag already prevents from queuing the work, so
we can make it contain the pending stage (after work be queued and before
running into tcpm_state_machine_work). The state_machine_pending_or_running
flag can be used to indicate that a state can be handled without queuing
the work again.

Because the state_machine work has been queued for state A, there is no
way to cancel as it may be already dequeued later, and then will run into
tcpm_state_machine_work() certainly. To handle the delayed state B, such
an abnormal work should be skiped. If port->delayed_state != INVALID_STATE
and timer is still running, it's time to skip.

Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
cc: <stable@vger.kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 049f4c61ee82..a913bc620e88 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -371,7 +371,7 @@ struct tcpm_port {
 	struct kthread_work enable_frs;
 	struct hrtimer send_discover_timer;
 	struct kthread_work send_discover_work;
-	bool state_machine_running;
+	bool state_machine_pending_or_running;
 	bool vdm_sm_running;
 
 	struct completion tx_complete;
@@ -1192,6 +1192,7 @@ static void mod_tcpm_delayed_work(struct tcpm_port *port, unsigned int delay_ms)
 	} else {
 		hrtimer_cancel(&port->state_machine_timer);
 		kthread_queue_work(port->wq, &port->state_machine);
+		port->state_machine_pending_or_running = true;
 	}
 }
 
@@ -1250,7 +1251,7 @@ static void tcpm_set_state(struct tcpm_port *port, enum tcpm_state state,
 		 * tcpm_state_machine_work() will continue running the state
 		 * machine.
 		 */
-		if (!port->state_machine_running)
+		if (!port->state_machine_pending_or_running)
 			mod_tcpm_delayed_work(port, 0);
 	}
 }
@@ -4810,13 +4811,15 @@ static void tcpm_state_machine_work(struct kthread_work *work)
 	enum tcpm_state prev_state;
 
 	mutex_lock(&port->lock);
-	port->state_machine_running = true;
 
 	if (port->queued_message && tcpm_send_queued_message(port))
 		goto done;
 
 	/* If we were queued due to a delayed state change, update it now */
 	if (port->delayed_state) {
+		if (ktime_before(ktime_get(), port->delayed_runtime))
+			goto done;
+
 		tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
 			 tcpm_states[port->state],
 			 tcpm_states[port->delayed_state], port->delay_ms);
@@ -4837,7 +4840,7 @@ static void tcpm_state_machine_work(struct kthread_work *work)
 	} while (port->state != prev_state && !port->delayed_state);
 
 done:
-	port->state_machine_running = false;
+	port->state_machine_pending_or_running = false;
 	mutex_unlock(&port->lock);
 }
 
@@ -6300,6 +6303,7 @@ static enum hrtimer_restart state_machine_timer_handler(struct hrtimer *timer)
 	struct tcpm_port *port = container_of(timer, struct tcpm_port, state_machine_timer);
 
 	kthread_queue_work(port->wq, &port->state_machine);
+	port->state_machine_pending_or_running = true;
 	return HRTIMER_NORESTART;
 }
 
-- 
2.25.1

RE: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Xu Yang]

> -----Original Message-----
> From: Xu Yang <xu.yang_2@nxp.com>
> Sent: Friday, August 27, 2021 7:48 PM
> To: linux@roeck-us.net
> Cc: Jun Li <jun.li@nxp.com>; heikki.krogerus@linux.intel.com;
> gregkh@linuxfoundation.org; linux-usb@vger.kernel.org; dl-linux-imx <linux-
> imx@nxp.com>
> Subject: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state
> 
> There are potential problems when states are set as following:
> 
>     tcpm_set_state(A, 0)
>     tcpm_set_state(B, X)
> 
> As long as the state A is set and the state_machine work is queued
> successfully, state_machine work will be scheduled soon after. Before
> running into tcpm_state_machine_work(), there is a chance to set state B
> again. If it does occur:
> 
> either (X = 0)
>     port->state = B and state_machine work is queued again, then work
>     will be executed twice.
> or (X != 0)
>     port->state = A and port->delayed_state = B, then work will be
>     executed once but timer is still running.
> 
> For this situation, tcpm should only handle the most recent state change as if
> only one state is set just now. Therefore, if the state_machine work has
> already been queued, it can't be queued again before running into
> tcpm_state_machine_work().
> 
> The state_machine_running flag already prevents from queuing the work, so
> we can make it contain the pending stage (after work be queued and before
> running into tcpm_state_machine_work). The
> state_machine_pending_or_running flag can be used to indicate that a state
> can be handled without queuing the work again.
> 
> Because the state_machine work has been queued for state A, there is no
> way to cancel as it may be already dequeued later, and then will run into
> tcpm_state_machine_work() certainly. To handle the delayed state B, such
> an abnormal work should be skiped. If port->delayed_state !=
> INVALID_STATE and timer is still running, it's time to skip.
> 
> Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
> cc: <stable@vger.kernel.org>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 049f4c61ee82..a913bc620e88 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -371,7 +371,7 @@ struct tcpm_port {
>  	struct kthread_work enable_frs;
>  	struct hrtimer send_discover_timer;
>  	struct kthread_work send_discover_work;
> -	bool state_machine_running;
> +	bool state_machine_pending_or_running;
>  	bool vdm_sm_running;
> 
>  	struct completion tx_complete;
> @@ -1192,6 +1192,7 @@ static void mod_tcpm_delayed_work(struct
> tcpm_port *port, unsigned int delay_ms)
>  	} else {
>  		hrtimer_cancel(&port->state_machine_timer);
>  		kthread_queue_work(port->wq, &port->state_machine);
> +		port->state_machine_pending_or_running = true;
>  	}
>  }
> 
> @@ -1250,7 +1251,7 @@ static void tcpm_set_state(struct tcpm_port *port,
> enum tcpm_state state,
>  		 * tcpm_state_machine_work() will continue running the
> state
>  		 * machine.
>  		 */
> -		if (!port->state_machine_running)
> +		if (!port->state_machine_pending_or_running)
>  			mod_tcpm_delayed_work(port, 0);
>  	}
>  }
> @@ -4810,13 +4811,15 @@ static void tcpm_state_machine_work(struct
> kthread_work *work)
>  	enum tcpm_state prev_state;
> 
>  	mutex_lock(&port->lock);
> -	port->state_machine_running = true;
> 
>  	if (port->queued_message && tcpm_send_queued_message(port))
>  		goto done;
> 
>  	/* If we were queued due to a delayed state change, update it now
> */
>  	if (port->delayed_state) {
> +		if (ktime_before(ktime_get(), port->delayed_runtime))
> +			goto done;
> +
>  		tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
>  			 tcpm_states[port->state],
>  			 tcpm_states[port->delayed_state], port->delay_ms);
> @@ -4837,7 +4840,7 @@ static void tcpm_state_machine_work(struct
> kthread_work *work)
>  	} while (port->state != prev_state && !port->delayed_state);
> 
>  done:
> -	port->state_machine_running = false;
> +	port->state_machine_pending_or_running = false;
>  	mutex_unlock(&port->lock);
>  }
> 
> @@ -6300,6 +6303,7 @@ static enum hrtimer_restart
> state_machine_timer_handler(struct hrtimer *timer)
>  	struct tcpm_port *port = container_of(timer, struct tcpm_port,
> state_machine_timer);
> 
>  	kthread_queue_work(port->wq, &port->state_machine);
> +	port->state_machine_pending_or_running = true;
>  	return HRTIMER_NORESTART;
>  }
> 
> --
> 2.25.1

A gentle ping.

Xu Yang

RE: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Xu Yang]

> -----Original Message-----
> From: Xu Yang
> Sent: Monday, September 13, 2021 6:42 PM
> To: linux@roeck-us.net
> Cc: Jun Li <jun.li@nxp.com>; heikki.krogerus@linux.intel.com;
> gregkh@linuxfoundation.org; linux-usb@vger.kernel.org; dl-linux-imx <linux-
> imx@nxp.com>
> Subject: RE: [PATCH v2] usb: typec: tcpm: fix issue of multiple
> tcpm_set_state
> 
> 
> > -----Original Message-----
> > From: Xu Yang <xu.yang_2@nxp.com>
> > Sent: Friday, August 27, 2021 7:48 PM
> > To: linux@roeck-us.net
> > Cc: Jun Li <jun.li@nxp.com>; heikki.krogerus@linux.intel.com;
> > gregkh@linuxfoundation.org; linux-usb@vger.kernel.org; dl-linux-imx
> > <linux- imx@nxp.com>
> > Subject: [PATCH v2] usb: typec: tcpm: fix issue of multiple
> > tcpm_set_state
> >
> > There are potential problems when states are set as following:
> >
> >     tcpm_set_state(A, 0)
> >     tcpm_set_state(B, X)
> >
> > As long as the state A is set and the state_machine work is queued
> > successfully, state_machine work will be scheduled soon after. Before
> > running into tcpm_state_machine_work(), there is a chance to set state
> > B again. If it does occur:
> >
> > either (X = 0)
> >     port->state = B and state_machine work is queued again, then work
> >     will be executed twice.
> > or (X != 0)
> >     port->state = A and port->delayed_state = B, then work will be
> >     executed once but timer is still running.
> >
> > For this situation, tcpm should only handle the most recent state
> > change as if only one state is set just now. Therefore, if the
> > state_machine work has already been queued, it can't be queued again
> > before running into tcpm_state_machine_work().
> >
> > The state_machine_running flag already prevents from queuing the work,
> > so we can make it contain the pending stage (after work be queued and
> > before running into tcpm_state_machine_work). The
> > state_machine_pending_or_running flag can be used to indicate that a
> > state can be handled without queuing the work again.
> >
> > Because the state_machine work has been queued for state A, there is
> > no way to cancel as it may be already dequeued later, and then will
> > run into
> > tcpm_state_machine_work() certainly. To handle the delayed state B,
> > such an abnormal work should be skiped. If port->delayed_state !=
> > INVALID_STATE and timer is still running, it's time to skip.
> >
> > Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
> > cc: <stable@vger.kernel.org>
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpm.c
> > b/drivers/usb/typec/tcpm/tcpm.c index 049f4c61ee82..a913bc620e88
> > 100644
> > --- a/drivers/usb/typec/tcpm/tcpm.c
> > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > @@ -371,7 +371,7 @@ struct tcpm_port {
> >  	struct kthread_work enable_frs;
> >  	struct hrtimer send_discover_timer;
> >  	struct kthread_work send_discover_work;
> > -	bool state_machine_running;
> > +	bool state_machine_pending_or_running;
> >  	bool vdm_sm_running;
> >
> >  	struct completion tx_complete;
> > @@ -1192,6 +1192,7 @@ static void mod_tcpm_delayed_work(struct
> > tcpm_port *port, unsigned int delay_ms)
> >  	} else {
> >  		hrtimer_cancel(&port->state_machine_timer);
> >  		kthread_queue_work(port->wq, &port->state_machine);
> > +		port->state_machine_pending_or_running = true;
> >  	}
> >  }
> >
> > @@ -1250,7 +1251,7 @@ static void tcpm_set_state(struct tcpm_port
> > *port, enum tcpm_state state,
> >  		 * tcpm_state_machine_work() will continue running the
> state
> >  		 * machine.
> >  		 */
> > -		if (!port->state_machine_running)
> > +		if (!port->state_machine_pending_or_running)
> >  			mod_tcpm_delayed_work(port, 0);
> >  	}
> >  }
> > @@ -4810,13 +4811,15 @@ static void tcpm_state_machine_work(struct
> > kthread_work *work)
> >  	enum tcpm_state prev_state;
> >
> >  	mutex_lock(&port->lock);
> > -	port->state_machine_running = true;
> >
> >  	if (port->queued_message && tcpm_send_queued_message(port))
> >  		goto done;
> >
> >  	/* If we were queued due to a delayed state change, update it now
> */
> >  	if (port->delayed_state) {
> > +		if (ktime_before(ktime_get(), port->delayed_runtime))
> > +			goto done;
> > +
> >  		tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
> >  			 tcpm_states[port->state],
> >  			 tcpm_states[port->delayed_state], port->delay_ms);
> @@ -4837,7
> > +4840,7 @@ static void tcpm_state_machine_work(struct kthread_work
> > *work)
> >  	} while (port->state != prev_state && !port->delayed_state);
> >
> >  done:
> > -	port->state_machine_running = false;
> > +	port->state_machine_pending_or_running = false;
> >  	mutex_unlock(&port->lock);
> >  }
> >
> > @@ -6300,6 +6303,7 @@ static enum hrtimer_restart
> > state_machine_timer_handler(struct hrtimer *timer)
> >  	struct tcpm_port *port = container_of(timer, struct tcpm_port,
> > state_machine_timer);
> >
> >  	kthread_queue_work(port->wq, &port->state_machine);
> > +	port->state_machine_pending_or_running = true;
> >  	return HRTIMER_NORESTART;
> >  }
> >
> > --
> > 2.25.1
> 
> A gentle ping.
> 
> Xu Yang

A gentle ping.
Xu Yang

Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Heikki Krogerus]

Guenter, can you check this?

On Fri, Aug 27, 2021 at 07:48:09PM +0800, Xu Yang wrote:
> There are potential problems when states are set as following:
> 
>     tcpm_set_state(A, 0)
>     tcpm_set_state(B, X)
> 
> As long as the state A is set and the state_machine work is queued
> successfully, state_machine work will be scheduled soon after. Before
> running into tcpm_state_machine_work(), there is a chance to set state
> B again. If it does occur:
> 
> either (X = 0)
>     port->state = B and state_machine work is queued again, then work
>     will be executed twice.
> or (X != 0)
>     port->state = A and port->delayed_state = B, then work will be
>     executed once but timer is still running.
> 
> For this situation, tcpm should only handle the most recent state change
> as if only one state is set just now. Therefore, if the state_machine work
> has already been queued, it can't be queued again before running into
> tcpm_state_machine_work().
> 
> The state_machine_running flag already prevents from queuing the work, so
> we can make it contain the pending stage (after work be queued and before
> running into tcpm_state_machine_work). The state_machine_pending_or_running
> flag can be used to indicate that a state can be handled without queuing
> the work again.
> 
> Because the state_machine work has been queued for state A, there is no
> way to cancel as it may be already dequeued later, and then will run into
> tcpm_state_machine_work() certainly. To handle the delayed state B, such
> an abnormal work should be skiped. If port->delayed_state != INVALID_STATE
> and timer is still running, it's time to skip.
> 
> Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
> cc: <stable@vger.kernel.org>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

What changed since v1?

thanks,

> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 049f4c61ee82..a913bc620e88 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -371,7 +371,7 @@ struct tcpm_port {
>  	struct kthread_work enable_frs;
>  	struct hrtimer send_discover_timer;
>  	struct kthread_work send_discover_work;
> -	bool state_machine_running;
> +	bool state_machine_pending_or_running;
>  	bool vdm_sm_running;
>  
>  	struct completion tx_complete;
> @@ -1192,6 +1192,7 @@ static void mod_tcpm_delayed_work(struct tcpm_port *port, unsigned int delay_ms)
>  	} else {
>  		hrtimer_cancel(&port->state_machine_timer);
>  		kthread_queue_work(port->wq, &port->state_machine);
> +		port->state_machine_pending_or_running = true;
>  	}
>  }
>  
> @@ -1250,7 +1251,7 @@ static void tcpm_set_state(struct tcpm_port *port, enum tcpm_state state,
>  		 * tcpm_state_machine_work() will continue running the state
>  		 * machine.
>  		 */
> -		if (!port->state_machine_running)
> +		if (!port->state_machine_pending_or_running)
>  			mod_tcpm_delayed_work(port, 0);
>  	}
>  }
> @@ -4810,13 +4811,15 @@ static void tcpm_state_machine_work(struct kthread_work *work)
>  	enum tcpm_state prev_state;
>  
>  	mutex_lock(&port->lock);
> -	port->state_machine_running = true;
>  
>  	if (port->queued_message && tcpm_send_queued_message(port))
>  		goto done;
>  
>  	/* If we were queued due to a delayed state change, update it now */
>  	if (port->delayed_state) {
> +		if (ktime_before(ktime_get(), port->delayed_runtime))
> +			goto done;
> +
>  		tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
>  			 tcpm_states[port->state],
>  			 tcpm_states[port->delayed_state], port->delay_ms);
> @@ -4837,7 +4840,7 @@ static void tcpm_state_machine_work(struct kthread_work *work)
>  	} while (port->state != prev_state && !port->delayed_state);
>  
>  done:
> -	port->state_machine_running = false;
> +	port->state_machine_pending_or_running = false;
>  	mutex_unlock(&port->lock);
>  }
>  
> @@ -6300,6 +6303,7 @@ static enum hrtimer_restart state_machine_timer_handler(struct hrtimer *timer)
>  	struct tcpm_port *port = container_of(timer, struct tcpm_port, state_machine_timer);
>  
>  	kthread_queue_work(port->wq, &port->state_machine);
> +	port->state_machine_pending_or_running = true;
>  	return HRTIMER_NORESTART;
>  }
>  
> -- 
> 2.25.1

-- 
heikki

RE: [EXT] Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Xu Yang]

Hi heikki,

> -----Original Message-----
> From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Sent: Monday, October 11, 2021 2:31 PM
> To: Xu Yang <xu.yang_2@nxp.com>; linux@roeck-us.net
> Cc: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org; linux-
> usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: [EXT] Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple
> tcpm_set_state
> 
> Caution: EXT Email
> 
> Guenter, can you check this?
> 
> On Fri, Aug 27, 2021 at 07:48:09PM +0800, Xu Yang wrote:
> > There are potential problems when states are set as following:
> >
> >     tcpm_set_state(A, 0)
> >     tcpm_set_state(B, X)
> >
> > As long as the state A is set and the state_machine work is queued
> > successfully, state_machine work will be scheduled soon after. Before
> > running into tcpm_state_machine_work(), there is a chance to set state
> > B again. If it does occur:
> >
> > either (X = 0)
> >     port->state = B and state_machine work is queued again, then work
> >     will be executed twice.
> > or (X != 0)
> >     port->state = A and port->delayed_state = B, then work will be
> >     executed once but timer is still running.
> >
> > For this situation, tcpm should only handle the most recent state
> > change as if only one state is set just now. Therefore, if the
> > state_machine work has already been queued, it can't be queued again
> > before running into tcpm_state_machine_work().
> >
> > The state_machine_running flag already prevents from queuing the work,
> > so we can make it contain the pending stage (after work be queued and
> > before running into tcpm_state_machine_work). The
> > state_machine_pending_or_running flag can be used to indicate that a
> > state can be handled without queuing the work again.
> >
> > Because the state_machine work has been queued for state A, there is
> > no way to cancel as it may be already dequeued later, and then will
> > run into
> > tcpm_state_machine_work() certainly. To handle the delayed state B,
> > such an abnormal work should be skiped. If port->delayed_state !=
> > INVALID_STATE and timer is still running, it's time to skip.
> >
> > Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
> > cc: <stable@vger.kernel.org>
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> 
> What changed since v1?
> 
> thanks,

In patch v1, I committed two patches to fix two problems. However, the two 
problems are resulted by the same reason. And I try to address the issues 
after it occurs.

In patch v2, according to Guenter's advice, I try to avoid such problems 
occurring from the source. So I set a state_machine_pending_or_running flag 
to indicate that a state can be handled without queuing the work again. 
Meanwhile, one patch is enough to address the problems.

Xu Yang

> 
> > diff --git a/drivers/usb/typec/tcpm/tcpm.c
> > b/drivers/usb/typec/tcpm/tcpm.c index 049f4c61ee82..a913bc620e88
> > 100644
> > --- a/drivers/usb/typec/tcpm/tcpm.c
> > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > @@ -371,7 +371,7 @@ struct tcpm_port {
> >       struct kthread_work enable_frs;
> >       struct hrtimer send_discover_timer;
> >       struct kthread_work send_discover_work;
> > -     bool state_machine_running;
> > +     bool state_machine_pending_or_running;
> >       bool vdm_sm_running;
> >
> >       struct completion tx_complete;
> > @@ -1192,6 +1192,7 @@ static void mod_tcpm_delayed_work(struct
> tcpm_port *port, unsigned int delay_ms)
> >       } else {
> >               hrtimer_cancel(&port->state_machine_timer);
> >               kthread_queue_work(port->wq, &port->state_machine);
> > +             port->state_machine_pending_or_running = true;
> >       }
> >  }
> >
> > @@ -1250,7 +1251,7 @@ static void tcpm_set_state(struct tcpm_port
> *port, enum tcpm_state state,
> >                * tcpm_state_machine_work() will continue running the state
> >                * machine.
> >                */
> > -             if (!port->state_machine_running)
> > +             if (!port->state_machine_pending_or_running)
> >                       mod_tcpm_delayed_work(port, 0);
> >       }
> >  }
> > @@ -4810,13 +4811,15 @@ static void tcpm_state_machine_work(struct
> kthread_work *work)
> >       enum tcpm_state prev_state;
> >
> >       mutex_lock(&port->lock);
> > -     port->state_machine_running = true;
> >
> >       if (port->queued_message && tcpm_send_queued_message(port))
> >               goto done;
> >
> >       /* If we were queued due to a delayed state change, update it now */
> >       if (port->delayed_state) {
> > +             if (ktime_before(ktime_get(), port->delayed_runtime))
> > +                     goto done;
> > +
> >               tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
> >                        tcpm_states[port->state],
> >                        tcpm_states[port->delayed_state],
> > port->delay_ms); @@ -4837,7 +4840,7 @@ static void
> tcpm_state_machine_work(struct kthread_work *work)
> >       } while (port->state != prev_state && !port->delayed_state);
> >
> >  done:
> > -     port->state_machine_running = false;
> > +     port->state_machine_pending_or_running = false;
> >       mutex_unlock(&port->lock);
> >  }
> >
> > @@ -6300,6 +6303,7 @@ static enum hrtimer_restart
> state_machine_timer_handler(struct hrtimer *timer)
> >       struct tcpm_port *port = container_of(timer, struct tcpm_port,
> > state_machine_timer);
> >
> >       kthread_queue_work(port->wq, &port->state_machine);
> > +     port->state_machine_pending_or_running = true;
> >       return HRTIMER_NORESTART;
> >  }
> >
> > --
> > 2.25.1
> 
> --
> heikki

Re: [EXT] Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Heikki Krogerus]

Hi,

On Mon, Oct 11, 2021 at 09:17:54AM +0000, Xu Yang wrote:
> Hi heikki,
> 
> > -----Original Message-----
> > From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > Sent: Monday, October 11, 2021 2:31 PM
> > To: Xu Yang <xu.yang_2@nxp.com>; linux@roeck-us.net
> > Cc: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org; linux-
> > usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> > Subject: [EXT] Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple
> > tcpm_set_state
> > 
> > Caution: EXT Email
> > 
> > Guenter, can you check this?
> > 
> > On Fri, Aug 27, 2021 at 07:48:09PM +0800, Xu Yang wrote:
> > > There are potential problems when states are set as following:
> > >
> > >     tcpm_set_state(A, 0)
> > >     tcpm_set_state(B, X)
> > >
> > > As long as the state A is set and the state_machine work is queued
> > > successfully, state_machine work will be scheduled soon after. Before
> > > running into tcpm_state_machine_work(), there is a chance to set state
> > > B again. If it does occur:
> > >
> > > either (X = 0)
> > >     port->state = B and state_machine work is queued again, then work
> > >     will be executed twice.
> > > or (X != 0)
> > >     port->state = A and port->delayed_state = B, then work will be
> > >     executed once but timer is still running.
> > >
> > > For this situation, tcpm should only handle the most recent state
> > > change as if only one state is set just now. Therefore, if the
> > > state_machine work has already been queued, it can't be queued again
> > > before running into tcpm_state_machine_work().
> > >
> > > The state_machine_running flag already prevents from queuing the work,
> > > so we can make it contain the pending stage (after work be queued and
> > > before running into tcpm_state_machine_work). The
> > > state_machine_pending_or_running flag can be used to indicate that a
> > > state can be handled without queuing the work again.
> > >
> > > Because the state_machine work has been queued for state A, there is
> > > no way to cancel as it may be already dequeued later, and then will
> > > run into
> > > tcpm_state_machine_work() certainly. To handle the delayed state B,
> > > such an abnormal work should be skiped. If port->delayed_state !=
> > > INVALID_STATE and timer is still running, it's time to skip.
> > >
> > > Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
> > > cc: <stable@vger.kernel.org>
> > > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> > 
> > What changed since v1?
> > 
> > thanks,
> 
> In patch v1, I committed two patches to fix two problems. However, the two 
> problems are resulted by the same reason. And I try to address the issues 
> after it occurs.
> 
> In patch v2, according to Guenter's advice, I try to avoid such problems 
> occurring from the source. So I set a state_machine_pending_or_running flag 
> to indicate that a state can be handled without queuing the work again. 
> Meanwhile, one patch is enough to address the problems.

This did not apply on top of Greg's latest usb-next branch anymore,
so you need to rebase and resend. Don't forget the changelog :-)


thanks,

-- 
heikki

Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Guenter Roeck]

On 10/10/21 11:31 PM, Heikki Krogerus wrote:
> Guenter, can you check this?
> 

I tried quite some time ago, but was concerned if it really solves
the problem or just the symptom, and never had the time for a deep
dive so far.

Guenter

> On Fri, Aug 27, 2021 at 07:48:09PM +0800, Xu Yang wrote:
>> There are potential problems when states are set as following:
>>
>>      tcpm_set_state(A, 0)
>>      tcpm_set_state(B, X)
>>
>> As long as the state A is set and the state_machine work is queued
>> successfully, state_machine work will be scheduled soon after. Before
>> running into tcpm_state_machine_work(), there is a chance to set state
>> B again. If it does occur:
>>
>> either (X = 0)
>>      port->state = B and state_machine work is queued again, then work
>>      will be executed twice.
>> or (X != 0)
>>      port->state = A and port->delayed_state = B, then work will be
>>      executed once but timer is still running.
>>
>> For this situation, tcpm should only handle the most recent state change
>> as if only one state is set just now. Therefore, if the state_machine work
>> has already been queued, it can't be queued again before running into
>> tcpm_state_machine_work().
>>
>> The state_machine_running flag already prevents from queuing the work, so
>> we can make it contain the pending stage (after work be queued and before
>> running into tcpm_state_machine_work). The state_machine_pending_or_running
>> flag can be used to indicate that a state can be handled without queuing
>> the work again.
>>
>> Because the state_machine work has been queued for state A, there is no
>> way to cancel as it may be already dequeued later, and then will run into
>> tcpm_state_machine_work() certainly. To handle the delayed state B, such
>> an abnormal work should be skiped. If port->delayed_state != INVALID_STATE
>> and timer is still running, it's time to skip.
>>
>> Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
>> cc: <stable@vger.kernel.org>
>> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> 
> What changed since v1?
> 
> thanks,
> 
>> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
>> index 049f4c61ee82..a913bc620e88 100644
>> --- a/drivers/usb/typec/tcpm/tcpm.c
>> +++ b/drivers/usb/typec/tcpm/tcpm.c
>> @@ -371,7 +371,7 @@ struct tcpm_port {
>>   	struct kthread_work enable_frs;
>>   	struct hrtimer send_discover_timer;
>>   	struct kthread_work send_discover_work;
>> -	bool state_machine_running;
>> +	bool state_machine_pending_or_running;
>>   	bool vdm_sm_running;
>>   
>>   	struct completion tx_complete;
>> @@ -1192,6 +1192,7 @@ static void mod_tcpm_delayed_work(struct tcpm_port *port, unsigned int delay_ms)
>>   	} else {
>>   		hrtimer_cancel(&port->state_machine_timer);
>>   		kthread_queue_work(port->wq, &port->state_machine);
>> +		port->state_machine_pending_or_running = true;
>>   	}
>>   }
>>   
>> @@ -1250,7 +1251,7 @@ static void tcpm_set_state(struct tcpm_port *port, enum tcpm_state state,
>>   		 * tcpm_state_machine_work() will continue running the state
>>   		 * machine.
>>   		 */
>> -		if (!port->state_machine_running)
>> +		if (!port->state_machine_pending_or_running)
>>   			mod_tcpm_delayed_work(port, 0);
>>   	}
>>   }
>> @@ -4810,13 +4811,15 @@ static void tcpm_state_machine_work(struct kthread_work *work)
>>   	enum tcpm_state prev_state;
>>   
>>   	mutex_lock(&port->lock);
>> -	port->state_machine_running = true;
>>   
>>   	if (port->queued_message && tcpm_send_queued_message(port))
>>   		goto done;
>>   
>>   	/* If we were queued due to a delayed state change, update it now */
>>   	if (port->delayed_state) {
>> +		if (ktime_before(ktime_get(), port->delayed_runtime))
>> +			goto done;
>> +
>>   		tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
>>   			 tcpm_states[port->state],
>>   			 tcpm_states[port->delayed_state], port->delay_ms);
>> @@ -4837,7 +4840,7 @@ static void tcpm_state_machine_work(struct kthread_work *work)
>>   	} while (port->state != prev_state && !port->delayed_state);
>>   
>>   done:
>> -	port->state_machine_running = false;
>> +	port->state_machine_pending_or_running = false;
>>   	mutex_unlock(&port->lock);
>>   }
>>   
>> @@ -6300,6 +6303,7 @@ static enum hrtimer_restart state_machine_timer_handler(struct hrtimer *timer)
>>   	struct tcpm_port *port = container_of(timer, struct tcpm_port, state_machine_timer);
>>   
>>   	kthread_queue_work(port->wq, &port->state_machine);
>> +	port->state_machine_pending_or_running = true;
>>   	return HRTIMER_NORESTART;
>>   }
>>   
>> -- 
>> 2.25.1
> 

[PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Xu Yang]

There are potential problems when states are set as following:

    tcpm_set_state(A, 0)
    tcpm_set_state(B, X)

As long as the state A is set and the state_machine work is queued
successfully, state_machine work will be scheduled soon after. Before
running into tcpm_state_machine_work(), there is a chance to set state
B again. If it does occur:

either (X = 0)
    port->state = B and state_machine work is queued again, then work
    will be executed twice.
or (X != 0)
    port->state = A and port->delayed_state = B, then work will be
    executed once but timer is still running.

For this situation, tcpm should only handle the most recent state change
as if only one state is set just now. Therefore, if the state_machine work
has already been queued, it can't be queued again before running into
tcpm_state_machine_work().

The state_machine_running flag already prevents from queuing the work, so
we can make it contain the pending stage (after work be queued and before
running into tcpm_state_machine_work). The state_machine_pending_or_running
flag can be used to indicate that a state can be handled without queuing
the work again.

Because the state_machine work has been queued for state A, there is no
way to cancel as it may be already dequeued later, and then will run into
tcpm_state_machine_work() certainly. To handle the delayed state B, such
an abnormal work should be skiped. If port->delayed_state != INVALID_STATE
and timer is still running, it's time to skip.

Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
cc: <stable@vger.kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes for v2:
-Try to avoid such problems occurring from the source.
-Set a state_machine_pending_or_running flag to indicate that a state
 can be handled without queuing the work again.
---
 drivers/usb/typec/tcpm/tcpm.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index a4d37205df54..7819deae6bff 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -372,7 +372,7 @@ struct tcpm_port {
 	struct kthread_work enable_frs;
 	struct hrtimer send_discover_timer;
 	struct kthread_work send_discover_work;
-	bool state_machine_running;
+	bool state_machine_pending_or_running;
 	/* Set to true when VDM State Machine has following actions. */
 	bool vdm_sm_running;
 
@@ -1194,6 +1194,7 @@ static void mod_tcpm_delayed_work(struct tcpm_port *port, unsigned int delay_ms)
 	} else {
 		hrtimer_cancel(&port->state_machine_timer);
 		kthread_queue_work(port->wq, &port->state_machine);
+		port->state_machine_pending_or_running = true;
 	}
 }
 
@@ -1252,7 +1253,7 @@ static void tcpm_set_state(struct tcpm_port *port, enum tcpm_state state,
 		 * tcpm_state_machine_work() will continue running the state
 		 * machine.
 		 */
-		if (!port->state_machine_running)
+		if (!port->state_machine_pending_or_running)
 			mod_tcpm_delayed_work(port, 0);
 	}
 }
@@ -4805,13 +4806,15 @@ static void tcpm_state_machine_work(struct kthread_work *work)
 	enum tcpm_state prev_state;
 
 	mutex_lock(&port->lock);
-	port->state_machine_running = true;
 
 	if (port->queued_message && tcpm_send_queued_message(port))
 		goto done;
 
 	/* If we were queued due to a delayed state change, update it now */
 	if (port->delayed_state) {
+		if (ktime_before(ktime_get(), port->delayed_runtime))
+			goto done;
+
 		tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
 			 tcpm_states[port->state],
 			 tcpm_states[port->delayed_state], port->delay_ms);
@@ -4832,7 +4835,7 @@ static void tcpm_state_machine_work(struct kthread_work *work)
 	} while (port->state != prev_state && !port->delayed_state);
 
 done:
-	port->state_machine_running = false;
+	port->state_machine_pending_or_running = false;
 	mutex_unlock(&port->lock);
 }
 
@@ -6295,6 +6298,7 @@ static enum hrtimer_restart state_machine_timer_handler(struct hrtimer *timer)
 	struct tcpm_port *port = container_of(timer, struct tcpm_port, state_machine_timer);
 
 	kthread_queue_work(port->wq, &port->state_machine);
+	port->state_machine_pending_or_running = true;
 	return HRTIMER_NORESTART;
 }
 
-- 
2.25.1

Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state

[Greg KH]

On Mon, Oct 11, 2021 at 06:32:10PM +0800, Xu Yang wrote:
> There are potential problems when states are set as following:
> 
>     tcpm_set_state(A, 0)
>     tcpm_set_state(B, X)
> 
> As long as the state A is set and the state_machine work is queued
> successfully, state_machine work will be scheduled soon after. Before
> running into tcpm_state_machine_work(), there is a chance to set state
> B again. If it does occur:
> 
> either (X = 0)
>     port->state = B and state_machine work is queued again, then work
>     will be executed twice.
> or (X != 0)
>     port->state = A and port->delayed_state = B, then work will be
>     executed once but timer is still running.
> 
> For this situation, tcpm should only handle the most recent state change
> as if only one state is set just now. Therefore, if the state_machine work
> has already been queued, it can't be queued again before running into
> tcpm_state_machine_work().
> 
> The state_machine_running flag already prevents from queuing the work, so
> we can make it contain the pending stage (after work be queued and before
> running into tcpm_state_machine_work). The state_machine_pending_or_running
> flag can be used to indicate that a state can be handled without queuing
> the work again.
> 
> Because the state_machine work has been queued for state A, there is no
> way to cancel as it may be already dequeued later, and then will run into
> tcpm_state_machine_work() certainly. To handle the delayed state B, such
> an abnormal work should be skiped. If port->delayed_state != INVALID_STATE
> and timer is still running, it's time to skip.
> 
> Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
> cc: <stable@vger.kernel.org>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> 
> ---
> Changes for v2:
> -Try to avoid such problems occurring from the source.
> -Set a state_machine_pending_or_running flag to indicate that a state
>  can be handled without queuing the work again.

I think this is a v3, as I see 2 v2 patches here :(

v4 now please?

thanks,

greg k-h