Prevent faults that would occur during this sequence of activity during
network stress:
rmmod visornic
modprobe visornic
/etc/init.d/network restart
The problem fixed was that the back-end IO partition was holding onto
stale receive buffers after the "rmmod visornic", and erroneously
completing them after a subsequent "modprobe visornic". This is fixed
in this patch as follows:
* Tell the back-end IO partition that we want it to employ its
"incarnation mechanism" to ensure it does not complete stale receive
buffers after the guest virtual device environment changes (e.g., by
re-loading the driver), by setting the
ULTRA_IO_DRIVER_SUPPORTS_ENHANCED_RCVBUF_CHECKING feature bit, and
supplying a unique incarnation number in rcvpost.unique_num for each
receive buffer posted.
* When visornic loads, make sure we drain and ignore any possible-stale
data in the channel before beginning network operation.
Prior to this patch, faults like this would occur almost every time if
you attempted to rmmod + modprobe the visornic driver and restart the
network service during heavy network activity:
BUG: spinlock bad magic on CPU#0, ksoftirqd/0/3
lock: 0xffff88002d8a56d8, .magic: ffff8800, .owner: <none>/-1,
.owner_cpu: 2304
CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G C
4.3.0-rc3-ARCH+ #74
Signed-off-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
91678f3700