Re: [PATCH rdma-next 02/10] RDMA/core: Enable Relaxed Ordering in __ib_alloc_pd()
On 4/5/21 11:01 AM, Tom Talpey wrote:
> On 4/5/2021 1:23 AM, Leon Romanovsky wrote:
>> From: Avihai Horon
>>
>> Enable Relaxed Ordering in __ib_alloc_pd() allocation of the
>> local_dma_lkey.
>>
>> This will take effect only for devices that don't pre-allocate the lkey
>> but allocate it per PD allocation.
>>
>> Signed-off-by: Avihai Horon
>> Reviewed-by: Michael Guralnik
>> Signed-off-by: Leon Romanovsky
>> ---
>> drivers/infiniband/core/verbs.c | 3 ++-
>> drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 1 +
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/core/verbs.c
>> b/drivers/infiniband/core/verbs.c
>> index a1782f8a6ca0..9b719f7d6fd5 100644
>> --- a/drivers/infiniband/core/verbs.c
>> +++ b/drivers/infiniband/core/verbs.c
>> @@ -287,7 +287,8 @@ struct ib_pd *__ib_alloc_pd(struct ib_device *device,
>> unsigned int flags,
>> if (device->attrs.device_cap_flags & IB_DEVICE_LOCAL_DMA_LKEY)
>> pd->local_dma_lkey = device->local_dma_lkey;
>> else
>> - mr_access_flags |= IB_ACCESS_LOCAL_WRITE;
>> + mr_access_flags |=
>> + IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING;
>
> So, do local_dma_lkey's get relaxed ordering unconditionally?
>
>> if (flags & IB_PD_UNSAFE_GLOBAL_RKEY) {
>> pr_warn("%s: enabling unsafe global rkey\n", caller);
>> diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
>> b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
>> index b3fa783698a0..d74827694f92 100644
>> --- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
>> +++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
>> @@ -66,6 +66,7 @@ struct ib_mr *pvrdma_get_dma_mr(struct ib_pd *pd, int acc)
>> int ret;
>> /* Support only LOCAL_WRITE flag for DMA MRs */
>> + acc &= ~IB_ACCESS_RELAXED_ORDERING;
>> if (acc & ~IB_ACCESS_LOCAL_WRITE) {
>> dev_warn(>pdev->dev,
>> "unsupported dma mr access flags %#x\n", acc);
>
> Why does the pvrdma driver require relaxed ordering to be off?
PVRDMA doesn't support any other flags other than LOCAL_WRITE for
DMA MRs so the MR creation will fail if any new unconditionally added
flag isn't cleared.
Re: [PATCH rdma-next 0/2] Spring cleanup
On 3/22/21 7:12 AM, Leon Romanovsky wrote: > On Mon, Mar 22, 2021 at 10:00:12AM -0300, Jason Gunthorpe wrote: >> On Sun, Mar 14, 2021 at 03:39:06PM +0200, Leon Romanovsky wrote: >>> From: Leon Romanovsky >>> >>> Bunch of cleanup in RDMA subsystem. >>> >>> Leon Romanovsky (2): >>> RDMA: Fix kernel-doc compilation warnings >>> RDMA: Delete not-used static inline functions >> Applied to for-next >> >> How did you find the unused static inline functions? > Accidentally spotted such in pvrdma and later wrote one liner to create > me a list of functions to delete. Thanks for removing these. > Thanks > >> Thanks, >> Jason
Re: [PATCH] RDMA/pvrdma: fix missing kfree in pvrdma_register_device
On 11/10/20 7:22 PM, Qinglang Miao wrote:
> Fix missing kfree in pvrdma_register_device() when fails
> to do ib_device_set_netdev.
>
> Fixes: 4b38da75e089 ("RDMA/drivers: Convert easy drivers to use
> ib_device_set_netdev()")
> Reported-by: Hulk Robot
> Signed-off-by: Qinglang Miao
> ---
> drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
> b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
> index fa2a3fa0c3e4..f71d99946bed 100644
> --- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
> +++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
> @@ -266,7 +266,7 @@ static int pvrdma_register_device(struct pvrdma_dev *dev)
> }
> ret = ib_device_set_netdev(>ib_dev, dev->netdev, 1);
> if (ret)
> - return ret;
> + goto err_qp_free;
Thanks. This should be 'goto err_srq_free'.
> spin_lock_init(>srq_tbl_lock);
> rdma_set_device_sysfs_group(>ib_dev, _attr_group);
>
>
Re: [PATCH v2] vmw_pvrdma: Release netdev when vmxnet3 module is removed
On 6/29/18 4:52 AM, Neil Horman wrote: > On repeated module load/unload cycles, its possible for the pvrmda > driver to encounter this crash: > > ... > 297.032448] RIP: 0010:[] [] > netdev_walk_all_upper_dev_rcu+0x50/0xb0 > [ 297.034078] RSP: 0018:95087780bd08 EFLAGS: 00010286 > [ 297.034986] RAX: RBX: RCX: > 95087a0c > [ 297.036196] RDX: 95087a0c RSI: 839e44e0 RDI: > 950835d0c000 > [ 297.037421] RBP: 95087780bd40 R08: 95087a0e0ea0 R09: > abddacd03f8e0ea0 > [ 297.038636] R10: abddacd03f8e0ea0 R11: ef5901e9dbc0 R12: > 95087a0c > [ 297.039854] R13: 839e44e0 R14: 95087a0c R15: > 950835d0c828 > [ 297.041071] FS: () GS:95087fc0() > knlGS: > [ 297.042443] CS: 0010 DS: ES: CR0: 80050033 > [ 297.043429] CR2: ffe8 CR3: 7a652000 CR4: > 003607f0 > [ 297.044674] DR0: DR1: DR2: > > [ 297.045893] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 297.047109] Call Trace: > [ 297.047545] [] netdev_has_upper_dev_all_rcu+0x18/0x20 > [ 297.048691] [] is_eth_port_of_netdev+0x2f/0xa0 [ib_core] > [ 297.049886] [] ? > is_eth_active_slave_of_bonding_rcu+0x70/0x70 [ib_core] > ... > > This occurs because vmw_pvrdma on probe stores a pointer to the netdev > that exists on function 0 of the same bus/device/slot (which represents > the vmxnet3 ethernet driver). However, it never removes this pointer if > the vmxnet3 module is removed, leading to crashes resulting from use > after free dereferencing incidents like the one above. > > The fix is pretty straightforward. vmw_pvrdma should listen for > NETDEV_REGISTER and NETDEV_UNREGISTER events in its event listener code > block, and update the stored netdev pointer accordingly. This solution > has been tested by myself and the reporter with successful results. > This fix also allows the pvrdma driver to find its underlying ethernet > device in the event that vmxnet3 is loaded after pvrdma, which it was > not able to do before. > > Signed-off-by: Neil Horman > Reported-by: ruq...@redhat.com > CC: Adit Ranadive > CC: VMware PV-Drivers > CC: Doug Ledford > CC: Jason Gunthorpe > CC: linux-kernel@vger.kernel.org > > --- > Change notes > > v2) > * Move dev_hold in pvrda_pci_probe to below null check (aditr) > * Add dev_puts to probe error path and pvrda_pci_remove (jgg) > * Cleaned up some checkpatch warnings (nhorman) > --- > .../infiniband/hw/vmw_pvrdma/pvrdma_main.c| 39 ++- > 1 file changed, 37 insertions(+), 2 deletions(-) Thanks Neil! Tested-by: Adit Ranadive Acked-by: Adit Ranadive
Re: [PATCH v2] vmw_pvrdma: Release netdev when vmxnet3 module is removed
On 6/29/18 4:52 AM, Neil Horman wrote: > On repeated module load/unload cycles, its possible for the pvrmda > driver to encounter this crash: > > ... > 297.032448] RIP: 0010:[] [] > netdev_walk_all_upper_dev_rcu+0x50/0xb0 > [ 297.034078] RSP: 0018:95087780bd08 EFLAGS: 00010286 > [ 297.034986] RAX: RBX: RCX: > 95087a0c > [ 297.036196] RDX: 95087a0c RSI: 839e44e0 RDI: > 950835d0c000 > [ 297.037421] RBP: 95087780bd40 R08: 95087a0e0ea0 R09: > abddacd03f8e0ea0 > [ 297.038636] R10: abddacd03f8e0ea0 R11: ef5901e9dbc0 R12: > 95087a0c > [ 297.039854] R13: 839e44e0 R14: 95087a0c R15: > 950835d0c828 > [ 297.041071] FS: () GS:95087fc0() > knlGS: > [ 297.042443] CS: 0010 DS: ES: CR0: 80050033 > [ 297.043429] CR2: ffe8 CR3: 7a652000 CR4: > 003607f0 > [ 297.044674] DR0: DR1: DR2: > > [ 297.045893] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 297.047109] Call Trace: > [ 297.047545] [] netdev_has_upper_dev_all_rcu+0x18/0x20 > [ 297.048691] [] is_eth_port_of_netdev+0x2f/0xa0 [ib_core] > [ 297.049886] [] ? > is_eth_active_slave_of_bonding_rcu+0x70/0x70 [ib_core] > ... > > This occurs because vmw_pvrdma on probe stores a pointer to the netdev > that exists on function 0 of the same bus/device/slot (which represents > the vmxnet3 ethernet driver). However, it never removes this pointer if > the vmxnet3 module is removed, leading to crashes resulting from use > after free dereferencing incidents like the one above. > > The fix is pretty straightforward. vmw_pvrdma should listen for > NETDEV_REGISTER and NETDEV_UNREGISTER events in its event listener code > block, and update the stored netdev pointer accordingly. This solution > has been tested by myself and the reporter with successful results. > This fix also allows the pvrdma driver to find its underlying ethernet > device in the event that vmxnet3 is loaded after pvrdma, which it was > not able to do before. > > Signed-off-by: Neil Horman > Reported-by: ruq...@redhat.com > CC: Adit Ranadive > CC: VMware PV-Drivers > CC: Doug Ledford > CC: Jason Gunthorpe > CC: linux-kernel@vger.kernel.org > > --- > Change notes > > v2) > * Move dev_hold in pvrda_pci_probe to below null check (aditr) > * Add dev_puts to probe error path and pvrda_pci_remove (jgg) > * Cleaned up some checkpatch warnings (nhorman) > --- > .../infiniband/hw/vmw_pvrdma/pvrdma_main.c| 39 ++- > 1 file changed, 37 insertions(+), 2 deletions(-) Thanks Neil! Tested-by: Adit Ranadive Acked-by: Adit Ranadive
Re: [PATCH] vmw_pvrdma: Release netdev when vmxnet3 module is removed
On 6/28/18, 1:37 PM, "Jason Gunthorpe" wrote:
> On Thu, Jun 28, 2018 at 03:45:26PM -0400, Neil Horman wrote:
> > On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> > > On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > > > On repeated module load/unload cycles, its possible for the pvrmda
> > > > driver to encounter this crash:
> > > > @@ -962,6 +982,7 @@ static int pvrdma_pci_probe(struct pci_dev *pdev,
> > > > }
> > > >
> > > > dev->netdev = pci_get_drvdata(pdev_net);
> > > > + dev_hold(dev->netdev);
That doesn't seem right. If the vmxnet3 driver isn't loaded at all or failed
to create a netdev, you would be requesting a hold on a NULL netdev. What if
you moved this to after the if(!dev->netdev) check?
> > > > pci_dev_put(pdev_net);
> > > > if (!dev->netdev) {
> > > > dev_err(>dev, "failed to get vmxnet3 device\n");
> > >
> > > I see a lot of new dev_hold's here, where are the matching
> > > dev_puts()?
> > >
> I'm not sure I'd call 2 alot, but sure, there is a new dev_hold in the
> pvrdma_pci_probe routine, to hold a reference to the netdev that is looked up
> there. It is balanced by the NETDEV_UNREGISTER case in
> pvrdma_netdevice_event_handle. The UNREGISTER clause is also balancing the
> NETDEV_REGISTER case of the hanlder that looks up the matching netdev should a
> new device be registered. Note that we will only hold a single device at a
> time, because a given pvrdma device only recongnizes a single vmxnet3 device
> (the one on function 0 of its own bus/device tuple).
>
> I don't see how the dev_hold in pvrdma_pci_probe is undone during
> error unwind (eg goto err_free_cq_ring)
>
> And I don't see how it is put when pvrdma_pci_remove() is called.
That's right. These seem missing as well.
Re: [PATCH] vmw_pvrdma: Release netdev when vmxnet3 module is removed
On 6/28/18, 1:37 PM, "Jason Gunthorpe" wrote:
> On Thu, Jun 28, 2018 at 03:45:26PM -0400, Neil Horman wrote:
> > On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> > > On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > > > On repeated module load/unload cycles, its possible for the pvrmda
> > > > driver to encounter this crash:
> > > > @@ -962,6 +982,7 @@ static int pvrdma_pci_probe(struct pci_dev *pdev,
> > > > }
> > > >
> > > > dev->netdev = pci_get_drvdata(pdev_net);
> > > > + dev_hold(dev->netdev);
That doesn't seem right. If the vmxnet3 driver isn't loaded at all or failed
to create a netdev, you would be requesting a hold on a NULL netdev. What if
you moved this to after the if(!dev->netdev) check?
> > > > pci_dev_put(pdev_net);
> > > > if (!dev->netdev) {
> > > > dev_err(>dev, "failed to get vmxnet3 device\n");
> > >
> > > I see a lot of new dev_hold's here, where are the matching
> > > dev_puts()?
> > >
> I'm not sure I'd call 2 alot, but sure, there is a new dev_hold in the
> pvrdma_pci_probe routine, to hold a reference to the netdev that is looked up
> there. It is balanced by the NETDEV_UNREGISTER case in
> pvrdma_netdevice_event_handle. The UNREGISTER clause is also balancing the
> NETDEV_REGISTER case of the hanlder that looks up the matching netdev should a
> new device be registered. Note that we will only hold a single device at a
> time, because a given pvrdma device only recongnizes a single vmxnet3 device
> (the one on function 0 of its own bus/device tuple).
>
> I don't see how the dev_hold in pvrdma_pci_probe is undone during
> error unwind (eg goto err_free_cq_ring)
>
> And I don't see how it is put when pvrdma_pci_remove() is called.
That's right. These seem missing as well.
RE: [PATCH] vmxnet3: Move PCI Id to pci_ids.h
On Fri, Aug 05, 2016 11:23:41AM -0700, Bjorn Helgaas <helg...@kernel.org> wrote: > On Fri, Aug 05, 2016 at 11:00:39AM -0700, Adit Ranadive wrote: > > The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA > > driver. Moved it to the shared location in pci_ids.h and updated the > > driver version. > > > > Suggested-by: Leon Romanovsky <l...@kernel.org> > > Signed-off-by: Adit Ranadive <ad...@vmware.com> > > Please include this in the series that adds your paravirtual RDMA > driver. Please do not change the driver version information in this > patch, because that change is unrelated to moving the PCI ID. Ok, I will. Please drop this patch then. Thanks, Adit
RE: [PATCH] vmxnet3: Move PCI Id to pci_ids.h
On Fri, Aug 05, 2016 11:23:41AM -0700, Bjorn Helgaas wrote: > On Fri, Aug 05, 2016 at 11:00:39AM -0700, Adit Ranadive wrote: > > The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA > > driver. Moved it to the shared location in pci_ids.h and updated the > > driver version. > > > > Suggested-by: Leon Romanovsky > > Signed-off-by: Adit Ranadive > > Please include this in the series that adds your paravirtual RDMA > driver. Please do not change the driver version information in this > patch, because that change is unrelated to moving the PCI ID. Ok, I will. Please drop this patch then. Thanks, Adit
[PATCH] vmxnet3: Move PCI Id to pci_ids.h
The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA
driver. Moved it to the shared location in pci_ids.h and updated the
driver version.
Suggested-by: Leon Romanovsky <l...@kernel.org>
Signed-off-by: Adit Ranadive <ad...@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_int.h | 7 +++
include/linux/pci_ids.h | 1 +
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h
b/drivers/net/vmxnet3/vmxnet3_int.h
index 74fc030..be5991e 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.4.9.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.4.10.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01040900
+#define VMXNET3_DRIVER_VERSION_NUM 0x01040A00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
@@ -119,9 +119,8 @@ enum {
};
/*
- * PCI vendor and device IDs.
+ * Maximum devices supported.
*/
-#define PCI_DEVICE_ID_VMWARE_VMXNET30x07B0
#define MAX_ETHERNET_CARDS 10
#define MAX_PCI_PASSTHRU_DEVICE6
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index c58752f..98bb455 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2251,6 +2251,7 @@
#define PCI_DEVICE_ID_RASTEL_2PORT 0x2000
#define PCI_VENDOR_ID_VMWARE 0x15ad
+#define PCI_DEVICE_ID_VMWARE_VMXNET3 0x07b0
#define PCI_VENDOR_ID_ZOLTRIX 0x15b0
#define PCI_DEVICE_ID_ZOLTRIX_2BD0 0x2bd0
--
2.7.4
[PATCH] vmxnet3: Move PCI Id to pci_ids.h
The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA
driver. Moved it to the shared location in pci_ids.h and updated the
driver version.
Suggested-by: Leon Romanovsky
Signed-off-by: Adit Ranadive
---
drivers/net/vmxnet3/vmxnet3_int.h | 7 +++
include/linux/pci_ids.h | 1 +
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h
b/drivers/net/vmxnet3/vmxnet3_int.h
index 74fc030..be5991e 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.4.9.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.4.10.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01040900
+#define VMXNET3_DRIVER_VERSION_NUM 0x01040A00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
@@ -119,9 +119,8 @@ enum {
};
/*
- * PCI vendor and device IDs.
+ * Maximum devices supported.
*/
-#define PCI_DEVICE_ID_VMWARE_VMXNET30x07B0
#define MAX_ETHERNET_CARDS 10
#define MAX_PCI_PASSTHRU_DEVICE6
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index c58752f..98bb455 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2251,6 +2251,7 @@
#define PCI_DEVICE_ID_RASTEL_2PORT 0x2000
#define PCI_VENDOR_ID_VMWARE 0x15ad
+#define PCI_DEVICE_ID_VMWARE_VMXNET3 0x07b0
#define PCI_VENDOR_ID_ZOLTRIX 0x15b0
#define PCI_DEVICE_ID_ZOLTRIX_2BD0 0x2bd0
--
2.7.4
PATCH - Pktgen srcmac fix - Kernel 2.6.22.6
diff -urNp linux-orig/net/core/pktgen.c linux-mod/net/core/pktgen.c
--- linux-orig/net/core/pktgen.c2007-08-31 02:21:01.0 -0400
+++ linux-mod/net/core/pktgen.c 2007-09-01 20:51:22.0 -0400
@@ -111,6 +111,9 @@
*
* 802.1Q/Q-in-Q support by Francesco Fondelli (FF)
<[EMAIL PROTECTED]>
*
+ * Fixed src_mac command to set source mac of packet to value specified in
+ * command by Adit Ranadive <[EMAIL PROTECTED]>
+ *
*/
#include
#include
@@ -1415,7 +1418,9 @@ static ssize_t pktgen_if_write(struct fi
}
if (!strcmp(name, "src_mac")) {
char *v = valstr;
+ unsigned char old_smac[ETH_ALEN];
unsigned char *m = pkt_dev->src_mac;
+ memcpy(old_smac, pkt_dev->src_mac, ETH_ALEN);
len = strn_len(_buffer[i], sizeof(valstr) - 1);
if (len < 0) {
@@ -1445,6 +1450,10 @@ static ssize_t pktgen_if_write(struct fi
}
}
+ /* Set up Src MAC */
+ if (compare_ether_addr(old_smac, pkt_dev->src_mac))
+ memcpy(&(pkt_dev->hh[6]), pkt_dev->src_mac, ETH_ALEN);
+
sprintf(pg_result, "OK: srcmac");
return count;
}
--
Adit Ranadive
MS CS Candidate
Georgia Institute of Technology,
Atlanta, GA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH - Pktgen srcmac fix - Kernel 2.6.22.6
diff -urNp linux-orig/net/core/pktgen.c linux-mod/net/core/pktgen.c
--- linux-orig/net/core/pktgen.c2007-08-31 02:21:01.0 -0400
+++ linux-mod/net/core/pktgen.c 2007-09-01 20:51:22.0 -0400
@@ -111,6 +111,9 @@
*
* 802.1Q/Q-in-Q support by Francesco Fondelli (FF)
[EMAIL PROTECTED]
*
+ * Fixed src_mac command to set source mac of packet to value specified in
+ * command by Adit Ranadive [EMAIL PROTECTED]
+ *
*/
#include linux/sys.h
#include linux/types.h
@@ -1415,7 +1418,9 @@ static ssize_t pktgen_if_write(struct fi
}
if (!strcmp(name, src_mac)) {
char *v = valstr;
+ unsigned char old_smac[ETH_ALEN];
unsigned char *m = pkt_dev-src_mac;
+ memcpy(old_smac, pkt_dev-src_mac, ETH_ALEN);
len = strn_len(user_buffer[i], sizeof(valstr) - 1);
if (len 0) {
@@ -1445,6 +1450,10 @@ static ssize_t pktgen_if_write(struct fi
}
}
+ /* Set up Src MAC */
+ if (compare_ether_addr(old_smac, pkt_dev-src_mac))
+ memcpy((pkt_dev-hh[6]), pkt_dev-src_mac, ETH_ALEN);
+
sprintf(pg_result, OK: srcmac);
return count;
}
--
Adit Ranadive
MS CS Candidate
Georgia Institute of Technology,
Atlanta, GA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
