Thread (1 message) 1 message, 1 author, 2021-09-23

Re: [PATCH net v2] napi: fix race inside napi_enable

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-09-23 14:54:24

On Thu, 23 Sep 2021 21:40:56 +0800 Xuan Zhuo wrote:
On Thu, 23 Sep 2021 06:14:17 -0700, Jakub Kicinski [off-list ref] wrote:
quoted
quoted
I think it should be an atomic operation. The original two-step clear itself is
problematic. So from this perspective, it is not just a solution to this
problem.  
[resending, my MUA seems to have corrupted the CC list previously]

Can you show what breaks by it being non-atomic?  
Isn't the problem this time caused by non-atoms?

Of course, in response to this problem, adjusting the order seems to be able to
solve this problem. Compared to changing to atomic operations, we have to test
other problems that may be caused by modifying this order.

Relatively speaking, the use of atoms is a relatively simple way of processing.
Whether atomics are simple or not is not the question.

What I'm saying is that having asymmetric enable and disable paths
is fragile.
quoted
Because, again, the disable part is not atomic. Either it's needed on
both sides or it's not needed on either.  
For the disable part, I think it’s okay not to use atoms. Have you considered
any special scenarios?
The point is both sides should do the same thing.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help