[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171216.230321.468890097045981694.davem@davemloft.net>
Date: Sat, 16 Dec 2017 23:03:21 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: cugyly@....com
Cc: netdev@...r.kernel.org, Linyu.Yuan@...atel-sbell.com.cn
Subject: Re: [PATCH net-next] net: tap: fix POLLOUT condition in tap_poll()
From: yuan linyu <cugyly@....com>
Date: Thu, 14 Dec 2017 22:22:16 +0800
> From: yuan linyu <Linyu.Yuan@...atel-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@...atel-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.
Powered by blists - more mailing lists