[PATCH net-next] net: tap: fix POLLOUT condition in tap_poll()

[PATCH net-next] net: tap: fix POLLOUT condition in tap_poll()

[yuan linyu]

From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>

from logical view, if sock_writeable(&q->sk) return false,
original second condition will return false too,
change it and make second condition can return true.

Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
---
 drivers/net/tap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 0a886fda..72212bf 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -587,8 +587,7 @@ static unsigned int tap_poll(struct file *file, poll_table *wait)
 		mask |= POLLIN | POLLRDNORM;
 
 	if (sock_writeable(&q->sk) ||
-	    (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &q->sock.flags) &&
-	     sock_writeable(&q->sk)))
+	    !test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &q->sock.flags))
 		mask |= POLLOUT | POLLWRNORM;
 
 out:
-- 
2.7.4

Re: [PATCH net-next] net: tap: fix POLLOUT condition in tap_poll()

[David Miller]

From: yuan linyu <cugyly@163.com>
Date: Thu, 14 Dec 2017 22:22:16 +0800

> From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
> 
> from logical view, if sock_writeable(&q->sk) return false,
> original second condition will return false too,
> change it and make second condition can return true.
> 
> Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
 ...
> @@ -587,8 +587,7 @@ static unsigned int tap_poll(struct file *file, poll_table *wait)
>  		mask |= POLLIN | POLLRDNORM;
>  
>  	if (sock_writeable(&q->sk) ||
> -	    (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &q->sock.flags) &&
> -	     sock_writeable(&q->sk)))
> +	    !test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &q->sock.flags))
>  		mask |= POLLOUT | POLLWRNORM;
>  
>  out:
> -- 
> 2.7.4

Hmmm, this same exact test also exists in tun_chr_poll().

The second condition probably never trigger, because of the reasons
you have listed.  The only side effect is that it will set the
ASYNC_NOSPACE bit in the socket flags.

Logically, it seems we can remove the second condition altogether.

But I wonder what might break if we stop trying to set that socket
flags bit in this situation.

Overall, I'm not sure this change is safe at all.