staging: unisys: visornic: prevent faults if driver re-loaded during stress
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>
Showing
Please register or sign in to comment