]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'nic-thunderx-fix-communication-races-between-VF-PF'
authorDavid S. Miller <davem@davemloft.net>
Fri, 22 Feb 2019 19:43:45 +0000 (11:43 -0800)
committerDavid S. Miller <davem@davemloft.net>
Fri, 22 Feb 2019 19:43:45 +0000 (11:43 -0800)
commitc14a205a0b003e7fbf9ee21429cd3c22721d0927
treeb2fa34d4b41a2973de77f0cb27eb90499f6cbaf3
parentc118a7f25dec5d901088893e80b3c09b5e623136
parentbdf0aca048d5bb419e10c3957b352efd8d74d63d
Merge branch 'nic-thunderx-fix-communication-races-between-VF-PF'

Vadim Lomovtsev says:

====================
nic: thunderx: fix communication races between VF & PF

The ThunderX CN88XX NIC Virtual Function driver uses mailbox interface
to communicate to physical function driver. Each of VF has it's own pair
of mailbox registers to read from and write to. The mailbox registers
has no protection from possible races, so it has to be implemented
at software side.

After long term testing by loop of 'ip link set <ifname> up/down'
command it was found that there are two possible scenarios when
race condition appears:
 1. VF receives link change message from PF and VF send RX mode
configuration message to PF in the same time from separate thread.
 2. PF receives RX mode configuration from VF and in the same time,
in separate thread PF detects link status change and sends appropriate
message to particular VF.

Both cases leads to mailbox data to be rewritten, NIC VF messaging control
data to be updated incorrectly and communication sequence gets broken.

This patch series is to address race condition with VF & PF communication.

Changes:
v1 -> v2
 - 0000: correct typo in cover letter subject: 'betwen' -> 'between';
 - move link state polling request task from pf to vf
   instead of cheking status of mailbox irq;
v2 -> v3
 - 0003: change return type of nicvf_send_cfg_done() function
   from int to void;
 - 0007: update subject and remove unused variable 'netdev'
   from nicvf_link_status_check_task() function;
====================

Signed-off-by: David S. Miller <davem@davemloft.net>