* Re: [Xen-devel] [PATCH net] xen-netback: add the scenario which now beyond the range time_after_eq().
From: annie li @ 2013-10-18 1:59 UTC (permalink / raw)
To: Wei Liu
Cc: Jan Beulich, jianhai luan, david.vrabel, ian.campbell, xen-devel,
netdev
In-Reply-To: <20131017164127.GA11894@zion.uk.xensource.com>
On 2013-10-18 0:41, Wei Liu wrote:
> On Fri, Oct 18, 2013 at 12:38:12AM +0800, annie li wrote:
>> On 2013-10-17 17:26, Jan Beulich wrote:
>>>> Yes, the issue only can be reproduced in 32-bit Dom0 (Beyond
>>>> MAX_ULONG/2 in 64-bit will need long long time)
>>>>
>>>> I think the gap should be think all environment even now extending 480+.
>>>> if now fall in the gap, one timer will be pending and replenish will be
>>>> in time. Please run the attachment test program.
>>> Not sure what this is supposed to tell me. I recognize that there
>>> are overflow conditions not handled properly, but (a) I have a
>>> hard time thinking of a sensible guest that sits idle for over 240
>>> days (host uptime usually isn't even coming close to that due to
>>> maintenance requirements) and (b) if there is such a sensible
>>> guest, then I can't see why dealing with one being idle for over
>>> 480 days should be required too.
>>>
>> If the guest contains multiple NICs, that situation probably happens
>> when one NIC keeps idle and others work under load. BTW, how do you
>> get the 240?
>>
> I think Jan got this number with HZ=100. It take ~240 days for jiffies
> to overflow in 32 bit machine when HZ=100.
If HZ is larger then the days would be less, for example, HZ=250, the
days would be ~99. It is possible to hit overflow in environment where
multiple NICs coexist and one NIC keeps idle all the time. Moreover,
this patch does not extend to the days doubled, the timer is set with
value based on next_credit.
Thanks
Annie
^ permalink raw reply
* Re: [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
From: Paul Moore @ 2013-10-18 1:20 UTC (permalink / raw)
To: seif; +Cc: David Miller, netdev, thomas.petazzoni, dima
In-Reply-To: <20131017.154742.370913034142395176.davem@davemloft.net>
On Thursday, October 17, 2013 03:47:42 PM David Miller wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Mon, 14 Oct 2013 11:12:47 -0400
>
> > On Saturday, October 12, 2013 10:21:50 PM Seif Mazareeb wrote:
> >> When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could
> >> loop forever in the main loop if opt[opt_iter +1] == 0, this will causing
> >> a
> >> kernel crash in an SMP system, since the CPU executing this function will
> >> stall /not respond to IPIs.
> >>
> >> This problem can be reproduced by running the IP Stack Integrity Checker
> >> (http://isic.sourceforge.net) using the following command on a Linux
> >> machine connected to DUT:
> >>
> >> "icmpsic -s rand -d <DUT IP address> -r 123456"
> >> wait (1-2 min)
> >>
> >> Signed-off-by: Seif Mazareeb <seif@marvell.com>
> >
> > Thanks for sticking with this.
> >
> > Acked-by: Paul Moore <paul@paul-moore.com>
>
> This patch, like all the others Seif submitted, has been corrupted by
> his email client and is this unusable.
Seif, please fix this. If I don't see a new patch by tomorrow I'll go ahead
and resubmit.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next] {selinux, af_key} Rework pfkey_sadb2xfrm_user_sec_ctx
From: Paul Moore @ 2013-10-18 1:18 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Fan Du, davem, netdev
In-Reply-To: <20131017095148.GC7660@secunet.com>
On Thursday, October 17, 2013 11:51:48 AM Steffen Klassert wrote:
> On Thu, Oct 17, 2013 at 09:34:53AM +0800, Fan Du wrote:
> > On 2013年10月16日 23:15, Paul Moore wrote:
> > >The fact that you are now changing sadb_x_sec_ctx->sadb_x_sec_len
> > >whenever
> > >pfkey_sadb2xfrm_user_sec_ctx() is called raises an eyebrow. Can you
> > >elaborate on why this is not a problem?
> >
> > Thanks for your attention, Paul.
> >
> > sadb_x_sec_ctx is extra headers passed down from user space, the usage of
> > of this data structure falls down to one of pfkey_funcs function only for
> > one time, more specifically speaking, it's only used by SELINUX for
> > security checking for each operation. In other words, sadb_x_sec_ctx
> > involves with a one shot business here. So the original codes seems do a
> > lots of extra job which could easily be avoid using casting operation.
>
> Since the selinux people have to live with that change in the fist place,
> I'd like to see an ack of one of the selinux maintainers before I take
> in into ipsec-next, Paul?
Well, my earlier concern over modifying the length field probably isn't a
major concern as was pointed out so I could maybe look the other way on that
point. However, while looking a bit closer at the structs and how they are
used, I noticed that PFKEY structs are all explicitly packed (sadb_x_sec_ctx)
and the LSM struct is not (xfrm_user_sec_ctx). I'm not enough of a compiler
guru across all the different architectures to know if this is significant or
not given the structure, but it does make me pause.
Any compiler gurus care to weigh in on this?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called
From: Hannes Frederic Sowa @ 2013-10-18 1:16 UTC (permalink / raw)
To: Andi Kleen; +Cc: Steven Rostedt, netdev, linux-kernel, Peter Zijlstra
In-Reply-To: <20131018005057.GL2592@two.firstfloor.org>
On Fri, Oct 18, 2013 at 02:50:57AM +0200, Andi Kleen wrote:
> On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> > On Thu, 17 Oct 2013 07:31:57 +0200
> > Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> >
> > > Based on a patch from Andi Kleen.
> >
> > I'm fine with the patch, but the change log needs a lot more work.
> > Like, why is this needed? I know, but does anyone else?
>
> Or just merge the orininal patch. While being less verbose
> in the warning it had a full changelog.
I don't care that much which patch gets merged but I just want to
point out another difference: I added WARN_ONs on code paths without
architecture support for static_keys to help developers on platforms
without support for that.
Greetings,
Hannes
^ permalink raw reply
* Re: Any suggestions for a 40G Ethernet NIC?
From: Ben Greear @ 2013-10-18 1:08 UTC (permalink / raw)
To: Ding Tianhong; +Cc: netdev
In-Reply-To: <526088B6.7070503@huawei.com>
On 10/17/2013 06:02 PM, Ding Tianhong wrote:
> On 2013/10/18 1:55, Ben Greear wrote:
>> I'd like to start playing around with 40G, but doesn't seem to be too
>> many such NICs available. Does anyone have any suggestions for 40G NICs
>> that work well with Linux?
>>
>> Thanks,
>> Ben
>>
>
> I have the situation for test 40G for Linux, which consist of 4 82599 NICs,
> and I use bonding LACP mode to test the performance, when turn on the iommu for
> kernel, the performance is up to 30G, when close it, the performance is up to 38G,
> what do you think about it?
Nice performance!
But, for my purposes, I need a real 40g port to test some other 40g
equipment.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Any suggestions for a 40G Ethernet NIC?
From: Ding Tianhong @ 2013-10-18 1:02 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <5260248B.3090400@candelatech.com>
On 2013/10/18 1:55, Ben Greear wrote:
> I'd like to start playing around with 40G, but doesn't seem to be too
> many such NICs available. Does anyone have any suggestions for 40G NICs
> that work well with Linux?
>
> Thanks,
> Ben
>
I have the situation for test 40G for Linux, which consist of 4 82599 NICs,
and I use bonding LACP mode to test the performance, when turn on the iommu for
kernel, the performance is up to 30G, when close it, the performance is up to 38G,
what do you think about it?
Thanks.
Ding
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: Rusty Russell @ 2013-10-18 1:00 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, virtualization, Greg Kroah-Hartman
In-Reply-To: <20131017050710.GA12141@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote:
>> Jason Wang <jasowang@redhat.com> writes:
>> > We're trying to re-configure the affinity unconditionally in cpu hotplug
>> > callback. This may lead the issue during resuming from s3/s4 since
>> >
>> > - virt queues haven't been allocated at that time.
>> > - it's unnecessary since thaw method will re-configure the affinity.
>> >
>> > Fix this issue by checking the config_enable and do nothing is we're not ready.
>> >
>> > The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
>> > (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>> >
>> > Cc: Rusty Russell <rusty@rustcorp.com.au>
>> > Cc: Michael S. Tsirkin <mst@redhat.com>
>> > Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
>> > Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>> > ---
>> > The patch is need for 3.8 and above.
>>
>> Please put 'CC: stable@kernel.org # 3.8+' in the commit.
>
> Not if this is going in through the net tree.
WTF? Wow, there really *is* an FAQ: https://lwn.net/Articles/561669/
DaveM is the best maintainer I've ever known, but I abhor the idea that
every subsystem has its own incompatible variant on workflow and style.
Asking people to express 'CC: stable' in words is error-prone; if Dave
wants to filter it, he's quite capable.
Rusty.
^ permalink raw reply
* Re: [PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called
From: Andi Kleen @ 2013-10-18 0:50 UTC (permalink / raw)
To: Steven Rostedt
Cc: Hannes Frederic Sowa, netdev, linux-kernel, Peter Zijlstra,
Andi Kleen
In-Reply-To: <20131017171940.173bab09@gandalf.local.home>
On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 07:31:57 +0200
> Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>
> > Based on a patch from Andi Kleen.
>
> I'm fine with the patch, but the change log needs a lot more work.
> Like, why is this needed? I know, but does anyone else?
Or just merge the orininal patch. While being less verbose
in the warning it had a full changelog.
-Andi
^ permalink raw reply
* [PATCH 14/15] net: cxgb4vf: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:24 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Casey Leedom'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index 40c22e7..43bb012 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2782,11 +2782,9 @@ err_unmap_bar:
err_free_adapter:
kfree(adapter);
- pci_set_drvdata(pdev, NULL);
err_release_regions:
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
pci_clear_master(pdev);
err_disable_device:
@@ -2851,7 +2849,6 @@ static void cxgb4vf_pci_remove(struct pci_dev *pdev)
}
iounmap(adapter->regs);
kfree(adapter);
- pci_set_drvdata(pdev, NULL);
}
/*
--
1.7.10.4
^ permalink raw reply related
* [PATCH 15/15] net: enic: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:25 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Christian Benvenuti',
'Sujith Sankar', 'Govindarajulu Varadarajan',
'Neel Patel', 'Nishank Trivedi'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 7b756cf9..ff78dfa 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2309,7 +2309,6 @@ err_out_release_regions:
err_out_disable_device:
pci_disable_device(pdev);
err_out_free_netdev:
- pci_set_drvdata(pdev, NULL);
free_netdev(netdev);
return err;
@@ -2338,7 +2337,6 @@ static void enic_remove(struct pci_dev *pdev)
enic_iounmap(enic);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
free_netdev(netdev);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 13/15] net: cxgb2: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:24 UTC (permalink / raw)
To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
index d7048db..1d02105 100644
--- a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
+++ b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
@@ -1168,7 +1168,6 @@ out_free_dev:
pci_release_regions(pdev);
out_disable_pdev:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
return err;
}
@@ -1347,7 +1346,6 @@ static void remove_one(struct pci_dev *pdev)
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
t1_sw_reset(pdev);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 12/15] net: cxgb3: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:23 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Divy Le Ray'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index b650951..45d7733 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -3374,7 +3374,6 @@ out_release_regions:
pci_release_regions(pdev);
out_disable_device:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
out:
return err;
}
@@ -3415,7 +3414,6 @@ static void remove_one(struct pci_dev *pdev)
kfree(adapter);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/15] net: cxgb4: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:23 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Dimitris Michailidis'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 85d0cda..8b929ee 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -6075,7 +6075,6 @@ sriov:
pci_disable_device(pdev);
out_release_regions:
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
return err;
}
@@ -6123,7 +6122,6 @@ static void remove_one(struct pci_dev *pdev)
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
} else
pci_release_regions(pdev);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/15] net: bna: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:22 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Rasesh Mody'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..f276433 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3212,7 +3212,6 @@ bnad_init(struct bnad *bnad,
bnad->bar0 = ioremap_nocache(bnad->mmio_start, bnad->mmio_len);
if (!bnad->bar0) {
dev_err(&pdev->dev, "ioremap for bar0 failed\n");
- pci_set_drvdata(pdev, NULL);
return -ENOMEM;
}
pr_info("bar0 mapped to %p, len %llu\n", bnad->bar0,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/15] net: tg3: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:21 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Nithin Nayak Sujir',
'Michael Chan'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/broadcom/tg3.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 498569e..819d87c 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -17701,7 +17701,6 @@ err_out_free_res:
err_out_disable_pdev:
if (pci_is_enabled(pdev))
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
return err;
}
@@ -17733,7 +17732,6 @@ static void tg3_remove_one(struct pci_dev *pdev)
free_netdev(dev);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/15] net: bnx2x: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:21 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Eilon Greenstein'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index e53ff1e..8fd3432 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12297,7 +12297,6 @@ err_out_release:
err_out_disable:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
err_out:
return rc;
@@ -12840,7 +12839,6 @@ init_one_exit:
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
return rc;
}
@@ -12923,7 +12921,6 @@ static void __bnx2x_remove(struct pci_dev *pdev,
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
static void bnx2x_remove_one(struct pci_dev *pdev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/15] net: bnx2: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:21 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Michael Chan'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 6111870..d9980ad 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -8413,7 +8413,6 @@ err_out_release:
err_out_disable:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
err_out:
return rc;
@@ -8546,7 +8545,6 @@ error:
pci_iounmap(pdev, bp->regview);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
err_free:
free_netdev(dev);
return rc;
@@ -8578,7 +8576,6 @@ bnx2_remove_one(struct pci_dev *pdev)
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
static int
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/15] net: alx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:20 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Jay Cliburn',
'Chris Snook'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/atheros/alx/main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet/atheros/alx/main.c
index fc95b23..5aa5e81 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1367,7 +1367,6 @@ static void alx_remove(struct pci_dev *pdev)
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
free_netdev(alx->dev);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/15] net: amd8111e: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:19 UTC (permalink / raw)
To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/amd/amd8111e.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/amd8111e.c b/drivers/net/ethernet/amd/amd8111e.c
index 1b1429d..d042511 100644
--- a/drivers/net/ethernet/amd/amd8111e.c
+++ b/drivers/net/ethernet/amd/amd8111e.c
@@ -1711,7 +1711,6 @@ static void amd8111e_remove_one(struct pci_dev *pdev)
free_netdev(dev);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
}
static void amd8111e_config_ipg(struct net_device* dev)
@@ -1967,7 +1966,6 @@ err_free_reg:
err_disable_pdev:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
return err;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/15] net: pcnet32: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:19 UTC (permalink / raw)
To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han', 'Don Fry'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Don Fry <pcnet32@frontier.com>
---
drivers/net/ethernet/amd/pcnet32.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c
index bd4e640..38492e0 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -2818,7 +2818,6 @@ static void pcnet32_remove_one(struct pci_dev *pdev)
lp->init_block, lp->init_dma_addr);
free_netdev(dev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/15] net: starfire: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:18 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Ion Badulescu'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/adaptec/starfire.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/adaptec/starfire.c b/drivers/net/ethernet/adaptec/starfire.c
index 8b04bfc..171d73c 100644
--- a/drivers/net/ethernet/adaptec/starfire.c
+++ b/drivers/net/ethernet/adaptec/starfire.c
@@ -835,7 +835,6 @@ static int starfire_init_one(struct pci_dev *pdev,
return 0;
err_out_cleardev:
- pci_set_drvdata(pdev, NULL);
iounmap(base);
err_out_free_res:
pci_release_regions (pdev);
@@ -2012,7 +2011,6 @@ static void starfire_remove_one(struct pci_dev *pdev)
iounmap(np->base);
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
free_netdev(dev); /* Will also free np!! */
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/15] net: 8390: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:18 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Paul Gortmaker'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/8390/ne2k-pci.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/8390/ne2k-pci.c b/drivers/net/ethernet/8390/ne2k-pci.c
index 9220108..fc14a85 100644
--- a/drivers/net/ethernet/8390/ne2k-pci.c
+++ b/drivers/net/ethernet/8390/ne2k-pci.c
@@ -389,9 +389,7 @@ err_out_free_netdev:
free_netdev (dev);
err_out_free_res:
release_region (ioaddr, NE_IO_EXTENT);
- pci_set_drvdata (pdev, NULL);
return -ENODEV;
-
}
/*
@@ -655,7 +653,6 @@ static void ne2k_pci_remove_one(struct pci_dev *pdev)
release_region(dev->base_addr, NE_IO_EXTENT);
free_netdev(dev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
#ifdef CONFIG_PM
--
1.7.10.4
^ permalink raw reply related
* [PATCH 01/15] net: typhoon: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:17 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'David Dillow'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: David Dillow <dave@thedillows.org>
---
drivers/net/ethernet/3com/typhoon.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c
index 144942f6..465cc71 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -2525,7 +2525,6 @@ typhoon_remove_one(struct pci_dev *pdev)
pci_release_regions(pdev);
pci_clear_mwi(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
free_netdev(dev);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 00/15] net: ethernet: remove unnecessary pci_set_drvdata() part 1
From: Jingoo Han @ 2013-10-18 0:16 UTC (permalink / raw)
To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound),
the driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
---
drivers/net/ethernet/3com/typhoon.c | 1 -
drivers/net/ethernet/8390/ne2k-pci.c | 3 ---
drivers/net/ethernet/adaptec/starfire.c | 2 --
drivers/net/ethernet/amd/amd8111e.c | 2 --
drivers/net/ethernet/amd/pcnet32.c | 1 -
drivers/net/ethernet/atheros/alx/main.c | 1 -
drivers/net/ethernet/broadcom/bnx2.c | 3 ---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 3 ---
drivers/net/ethernet/broadcom/tg3.c | 2 --
drivers/net/ethernet/brocade/bna/bnad.c | 1 -
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 2 --
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 2 --
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 --
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 3 ---
drivers/net/ethernet/cisco/enic/enic_main.c | 2 --
15 files changed, 30 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called
From: Hannes Frederic Sowa @ 2013-10-18 0:01 UTC (permalink / raw)
To: Steven Rostedt; +Cc: netdev, linux-kernel, Peter Zijlstra, Andi Kleen
In-Reply-To: <20131017171940.173bab09@gandalf.local.home>
On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 07:31:57 +0200
> Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>
> > Based on a patch from Andi Kleen.
>
> I'm fine with the patch, but the change log needs a lot more work.
> Like, why is this needed? I know, but does anyone else?
Ok. :)
I'll move the description from the changelog here and write something
in a few days (hope to get more feedback on the other parts, especially
net_get_random_once).
Does that also mean you are in principle ok with the patch weakening
the check in arch/x86/jump_label.c?
Thanks for the review,
Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox