kernel/linux.git/drivers/net/vmxnet3, branch v4.4.171

vmxnet3: ensure that adapter is in proper state during force_close

2018-04-13T17:50:04+00:00

[ Upstream commit 1c4d5f51a812a82de97beee24f48ed05c65ebda5 ] There are several paths in vmxnet3, where settings changes cause the adapter to be brought down and back up (vmxnet3_set_ringparam among them). Should part of the reset operation fail, these paths call vmxnet3_force_close, which enables all napi instances prior to calling dev_close (with the expectation that vmxnet3_close will then properly disable them again). However, vmxnet3_force_close neglects to clear VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and leaves all the napi instances in a enabled state while the device itself is closed. If a device in this state is activated again, napi_enable will be called on already enabled napi_instances, leading to a BUG halt. The fix is to simply enausre that the QUIESCED bit is cleared in vmxnet3_force_close to allow quesence to be completed properly on close. Signed-off-by: Neil Horman CC: Shrikrishna Khare CC: "VMware, Inc." CC: "David S. Miller" Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

vmxnet3: repair memory leak

2018-01-31T11:06:13+00:00

[ Upstream commit 848b159835ddef99cc4193083f7e786c3992f580 ] with the introduction of commit b0eb57cb97e7837ebb746404c2c58c6f536f23fa, it appears that rq->buf_info is improperly handled. While it is heap allocated when an rx queue is setup, and freed when torn down, an old line of code in vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0] being set to NULL prior to its being freed, causing a memory leak, which eventually exhausts the system on repeated create/destroy operations (for example, when the mtu of a vmxnet3 interface is changed frequently. Fix is pretty straight forward, just move the NULL set to after the free. Tested by myself with successful results Applies to net, and should likely be queued for stable, please Signed-off-by: Neil Horman Reported-By: boyang@redhat.com CC: boyang@redhat.com CC: Shrikrishna Khare CC: "VMware, Inc." CC: David S. Miller Acked-by: Shrikrishna Khare Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Driver: Vmxnet3: Fix regression caused by 5738a09

2016-01-06T21:20:13+00:00

Reported-by: Bingkuo Liu Signed-off-by: Shrikrishna Khare Signed-off-by: David S. Miller

vmxnet3: fix checks for dma mapping errors

2015-12-01T20:19:16+00:00

vmxnet3_drv does not check dma_addr with dma_mapping_error() after mapping dma memory. The patch adds the checks and tries to handle failures. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Acked-by: Shrikrishna Khare Signed-off-by: David S. Miller

Driver: Vmxnet3: Fix use of mfTableLen for big endian architectures

2015-11-16T20:06:47+00:00

Signed-off-by: Shrikrishna Khare Reported-by: Masao Uebayashi Signed-off-by: Bhavesh Davda Signed-off-by: David S. Miller

drivers/net: get rid of unnecessary initializations in .get_drvinfo()

2015-10-16T07:24:10+00:00

Many drivers initialize uselessly n_priv_flags, n_stats, testinfo_len, eedump_len & regdump_len fields in their .get_drvinfo() ethtool op. It's not necessary as these fields is filled in ethtool_get_drvinfo(). v2: removed unused variable v3: removed another unused variable Signed-off-by: Ivan Vecera Signed-off-by: David S. Miller

Driver: Vmxnet3: Extend register dump support

2015-09-23T22:06:27+00:00

Signed-off-by: Shrikrishna Khare Signed-off-by: Bhavesh Davda Acked-by: Srividya Murali Signed-off-by: David S. Miller

vmxnet3: prevent receive getting out of sequence on napi poll

2015-07-09T06:36:11+00:00

vmxnet3's current napi path is built to count every rx descriptor we recieve, and use that as a count of the napi budget. That means its possible to return from a napi poll halfway through recieving a fragmented packet accross multiple dma descriptors. If that happens, the next napi poll will start with the descriptor ring in an improper state (e.g. the first descriptor we look at may have the end-of-packet bit set), which will cause a BUG halt in the driver. Fix the issue by only counting whole received packets in the napi poll and returning that value, rather than the descriptor count. Tested by the reporter and myself, successfully Signed-off-by: Neil Horman CC: Shreyas Bhatewara CC: "David S. Miller" Acked-by: Andy Gospodarek Signed-off-by: David S. Miller

vmxnet3: Bump up driver version number

2015-06-29T16:27:45+00:00

Bump up the driver version number to reflect the changes done to work with vmxnet3 adapter version 2 Signed-off-by: Shreyas N Bhatewara Signed-off-by: David S. Miller

vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)

2015-06-23T13:26:01+00:00

Make the driver understand adapter version 2. Cc: Rachel Lunnon Signed-off-by: Guolin Yang Signed-off-by: Shreyas N Bhatewara Signed-off-by: David S. Miller