[PATCH net-next] net: wwan: core: Return poll error in case of port removal

[PATCH net-next] net: wwan: core: Return poll error in case of port removal

[Loic Poulain]

Ensure that the poll system call returns error flags when port is
removed, allowing user side to properly fail, without trying read
or write. Port removal leads to nullified port operations, add a
is_port_connected() helper to safely check the status.

Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
---
 drivers/net/wwan/wwan_core.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c
index 5be5e1e..c965b21 100644
--- a/drivers/net/wwan/wwan_core.c
+++ b/drivers/net/wwan/wwan_core.c
@@ -369,14 +369,25 @@ static int wwan_port_op_tx(struct wwan_port *port, struct sk_buff *skb)
 	return ret;
 }
 
+static bool is_port_connected(struct wwan_port *port)
+{
+	bool connected;
+
+	mutex_lock(&port->ops_lock);
+	connected = !!port->ops;
+	mutex_unlock(&port->ops_lock);
+
+	return connected;
+}
+
 static bool is_read_blocked(struct wwan_port *port)
 {
-	return skb_queue_empty(&port->rxq) && port->ops;
+	return skb_queue_empty(&port->rxq) && is_port_connected(port);
 }
 
 static bool is_write_blocked(struct wwan_port *port)
 {
-	return test_bit(WWAN_PORT_TX_OFF, &port->flags) && port->ops;
+	return test_bit(WWAN_PORT_TX_OFF, &port->flags) && is_port_connected(port);
 }
 
 static int wwan_wait_rx(struct wwan_port *port, bool nonblock)
@@ -508,6 +519,8 @@ static __poll_t wwan_port_fops_poll(struct file *filp, poll_table *wait)
 		mask |= EPOLLOUT | EPOLLWRNORM;
 	if (!is_read_blocked(port))
 		mask |= EPOLLIN | EPOLLRDNORM;
+	if (!is_port_connected(port))
+		mask |= EPOLLHUP | EPOLLERR;
 
 	return mask;
 }
-- 
2.7.4

Re: [PATCH net-next] net: wwan: core: Return poll error in case of port removal

[Leon Romanovsky]

On Thu, Apr 22, 2021 at 11:43:34AM +0200, Loic Poulain wrote:
> Ensure that the poll system call returns error flags when port is
> removed, allowing user side to properly fail, without trying read
> or write. Port removal leads to nullified port operations, add a
> is_port_connected() helper to safely check the status.
> 
> Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem")
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> ---
>  drivers/net/wwan/wwan_core.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c
> index 5be5e1e..c965b21 100644
> --- a/drivers/net/wwan/wwan_core.c
> +++ b/drivers/net/wwan/wwan_core.c
> @@ -369,14 +369,25 @@ static int wwan_port_op_tx(struct wwan_port *port, struct sk_buff *skb)
>  	return ret;
>  }
>  
> +static bool is_port_connected(struct wwan_port *port)
> +{
> +	bool connected;
> +
> +	mutex_lock(&port->ops_lock);
> +	connected = !!port->ops;
> +	mutex_unlock(&port->ops_lock);
> +
> +	return connected;
> +}

The above can't be correct. What prevents to change the status of
port->ops right before or after your mutex_lock/mutex_unlock?

> +
>  static bool is_read_blocked(struct wwan_port *port)
>  {
> -	return skb_queue_empty(&port->rxq) && port->ops;
> +	return skb_queue_empty(&port->rxq) && is_port_connected(port);
>  }
>  
>  static bool is_write_blocked(struct wwan_port *port)
>  {
> -	return test_bit(WWAN_PORT_TX_OFF, &port->flags) && port->ops;
> +	return test_bit(WWAN_PORT_TX_OFF, &port->flags) && is_port_connected(port);
>  }
>  
>  static int wwan_wait_rx(struct wwan_port *port, bool nonblock)
> @@ -508,6 +519,8 @@ static __poll_t wwan_port_fops_poll(struct file *filp, poll_table *wait)
>  		mask |= EPOLLOUT | EPOLLWRNORM;
>  	if (!is_read_blocked(port))
>  		mask |= EPOLLIN | EPOLLRDNORM;
> +	if (!is_port_connected(port))
> +		mask |= EPOLLHUP | EPOLLERR;
>  
>  	return mask;
>  }
> -- 
> 2.7.4
> 

Re: [PATCH net-next] net: wwan: core: Return poll error in case of port removal

[Loic Poulain]

Hi Leon,

On Thu, 22 Apr 2021 at 12:49, Leon Romanovsky <leon@kernel.org> wrote:
>
> On Thu, Apr 22, 2021 at 11:43:34AM +0200, Loic Poulain wrote:
> > Ensure that the poll system call returns error flags when port is
> > removed, allowing user side to properly fail, without trying read
> > or write. Port removal leads to nullified port operations, add a
> > is_port_connected() helper to safely check the status.
> >
> > Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem")
> > Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> > ---
> >  drivers/net/wwan/wwan_core.c | 17 +++++++++++++++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c
> > index 5be5e1e..c965b21 100644
> > --- a/drivers/net/wwan/wwan_core.c
> > +++ b/drivers/net/wwan/wwan_core.c
> > @@ -369,14 +369,25 @@ static int wwan_port_op_tx(struct wwan_port *port, struct sk_buff *skb)
> >       return ret;
> >  }
> >
> > +static bool is_port_connected(struct wwan_port *port)
> > +{
> > +     bool connected;
> > +
> > +     mutex_lock(&port->ops_lock);
> > +     connected = !!port->ops;
> > +     mutex_unlock(&port->ops_lock);
> > +
> > +     return connected;
> > +}
>
> The above can't be correct. What prevents to change the status of
> port->ops right before or after your mutex_lock/mutex_unlock?

Nothing, this is just to protect access to the variable (probably
overkill though), which can be concurrently nullified in port removal,
and to check if the event (poll wake-up) has been caused by removal of
the port, no port operation (port->ops...) is actually called on that
condition. If the status is changed right after the check, then any
subsequent poll/read/write syscall will simply fail properly.

Regards,
Loic

Re: [PATCH net-next] net: wwan: core: Return poll error in case of port removal

[Leon Romanovsky]

On Thu, Apr 22, 2021 at 01:21:47PM +0200, Loic Poulain wrote:
> Hi Leon,
> 
> On Thu, 22 Apr 2021 at 12:49, Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Thu, Apr 22, 2021 at 11:43:34AM +0200, Loic Poulain wrote:
> > > Ensure that the poll system call returns error flags when port is
> > > removed, allowing user side to properly fail, without trying read
> > > or write. Port removal leads to nullified port operations, add a
> > > is_port_connected() helper to safely check the status.
> > >
> > > Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem")
> > > Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> > > ---
> > >  drivers/net/wwan/wwan_core.c | 17 +++++++++++++++--
> > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c
> > > index 5be5e1e..c965b21 100644
> > > --- a/drivers/net/wwan/wwan_core.c
> > > +++ b/drivers/net/wwan/wwan_core.c
> > > @@ -369,14 +369,25 @@ static int wwan_port_op_tx(struct wwan_port *port, struct sk_buff *skb)
> > >       return ret;
> > >  }
> > >
> > > +static bool is_port_connected(struct wwan_port *port)
> > > +{
> > > +     bool connected;
> > > +
> > > +     mutex_lock(&port->ops_lock);
> > > +     connected = !!port->ops;
> > > +     mutex_unlock(&port->ops_lock);
> > > +
> > > +     return connected;
> > > +}
> >
> > The above can't be correct. What prevents to change the status of
> > port->ops right before or after your mutex_lock/mutex_unlock?
> 
> Nothing, this is just to protect access to the variable (probably
> overkill though), which can be concurrently nullified in port removal,
> and to check if the event (poll wake-up) has been caused by removal of
> the port, no port operation (port->ops...) is actually called on that
> condition. If the status is changed right after the check, then any
> subsequent poll/read/write syscall will simply fail properly.

Taking locks when it is not needed is not overkill, but bug.

I wander if all these is_*_blocked() checks can be trusted if port->ops
pointer flips.

Thanks

> 
> Regards,
> Loic

Re: [PATCH net-next] net: wwan: core: Return poll error in case of port removal

[Loic Poulain]

On Thu, 22 Apr 2021 at 14:59, Leon Romanovsky <leon@kernel.org> wrote:
>
> On Thu, Apr 22, 2021 at 01:21:47PM +0200, Loic Poulain wrote:
> > Hi Leon,
> >
> > On Thu, 22 Apr 2021 at 12:49, Leon Romanovsky <leon@kernel.org> wrote:
> > >
> > > On Thu, Apr 22, 2021 at 11:43:34AM +0200, Loic Poulain wrote:
> > > > Ensure that the poll system call returns error flags when port is
> > > > removed, allowing user side to properly fail, without trying read
> > > > or write. Port removal leads to nullified port operations, add a
> > > > is_port_connected() helper to safely check the status.
> > > >
> > > > Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem")
> > > > Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> > > > ---
> > > >  drivers/net/wwan/wwan_core.c | 17 +++++++++++++++--
> > > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c
> > > > index 5be5e1e..c965b21 100644
> > > > --- a/drivers/net/wwan/wwan_core.c
> > > > +++ b/drivers/net/wwan/wwan_core.c
> > > > @@ -369,14 +369,25 @@ static int wwan_port_op_tx(struct wwan_port *port, struct sk_buff *skb)
> > > >       return ret;
> > > >  }
> > > >
> > > > +static bool is_port_connected(struct wwan_port *port)
> > > > +{
> > > > +     bool connected;
> > > > +
> > > > +     mutex_lock(&port->ops_lock);
> > > > +     connected = !!port->ops;
> > > > +     mutex_unlock(&port->ops_lock);
> > > > +
> > > > +     return connected;
> > > > +}
> > >
> > > The above can't be correct. What prevents to change the status of
> > > port->ops right before or after your mutex_lock/mutex_unlock?
> >
> > Nothing, this is just to protect access to the variable (probably
> > overkill though), which can be concurrently nullified in port removal,
> > and to check if the event (poll wake-up) has been caused by removal of
> > the port, no port operation (port->ops...) is actually called on that
> > condition. If the status is changed right after the check, then any
> > subsequent poll/read/write syscall will simply fail properly.
>
> Taking locks when it is not needed is not overkill, but bug.

Ok understood, so going to rework that patch properly.

> I wander if all these is_*_blocked() checks can be trusted if port->ops
> pointer flips.

The port->ops value can only flip from something (port connected) to
null (port disconnected), and testing port->ops in is_*_blocked()
prevents blocking on waitqueue once the port is removed (similarly to
e.g. virtio_console).

Regards,
Loic

Re: [PATCH net-next] net: wwan: core: Return poll error in case of port removal

[Leon Romanovsky]

On Thu, Apr 22, 2021 at 03:37:10PM +0200, Loic Poulain wrote:
> On Thu, 22 Apr 2021 at 14:59, Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Thu, Apr 22, 2021 at 01:21:47PM +0200, Loic Poulain wrote:
> > > Hi Leon,
> > >
> > > On Thu, 22 Apr 2021 at 12:49, Leon Romanovsky <leon@kernel.org> wrote:
> > > >
> > > > On Thu, Apr 22, 2021 at 11:43:34AM +0200, Loic Poulain wrote:
> > > > > Ensure that the poll system call returns error flags when port is
> > > > > removed, allowing user side to properly fail, without trying read
> > > > > or write. Port removal leads to nullified port operations, add a
> > > > > is_port_connected() helper to safely check the status.
> > > > >
> > > > > Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem")
> > > > > Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> > > > > ---
> > > > >  drivers/net/wwan/wwan_core.c | 17 +++++++++++++++--
> > > > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c
> > > > > index 5be5e1e..c965b21 100644
> > > > > --- a/drivers/net/wwan/wwan_core.c
> > > > > +++ b/drivers/net/wwan/wwan_core.c
> > > > > @@ -369,14 +369,25 @@ static int wwan_port_op_tx(struct wwan_port *port, struct sk_buff *skb)
> > > > >       return ret;
> > > > >  }
> > > > >
> > > > > +static bool is_port_connected(struct wwan_port *port)
> > > > > +{
> > > > > +     bool connected;
> > > > > +
> > > > > +     mutex_lock(&port->ops_lock);
> > > > > +     connected = !!port->ops;
> > > > > +     mutex_unlock(&port->ops_lock);
> > > > > +
> > > > > +     return connected;
> > > > > +}
> > > >
> > > > The above can't be correct. What prevents to change the status of
> > > > port->ops right before or after your mutex_lock/mutex_unlock?
> > >
> > > Nothing, this is just to protect access to the variable (probably
> > > overkill though), which can be concurrently nullified in port removal,
> > > and to check if the event (poll wake-up) has been caused by removal of
> > > the port, no port operation (port->ops...) is actually called on that
> > > condition. If the status is changed right after the check, then any
> > > subsequent poll/read/write syscall will simply fail properly.
> >
> > Taking locks when it is not needed is not overkill, but bug.
> 
> Ok understood, so going to rework that patch properly.

Thanks