* Regression 2.6.36 - driver rtl8169 crashes kernel, triggered by user app
From: Michael Monnerie @ 2010-11-11 18:33 UTC (permalink / raw)
To: linux-kernel; +Cc: romieu, netdev
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
Dear list, I've hunted down a bug which does *NOT* occur in kernel
2.6.34.7-0.5-desktop from openSUSE 11.3, but crashes stock kernel 2.6.36
triggered by a user!
It's actually very simple. From my desktop (kernel 2.6.36) I "cd" to an
NFS4 share, where a xz compressed image of Win7-64.iso.xz is located.
# cd /q/iso-images
and then I try to uncompress it there (as user, not root!):
# xz -kv Win7-64.iso.xz
With kernel 2.6.34.7-0.5-desktop, this runs with ~41MiB/s without
problems.
With kernel 2.6.36, it runs at ~26MiB/s, and while doing so, dmesg shows
a lot of noise about r8169 complaining:
http://zmi.at/x/kernel2.6.36-crash86.jpg
Here are 2 pictures of different crashes:
http://zmi.at/x/kernel2.6.36-crash84.jpg
http://zmi.at/x/kernel2.6.36-crash85.jpg
Neither the dmesg-messages nor the crash happens with kernel
2.6.34.7-0.5-desktop as delivered by openSUSE 11.3, but it always fully
crashes 2.6.36. I've retried about 10 times, it *never* finished to
uncompress the ~3GB image. At around 500-1000MB the kernel was gone.
I'm sure someone knows how to fix it. :-)
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31
****** Radiointerview zum Thema Spam ******
http://www.it-podcast.at/archiv.html#podcast-100716
// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] macvlan: lockless tx path
From: Ben Greear @ 2010-11-11 18:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1289498572.17691.1599.camel@edumazet-laptop>
On 11/11/2010 10:02 AM, Eric Dumazet wrote:
> Le jeudi 11 novembre 2010 à 09:20 -0800, Ben Greear a écrit :
>
>> I've shown you my algorithm that requires one to know the counter
>> width, and in response you offered on that will work with 32 OR 64 bits,
>> as long as you make some assumptions.
>>
>> If you have an algorithm that can properly deal with wrapped counters of
>> arbitrary bits, then post it.
>>
>
> Its only a generalization of RRD algo
>
> No rocket science I am afraid.
>
> You can try all the numbers in `seq 32 64` in this order, to get a
> generic algo.
Ok, so then you have to sample soon enough that a 32-bit counter
can't wrap twice..otherwise you couldn't tell a 32 bit from a
33 bit counter, and you basically gain nothing from having "64-bit"
stats.
And that still assumes at least 32-bit stats..not 16 or whatever.
Thankfully, I doubt there are any drivers using < 32 bit stats.
I'll work on a patch for my idea when I get a chance..we'll see if
anyone likes it.
If you are aware of any drivers that return counters of other than 32 or
64bit widths, please let us know and perhaps we can fix them as well.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: vxge update version 3
From: David Miller @ 2010-11-11 18:12 UTC (permalink / raw)
To: jon.mason; +Cc: netdev, sivakumar.subramani, sreenivasa.honnur
In-Reply-To: <1289485564-8822-1-git-send-email-jon.mason@exar.com>
From: Jon Mason <jon.mason@exar.com>
Date: Thu, 11 Nov 2010 08:25:52 -0600
> This version of the patch series includes Ben Hutchings' comments on the
> firmware flashing patch and resolves the merge issues with the latest
> code.
All applied, thank you.
^ permalink raw reply
* Re: [PATCH] macvlan: lockless tx path
From: Eric Dumazet @ 2010-11-11 18:02 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4CDC25F5.7010501@candelatech.com>
Le jeudi 11 novembre 2010 à 09:20 -0800, Ben Greear a écrit :
> I've shown you my algorithm that requires one to know the counter
> width, and in response you offered on that will work with 32 OR 64 bits,
> as long as you make some assumptions.
>
> If you have an algorithm that can properly deal with wrapped counters of
> arbitrary bits, then post it.
>
Its only a generalization of RRD algo
No rocket science I am afraid.
You can try all the numbers in `seq 32 64` in this order, to get a
generic algo.
If you can certify all your devices are 32 or 64, then the RRD method is
OK.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: lockless transmit path
From: Eric Dumazet @ 2010-11-11 17:52 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <AANLkTikBkUNfrfSZkoVd1xzisD3jgg5kVUUZC45gNpde@mail.gmail.com>
Le jeudi 11 novembre 2010 à 09:40 -0800, Jesse Gross a écrit :
> If we're only allocating a single queue then we should also drop
> vlan_dev_select_queue() and the netdev_ops that call it. If the
> underlying device is multiqueue and has its own select_queue function
> then it can pick a queue number that is larger than what the vlan
> device has. The problem will be caught by dev_cap_txqueue() but it's
> not right and it would also be nice to get rid of half of those
> netdev_ops.
Hmm, you refer to old kernels dont you ?
My patch is for net-next
The plan is that after last Tom Herbert patches, dev_pick_tx() wont
call do_select_queue() on mono queue device.
http://patchwork.ozlabs.org/patch/70369/
This logicaly is a second cleanup patch I believe.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: lockless transmit path
From: Jesse Gross @ 2010-11-11 17:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <1289468520.17691.1018.camel@edumazet-laptop>
On Thu, Nov 11, 2010 at 1:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> vlan is a stacked device, like tunnels. We should use the lockless
> mechanism we are using in tunnels and loopback.
>
> This patch completely removes locking in TX path.
>
> tx stat counters are added into existing percpu stat structure, renamed
> from vlan_rx_stats to vlan_pcpu_stats.
>
> Note : this partially reverts commit 2e59af3dcbdf (vlan: multiqueue vlan
> device)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Patrick McHardy <kaber@trash.net>
> ---
> net/8021q/vlan.c | 4 -
> net/8021q/vlan.h | 16 +++++--
> net/8021q/vlan_core.c | 4 -
> net/8021q/vlan_dev.c | 78 +++++++++++++++++++++----------------
> net/8021q/vlan_netlink.c | 20 ---------
> 5 files changed, 59 insertions(+), 63 deletions(-)
>
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index 52077ca..2f54ce8 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -272,13 +272,11 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
> snprintf(name, IFNAMSIZ, "vlan%.4i", vlan_id);
> }
>
> - new_dev = alloc_netdev_mq(sizeof(struct vlan_dev_info), name,
> - vlan_setup, real_dev->num_tx_queues);
> + new_dev = alloc_netdev(sizeof(struct vlan_dev_info), name, vlan_setup);
If we're only allocating a single queue then we should also drop
vlan_dev_select_queue() and the netdev_ops that call it. If the
underlying device is multiqueue and has its own select_queue function
then it can pick a queue number that is larger than what the vlan
device has. The problem will be caught by dev_cap_txqueue() but it's
not right and it would also be nice to get rid of half of those
netdev_ops.
^ permalink raw reply
* Re: [PATCH 00/10] cxgb4vf: a number of bug fixes and minor cleanup
From: Casey Leedom @ 2010-11-11 17:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101111.093315.183049721.davem@davemloft.net>
| From: David Miller <davem@davemloft.net>
| Date: Thursday, November 11, 2010 09:33 am
|
| From: Casey Leedom <leedom@chelsio.com>
| Date: Wed, 10 Nov 2010 18:01:33 -0800
|
| > The following patch set includes a number of bug fixes and some
| > minor cleanup for the cxgb4vf network driver. If there are any
| > problems with formatting, etc. of the patch set please just reject
| > the patch set and kick my butt ― I'm still a novice at putting these
| > together!
|
| This is a mix of bug fixes (which would be appropriate for net-2.6)
| and also changes like cleanups and minor feature adds which are not
| appropriate in net-2.6
|
| Please split them up.
|
| I'd suggest sending out only the real bug fixes so I can quickly get
| them into net-2.6, and then later you can submit the cleanups and
| feature-adds realtive to the net-2.6 stuff.
Okay, sorry, I didn't know what the policies were. It'll take a bit for me to
wrangle "git send-email" into doing this. Two new patch sets coming before the
end of the day!
Casey
^ permalink raw reply
* SEASON LOAN!
From: PRIVATE HOME LENDER INC @ 2010-11-11 17:35 UTC (permalink / raw)
To: thiery455
Apply for a loan to establish your business.
Our interest is very affordable and our loan process is very fast as well as
percentage rate of 2.5% yea rly from $5 000.00 Min. To $100 000 000.00 M a x.
Contact us via email if you are interested with the following details
NAME:
PHONE:
DURATION:
ADDRESS:
AMOUNT:
Regards,
Private Money Lender Inc
phl111mikejack@live.com.my
^ permalink raw reply
* Re: [PATCH 00/10] cxgb4vf: a number of bug fixes and minor cleanup
From: David Miller @ 2010-11-11 17:33 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <450C6E98-D0D9-42A6-9F15-4DB98647DB04@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Wed, 10 Nov 2010 18:01:33 -0800
> The following patch set includes a number of bug fixes and some
> minor cleanup for the cxgb4vf network driver. If there are any
> problems with formatting, etc. of the patch set please just reject
> the patch set and kick my butt ― I'm still a novice at putting these
> together!
This is a mix of bug fixes (which would be appropriate for net-2.6)
and also changes like cleanups and minor feature adds which are not
appropriate in net-2.6
Please split them up.
I'd suggest sending out only the real bug fixes so I can quickly get
them into net-2.6, and then later you can submit the cleanups and
feature-adds realtive to the net-2.6 stuff.
^ permalink raw reply
* Re: [PATCH] macvlan: lockless tx path
From: Ben Greear @ 2010-11-11 17:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1289494618.17691.1498.camel@edumazet-laptop>
On 11/11/2010 08:56 AM, Eric Dumazet wrote:
> Le jeudi 11 novembre 2010 à 08:40 -0800, Ben Greear a écrit :
>
>> So, they assume counters are exactly 32 or 64 bits.
>> Your example of the 36-bit counter would break their
>> assumptions of 32 or 64 bits.
>>
>
> They 'assume'. I am not. How do you handle counters that suddenly go to
> 0 ?
I've shown you my algorithm that requires one to know the counter
width, and in response you offered on that will work with 32 OR 64 bits,
as long as you make some assumptions.
If you have an algorithm that can properly deal with wrapped counters of
arbitrary bits, then post it.
As for counters that go to zero, if the previous value was > 0, then
it was a wrap. There is a reason Dave won't let anyone add a patch to
clear network counters. If the network device was removed and came back,
then you must listen for those events and take proper precautions (set
prev to 0 before sampling any counters, for instance).
>> I agree that you can guess if the counter is 32 or 64, at least with today's
>> hardware and relatively normal poll times, and the requirement that the
>> counters can ONLY be 32 or 64 bits. I still consider it a kludge to
>> return 32 bit counters in stats64, however. Would you consider
>> a patch to have netlink pay attention to whether the stats are 32 or
>> 64 (based on a flag returned from dev_get_stats perhaps)?
>
> So what ? How is it going to help /proc/net/dev users (most apps use it)
At least they will have an opportunity to use a better defined API
if they wish. And, if you only want stats for one interface, and
you have 4000 VLANs in the system, reading /proc/net/dev seems quite
inefficient.
> Could you please adapt your software, and not adapt linux to your
> needs ? Dont your software runs on linux 2.6.32 ?
Yes, I used to carry a patch that allowed direct access to the netdev_stats,
and I'd fall back to parsing /proc/net/dev on standard kernels. I've now
moved to using netlink API as that seems the preferred method going
forward and allows the granularity (ie, get stats for a single device)
that I prefer.
And, I'll certainly keep trying to improve Linux, because if it helps
my needs, it may help others. If it causes harm to others, then hopefully
someone will notice and reject my patch or help me to see how to make
it better.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 01/10] cxgb4vf: minor comment/symbolic name cleanup.
From: Casey Leedom @ 2010-11-11 17:17 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, davem
In-Reply-To: <1289445578.15905.173.camel@Joe-Laptop>
[[Second attempt: First effort at replying got dropped because of local relay
security insanity ... and would have been dropped in any case because my mailer
was configured for HTML "Rich Text. -- Casey]]
| | From: Joe Perches <joe@perches.com>
| | Date: Wednesday, November 10, 2010 07:19 pm
| |
| | > const struct port_info *pi = netdev_priv(dev);
| | > int qs, msi;
| | >
| | > - for (qs = 0, msi = MSIX_NIQFLINT;
| | > + for (qs = 0, msi = MSIX_IQFLINT;
| | >
| | > qs < pi->nqsets;
| | > qs++, msi++) {
| |
| | This for now fits on a single line.
| |
| | > - struct fw_cmd_hdr *cmd_hdr = (struct fw_cmd_hdr *)rpl;
| | > + const struct fw_cmd_hdr *cmd_hdr = (const struct fw_cmd_hdr *)rpl;
| | > @@ -1265,7 +1265,7 @@ int t4vf_handle_fw_rpl(struct adapter *adapter,
| | > const __be64 *rpl) - const struct fw_port_cmd *port_cmd = (void *)rpl;
| | > + const struct fw_port_cmd *port_cmd = (const void *)rpl;
| |
| | might be better to have a consistent casting style.
| | 1st uses a direct cast, 2nd an implicit one.
|
| Sure. These both look good. May I fix these in a follow up patch or
| should I respin the patches with this last change?
[[To which Joe responded to me because of the aforementioned HTML email botch:]]
| Date: Thu Nov 11 06:55:43 2010
| From: Joe Perches <joe@perches.com>
| To: Casey Leedom <leedom@chelsio.com>
|
| It's just trivial formatting.
| Do what you think appropriate.
|
| fyi: linux-kernel doesn't accept emails with html formatting.
| You'll need to default to text otherwise your emails to
| any kernel related list will be silently rejected.
|
| cheers, Joe
Thanks Joe!
Casey
^ permalink raw reply
* [PATCH net-next-2.6] net: get rid of rtable->idev
From: Eric Dumazet @ 2010-11-11 17:14 UTC (permalink / raw)
To: David Miller, Herbert Xu
Cc: netdev, Roland Dreier, Sean Hefty, Hal Rosenstock
It seems idev field in struct rtable has no special purpose, but adding
extra atomic ops.
We hold refcounts on the device itself (using percpu data, so pretty
cheap in current kernel).
infiniband case is solved using dst.dev instead of idev->dev
Removal of this field means routing without route cache is now using
shared data, percpu data, and only potential contention is a pair of
atomic ops on struct neighbour per forwarded packet.
About 5% speedup on routing test.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
---
drivers/infiniband/core/addr.c | 8 +++---
include/net/route.h | 2 -
net/ipv4/route.c | 37 +++----------------------------
net/ipv4/xfrm4_policy.c | 24 --------------------
4 files changed, 8 insertions(+), 63 deletions(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index a5ea1bc..c15fd2e 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -200,7 +200,7 @@ static int addr4_resolve(struct sockaddr_in *src_in,
src_in->sin_family = AF_INET;
src_in->sin_addr.s_addr = rt->rt_src;
- if (rt->idev->dev->flags & IFF_LOOPBACK) {
+ if (rt->dst.dev->flags & IFF_LOOPBACK) {
ret = rdma_translate_ip((struct sockaddr *) dst_in, addr);
if (!ret)
memcpy(addr->dst_dev_addr, addr->src_dev_addr, MAX_ADDR_LEN);
@@ -208,12 +208,12 @@ static int addr4_resolve(struct sockaddr_in *src_in,
}
/* If the device does ARP internally, return 'done' */
- if (rt->idev->dev->flags & IFF_NOARP) {
- rdma_copy_addr(addr, rt->idev->dev, NULL);
+ if (rt->dst.dev->flags & IFF_NOARP) {
+ rdma_copy_addr(addr, rt->dst.dev, NULL);
goto put;
}
- neigh = neigh_lookup(&arp_tbl, &rt->rt_gateway, rt->idev->dev);
+ neigh = neigh_lookup(&arp_tbl, &rt->rt_gateway, rt->dst.dev);
if (!neigh || !(neigh->nud_state & NUD_VALID)) {
neigh_event_send(rt->dst.neighbour, NULL);
ret = -ENODATA;
diff --git a/include/net/route.h b/include/net/route.h
index 7e5e73b..cea533e 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -55,8 +55,6 @@ struct rtable {
/* Cache lookup keys */
struct flowi fl;
- struct in_device *idev;
-
int rt_genid;
unsigned rt_flags;
__u16 rt_type;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 987bf9a..5955965 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -140,13 +140,15 @@ static unsigned long expires_ljiffies;
static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie);
static void ipv4_dst_destroy(struct dst_entry *dst);
-static void ipv4_dst_ifdown(struct dst_entry *dst,
- struct net_device *dev, int how);
static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst);
static void ipv4_link_failure(struct sk_buff *skb);
static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu);
static int rt_garbage_collect(struct dst_ops *ops);
+static void ipv4_dst_ifdown(struct dst_entry *dst, struct net_device *dev,
+ int how)
+{
+}
static struct dst_ops ipv4_dst_ops = {
.family = AF_INET,
@@ -1433,8 +1435,6 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
rt->dst.child = NULL;
if (rt->dst.dev)
dev_hold(rt->dst.dev);
- if (rt->idev)
- in_dev_hold(rt->idev);
rt->dst.obsolete = -1;
rt->dst.lastuse = jiffies;
rt->dst.path = &rt->dst;
@@ -1728,33 +1728,13 @@ static void ipv4_dst_destroy(struct dst_entry *dst)
{
struct rtable *rt = (struct rtable *) dst;
struct inet_peer *peer = rt->peer;
- struct in_device *idev = rt->idev;
if (peer) {
rt->peer = NULL;
inet_putpeer(peer);
}
-
- if (idev) {
- rt->idev = NULL;
- in_dev_put(idev);
- }
}
-static void ipv4_dst_ifdown(struct dst_entry *dst, struct net_device *dev,
- int how)
-{
- struct rtable *rt = (struct rtable *) dst;
- struct in_device *idev = rt->idev;
- if (dev != dev_net(dev)->loopback_dev && idev && idev->dev == dev) {
- struct in_device *loopback_idev =
- in_dev_get(dev_net(dev)->loopback_dev);
- if (loopback_idev) {
- rt->idev = loopback_idev;
- in_dev_put(idev);
- }
- }
-}
static void ipv4_link_failure(struct sk_buff *skb)
{
@@ -1910,7 +1890,6 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
rth->fl.iif = dev->ifindex;
rth->dst.dev = init_net.loopback_dev;
dev_hold(rth->dst.dev);
- rth->idev = in_dev_get(rth->dst.dev);
rth->fl.oif = 0;
rth->rt_gateway = daddr;
rth->rt_spec_dst= spec_dst;
@@ -2050,7 +2029,6 @@ static int __mkroute_input(struct sk_buff *skb,
rth->fl.iif = in_dev->dev->ifindex;
rth->dst.dev = (out_dev)->dev;
dev_hold(rth->dst.dev);
- rth->idev = in_dev_get(rth->dst.dev);
rth->fl.oif = 0;
rth->rt_spec_dst= spec_dst;
@@ -2231,7 +2209,6 @@ local_input:
rth->fl.iif = dev->ifindex;
rth->dst.dev = net->loopback_dev;
dev_hold(rth->dst.dev);
- rth->idev = in_dev_get(rth->dst.dev);
rth->rt_gateway = daddr;
rth->rt_spec_dst= spec_dst;
rth->dst.input= ip_local_deliver;
@@ -2417,9 +2394,6 @@ static int __mkroute_output(struct rtable **result,
if (!rth)
return -ENOBUFS;
- in_dev_hold(in_dev);
- rth->idev = in_dev;
-
atomic_set(&rth->dst.__refcnt, 1);
rth->dst.flags= DST_HOST;
if (IN_DEV_CONF_GET(in_dev, NOXFRM))
@@ -2759,9 +2733,6 @@ static int ipv4_dst_blackhole(struct net *net, struct rtable **rp, struct flowi
rt->fl = ort->fl;
- rt->idev = ort->idev;
- if (rt->idev)
- in_dev_hold(rt->idev);
rt->rt_genid = rt_genid(net);
rt->rt_flags = ort->rt_flags;
rt->rt_type = ort->rt_type;
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 4464f3b..dd1fd8c 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -80,10 +80,6 @@ static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
xdst->u.dst.dev = dev;
dev_hold(dev);
- xdst->u.rt.idev = in_dev_get(dev);
- if (!xdst->u.rt.idev)
- return -ENODEV;
-
xdst->u.rt.peer = rt->peer;
if (rt->peer)
atomic_inc(&rt->peer->refcnt);
@@ -189,8 +185,6 @@ static void xfrm4_dst_destroy(struct dst_entry *dst)
{
struct xfrm_dst *xdst = (struct xfrm_dst *)dst;
- if (likely(xdst->u.rt.idev))
- in_dev_put(xdst->u.rt.idev);
if (likely(xdst->u.rt.peer))
inet_putpeer(xdst->u.rt.peer);
xfrm_dst_destroy(xdst);
@@ -199,27 +193,9 @@ static void xfrm4_dst_destroy(struct dst_entry *dst)
static void xfrm4_dst_ifdown(struct dst_entry *dst, struct net_device *dev,
int unregister)
{
- struct xfrm_dst *xdst;
-
if (!unregister)
return;
- xdst = (struct xfrm_dst *)dst;
- if (xdst->u.rt.idev->dev == dev) {
- struct in_device *loopback_idev =
- in_dev_get(dev_net(dev)->loopback_dev);
- BUG_ON(!loopback_idev);
-
- do {
- in_dev_put(xdst->u.rt.idev);
- xdst->u.rt.idev = loopback_idev;
- in_dev_hold(loopback_idev);
- xdst = (struct xfrm_dst *)xdst->u.dst.child;
- } while (xdst->u.dst.xfrm);
-
- __in_dev_put(loopback_idev);
- }
-
xfrm_dst_ifdown(dst, dev);
}
^ permalink raw reply related
* Re: [PATCH] net: b43legacy: fix compile error
From: John W. Linville @ 2010-11-11 17:07 UTC (permalink / raw)
To: Larry Finger
Cc: Arnd Hannemann, David S. Miller, netdev, linux-kernel,
linux-wireless, Eric Dumazet
In-Reply-To: <4CDC2298.1050803@lwfinger.net>
On Thu, Nov 11, 2010 at 11:06:32AM -0600, Larry Finger wrote:
> On 11/11/2010 10:35 AM, John W. Linville wrote:
> > On Mon, Oct 25, 2010 at 10:13:06PM +0200, Arnd Hannemann wrote:
> >> Am 25.10.2010 20:59, schrieb Larry Finger:
> >>> On 10/25/2010 01:44 PM, Arnd Hannemann wrote:
> >>>> Am 25.10.2010 20:36, schrieb Larry Finger:
> >>>>> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
> >>>>>> Am 25.10.2010 17:32, schrieb Larry Finger:
> >>>>>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
> >>>>>>>> On todays linus tree the following compile error happened to me:
> >>>>>>>>
> >>>>>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
> >>>>>>>> In file included from include/net/dst.h:11,
> >>>>>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
> >>>>>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
> >>>>>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
> >>>>>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
> >>>>>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>>>> include/net/dst_ops.h: In function 'dst_entries_add':
> >>>>>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>>>> include/net/dst_ops.h: In function 'dst_entries_init':
> >>>>>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
> >>>>>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
> >>>>>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
> >>>>>>>> make[2]: *** [drivers/net/wireless] Error 2
> >>>>>>>> make[1]: *** [drivers/net] Error 2
> >>>>>>>> make: *** [drivers] Error 2
> >>>>>>>>
> >>>>>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
> >>>>>>>> "include/net/dst_ops.h".
> >>>>>>>
> >>>>>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
> >>>>>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
> >>>>>>
> >>>>>> Exactly the same git describe here.
> >>>>>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
> >>>>>
> >>>>> That probably makes the difference. Using Eric's fix that removes the #include
> >>>>> <linux/dst.h> should be better. Does it work for you?
> >>>>>
> >>>>> There are probably a lot more of the system includes that may not be needed. If
> >>>>> I send you a patch removing them, could you test?
> >>>>
> >>>> As it turns out my card is not supported by b43legacy, but compilation testing,
> >>>> sure I can test that.
> >>>
> >>> If it is a Broadcom card, it is likely handled by b43.
> >>
> >> Yes. It seems it should work with b43 (its an SDIO card) and it almost does...
> >>
> >>> Attached is a trial removal of a number of include statements. Does it compile?
> >>
> >> Nope:
> >> NSTALL_MOD_PATH=/home/arnd/projekte/renesas-2/nfs modules
> >> CHK include/linux/version.h
> >> CHK include/generated/utsrelease.h
> >> make[1]: `include/generated/mach-types.h' is up to date.
> >> CALL scripts/checksyscalls.sh
> >> CC [M] drivers/net/wireless/b43legacy/main.o
> >> drivers/net/wireless/b43legacy/main.c: In function 'b43legacy_upload_microcode':
> >> drivers/net/wireless/b43legacy/main.c:1688: error: implicit declaration of function 'signal_pending'
> >> make[4]: *** [drivers/net/wireless/b43legacy/main.o] Error 1
> >> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
> >> make[2]: *** [drivers/net/wireless] Error 2
> >> make[1]: *** [drivers/net] Error 2
> >> make: *** [drivers] Error 2
> >
> > Is this issue resolved? Should I be expecting a b43 patch?
>
> I don't know if a similar patch for b43 is needed. I tried to set up a cross
> compiler for ARM. My initial attempt failed and I did not have time to explore
> the situation. If anyone has links to a cross-compiler solution for x86_64 on
> openSUSE, please let me know.
Sorry, I mean b43legacy -- will there be a formal patch?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: Larry Finger @ 2010-11-11 17:06 UTC (permalink / raw)
To: John W. Linville
Cc: Arnd Hannemann, David S. Miller, netdev, linux-kernel,
linux-wireless, Eric Dumazet
In-Reply-To: <20101111163531.GB2559@tuxdriver.com>
On 11/11/2010 10:35 AM, John W. Linville wrote:
> On Mon, Oct 25, 2010 at 10:13:06PM +0200, Arnd Hannemann wrote:
>> Am 25.10.2010 20:59, schrieb Larry Finger:
>>> On 10/25/2010 01:44 PM, Arnd Hannemann wrote:
>>>> Am 25.10.2010 20:36, schrieb Larry Finger:
>>>>> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
>>>>>> Am 25.10.2010 17:32, schrieb Larry Finger:
>>>>>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
>>>>>>>> On todays linus tree the following compile error happened to me:
>>>>>>>>
>>>>>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
>>>>>>>> In file included from include/net/dst.h:11,
>>>>>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
>>>>>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
>>>>>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
>>>>>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
>>>>>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>>>> include/net/dst_ops.h: In function 'dst_entries_add':
>>>>>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>>>> include/net/dst_ops.h: In function 'dst_entries_init':
>>>>>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
>>>>>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
>>>>>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
>>>>>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>>>>>>>> make[2]: *** [drivers/net/wireless] Error 2
>>>>>>>> make[1]: *** [drivers/net] Error 2
>>>>>>>> make: *** [drivers] Error 2
>>>>>>>>
>>>>>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
>>>>>>>> "include/net/dst_ops.h".
>>>>>>>
>>>>>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
>>>>>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
>>>>>>
>>>>>> Exactly the same git describe here.
>>>>>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
>>>>>
>>>>> That probably makes the difference. Using Eric's fix that removes the #include
>>>>> <linux/dst.h> should be better. Does it work for you?
>>>>>
>>>>> There are probably a lot more of the system includes that may not be needed. If
>>>>> I send you a patch removing them, could you test?
>>>>
>>>> As it turns out my card is not supported by b43legacy, but compilation testing,
>>>> sure I can test that.
>>>
>>> If it is a Broadcom card, it is likely handled by b43.
>>
>> Yes. It seems it should work with b43 (its an SDIO card) and it almost does...
>>
>>> Attached is a trial removal of a number of include statements. Does it compile?
>>
>> Nope:
>> NSTALL_MOD_PATH=/home/arnd/projekte/renesas-2/nfs modules
>> CHK include/linux/version.h
>> CHK include/generated/utsrelease.h
>> make[1]: `include/generated/mach-types.h' is up to date.
>> CALL scripts/checksyscalls.sh
>> CC [M] drivers/net/wireless/b43legacy/main.o
>> drivers/net/wireless/b43legacy/main.c: In function 'b43legacy_upload_microcode':
>> drivers/net/wireless/b43legacy/main.c:1688: error: implicit declaration of function 'signal_pending'
>> make[4]: *** [drivers/net/wireless/b43legacy/main.o] Error 1
>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
>> make[2]: *** [drivers/net/wireless] Error 2
>> make[1]: *** [drivers/net] Error 2
>> make: *** [drivers] Error 2
>
> Is this issue resolved? Should I be expecting a b43 patch?
I don't know if a similar patch for b43 is needed. I tried to set up a cross
compiler for ARM. My initial attempt failed and I did not have time to explore
the situation. If anyone has links to a cross-compiler solution for x86_64 on
openSUSE, please let me know.
Larry
^ permalink raw reply
* [PATCH] neigh: reorder struct neighbour
From: Eric Dumazet @ 2010-11-11 16:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev
It is important to move nud_state outside of the often modified cache
line (because of refcnt), to reduce false sharing in neigh_event_send()
This is a followup of commit 0ed8ddf4045f (neigh: Protect neigh->ha[]
with a seqlock)
This gives a 7% speedup on routing test with IP route cache disabled.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
David, it appears I forgot to push this patch, I have it in my tree
since one month. Thanks !
include/net/neighbour.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 55590ab..815b2ce 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -96,16 +96,16 @@ struct neighbour {
struct neigh_parms *parms;
unsigned long confirmed;
unsigned long updated;
- __u8 flags;
- __u8 nud_state;
- __u8 type;
- __u8 dead;
+ rwlock_t lock;
atomic_t refcnt;
struct sk_buff_head arp_queue;
struct timer_list timer;
unsigned long used;
atomic_t probes;
- rwlock_t lock;
+ __u8 flags;
+ __u8 nud_state;
+ __u8 type;
+ __u8 dead;
seqlock_t ha_lock;
unsigned char ha[ALIGN(MAX_ADDR_LEN, sizeof(unsigned long))];
struct hh_cache *hh;
^ permalink raw reply related
* Re: [PATCH] macvlan: lockless tx path
From: Eric Dumazet @ 2010-11-11 16:56 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4CDC1C9A.3070102@candelatech.com>
Le jeudi 11 novembre 2010 à 08:40 -0800, Ben Greear a écrit :
> So, they assume counters are exactly 32 or 64 bits.
> Your example of the 36-bit counter would break their
> assumptions of 32 or 64 bits.
>
They 'assume'. I am not. How do you handle counters that suddenly go to
0 ?
> I agree that you can guess if the counter is 32 or 64, at least with today's
> hardware and relatively normal poll times, and the requirement that the
> counters can ONLY be 32 or 64 bits. I still consider it a kludge to
> return 32 bit counters in stats64, however. Would you consider
> a patch to have netlink pay attention to whether the stats are 32 or
> 64 (based on a flag returned from dev_get_stats perhaps)?
So what ? How is it going to help /proc/net/dev users (most apps use it)
Could you please adapt your software, and not adapt linux to your
needs ? Dont your software runs on linux 2.6.32 ?
^ permalink raw reply
* Re: [PATCH] macvlan: lockless tx path
From: Ben Greear @ 2010-11-11 16:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1289459012.17691.1001.camel@edumazet-laptop>
On 11/10/2010 11:03 PM, Eric Dumazet wrote:
> Le mercredi 10 novembre 2010 à 15:46 -0800, Ben Greear a écrit :
>> On 11/10/2010 03:36 PM, Eric Dumazet wrote:
>>> Le mercredi 10 novembre 2010 à 14:53 -0800, Ben Greear a écrit :
>>>
>>>> I did similar, and then wrote extra code to detect a 64-bit kernel and if
>>>> so assume that the counters wrap at 64 bits so I didn't have to poll so
>>>> often to make sure I didn't miss a wrap for a 10G NIC. If instead one wraps at 33
>>>> bits and the other at 36, there is no way for me to deal with the wrap
>>>> properly w/out explicitly knowing about that 33 and 36.
>>>>
>>>
>>> How do you define 'wrap around' ? Maybe your definition is wrong.
>>
>> Maybe so. My algorithm looks like:
>>
>> // uint64 accum;
>> // uint32 old;
>> // uint32 new;
>> if (old> new) {
>> // This assumes counters wrap at 32 bits (ie, 0xFFFFFFFF).
>> accum += ((uint32)(0xFFFFFFFF) - old) + new;
>> }
>> else if (old< new) {
>> accum += new - old;
>> }
>> old = new;
>>
>> ...
>>
>> Is there some way I can do this w/out the (0xFFFFFFFF - old),
>> and thus the assumption of 32-bit counters?
>>
>
> Yes, please take a look at RRD for an example, then you can adapt to
> your needs.
>
> <quote>
>
> http://www.mrtg.org/rrdtool/tut/rrdtutorial.en.html
>
> At the time of writing this document, RRDtool knows of counters that are
> either 32 bits or 64 bits of size. These counters can handle the
> following different values:
>
> - 32 bits: 0 .. 4294967295
> - 64 bits: 0 .. 18446744073709551615
>
> If these numbers look strange to you, you can view them in their
> hexadecimal form:
>
> - 32 bits: 0 .. FFFFFFFF
> - 64 bits: 0 .. FFFFFFFFFFFFFFFF
>
> RRDtool handles both counters the same. If an overflow occurs and the
> delta would be negative, RRDtool first adds the maximum of a small
> counter + 1 to the delta. If the delta is still negative, it had to be
> the large counter that wrapped. Add the maximum possible value of the
> large counter + 1 and subtract the erroneously added small value.
>
> There is a risk in this: suppose the large counter wrapped while adding
> a huge delta, it could happen, theoretically, that adding the smaller
> value would make the delta positive. In this unlikely case the results
> would not be correct. The increase should be nearly as high as the
> maximum counter value for that to happen, so chances are you would have
> several other problems as well and this particular problem would not
> even be worth thinking about. Even though, I did include an example, so
> you can judge for yourself.
So, they assume counters are exactly 32 or 64 bits.
Your example of the 36-bit counter would break their
assumptions of 32 or 64 bits.
I agree that you can guess if the counter is 32 or 64, at least with today's
hardware and relatively normal poll times, and the requirement that the
counters can ONLY be 32 or 64 bits. I still consider it a kludge to
return 32 bit counters in stats64, however. Would you consider
a patch to have netlink pay attention to whether the stats are 32 or
64 (based on a flag returned from dev_get_stats perhaps)?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net: b43legacy: fix compile error
From: John W. Linville @ 2010-11-11 16:35 UTC (permalink / raw)
To: Arnd Hannemann
Cc: Larry Finger, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet
In-Reply-To: <4CC5E4D2.6080606-BCMAnToX5e2ELgA04lAiVw@public.gmane.org>
On Mon, Oct 25, 2010 at 10:13:06PM +0200, Arnd Hannemann wrote:
> Am 25.10.2010 20:59, schrieb Larry Finger:
> > On 10/25/2010 01:44 PM, Arnd Hannemann wrote:
> >> Am 25.10.2010 20:36, schrieb Larry Finger:
> >>> On 10/25/2010 01:26 PM, Arnd Hannemann wrote:
> >>>> Am 25.10.2010 17:32, schrieb Larry Finger:
> >>>>> On 10/25/2010 09:41 AM, Arnd Hannemann wrote:
> >>>>>> On todays linus tree the following compile error happened to me:
> >>>>>>
> >>>>>> CC [M] drivers/net/wireless/b43legacy/xmit.o
> >>>>>> In file included from include/net/dst.h:11,
> >>>>>> from drivers/net/wireless/b43legacy/xmit.c:31:
> >>>>>> include/net/dst_ops.h:28: error: expected ':', ',', ';', '}' or '__attribute__' before '____cacheline_aligned_in_smp'
> >>>>>> include/net/dst_ops.h: In function 'dst_entries_get_fast':
> >>>>>> include/net/dst_ops.h:33: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>> include/net/dst_ops.h: In function 'dst_entries_get_slow':
> >>>>>> include/net/dst_ops.h:41: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>> include/net/dst_ops.h: In function 'dst_entries_add':
> >>>>>> include/net/dst_ops.h:49: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>> include/net/dst_ops.h: In function 'dst_entries_init':
> >>>>>> include/net/dst_ops.h:55: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>> include/net/dst_ops.h: In function 'dst_entries_destroy':
> >>>>>> include/net/dst_ops.h:60: error: 'struct dst_ops' has no member named 'pcpuc_entries'
> >>>>>> make[4]: *** [drivers/net/wireless/b43legacy/xmit.o] Error 1
> >>>>>> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
> >>>>>> make[2]: *** [drivers/net/wireless] Error 2
> >>>>>> make[1]: *** [drivers/net] Error 2
> >>>>>> make: *** [drivers] Error 2
> >>>>>>
> >>>>>> This patch fixes this issue by adding "linux/cache.h" as an include to
> >>>>>> "include/net/dst_ops.h".
> >>>>>
> >>>>> Strange. Compiling b43legacy from the linux-2.6.git tree (git describe is
> >>>>> v2.6.36-4464-g229aebb) works fine on x86_64. I wonder what is different.
> >>>>
> >>>> Exactly the same git describe here.
> >>>> Maybe your arch includes cache.h already, in my case its a compile for ARM (shmobile).
> >>>
> >>> That probably makes the difference. Using Eric's fix that removes the #include
> >>> <linux/dst.h> should be better. Does it work for you?
> >>>
> >>> There are probably a lot more of the system includes that may not be needed. If
> >>> I send you a patch removing them, could you test?
> >>
> >> As it turns out my card is not supported by b43legacy, but compilation testing,
> >> sure I can test that.
> >
> > If it is a Broadcom card, it is likely handled by b43.
>
> Yes. It seems it should work with b43 (its an SDIO card) and it almost does...
>
> > Attached is a trial removal of a number of include statements. Does it compile?
>
> Nope:
> NSTALL_MOD_PATH=/home/arnd/projekte/renesas-2/nfs modules
> CHK include/linux/version.h
> CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
> CALL scripts/checksyscalls.sh
> CC [M] drivers/net/wireless/b43legacy/main.o
> drivers/net/wireless/b43legacy/main.c: In function 'b43legacy_upload_microcode':
> drivers/net/wireless/b43legacy/main.c:1688: error: implicit declaration of function 'signal_pending'
> make[4]: *** [drivers/net/wireless/b43legacy/main.o] Error 1
> make[3]: *** [drivers/net/wireless/b43legacy] Error 2
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
Is this issue resolved? Should I be expecting a b43 patch?
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] SUNRPC: Simplify rpc_alloc_iostats by removing pointless local variable
From: Chuck Lever @ 2010-11-11 15:57 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
J. Bruce Fields, Neil Brown, Trond Myklebust, David S. Miller,
Andrew Morton
In-Reply-To: <alpine.LNX.2.00.1011102229370.625-h2p7t3/P30RzeRGmFJ5qR7ZzlVVXadcDXqFh9Ls21Oc@public.gmane.org>
On Nov 10, 2010, at 4:32 PM, Jesper Juhl wrote:
> On Sun, 7 Nov 2010, Jesper Juhl wrote:
>
>> Hi,
>>
>> We can simplify net/sunrpc/stats.c::rpc_alloc_iostats() a bit by getting
>> rid of the unneeded local variable 'new'.
>>
>>
>> Please CC me on replies.
>>
>>
>> Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
>> ---
>> stats.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git
>> a/net/sunrpc/stats.c b/net/sunrpc/stats.c
>> index f71a731..80df89d 100644
>> --- a/net/sunrpc/stats.c
>> +++ b/net/sunrpc/stats.c
>> @@ -115,9 +115,7 @@ EXPORT_SYMBOL_GPL(svc_seq_show);
>> */
>> struct rpc_iostats *rpc_alloc_iostats(struct rpc_clnt *clnt)
>> {
>> - struct rpc_iostats *new;
>> - new = kcalloc(clnt->cl_maxproc, sizeof(struct rpc_iostats), GFP_KERNEL);
>> - return new;
>> + return kcalloc(clnt->cl_maxproc, sizeof(struct rpc_iostats), GFP_KERNEL);
>> }
>> EXPORT_SYMBOL_GPL(rpc_alloc_iostats);
>>
>>
>>
>
> Ok, no response to this for a couple of days.
> Is there some problem or did it just get missed?
> Could someone merge this and push it up-stream, please, if there are no
> problems with it...
The NFS maintainer is traveling.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Kernel rwlock design, Multicore and IGMP
From: Eric Dumazet @ 2010-11-11 15:32 UTC (permalink / raw)
To: Cypher Wu; +Cc: linux-kernel, netdev
In-Reply-To: <1289489007.17691.1310.camel@edumazet-laptop>
Le jeudi 11 novembre 2010 à 16:23 +0100, Eric Dumazet a écrit :
> Le jeudi 11 novembre 2010 à 21:49 +0800, Cypher Wu a écrit :
>
> Hi
>
> CC netdev, since you ask questions about network stuff _and_ rwlock
>
>
> > I'm using TILEPro and its rwlock in kernel is a liitle different than
> > other platforms. It have a priority for write lock that when tried it
> > will block the following read lock even if read lock is hold by
> > others. Its code can be read in Linux Kernel 2.6.36 in
> > arch/tile/lib/spinlock_32.c.
>
> This seems a bug to me.
>
> read_lock() can be nested. We used such a schem in the past in iptables
> (it can re-enter itself),
> and we used instead a spinlock(), but with many discussions with lkml
> and Linus himself if I remember well.
I meant, a percpu spinlock, and extra logic to spin_lock() it one time,
even if nested.
static inline void xt_info_rdlock_bh(void)
{
struct xt_info_lock *lock;
local_bh_disable();
lock = &__get_cpu_var(xt_info_locks);
if (likely(!lock->readers++))
spin_lock(&lock->lock);
}
static inline void xt_info_rdunlock_bh(void)
{
struct xt_info_lock *lock = &__get_cpu_var(xt_info_locks);
if (likely(!--lock->readers))
spin_unlock(&lock->lock);
local_bh_enable();
}
The write 'rwlock' side has to lock the percpu spinlock of all possible
cpus.
/*
* The "writer" side needs to get exclusive access to the lock,
* regardless of readers. This must be called with bottom half
* processing (and thus also preemption) disabled.
*/
static inline void xt_info_wrlock(unsigned int cpu)
{
spin_lock(&per_cpu(xt_info_locks, cpu).lock);
}
static inline void xt_info_wrunlock(unsigned int cpu)
{
spin_unlock(&per_cpu(xt_info_locks, cpu).lock);
}
^ permalink raw reply
* Re: Kernel rwlock design, Multicore and IGMP
From: Eric Dumazet @ 2010-11-11 15:23 UTC (permalink / raw)
To: Cypher Wu; +Cc: linux-kernel, netdev
In-Reply-To: <AANLkTikvT=x9eBovn2-m6HLqk7wyXSAR3sc9jCQ0C6mL@mail.gmail.com>
Le jeudi 11 novembre 2010 à 21:49 +0800, Cypher Wu a écrit :
Hi
CC netdev, since you ask questions about network stuff _and_ rwlock
> I'm using TILEPro and its rwlock in kernel is a liitle different than
> other platforms. It have a priority for write lock that when tried it
> will block the following read lock even if read lock is hold by
> others. Its code can be read in Linux Kernel 2.6.36 in
> arch/tile/lib/spinlock_32.c.
This seems a bug to me.
read_lock() can be nested. We used such a schem in the past in iptables
(it can re-enter itself),
and we used instead a spinlock(), but with many discussions with lkml
and Linus himself if I remember well.
>
> That different could cause a deadlock in kernel if we join/leave
> Multicast Group simultaneous and frequently on mutlicores. IGMP
> message is sent by
>
> igmp_ifc_timer_expire() -> igmpv3_send_cr() -> igmpv3_sendpack()
>
> in timer interrupt, igmpv3_send_cr() will generate the sk_buff for
> IGMP message with mc_list_lock read locked and then call
> igmpv3_sendpack() with it unlocked.
> But if we have so many join/leave messages have to generate and it
> can't be sent in one sk_buff then igmpv3_send_cr() -> add_grec() will
> call igmpv3_sendpack() to send it and reallocate a new buffer. When
> the message is sent:
>
> __mkroute_output() -> ip_check_mc()
>
> will read lock mc_list_lock again. If there is another core is try
> write lock mc_list_lock between the two read lock, then deadlock
> ocurred.
>
> The rwlock on other platforms I've check, say, PowerPC, x86, ARM, is
> just read lock shared and write_lock mutex, so if we've hold read lock
> the write lock will just wait, and if there have a read lock again it
> will success.
>
> So, What's the criteria of rwlock design in the Linux kernel? Is that
> read lock re-hold of IGMP a design error in Linux kernel, or the read
> lock has to be design like that?
>
Well, we try to get rid of all rwlocks in performance critical sections.
I would say, if you believe one rwlock can justify the special TILE
behavior you tried to make, then we should instead migrate this rwlock
to a RCU + spinlock schem (so that all arches benefit from this work,
not only TILE)
> There is a other thing, that the timer interrupt will start timer on
> the same in_dev, should that be optimized?
>
Not sure I understand what you mean.
> BTW: If we have so many cores, say 64, is there other things we have
> to think about spinlock? If there have collisions ocurred, should we
> just read the shared memory again and again, or just a very little
> 'delay' is better? I've seen relax() is called in the implementation
> of spinlock on TILEPro platform.
> --
Is TILE using ticket spinlocks ?
^ permalink raw reply
* [PATCH 12/12] vxge: update driver version
From: Jon Mason @ 2010-11-11 14:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
Update vxge driver version
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/vxge/vxge-version.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxge/vxge-version.h b/drivers/net/vxge/vxge-version.h
index b4eced1..f05bb2f 100644
--- a/drivers/net/vxge/vxge-version.h
+++ b/drivers/net/vxge/vxge-version.h
@@ -16,8 +16,8 @@
#define VXGE_VERSION_MAJOR "2"
#define VXGE_VERSION_MINOR "0"
-#define VXGE_VERSION_FIX "9"
-#define VXGE_VERSION_BUILD "20840"
+#define VXGE_VERSION_FIX "10"
+#define VXGE_VERSION_BUILD "21808"
#define VXGE_VERSION_FOR "k"
#define VXGE_FW_VER(maj, min, bld) (((maj) << 16) + ((min) << 8) + (bld))
--
1.7.0.4
^ permalink raw reply related
* [PATCH 11/12] vxge: sparse and other clean-ups
From: Jon Mason @ 2010-11-11 14:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur
Correct issues found by running sparse on the vxge driver, as well as
other miscellaneous cleanups.
Signed-off-by: Jon Mason <jon.mason@exar.com>
---
drivers/net/vxge/vxge-config.c | 100 +++++++++------------------------------
drivers/net/vxge/vxge-ethtool.c | 35 +++++--------
drivers/net/vxge/vxge-main.c | 94 +++++++++++++++---------------------
3 files changed, 76 insertions(+), 153 deletions(-)
diff --git a/drivers/net/vxge/vxge-config.c b/drivers/net/vxge/vxge-config.c
index 14dc8c8..409c2e6 100644
--- a/drivers/net/vxge/vxge-config.c
+++ b/drivers/net/vxge/vxge-config.c
@@ -22,19 +22,6 @@
#include "vxge-main.h"
static enum vxge_hw_status
-__vxge_hw_fifo_create(
- struct __vxge_hw_vpath_handle *vpath_handle,
- struct vxge_hw_fifo_attr *attr);
-
-static enum vxge_hw_status
-__vxge_hw_fifo_abort(
- struct __vxge_hw_fifo *fifoh);
-
-static enum vxge_hw_status
-__vxge_hw_fifo_reset(
- struct __vxge_hw_fifo *ringh);
-
-static enum vxge_hw_status
__vxge_hw_fifo_delete(
struct __vxge_hw_vpath_handle *vpath_handle);
@@ -72,44 +59,15 @@ __vxge_hw_blockpool_free(struct __vxge_hw_device *hldev,
u32 size,
struct vxge_hw_mempool_dma *dma_object);
-
-static struct __vxge_hw_channel*
-__vxge_hw_channel_allocate(struct __vxge_hw_vpath_handle *vph,
- enum __vxge_hw_channel_type type, u32 length,
- u32 per_dtr_space, void *userdata);
-
static void
__vxge_hw_channel_free(
struct __vxge_hw_channel *channel);
-static enum vxge_hw_status
-__vxge_hw_channel_initialize(
- struct __vxge_hw_channel *channel);
-
-static enum vxge_hw_status
-__vxge_hw_channel_reset(
- struct __vxge_hw_channel *channel);
-
static enum vxge_hw_status __vxge_hw_ring_delete(struct __vxge_hw_vpath_handle *vp);
static enum vxge_hw_status
-__vxge_hw_device_fifo_config_check(struct vxge_hw_fifo_config *fifo_config);
-
-static enum vxge_hw_status
__vxge_hw_device_config_check(struct vxge_hw_device_config *new_config);
-static void
-__vxge_hw_device_host_info_get(struct __vxge_hw_device *hldev);
-
-static enum vxge_hw_status
-__vxge_hw_device_initialize(struct __vxge_hw_device *hldev);
-
-static void
-__vxge_hw_device_pci_e_init(struct __vxge_hw_device *hldev);
-
-static enum vxge_hw_status
-__vxge_hw_device_reg_addr_get(struct __vxge_hw_device *hldev);
-
static enum vxge_hw_status
__vxge_hw_device_register_poll(
void __iomem *reg,
@@ -130,9 +88,10 @@ __vxge_hw_pio_mem_write64(u64 val64, void __iomem *addr,
static struct vxge_hw_mempool*
__vxge_hw_mempool_create(struct __vxge_hw_device *devh, u32 memblock_size,
- u32 item_size, u32 private_size, u32 items_initial,
- u32 items_max, struct vxge_hw_mempool_cbs *mp_callback,
- void *userdata);
+ u32 item_size, u32 private_size, u32 items_initial,
+ u32 items_max, struct vxge_hw_mempool_cbs *mp_callback,
+ void *userdata);
+
static void __vxge_hw_mempool_destroy(struct vxge_hw_mempool *mempool);
static enum vxge_hw_status
@@ -145,24 +104,10 @@ vxge_hw_vpath_stats_enable(struct __vxge_hw_vpath_handle *vpath_handle);
static enum vxge_hw_status
__vxge_hw_legacy_swapper_set(struct vxge_hw_legacy_reg __iomem *legacy_reg);
-static enum vxge_hw_status
-__vxge_hw_vpath_reset_check(struct __vxge_hw_virtualpath *vpath);
-
-
-static enum vxge_hw_status
-__vxge_hw_vpath_sw_reset(struct __vxge_hw_device *devh, u32 vp_id);
-
-static enum vxge_hw_status
-__vxge_hw_vpath_mac_configure(struct __vxge_hw_device *devh, u32 vp_id);
-
static void
__vxge_hw_vp_terminate(struct __vxge_hw_device *devh, u32 vp_id);
static enum vxge_hw_status
-__vxge_hw_vpath_stats_access(struct __vxge_hw_virtualpath *vpath,
- u32 operation, u32 offset, u64 *stat);
-
-static enum vxge_hw_status
__vxge_hw_vpath_xmac_tx_stats_get(struct __vxge_hw_virtualpath *vpath,
struct vxge_hw_xmac_vpath_tx_stats *vpath_tx_stats);
@@ -505,7 +450,7 @@ vxge_hw_vpath_eprom_img_ver_get(struct __vxge_hw_device *hldev,
* This function allocates required memory for the channel and various arrays
* in the channel
*/
-struct __vxge_hw_channel*
+static struct __vxge_hw_channel *
__vxge_hw_channel_allocate(struct __vxge_hw_vpath_handle *vph,
enum __vxge_hw_channel_type type,
u32 length, u32 per_dtr_space, void *userdata)
@@ -576,7 +521,7 @@ exit0:
* This function deallocates memory from the channel and various arrays
* in the channel
*/
-void __vxge_hw_channel_free(struct __vxge_hw_channel *channel)
+static void __vxge_hw_channel_free(struct __vxge_hw_channel *channel)
{
kfree(channel->work_arr);
kfree(channel->free_arr);
@@ -590,7 +535,7 @@ void __vxge_hw_channel_free(struct __vxge_hw_channel *channel)
* This function initializes a channel by properly setting the
* various references
*/
-enum vxge_hw_status
+static enum vxge_hw_status
__vxge_hw_channel_initialize(struct __vxge_hw_channel *channel)
{
u32 i;
@@ -625,7 +570,7 @@ __vxge_hw_channel_initialize(struct __vxge_hw_channel *channel)
* __vxge_hw_channel_reset - Resets a channel
* This function resets a channel by properly setting the various references
*/
-enum vxge_hw_status
+static enum vxge_hw_status
__vxge_hw_channel_reset(struct __vxge_hw_channel *channel)
{
u32 i;
@@ -652,8 +597,7 @@ __vxge_hw_channel_reset(struct __vxge_hw_channel *channel)
* Initialize certain PCI/PCI-X configuration registers
* with recommended values. Save config space for future hw resets.
*/
-void
-__vxge_hw_device_pci_e_init(struct __vxge_hw_device *hldev)
+static void __vxge_hw_device_pci_e_init(struct __vxge_hw_device *hldev)
{
u16 cmd = 0;
@@ -742,7 +686,7 @@ exit:
* register location pointers in the device object. It waits until the ric is
* completed initializing registers.
*/
-enum vxge_hw_status
+static enum vxge_hw_status
__vxge_hw_device_reg_addr_get(struct __vxge_hw_device *hldev)
{
u64 val64;
@@ -938,7 +882,8 @@ __vxge_hw_verify_pci_e_info(struct __vxge_hw_device *hldev)
* __vxge_hw_device_initialize
* Initialize Titan-V hardware.
*/
-enum vxge_hw_status __vxge_hw_device_initialize(struct __vxge_hw_device *hldev)
+static enum vxge_hw_status
+__vxge_hw_device_initialize(struct __vxge_hw_device *hldev)
{
enum vxge_hw_status status = VXGE_HW_OK;
@@ -2337,7 +2282,7 @@ static void __vxge_hw_mempool_destroy(struct vxge_hw_mempool *mempool)
* __vxge_hw_device_fifo_config_check - Check fifo configuration.
* Check the fifo configuration
*/
-enum vxge_hw_status
+static enum vxge_hw_status
__vxge_hw_device_fifo_config_check(struct vxge_hw_fifo_config *fifo_config)
{
if ((fifo_config->fifo_blocks < VXGE_HW_MIN_FIFO_BLOCKS) ||
@@ -2385,7 +2330,7 @@ __vxge_hw_device_vpath_config_check(struct vxge_hw_vp_config *vp_config)
* __vxge_hw_device_config_check - Check device configuration.
* Check the device configuration
*/
-enum vxge_hw_status
+static enum vxge_hw_status
__vxge_hw_device_config_check(struct vxge_hw_device_config *new_config)
{
u32 i;
@@ -2945,7 +2890,7 @@ __vxge_hw_fifo_mempool_item_alloc(
* __vxge_hw_fifo_create - Create a FIFO
* This function creates FIFO and initializes it.
*/
-enum vxge_hw_status
+static enum vxge_hw_status
__vxge_hw_fifo_create(struct __vxge_hw_vpath_handle *vp,
struct vxge_hw_fifo_attr *attr)
{
@@ -3109,7 +3054,8 @@ static enum vxge_hw_status __vxge_hw_fifo_reset(struct __vxge_hw_fifo *fifo)
* __vxge_hw_fifo_delete - Removes the FIFO
* This function freeup the memory pool and removes the FIFO
*/
-enum vxge_hw_status __vxge_hw_fifo_delete(struct __vxge_hw_vpath_handle *vp)
+static enum vxge_hw_status
+__vxge_hw_fifo_delete(struct __vxge_hw_vpath_handle *vp)
{
struct __vxge_hw_fifo *fifo = vp->vpath->fifoh;
@@ -4897,7 +4843,7 @@ static void vxge_os_dma_free(struct pci_dev *pdev, const void *vaddr,
* __vxge_hw_blockpool_create - Create block pool
*/
-enum vxge_hw_status
+static enum vxge_hw_status
__vxge_hw_blockpool_create(struct __vxge_hw_device *hldev,
struct __vxge_hw_blockpool *blockpool,
u32 pool_size,
@@ -4997,7 +4943,7 @@ blockpool_create_exit:
* __vxge_hw_blockpool_destroy - Deallocates the block pool
*/
-void __vxge_hw_blockpool_destroy(struct __vxge_hw_blockpool *blockpool)
+static void __vxge_hw_blockpool_destroy(struct __vxge_hw_blockpool *blockpool)
{
struct __vxge_hw_device *hldev;
@@ -5163,7 +5109,7 @@ exit:
* Allocates a block of memory of given size, either from block pool
* or by calling vxge_os_dma_malloc()
*/
-void *
+static void *
__vxge_hw_blockpool_malloc(struct __vxge_hw_device *devh, u32 size,
struct vxge_hw_mempool_dma *dma_object)
{
@@ -5227,7 +5173,7 @@ exit:
* __vxge_hw_blockpool_free - Frees the memory allcoated with
__vxge_hw_blockpool_malloc
*/
-void
+static void
__vxge_hw_blockpool_free(struct __vxge_hw_device *devh,
void *memblock, u32 size,
struct vxge_hw_mempool_dma *dma_object)
@@ -5279,7 +5225,7 @@ __vxge_hw_blockpool_free(struct __vxge_hw_device *devh,
* __vxge_hw_blockpool_block_allocate - Allocates a block from block pool
* This function allocates a block from block pool or from the system
*/
-struct __vxge_hw_blockpool_entry *
+static struct __vxge_hw_blockpool_entry *
__vxge_hw_blockpool_block_allocate(struct __vxge_hw_device *devh, u32 size)
{
struct __vxge_hw_blockpool_entry *entry = NULL;
@@ -5314,7 +5260,7 @@ __vxge_hw_blockpool_block_allocate(struct __vxge_hw_device *devh, u32 size)
*
* This function frees a block from block pool
*/
-void
+static void
__vxge_hw_blockpool_block_free(struct __vxge_hw_device *devh,
struct __vxge_hw_blockpool_entry *entry)
{
diff --git a/drivers/net/vxge/vxge-ethtool.c b/drivers/net/vxge/vxge-ethtool.c
index 3d2cd6a..09f721e 100644
--- a/drivers/net/vxge/vxge-ethtool.c
+++ b/drivers/net/vxge/vxge-ethtool.c
@@ -11,7 +11,7 @@
* Virtualized Server Adapter.
* Copyright(c) 2002-2010 Exar Corp.
******************************************************************************/
-#include<linux/ethtool.h>
+#include <linux/ethtool.h>
#include <linux/slab.h>
#include <linux/pci.h>
#include <linux/etherdevice.h>
@@ -29,7 +29,6 @@
* Return value:
* 0 on success.
*/
-
static int vxge_ethtool_sset(struct net_device *dev, struct ethtool_cmd *info)
{
/* We currently only support 10Gb/FULL */
@@ -79,10 +78,9 @@ static int vxge_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)
* Returns driver specefic information like name, version etc.. to ethtool.
*/
static void vxge_ethtool_gdrvinfo(struct net_device *dev,
- struct ethtool_drvinfo *info)
+ struct ethtool_drvinfo *info)
{
- struct vxgedev *vdev;
- vdev = (struct vxgedev *)netdev_priv(dev);
+ struct vxgedev *vdev = (struct vxgedev *)netdev_priv(dev);
strlcpy(info->driver, VXGE_DRIVER_NAME, sizeof(VXGE_DRIVER_NAME));
strlcpy(info->version, DRV_VERSION, sizeof(DRV_VERSION));
strlcpy(info->fw_version, vdev->fw_version, VXGE_HW_FW_STRLEN);
@@ -104,15 +102,14 @@ static void vxge_ethtool_gdrvinfo(struct net_device *dev,
* buffer area.
*/
static void vxge_ethtool_gregs(struct net_device *dev,
- struct ethtool_regs *regs, void *space)
+ struct ethtool_regs *regs, void *space)
{
int index, offset;
enum vxge_hw_status status;
u64 reg;
- u64 *reg_space = (u64 *) space;
+ u64 *reg_space = (u64 *)space;
struct vxgedev *vdev = (struct vxgedev *)netdev_priv(dev);
- struct __vxge_hw_device *hldev = (struct __vxge_hw_device *)
- pci_get_drvdata(vdev->pdev);
+ struct __vxge_hw_device *hldev = vdev->devh;
regs->len = sizeof(struct vxge_hw_vpath_reg) * vdev->no_of_vpath;
regs->version = vdev->pdev->subsystem_device;
@@ -148,8 +145,7 @@ static void vxge_ethtool_gregs(struct net_device *dev,
static int vxge_ethtool_idnic(struct net_device *dev, u32 data)
{
struct vxgedev *vdev = (struct vxgedev *)netdev_priv(dev);
- struct __vxge_hw_device *hldev = (struct __vxge_hw_device *)
- pci_get_drvdata(vdev->pdev);
+ struct __vxge_hw_device *hldev = vdev->devh;
vxge_hw_device_flick_link_led(hldev, VXGE_FLICKER_ON);
msleep_interruptible(data ? (data * HZ) : VXGE_MAX_FLICKER_TIME);
@@ -168,11 +164,10 @@ static int vxge_ethtool_idnic(struct net_device *dev, u32 data)
* void
*/
static void vxge_ethtool_getpause_data(struct net_device *dev,
- struct ethtool_pauseparam *ep)
+ struct ethtool_pauseparam *ep)
{
struct vxgedev *vdev = (struct vxgedev *)netdev_priv(dev);
- struct __vxge_hw_device *hldev = (struct __vxge_hw_device *)
- pci_get_drvdata(vdev->pdev);
+ struct __vxge_hw_device *hldev = vdev->devh;
vxge_hw_device_getpause_data(hldev, 0, &ep->tx_pause, &ep->rx_pause);
}
@@ -188,11 +183,10 @@ static void vxge_ethtool_getpause_data(struct net_device *dev,
* int, returns 0 on Success
*/
static int vxge_ethtool_setpause_data(struct net_device *dev,
- struct ethtool_pauseparam *ep)
+ struct ethtool_pauseparam *ep)
{
struct vxgedev *vdev = (struct vxgedev *)netdev_priv(dev);
- struct __vxge_hw_device *hldev = (struct __vxge_hw_device *)
- pci_get_drvdata(vdev->pdev);
+ struct __vxge_hw_device *hldev = vdev->devh;
vxge_hw_device_setpause_data(hldev, 0, ep->tx_pause, ep->rx_pause);
@@ -209,9 +203,8 @@ static void vxge_get_ethtool_stats(struct net_device *dev,
enum vxge_hw_status status;
enum vxge_hw_status swstatus;
struct vxge_vpath *vpath = NULL;
-
struct vxgedev *vdev = (struct vxgedev *)netdev_priv(dev);
- struct __vxge_hw_device *hldev = vdev->devh;
+ struct __vxge_hw_device *hldev = vdev->devh;
struct vxge_hw_xmac_stats *xmac_stats;
struct vxge_hw_device_stats_sw_info *sw_stats;
struct vxge_hw_device_stats_hw_info *hw_stats;
@@ -574,8 +567,8 @@ static void vxge_get_ethtool_stats(struct net_device *dev,
kfree(hw_stats);
}
-static void vxge_ethtool_get_strings(struct net_device *dev,
- u32 stringset, u8 *data)
+static void vxge_ethtool_get_strings(struct net_device *dev, u32 stringset,
+ u8 *data)
{
int stat_size = 0;
int i, j;
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index b8806a1..3f2d6ed 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -688,7 +688,7 @@ static int vxge_learn_mac(struct vxgedev *vdev, u8 *mac_header)
struct vxge_vpath *vpath = NULL;
struct __vxge_hw_device *hldev;
- hldev = (struct __vxge_hw_device *) pci_get_drvdata(vdev->pdev);
+ hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
mac_address = (u8 *)&mac_addr;
memcpy(mac_address, mac_header, ETH_ALEN);
@@ -1112,7 +1112,7 @@ static void vxge_set_multicast(struct net_device *dev)
/* Delete previous MC's */
for (i = 0; i < mcast_cnt; i++) {
list_for_each_safe(entry, next, list_head) {
- mac_entry = (struct vxge_mac_addrs *) entry;
+ mac_entry = (struct vxge_mac_addrs *)entry;
/* Copy the mac address to delete */
mac_address = (u8 *)&mac_entry->macaddr;
memcpy(mac_info.macaddr, mac_address, ETH_ALEN);
@@ -1155,7 +1155,7 @@ _set_all_mcast:
/* Delete previous MC's */
for (i = 0; i < mcast_cnt; i++) {
list_for_each_safe(entry, next, list_head) {
- mac_entry = (struct vxge_mac_addrs *) entry;
+ mac_entry = (struct vxge_mac_addrs *)entry;
/* Copy the mac address to delete */
mac_address = (u8 *)&mac_entry->macaddr;
memcpy(mac_info.macaddr, mac_address, ETH_ALEN);
@@ -1202,7 +1202,7 @@ static int vxge_set_mac_addr(struct net_device *dev, void *p)
{
struct sockaddr *addr = p;
struct vxgedev *vdev;
- struct __vxge_hw_device *hldev;
+ struct __vxge_hw_device *hldev;
enum vxge_hw_status status = VXGE_HW_OK;
struct macInfo mac_info_new, mac_info_old;
int vpath_idx = 0;
@@ -1632,7 +1632,7 @@ static int vxge_poll_inta(struct napi_struct *napi, int budget)
int budget_org = budget;
struct vxge_ring *ring;
- struct __vxge_hw_device *hldev = (struct __vxge_hw_device *)
+ struct __vxge_hw_device *hldev = (struct __vxge_hw_device *)
pci_get_drvdata(vdev->pdev);
for (i = 0; i < vdev->no_of_vpath; i++) {
@@ -1669,7 +1669,7 @@ static int vxge_poll_inta(struct napi_struct *napi, int budget)
*/
static void vxge_netpoll(struct net_device *dev)
{
- struct __vxge_hw_device *hldev;
+ struct __vxge_hw_device *hldev;
struct vxgedev *vdev;
vdev = (struct vxgedev *)netdev_priv(dev);
@@ -1821,7 +1821,7 @@ static int vxge_mac_list_del(struct vxge_vpath *vpath, struct macInfo *mac)
{
struct list_head *entry, *next;
u64 del_mac = 0;
- u8 *mac_address = (u8 *) (&del_mac);
+ u8 *mac_address = (u8 *)(&del_mac);
/* Copy the mac address to delete from the list */
memcpy(mac_address, mac->macaddr, ETH_ALEN);
@@ -2102,7 +2102,7 @@ static irqreturn_t vxge_isr_napi(int irq, void *dev_id)
struct __vxge_hw_device *hldev;
u64 reason;
enum vxge_hw_status status;
- struct vxgedev *vdev = (struct vxgedev *) dev_id;;
+ struct vxgedev *vdev = (struct vxgedev *)dev_id;
vxge_debug_intr(VXGE_TRACE, "%s:%d", __func__, __LINE__);
@@ -2341,8 +2341,8 @@ static void vxge_rem_msix_isr(struct vxgedev *vdev)
static void vxge_rem_isr(struct vxgedev *vdev)
{
- struct __vxge_hw_device *hldev;
- hldev = (struct __vxge_hw_device *) pci_get_drvdata(vdev->pdev);
+ struct __vxge_hw_device *hldev;
+ hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
#ifdef CONFIG_PCI_MSI
if (vdev->config.intr_type == MSI_X) {
@@ -2583,7 +2583,7 @@ vxge_open(struct net_device *dev)
"%s: %s:%d", dev->name, __func__, __LINE__);
vdev = (struct vxgedev *)netdev_priv(dev);
- hldev = (struct __vxge_hw_device *) pci_get_drvdata(vdev->pdev);
+ hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
function_mode = vdev->config.device_hw_info.function_mode;
/* make sure you have link off by default every time Nic is
@@ -2811,7 +2811,7 @@ static int do_vxge_close(struct net_device *dev, int do_io)
dev->name, __func__, __LINE__);
vdev = (struct vxgedev *)netdev_priv(dev);
- hldev = (struct __vxge_hw_device *) pci_get_drvdata(vdev->pdev);
+ hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
if (unlikely(!is_vxge_card_up(vdev)))
return 0;
@@ -3440,36 +3440,29 @@ _out0:
*
* This function will unregister and free network device
*/
-static void
-vxge_device_unregister(struct __vxge_hw_device *hldev)
+static void vxge_device_unregister(struct __vxge_hw_device *hldev)
{
struct vxgedev *vdev;
struct net_device *dev;
char buf[IFNAMSIZ];
-#if ((VXGE_DEBUG_INIT & VXGE_DEBUG_MASK) || \
- (VXGE_DEBUG_ENTRYEXIT & VXGE_DEBUG_MASK))
- u32 level_trace;
-#endif
dev = hldev->ndev;
vdev = netdev_priv(dev);
-#if ((VXGE_DEBUG_INIT & VXGE_DEBUG_MASK) || \
- (VXGE_DEBUG_ENTRYEXIT & VXGE_DEBUG_MASK))
- level_trace = vdev->level_trace;
-#endif
- vxge_debug_entryexit(level_trace,
- "%s: %s:%d", vdev->ndev->name, __func__, __LINE__);
- memcpy(buf, vdev->ndev->name, IFNAMSIZ);
+ vxge_debug_entryexit(vdev->level_trace, "%s: %s:%d", vdev->ndev->name,
+ __func__, __LINE__);
+
+ memcpy(buf, dev->name, IFNAMSIZ);
/* in 2.6 will call stop() if device is up */
unregister_netdev(dev);
flush_scheduled_work();
- vxge_debug_init(level_trace, "%s: ethernet device unregistered", buf);
- vxge_debug_entryexit(level_trace,
- "%s: %s:%d Exiting...", buf, __func__, __LINE__);
+ vxge_debug_init(vdev->level_trace, "%s: ethernet device unregistered",
+ buf);
+ vxge_debug_entryexit(vdev->level_trace, "%s: %s:%d Exiting...", buf,
+ __func__, __LINE__);
}
/*
@@ -3992,8 +3985,8 @@ static int vxge_pm_resume(struct pci_dev *pdev)
static pci_ers_result_t vxge_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
{
- struct __vxge_hw_device *hldev =
- (struct __vxge_hw_device *) pci_get_drvdata(pdev);
+ struct __vxge_hw_device *hldev =
+ (struct __vxge_hw_device *)pci_get_drvdata(pdev);
struct net_device *netdev = hldev->ndev;
netif_device_detach(netdev);
@@ -4022,8 +4015,8 @@ static pci_ers_result_t vxge_io_error_detected(struct pci_dev *pdev,
*/
static pci_ers_result_t vxge_io_slot_reset(struct pci_dev *pdev)
{
- struct __vxge_hw_device *hldev =
- (struct __vxge_hw_device *) pci_get_drvdata(pdev);
+ struct __vxge_hw_device *hldev =
+ (struct __vxge_hw_device *)pci_get_drvdata(pdev);
struct net_device *netdev = hldev->ndev;
struct vxgedev *vdev = netdev_priv(netdev);
@@ -4048,8 +4041,8 @@ static pci_ers_result_t vxge_io_slot_reset(struct pci_dev *pdev)
*/
static void vxge_io_resume(struct pci_dev *pdev)
{
- struct __vxge_hw_device *hldev =
- (struct __vxge_hw_device *) pci_get_drvdata(pdev);
+ struct __vxge_hw_device *hldev =
+ (struct __vxge_hw_device *)pci_get_drvdata(pdev);
struct net_device *netdev = hldev->ndev;
if (netif_running(netdev)) {
@@ -4243,7 +4236,7 @@ static int vxge_probe_fw_update(struct vxgedev *vdev)
static int __devinit
vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
{
- struct __vxge_hw_device *hldev;
+ struct __vxge_hw_device *hldev;
enum vxge_hw_status status;
int ret;
int high_dma = 0;
@@ -4689,34 +4682,25 @@ _exit0:
* Description: This function is called by the Pci subsystem to release a
* PCI device and free up all resource held up by the device.
*/
-static void __devexit
-vxge_remove(struct pci_dev *pdev)
+static void __devexit vxge_remove(struct pci_dev *pdev)
{
- struct __vxge_hw_device *hldev;
+ struct __vxge_hw_device *hldev;
struct vxgedev *vdev = NULL;
struct net_device *dev;
int i = 0;
-#if ((VXGE_DEBUG_INIT & VXGE_DEBUG_MASK) || \
- (VXGE_DEBUG_ENTRYEXIT & VXGE_DEBUG_MASK))
- u32 level_trace;
-#endif
- hldev = (struct __vxge_hw_device *) pci_get_drvdata(pdev);
+ hldev = (struct __vxge_hw_device *)pci_get_drvdata(pdev);
if (hldev == NULL)
return;
+
dev = hldev->ndev;
vdev = netdev_priv(dev);
-#if ((VXGE_DEBUG_INIT & VXGE_DEBUG_MASK) || \
- (VXGE_DEBUG_ENTRYEXIT & VXGE_DEBUG_MASK))
- level_trace = vdev->level_trace;
-#endif
- vxge_debug_entryexit(level_trace,
- "%s:%d", __func__, __LINE__);
+ vxge_debug_entryexit(vdev->level_trace, "%s:%d", __func__, __LINE__);
- vxge_debug_init(level_trace,
- "%s : removing PCI device...", __func__);
+ vxge_debug_init(vdev->level_trace, "%s : removing PCI device...",
+ __func__);
vxge_device_unregister(hldev);
for (i = 0; i < vdev->no_of_vpath; i++) {
@@ -4734,16 +4718,16 @@ vxge_remove(struct pci_dev *pdev)
/* we are safe to free it now */
free_netdev(dev);
- vxge_debug_init(level_trace,
- "%s:%d Device unregistered", __func__, __LINE__);
+ vxge_debug_init(vdev->level_trace, "%s:%d Device unregistered",
+ __func__, __LINE__);
vxge_hw_device_terminate(hldev);
pci_disable_device(pdev);
pci_release_regions(pdev);
pci_set_drvdata(pdev, NULL);
- vxge_debug_entryexit(level_trace,
- "%s:%d Exiting...", __func__, __LINE__);
+ vxge_debug_entryexit(vdev->level_trace, "%s:%d Exiting...", __func__,
+ __LINE__);
}
static struct pci_error_handlers vxge_err_handler = {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 10/12] vxge: update Kconfig
From: Jon Mason @ 2010-11-11 14:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
Update Kconfig to reflect Exar's purchase of Neterion (formerly S2IO).
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/Kconfig | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f6668cd..fa62a63 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2772,29 +2772,38 @@ config IXGB
will be called ixgb.
config S2IO
- tristate "S2IO 10Gbe XFrame NIC"
+ tristate "Exar Xframe 10Gb Ethernet Adapter"
depends on PCI
---help---
- This driver supports the 10Gbe XFrame NIC of S2IO.
+ This driver supports Exar Corp's Xframe Series 10Gb Ethernet Adapters.
+
More specific information on configuring the driver is in
<file:Documentation/networking/s2io.txt>.
+ To compile this driver as a module, choose M here. The module
+ will be called s2io.
+
config VXGE
- tristate "Neterion X3100 Series 10GbE PCIe Server Adapter"
+ tristate "Exar X3100 Series 10GbE PCIe Server Adapter"
depends on PCI && INET
---help---
- This driver supports Neterion Inc's X3100 Series 10 GbE PCIe
+ This driver supports Exar Corp's X3100 Series 10 GbE PCIe
I/O Virtualized Server Adapter.
+
More specific information on configuring the driver is in
<file:Documentation/networking/vxge.txt>.
+ To compile this driver as a module, choose M here. The module
+ will be called vxge.
+
config VXGE_DEBUG_TRACE_ALL
bool "Enabling All Debug trace statments in driver"
default n
depends on VXGE
---help---
Say Y here if you want to enabling all the debug trace statements in
- driver. By default only few debug trace statements are enabled.
+ the vxge driver. By default only few debug trace statements are
+ enabled.
config MYRI10GE
tristate "Myricom Myri-10G Ethernet support"
--
1.7.0.4
^ permalink raw reply related
* [PATCH 09/12] vxge: correct multi-function detection
From: Jon Mason @ 2010-11-11 14:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
The values used to determined if the adapter is running in single or
multi-function mode were previously modified to the values necessary
when making the VXGE_HW_FW_API_GET_FUNC_MODE firmware call. However,
the firmware call was not modified. This had the driver printing out on
probe that the adapter was in multi-function mode when in single
function mode and vice versa.
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/vxge/vxge-config.c | 6 +++---
drivers/net/vxge/vxge-reg.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxge/vxge-config.c b/drivers/net/vxge/vxge-config.c
index 5903b2e..14dc8c8 100644
--- a/drivers/net/vxge/vxge-config.c
+++ b/drivers/net/vxge/vxge-config.c
@@ -1091,16 +1091,16 @@ __vxge_hw_vpath_pci_func_mode_get(struct __vxge_hw_virtualpath *vpath,
u64 data0, data1 = 0, steer_ctrl = 0;
enum vxge_hw_status status;
- data0 = VXGE_HW_RTS_ACCESS_STEER_DATA0_MEMO_ITEM_PCI_MODE;
+ data0 = 0;
status = vxge_hw_vpath_fw_api(vpath,
- VXGE_HW_RTS_ACCESS_STEER_CTRL_ACTION_READ_MEMO_ENTRY,
+ VXGE_HW_FW_API_GET_FUNC_MODE,
VXGE_HW_RTS_ACCESS_STEER_CTRL_DATA_STRUCT_SEL_FW_MEMO,
0, &data0, &data1, &steer_ctrl);
if (status != VXGE_HW_OK)
return status;
- hw_info->function_mode = data0;
+ hw_info->function_mode = VXGE_HW_GET_FUNC_MODE_VAL(data0);
return status;
}
diff --git a/drivers/net/vxge/vxge-reg.h b/drivers/net/vxge/vxge-reg.h
index 0df52db..3e658b1 100644
--- a/drivers/net/vxge/vxge-reg.h
+++ b/drivers/net/vxge/vxge-reg.h
@@ -62,6 +62,9 @@
#define VXGE_HW_GET_EPROM_IMAGE_REV(val) vxge_bVALn(val, 48, 16)
#define VXGE_HW_RTS_ACCESS_STEER_ROM_IMAGE_INDEX(val) vxge_vBIT(val, 16, 8)
+#define VXGE_HW_FW_API_GET_FUNC_MODE 29
+#define VXGE_HW_GET_FUNC_MODE_VAL(val) (val & 0xFF)
+
#define VXGE_HW_FW_UPGRADE_MEMO 13
#define VXGE_HW_FW_UPGRADE_ACTION 16
#define VXGE_HW_FW_UPGRADE_OFFSET_START 2
--
1.7.0.4
^ permalink raw reply related
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