* [PATCH 0/4] generic netlink namespace awareness
From: Johannes Berg @ 2009-07-10 19:51 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, tgraf-G/eBtMaohhA,
Eric W. Biederman
This patch series makes generic netlink network namespace
aware, in some way, paving the way for making wireless
completely netns aware (which I will submit to John's tree).
The required changes are basically some preparations in
core netlink, a change to make it possible to iterate net
namespaces under just RCU (which may be useful elsewhere in
the future), the actual genetlink patch and finally also
exporting get_net_ns_by_pid() which wireless will need.
The last patch (for get_net_ns_by_pid) could go through
the wireless tree as well, but I've put it in here since
it touches core code. The others probably shouldn't go
through the wireless tree since they touch more than that.
The first patch in this series fixes the last remaining
problem I had with the generic netlink one, the patches
are actually unchanged from the previous submission other
than adding patch 1 in front.
johannes
--
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
* [PATCH] netlink: remove unused exports
From: Johannes Berg @ 2009-07-10 18:32 UTC (permalink / raw)
To: netdev; +Cc: Thomas Graf
I added those myself in commits b4ff4f04 and 84659eb5,
but I see no reason now why they should be exported,
only generic netlink uses them which cannot be modular.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/netlink/af_netlink.c | 2 --
1 file changed, 2 deletions(-)
--- wireless-testing.orig/net/netlink/af_netlink.c 2009-07-10 20:21:46.000000000 +0200
+++ wireless-testing/net/netlink/af_netlink.c 2009-07-10 20:26:28.000000000 +0200
@@ -1575,7 +1575,6 @@ int netlink_change_ngroups(struct sock *
kfree(old);
return err;
}
-EXPORT_SYMBOL(netlink_change_ngroups);
/**
* netlink_clear_multicast_users - kick off multicast listeners
@@ -1598,7 +1597,6 @@ void netlink_clear_multicast_users(struc
netlink_table_ungrab();
}
-EXPORT_SYMBOL(netlink_clear_multicast_users);
void netlink_set_nonroot(int protocol, unsigned int flags)
{
^ permalink raw reply
* Re: Using Wireless Extensions in a Kernel Module
From: Marcel Holtmann @ 2009-07-10 16:39 UTC (permalink / raw)
To: Tim Schneider; +Cc: netdev, Johannes Berg
In-Reply-To: <A353FA76-7D71-425F-BD67-FEE6DC26EF6F@cs.uni-bonn.de>
Hi Tim,
> I am trying to write a Kernel Module with an implementation of a new
> TCP-Algorithm. Since I need to know the RSSI-Value (Received Signal
> Strength indication) of the sent package, I extended the Pluggable
> Congestion Control Mechanism by a new function which is called right
> after the package is send. At that point, I need to read the RSSI-Value.
>
> I'm now trying to somehow access that value, but I can't figure out
> how. I've come as far, that I found out about the Wirelless
> Extensions, which seem to be very promising. In the header file the
> author states, that this mechanism can be used by both user-space apps
> and kernel modules. Unfortunately nobody seems to ever have used it in
> kernel space, since I can't find any documentations about it.
>
> I would be very glad, if somebody could give me link to a page
> containing informations about this topic, or even just a hint that
> could help me.
we are in the process of killing Wireless Extensions (WEXT) and
replacing it with a netlink based cfg80211/nl80211 interface. The better
mailing list is linux-wireless@vger.kernel.org for such questions.
Regards
Marcel
^ permalink raw reply
* CONGRATULATION WINNER
From: Web Draw @ 2009-07-10 16:04 UTC (permalink / raw)
To: info
£450,000.00 has been award to you in the Microsoft Prize,send us your Naames/Tel/Addresas/Country). for your claim prinnket.graffin7@btinternet.com
^ permalink raw reply
* Re: [PATCH net-2.6] Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits
From: Stephen Hemminger @ 2009-07-10 15:29 UTC (permalink / raw)
To: David Miller
Cc: jarkao2, pstaszewski, robert, Robert.Olsson, jorge, dada1,
robert.olsson, netdev
In-Reply-To: <20090630.124849.167332569.davem@davemloft.net>
On Tue, 30 Jun 2009 12:48:49 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Mon, 29 Jun 2009 10:58:20 +0000
>
> > On Mon, Jun 29, 2009 at 11:51:52AM +0200, Paweł Staszewski wrote:
> >> I apply this patch
> >>
> >> fib_triestats in attached file :)
> >>
> >>> ------------------->
> >>> ipv4: Fix fib_trie rebalancing, part 3
> >>>
> >>> Alas current delaying of freeing old tnodes by RCU in trie_rebalance
> >>> is still not enough because we can free a top tnode before updating a
> >>> t->trie pointer.
> >>>
> >>> Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
> >>> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> >>> ---
> >
> > David, I guess you could add:
> >
> > Tested-by: Pawel Staszewski <pstaszewski@itcare.pl>
>
> Done, and applied, thanks Jarek.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
This is probably in kernel bugzilla as well, so someone should
update:
http://bugzilla.kernel.org/show_bug.cgi?id=6648
--
^ permalink raw reply
* Re: iproute2: adding /128 address to sit interface borks
From: Stephen Hemminger @ 2009-07-10 15:27 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Stephen Hemminger, netdev
In-Reply-To: <alpine.LSU.2.00.0907101402430.21999@fbirervta.pbzchgretzou.qr>
On Fri, 10 Jul 2009 14:05:01 +0200 (CEST)
Jan Engelhardt <jengelh@medozas.de> wrote:
> Hi,
>
>
> it's impossible to do this, and the error message does not say why
> that is so. No word in dmesg either.
>
>
> # ip a a fc00::49/128 peer fc00::7 dev sit7
> RTNETLINK answers: Invalid argument
You will need to walk through the path in the kernel.
In worst case, it means adding kernel printk's.
Then if you want to be nice, make a patch to ipaddr.c in iproute
utilities so command line can find the error before passing to
kernel and give a nice error :-)
--
^ permalink raw reply
* Re: [regression] ath5k: Overrides regulatory domain set for cfg80211
From: Luis R. Rodriguez @ 2009-07-10 15:24 UTC (permalink / raw)
To: Frans Pop; +Cc: linux-wireless, netdev, Linux Kernel Mailing List
In-Reply-To: <200907101343.14113.elendil@planet.nl>
On Fri, Jul 10, 2009 at 4:43 AM, Frans Pop<elendil@planet.nl> wrote:
>> >> For further information please also read
>> >> Documentation/feature-removal-schedule.txt. Please use a valid
>> >> ISO-3166 alpha2 country code, I also advise to abandon the usage of
>> >> the ieee80211_regdom module parameter which we do eventually intend
>> >> on deprecating and if you know anyone using that please suggest the
>> >> same.
>> >
>> > As mentioned above I do not currently have the option of abandoning
>> > it.
>>
>> Yes you do, but you don't seem to want to do anything beyond what your
>> distribution offers, which is different.
>
> You're right :-)
> However, I am also a Debian Developer and Debian may (just as we did for
> Etch), at some point want to offer a newer kernel than the current .26
> for stable (possibly .31).
That'd be nice!
> From that PoV it is important to ensure there
> are no incompatibilities with what's in Debian stable.
And there shouldn't be.
Side note:
I'd suggest to disable OLD_REG and provide crda and iw on your shiny
new kernel. In the absence of crda you still have a really good world
regulatory domain with good world roaming capabilities. For setting
the regulatory domain you can look at what Fedora folks did with the
timezone info until the desktop catches up (geoclue and whatever).
> For that reason I am very conservative when it comes to installer newer or
> backported versions of packages.
Sure.
>> > That seems particularly bad in my case. For some weird reason this
>> > Trust PCMCIA card seems to have AM in its EEPROM, which is Armenia...
>> > The card was bought in the Netherlands (NL), which is also where I
>> > live.
>>
>> Yeah the short story of that is Armenia and Netherlands both have the
>> same regulatory rules, the first alpha2 that matched the same group
>> was picked up, which just so happened to be Armenia. In the future it
>> will be easier if cards are just programmed with the alpha2 country
>> code or with a world regulatory domain code, and just abandon the
>> grouping idea. That is something we will have to look forward to
>> change and promote for future device. What counts for regulatory
>> purposes is your device is complaint. The alternative was to keep all
>> the regulatory information statically in the kernel for each
>> regulatory group for Atheros devices.
>
> Ah! I had no idea about that and I guess that this is the real issue here:
> a simple usability problem. If I had seen the correct countrycode (NL
> instead of AM), I probably never would have reported a regression. What
> prompted my mail was that, from a user PoV, the country being selected
> looked to be completely broken. How am I, as a simple user, supposed to
> know that Armenia uses the same domain as the Netherlands and that what
> the driver is doing is actually 100% correct (and even that my PCMCIA
> card is not as broken as I thought)?
Yeah, its a good point.
> Would it be possible to improve the info presented by the kernel? Maybe
> print an extra line with a list of countries that use the selected reg
> domain (depends I guess on what's the max. nr. of countries that share a
> domain). Or at least indicate that the country code is a somewhat random
> choice.
Perhaps an informative "group regulatory domain" printk may make
sense, you're right.
>> > I can to some extend understand respecting hardware settings for APs,
>> > but for a wireless NIC it seems a useless limitation.
>>
>> You are right to a certain degree. The thing is wireless cards *can*
>> be used as APs on a regular desktops. Perhaps not with iwlagn, but
>> with ath5k and ath9k you can do AP, IBSS, Mesh, all of which actually
>> do start transmit with out any AP being around. For these cases you
>> *do* need to ensure proper regulatory compliance. And we haven't even
>> touched on DFS!
>
> Well, IIUC you do know what mode the card is being used in, so in theory
> you could distinguish between them. I'm not pushing for that though.
>
> End conclusion is that there is no regression and no backwards
> compatibility issue (which is good news), just a usability issue.
Yup.
Luis
^ permalink raw reply
* Re: weird problem
From: Jarek Poplawski @ 2009-07-10 14:47 UTC (permalink / raw)
To: Paweł Staszewski
Cc: Eric Dumazet, Eric Dumazet, Linux Network Development list
In-Reply-To: <4A568444.7010307@itcare.pl>
On Fri, Jul 10, 2009 at 01:59:00AM +0200, Paweł Staszewski wrote:
> Today i make other tests with change of
> /proc/sys/net/ipv4/rt_cache_rebuild_count and kernel 2.6.30.1
>
> And when rt_cache_rebuild_count is set to "-1" i have always load on
> x86_64 machine approx 40-50% of each cpu where network card is binded by
> irq_aff
>
> when rt_cache_rebuild_count is set to more than "-1" i have 15 to 20 sec
> of 1 to 3% cpu and after 40-50% cpu
...
Here is one more patch for testing (with caution!). It adds possibility
to turn off cache disabling (so it should even more resemble 2.6.28)
after setting: rt_cache_rebuild_count = 0
I'd like you to try this patch:
1) together with the previous patch and "rt_cache_rebuild_count = 0"
to check if there is still the difference wrt. 2.6.28; Btw., let
me know which /proc/sys/net/ipv4/route/* settings do you need to
change and why
2) alone (without the previous patch) and "rt_cache_rebuild_count = 0"
3) if it's possible to try 2.6.30.1 without these patches, but with
default /proc/sys/net/ipv4/route/* settings, and higher
rt_cache_rebuild_count, e.g. 100; I'm interested if/how long it
takes to trigger higher cpu load and the warning "... rebuilds is
over limit, route caching disabled"; (Btw., I wonder why you didn't
mention about these or maybe also other route caching warnings?)
Regards,
Jarek P.
--- (debugging patch #2; apply to 2.6.30.1 or 2.6.29.6)
net/ipv4/route.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 278f46f..3d183cb 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1181,12 +1181,18 @@ restart:
} else {
if (chain_length > rt_chain_length_max) {
struct net *net = dev_net(rt->u.dst.dev);
- int num = ++net->ipv4.current_rt_cache_rebuild_count;
- if (!rt_caching(dev_net(rt->u.dst.dev))) {
- printk(KERN_WARNING "%s: %d rebuilds is over limit, route caching disabled\n",
- rt->u.dst.dev->name, num);
+
+ if (net->ipv4.sysctl_rt_cache_rebuild_count > 0) {
+ int num = ++net->ipv4.current_rt_cache_rebuild_count;
+
+ if (!rt_caching(net))
+ printk(KERN_WARNING
+ "%s: %d rebuilds is over limit, "
+ "route caching disabled\n",
+ rt->u.dst.dev->name, num);
+
+ rt_emergency_hash_rebuild(net);
}
- rt_emergency_hash_rebuild(dev_net(rt->u.dst.dev));
}
}
^ permalink raw reply related
* iproute2: adding /128 address to sit interface borks
From: Jan Engelhardt @ 2009-07-10 12:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Hi,
it's impossible to do this, and the error message does not say why
that is so. No word in dmesg either.
# ip a a fc00::49/128 peer fc00::7 dev sit7
RTNETLINK answers: Invalid argument
^ permalink raw reply
* Re: [regression] ath5k: Overrides regulatory domain set for cfg80211
From: Frans Pop @ 2009-07-10 11:43 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List
In-Reply-To: <43e72e890907081907j279f48eep99e73cc2951dfdb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Thanks again for your elaborate explanation Louis.
On Thursday 09 July 2009, Luis R. Rodriguez wrote:
> EU is a valid regulatory domain only when the relic option
> CONFIG_WIRELESS_OLD_REGULATORY is used. When you use OLD_REG and "EU"
> you get stuck to a statically defined regulatory domain in the kernel.
>
> > [Now I specify NL and it gives me US; how's that an improvement?]
>
> Since you are using OLD_REG the default is "US", that was the behavior
> prior to the new regulatory code so its left as is. So that is by
> design following the old crap regulatory code design.
>
> > cfg80211: Calling CRDA for country: NL
> > [no agent, so this does not actually change anything]
>
> Users of OLD_REG who do not have new userspace should stick to using
> the 3 static regulatory domains:
>
> 1) US *
> 2) JP
> 3) EU
Right, so the EU I had originally was correct after all :-)
> >> For further information please also read
> >> Documentation/feature-removal-schedule.txt. Please use a valid
> >> ISO-3166 alpha2 country code, I also advise to abandon the usage of
> >> the ieee80211_regdom module parameter which we do eventually intend
> >> on deprecating and if you know anyone using that please suggest the
> >> same.
> >
> > As mentioned above I do not currently have the option of abandoning
> > it.
>
> Yes you do, but you don't seem to want to do anything beyond what your
> distribution offers, which is different.
You're right :-)
However, I am also a Debian Developer and Debian may (just as we did for
Etch), at some point want to offer a newer kernel than the current .26
for stable (possibly .31). From that PoV it is important to ensure there
are no incompatibilities with what's in Debian stable.
For that reason I am very conservative when it comes to installer newer or
backported versions of packages.
> > That seems particularly bad in my case. For some weird reason this
> > Trust PCMCIA card seems to have AM in its EEPROM, which is Armenia...
> > The card was bought in the Netherlands (NL), which is also where I
> > live.
>
> Yeah the short story of that is Armenia and Netherlands both have the
> same regulatory rules, the first alpha2 that matched the same group
> was picked up, which just so happened to be Armenia. In the future it
> will be easier if cards are just programmed with the alpha2 country
> code or with a world regulatory domain code, and just abandon the
> grouping idea. That is something we will have to look forward to
> change and promote for future device. What counts for regulatory
> purposes is your device is complaint. The alternative was to keep all
> the regulatory information statically in the kernel for each
> regulatory group for Atheros devices.
Ah! I had no idea about that and I guess that this is the real issue here:
a simple usability problem. If I had seen the correct countrycode (NL
instead of AM), I probably never would have reported a regression. What
prompted my mail was that, from a user PoV, the country being selected
looked to be completely broken. How am I, as a simple user, supposed to
know that Armenia uses the same domain as the Netherlands and that what
the driver is doing is actually 100% correct (and even that my PCMCIA
card is not as broken as I thought)?
Would it be possible to improve the info presented by the kernel? Maybe
print an extra line with a list of countries that use the selected reg
domain (depends I guess on what's the max. nr. of countries that share a
domain). Or at least indicate that the country code is a somewhat random
choice.
> > I can to some extend understand respecting hardware settings for APs,
> > but for a wireless NIC it seems a useless limitation.
>
> You are right to a certain degree. The thing is wireless cards *can*
> be used as APs on a regular desktops. Perhaps not with iwlagn, but
> with ath5k and ath9k you can do AP, IBSS, Mesh, all of which actually
> do start transmit with out any AP being around. For these cases you
> *do* need to ensure proper regulatory compliance. And we haven't even
> touched on DFS!
Well, IIUC you do know what mode the card is being used in, so in theory
you could distinguish between them. I'm not pushing for that though.
End conclusion is that there is no regression and no backwards
compatibility issue (which is good news), just a usability issue.
Thanks,
FJP
--
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] IPVS: Add handling of incoming ICMPV6_PKT_TOOBIG messages
From: Simon Horman @ 2009-07-10 9:56 UTC (permalink / raw)
To: Julius Volz; +Cc: lvs-devel, netdev, robert.gallagher
In-Reply-To: <43ca39800907020743v1ccc1979o5a934d5ead05edc9@mail.gmail.com>
On Thu, Jul 02, 2009 at 04:43:39PM +0200, Julius Volz wrote:
> Hi Simon,
>
> On Sun, Jun 28, 2009 at 5:43 PM, Simon Horman<horms@verge.net.au> wrote:
> > On Wed, Jun 24, 2009 at 03:22:32PM +0200, Julius Volz wrote:
> >> Add handling of incoming ICMPv6 Packet Too Big messages. This message
> >> is received when a realserver sends a packet >PMTU to the client. The
> >> hop on this path with insufficient MTU will generate an ICMPv6 Packet
> >> Too Big message back to the VIP. The LVS server receives this message,
> >> but the call to the function handling this has been missing. Thus, IPVS
> >> fails to forward the message to the real server, which then does not
> >> adjust the path MTU. This patch adds the missing call to
> >> ip_vs_in_icmp_v6() in ip_vs_in() to handle this situation.
> >>
> >> Thanks to Rob Gallagher from HEAnet for reporting this issue and for
> >> testing this patch in production (with direct routing mode).
> >>
> >> Signed-off-by: Julius Volz <julius.volz@gmail.com>
> >> Tested-by: Rob Gallagher <robert.gallagher@heanet.ie>
> >
> > Hi Julius, Hi Rob,
> >
> > this seems reasonable to me, although it seems that the following
> > code is common. I wonder if its repetition could be removed.
> >
> > if (related)
> > return verdict;
> > ip_vs_fill_iphdr(af, skb_network_header(skb), &iph);
>
> I agree, though I see no "nice" way to remove this duplication
> considering the ifs and #ifdefs around this. You could move the
> related and verdict variables to the top of the function and then
> recheck afterwards whether one of these ICMP-handling branches was
> entered and put the common code in there. But this seems more
> cumbersome to me than repeating the code. Maybe you see a nicer way?
> Btw., exactly this structure already exists in ip_vs_out(), which is
> why I adopted it like this for ip_vs_in().
Hi Julius,
sorry for the delay in responding, I've been off-line / recovering from
being off-line.
I couldn't see an obvious way either, though I was hoping that
you might :-) As you can't I'm happy to go with what you originally
posted.
Acked-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* Using Wireless Extensions in a Kernel Module
From: Tim Schneider @ 2009-07-10 9:23 UTC (permalink / raw)
To: netdev
Hi,
I am trying to write a Kernel Module with an implementation of a new
TCP-Algorithm. Since I need to know the RSSI-Value (Received Signal
Strength indication) of the sent package, I extended the Pluggable
Congestion Control Mechanism by a new function which is called right
after the package is send. At that point, I need to read the RSSI-Value.
I'm now trying to somehow access that value, but I can't figure out
how. I've come as far, that I found out about the Wirelless
Extensions, which seem to be very promising. In the header file the
author states, that this mechanism can be used by both user-space apps
and kernel modules. Unfortunately nobody seems to ever have used it in
kernel space, since I can't find any documentations about it.
I would be very glad, if somebody could give me link to a page
containing informations about this topic, or even just a hint that
could help me.
Thank you
Tim Schneider
^ permalink raw reply
* Re: sk_lock: inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage
From: Herbert Xu @ 2009-07-10 8:02 UTC (permalink / raw)
To: Wu Fengguang
Cc: David Miller, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20090710080017.GA24168@localhost>
On Fri, Jul 10, 2009 at 04:00:17PM +0800, Wu Fengguang wrote:
>
> The (sk_allocation & ~__GFP_WAIT) cases should be rare, but I guess
> the networking code shall do it anyway, because sk_allocation defaults
> to GFP_KERNEL. It seems that currently the networking code simply uses
> a lot of GFP_ATOMIC, do they really mean "I cannot sleep"?
Yep because they're done from softirq context.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: sk_lock: inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage
From: Wu Fengguang @ 2009-07-10 8:00 UTC (permalink / raw)
To: David Miller
Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20090709.171355.09466097.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, Jul 10, 2009 at 08:13:55AM +0800, David Miller wrote:
> From: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Thu, 9 Jul 2009 21:17:46 +0800
>
> > @@ -2100,7 +2100,8 @@ void tcp_send_fin(struct sock *sk)
> > } else {
> > /* Socket is locked, keep trying until memory is available. */
> > for (;;) {
> > - skb = alloc_skb_fclone(MAX_TCP_HEADER, GFP_KERNEL);
> > + skb = alloc_skb_fclone(MAX_TCP_HEADER,
> > + sk->sk_allocation);
> > if (skb)
> > break;
> > yield();
>
> I think this specific case needs more thinking.
>
> If the allocation fails, and it's GFP_ATOMIC, we are going to yield()
> (which sleeps) and loop endlessly waiting for the allocation to
> succeed.
The _retried_ GFP_ATOMIC won't be much worse than GFP_KERNEL.
GFP_KERNEL can directly reclaim FS pages; GFP_ATOMIC will wake up
kswapd to do that. So after yield(), GFP_ATOMIC have good opportunity
to succeed if GFP_KERNEL could succeed.
The original GFP_KERNEL does have _a bit_ better chance to succeed,
but there are no guarantee. It could loop endlessly whether it be
GFP_KERNEL or GFP_ATOMIC.
btw, generally speaking, it would be more robust that NFS set
sk_allocation to GFP_NOIO, and let the networking code choose
whether to use plain sk_allocation or (sk_allocation & ~__GFP_WAIT).
The (sk_allocation & ~__GFP_WAIT) cases should be rare, but I guess
the networking code shall do it anyway, because sk_allocation defaults
to GFP_KERNEL. It seems that currently the networking code simply uses
a lot of GFP_ATOMIC, do they really mean "I cannot sleep"?
Thanks,
Fengguang
--
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
* [PATCH 2/2] netdev: restore MTU change operation
From: Ben Hutchings @ 2009-07-10 3:59 UTC (permalink / raw)
To: David Miller; +Cc: Stephen Hemminger, stable, netdev
[-- Attachment #1: Type: text/plain, Size: 6479 bytes --]
alloc_etherdev() used to install a default implementation of this
operation, but it must now be explicitly installed in struct
net_device_ops.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Sorry about the previous copy without S-o-b.
It's not clear that all these drivers should allow changing MTU, but
they apparently used to.
This is applicable to 2.6.30 except that fec.c does not need to be
changed.
Ben.
drivers/net/8139too.c | 1 +
drivers/net/arm/ixp4xx_eth.c | 1 +
drivers/net/ehea/ehea_main.c | 1 +
drivers/net/fec.c | 1 +
drivers/net/plip.c | 1 +
drivers/net/smc91x.c | 1 +
drivers/net/smsc911x.c | 1 +
drivers/net/sunvnet.c | 1 +
drivers/net/usb/kaweth.c | 1 +
drivers/net/usb/pegasus.c | 1 +
drivers/net/via-rhine.c | 1 +
11 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 8ae72ec..0e2ba21 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -908,6 +908,7 @@ static const struct net_device_ops rtl8139_netdev_ops = {
.ndo_open = rtl8139_open,
.ndo_stop = rtl8139_close,
.ndo_get_stats = rtl8139_get_stats,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = rtl8139_set_mac_address,
.ndo_start_xmit = rtl8139_start_xmit,
diff --git a/drivers/net/arm/ixp4xx_eth.c b/drivers/net/arm/ixp4xx_eth.c
index 87fde32..3fe0987 100644
--- a/drivers/net/arm/ixp4xx_eth.c
+++ b/drivers/net/arm/ixp4xx_eth.c
@@ -1142,6 +1142,7 @@ static const struct net_device_ops ixp4xx_netdev_ops = {
.ndo_start_xmit = eth_xmit,
.ndo_set_multicast_list = eth_set_mcast_list,
.ndo_do_ioctl = eth_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c7d1886..e8d46cc 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -3080,6 +3080,7 @@ static const struct net_device_ops ehea_netdev_ops = {
.ndo_poll_controller = ehea_netpoll,
#endif
.ndo_get_stats = ehea_get_stats,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = ehea_set_mac_addr,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_multicast_list = ehea_set_multicast_list,
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 0f19b74..d4b9807 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -1642,6 +1642,7 @@ static const struct net_device_ops fec_netdev_ops = {
.ndo_stop = fec_enet_close,
.ndo_start_xmit = fec_enet_start_xmit,
.ndo_set_multicast_list = set_multicast_list,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = fec_timeout,
.ndo_set_mac_address = fec_set_mac_address,
diff --git a/drivers/net/plip.c b/drivers/net/plip.c
index b79f776..2ca8b0d 100644
--- a/drivers/net/plip.c
+++ b/drivers/net/plip.c
@@ -270,6 +270,7 @@ static const struct net_device_ops plip_netdev_ops = {
.ndo_stop = plip_close,
.ndo_start_xmit = plip_tx_packet,
.ndo_do_ioctl = plip_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
index fdcbaf8..1c70e99 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -1774,6 +1774,7 @@ static const struct net_device_ops smc_netdev_ops = {
.ndo_start_xmit = smc_hard_start_xmit,
.ndo_tx_timeout = smc_timeout,
.ndo_set_multicast_list = smc_set_multicast_list,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index 66067f9..94b6d26 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -1779,6 +1779,7 @@ static const struct net_device_ops smsc911x_netdev_ops = {
.ndo_get_stats = smsc911x_get_stats,
.ndo_set_multicast_list = smsc911x_set_multicast_list,
.ndo_do_ioctl = smsc911x_do_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = smsc911x_set_mac_address,
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/sunvnet.c b/drivers/net/sunvnet.c
index bc74db0..f1e5e45 100644
--- a/drivers/net/sunvnet.c
+++ b/drivers/net/sunvnet.c
@@ -1016,6 +1016,7 @@ static const struct net_device_ops vnet_ops = {
.ndo_open = vnet_open,
.ndo_stop = vnet_close,
.ndo_set_multicast_list = vnet_set_rx_mode,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = vnet_set_mac_addr,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = vnet_tx_timeout,
diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c
index 238bea1..1f9ec29 100644
--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -999,6 +999,7 @@ static const struct net_device_ops kaweth_netdev_ops = {
.ndo_tx_timeout = kaweth_tx_timeout,
.ndo_set_multicast_list = kaweth_set_rx_mode,
.ndo_get_stats = kaweth_netdev_stats,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index 9bea2af..631d269 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -1493,6 +1493,7 @@ static const struct net_device_ops pegasus_netdev_ops = {
.ndo_set_multicast_list = pegasus_set_multicast,
.ndo_get_stats = pegasus_netdev_stats,
.ndo_tx_timeout = pegasus_tx_timeout,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index d3489a3..88c30a5 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -621,6 +621,7 @@ static const struct net_device_ops rhine_netdev_ops = {
.ndo_start_xmit = rhine_start_tx,
.ndo_get_stats = rhine_get_stats,
.ndo_set_multicast_list = rhine_set_rx_mode,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
.ndo_do_ioctl = netdev_ioctl,
--
1.6.3.3
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [PATCH 2/2] netdev: restore MTU change operation
From: Ben Hutchings @ 2009-07-10 3:57 UTC (permalink / raw)
To: David Miller; +Cc: Stephen Hemminger, stable, netdev
[-- Attachment #1: Type: text/plain, Size: 6377 bytes --]
alloc_etherdev() used to install a default implementation of this
operation, but it must now be explicitly installed in struct
net_device_ops.
---
It's not clear that all these drivers should allow changing MTU, but
they apparently used to.
This is applicable to 2.6.30 except that fec.c does not need to be
changed.
Ben.
drivers/net/8139too.c | 1 +
drivers/net/arm/ixp4xx_eth.c | 1 +
drivers/net/ehea/ehea_main.c | 1 +
drivers/net/fec.c | 1 +
drivers/net/plip.c | 1 +
drivers/net/smc91x.c | 1 +
drivers/net/smsc911x.c | 1 +
drivers/net/sunvnet.c | 1 +
drivers/net/usb/kaweth.c | 1 +
drivers/net/usb/pegasus.c | 1 +
drivers/net/via-rhine.c | 1 +
11 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 8ae72ec..0e2ba21 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -908,6 +908,7 @@ static const struct net_device_ops rtl8139_netdev_ops = {
.ndo_open = rtl8139_open,
.ndo_stop = rtl8139_close,
.ndo_get_stats = rtl8139_get_stats,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = rtl8139_set_mac_address,
.ndo_start_xmit = rtl8139_start_xmit,
diff --git a/drivers/net/arm/ixp4xx_eth.c b/drivers/net/arm/ixp4xx_eth.c
index 87fde32..3fe0987 100644
--- a/drivers/net/arm/ixp4xx_eth.c
+++ b/drivers/net/arm/ixp4xx_eth.c
@@ -1142,6 +1142,7 @@ static const struct net_device_ops ixp4xx_netdev_ops = {
.ndo_start_xmit = eth_xmit,
.ndo_set_multicast_list = eth_set_mcast_list,
.ndo_do_ioctl = eth_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c7d1886..e8d46cc 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -3080,6 +3080,7 @@ static const struct net_device_ops ehea_netdev_ops = {
.ndo_poll_controller = ehea_netpoll,
#endif
.ndo_get_stats = ehea_get_stats,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = ehea_set_mac_addr,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_multicast_list = ehea_set_multicast_list,
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 0f19b74..d4b9807 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -1642,6 +1642,7 @@ static const struct net_device_ops fec_netdev_ops = {
.ndo_stop = fec_enet_close,
.ndo_start_xmit = fec_enet_start_xmit,
.ndo_set_multicast_list = set_multicast_list,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = fec_timeout,
.ndo_set_mac_address = fec_set_mac_address,
diff --git a/drivers/net/plip.c b/drivers/net/plip.c
index b79f776..2ca8b0d 100644
--- a/drivers/net/plip.c
+++ b/drivers/net/plip.c
@@ -270,6 +270,7 @@ static const struct net_device_ops plip_netdev_ops = {
.ndo_stop = plip_close,
.ndo_start_xmit = plip_tx_packet,
.ndo_do_ioctl = plip_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
index fdcbaf8..1c70e99 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -1774,6 +1774,7 @@ static const struct net_device_ops smc_netdev_ops = {
.ndo_start_xmit = smc_hard_start_xmit,
.ndo_tx_timeout = smc_timeout,
.ndo_set_multicast_list = smc_set_multicast_list,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index 66067f9..94b6d26 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -1779,6 +1779,7 @@ static const struct net_device_ops smsc911x_netdev_ops = {
.ndo_get_stats = smsc911x_get_stats,
.ndo_set_multicast_list = smsc911x_set_multicast_list,
.ndo_do_ioctl = smsc911x_do_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = smsc911x_set_mac_address,
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/sunvnet.c b/drivers/net/sunvnet.c
index bc74db0..f1e5e45 100644
--- a/drivers/net/sunvnet.c
+++ b/drivers/net/sunvnet.c
@@ -1016,6 +1016,7 @@ static const struct net_device_ops vnet_ops = {
.ndo_open = vnet_open,
.ndo_stop = vnet_close,
.ndo_set_multicast_list = vnet_set_rx_mode,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = vnet_set_mac_addr,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = vnet_tx_timeout,
diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c
index 238bea1..1f9ec29 100644
--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -999,6 +999,7 @@ static const struct net_device_ops kaweth_netdev_ops = {
.ndo_tx_timeout = kaweth_tx_timeout,
.ndo_set_multicast_list = kaweth_set_rx_mode,
.ndo_get_stats = kaweth_netdev_stats,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index 9bea2af..631d269 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -1493,6 +1493,7 @@ static const struct net_device_ops pegasus_netdev_ops = {
.ndo_set_multicast_list = pegasus_set_multicast,
.ndo_get_stats = pegasus_netdev_stats,
.ndo_tx_timeout = pegasus_tx_timeout,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index d3489a3..88c30a5 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -621,6 +621,7 @@ static const struct net_device_ops rhine_netdev_ops = {
.ndo_start_xmit = rhine_start_tx,
.ndo_get_stats = rhine_get_stats,
.ndo_set_multicast_list = rhine_set_rx_mode,
+ .ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
.ndo_do_ioctl = netdev_ioctl,
--
1.6.3.3
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [PATCH 1/2] netdev: restore MAC address set and validate operations
From: Ben Hutchings @ 2009-07-10 3:54 UTC (permalink / raw)
To: David Miller; +Cc: Stephen Hemminger, stable, 536455, netdev
[-- Attachment #1: Type: text/plain, Size: 6489 bytes --]
alloc_etherdev() used to install default implementations of these
operations, but they must now be explicitly installed in struct
net_device_ops.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Stephen Hemminger caught most of these omissions. I think this covers
the rest.
This is applicable to 2.6.30 with small offsets in some files.
Ben.
drivers/net/arm/ixp4xx_eth.c | 3 ++-
drivers/net/ehea/ehea_main.c | 1 +
drivers/net/gianfar.c | 2 ++
drivers/net/plip.c | 2 ++
drivers/net/ps3_gelic_net.c | 1 +
drivers/net/ps3_gelic_wireless.c | 1 +
drivers/net/sunvnet.c | 1 +
drivers/net/usb/kaweth.c | 2 ++
drivers/net/usb/pegasus.c | 2 ++
drivers/net/wireless/orinoco/main.c | 3 ++-
10 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/arm/ixp4xx_eth.c b/drivers/net/arm/ixp4xx_eth.c
index 6f42ad7..87fde32 100644
--- a/drivers/net/arm/ixp4xx_eth.c
+++ b/drivers/net/arm/ixp4xx_eth.c
@@ -1142,7 +1142,8 @@ static const struct net_device_ops ixp4xx_netdev_ops = {
.ndo_start_xmit = eth_xmit,
.ndo_set_multicast_list = eth_set_mcast_list,
.ndo_do_ioctl = eth_ioctl,
-
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
};
static int __devinit eth_init_one(struct platform_device *pdev)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 147c4b0..c7d1886 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -3081,6 +3081,7 @@ static const struct net_device_ops ehea_netdev_ops = {
#endif
.ndo_get_stats = ehea_get_stats,
.ndo_set_mac_address = ehea_set_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
.ndo_set_multicast_list = ehea_set_multicast_list,
.ndo_change_mtu = ehea_change_mtu,
.ndo_vlan_rx_register = ehea_vlan_rx_register,
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 4ae1d25..43d813e 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -156,6 +156,8 @@ static const struct net_device_ops gfar_netdev_ops = {
.ndo_tx_timeout = gfar_timeout,
.ndo_do_ioctl = gfar_ioctl,
.ndo_vlan_rx_register = gfar_vlan_rx_register,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = gfar_netpoll,
#endif
diff --git a/drivers/net/plip.c b/drivers/net/plip.c
index 7a62f78..b79f776 100644
--- a/drivers/net/plip.c
+++ b/drivers/net/plip.c
@@ -270,6 +270,8 @@ static const struct net_device_ops plip_netdev_ops = {
.ndo_stop = plip_close,
.ndo_start_xmit = plip_tx_packet,
.ndo_do_ioctl = plip_ioctl,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
};
/* Entry point of PLIP driver.
diff --git a/drivers/net/ps3_gelic_net.c b/drivers/net/ps3_gelic_net.c
index d1a5fb4..a3932c9 100644
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -1411,6 +1411,7 @@ static const struct net_device_ops gelic_netdevice_ops = {
.ndo_set_multicast_list = gelic_net_set_multi,
.ndo_change_mtu = gelic_net_change_mtu,
.ndo_tx_timeout = gelic_net_tx_timeout,
+ .ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = gelic_net_poll_controller,
diff --git a/drivers/net/ps3_gelic_wireless.c b/drivers/net/ps3_gelic_wireless.c
index b6b3ca9..6932b08 100644
--- a/drivers/net/ps3_gelic_wireless.c
+++ b/drivers/net/ps3_gelic_wireless.c
@@ -2707,6 +2707,7 @@ static const struct net_device_ops gelic_wl_netdevice_ops = {
.ndo_set_multicast_list = gelic_net_set_multi,
.ndo_change_mtu = gelic_net_change_mtu,
.ndo_tx_timeout = gelic_net_tx_timeout,
+ .ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = gelic_net_poll_controller,
diff --git a/drivers/net/sunvnet.c b/drivers/net/sunvnet.c
index a82fb2a..bc74db0 100644
--- a/drivers/net/sunvnet.c
+++ b/drivers/net/sunvnet.c
@@ -1017,6 +1017,7 @@ static const struct net_device_ops vnet_ops = {
.ndo_stop = vnet_close,
.ndo_set_multicast_list = vnet_set_rx_mode,
.ndo_set_mac_address = vnet_set_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = vnet_tx_timeout,
.ndo_change_mtu = vnet_change_mtu,
.ndo_start_xmit = vnet_start_xmit,
diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c
index e013147..238bea1 100644
--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -999,6 +999,8 @@ static const struct net_device_ops kaweth_netdev_ops = {
.ndo_tx_timeout = kaweth_tx_timeout,
.ndo_set_multicast_list = kaweth_set_rx_mode,
.ndo_get_stats = kaweth_netdev_stats,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
};
static int kaweth_probe(
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index 73acbd2..9bea2af 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -1493,6 +1493,8 @@ static const struct net_device_ops pegasus_netdev_ops = {
.ndo_set_multicast_list = pegasus_set_multicast,
.ndo_get_stats = pegasus_netdev_stats,
.ndo_tx_timeout = pegasus_tx_timeout,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
};
static struct usb_driver pegasus_driver = {
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
index 345593c..a370e51 100644
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -2521,6 +2521,8 @@ static const struct net_device_ops orinoco_netdev_ops = {
.ndo_start_xmit = orinoco_xmit,
.ndo_set_multicast_list = orinoco_set_multicast_list,
.ndo_change_mtu = orinoco_change_mtu,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = orinoco_tx_timeout,
.ndo_get_stats = orinoco_get_stats,
};
@@ -2555,7 +2557,6 @@ struct net_device
priv->wireless_data.spy_data = &priv->spy_data;
dev->wireless_data = &priv->wireless_data;
#endif
- /* we use the default eth_mac_addr for setting the MAC addr */
/* Reserve space in skb for the SNAP header */
dev->hard_header_len += ENCAPS_OVERHEAD;
--
1.6.3.3
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [GIT]: Networking
From: David Miller @ 2009-07-10 3:17 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) FEC build fix and FEC_X_DES_ACTIVE register offset cure, from
Greg Ungerer.
2) The socket poll vs. wake up memory ordering fix, after going
through many revisions and discussion, seems ready to merge.
From Jiri Olsa.
3) The netpoll carrier detection fix from Anton Vorontsov.
4) Revert fib_trie to pre-2.6.22 era root node thresholds to
fix memory allocation overstress seen with BGP workloads.
From Jarek Poplawski.
5) davinci_emac goes OOPS if MAC address changed while interface
is down, fix from Pablo Bitton.
6) cxgb3 hits wrong TX queue and crashses, from Roland Dreier.
7) IGB bug fix from Alexander Duyck
8) IXGBE bug fix from Yi Zou
9) R6040 bug fixes from Florian Fainelli
10) Merge in wireless bug fixes via John Linville.
Please pull, thanks a lot!
The following changes since commit 2e3167308048ca6c810733384d8289082f7e4ec1:
Roland Dreier (1):
fealnx: Fix build breakage -- PR_CONT should be KERN_CONT
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alexander Duyck (1):
igb: set lan id prior to configuring phy
Andrey Yurovsky (1):
mac80211: fix allocation in mesh_queue_preq
Anton Vorontsov (1):
netpoll: Fix carrier detection for drivers that are using phylib
Clyde McPherson (2):
b43: Add support for 4318E
ssb: Add support for 4318E
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Florian Fainelli (2):
r6040: restore MIER register correctly when IRQ line is shared
r6040: bump driver version to 0.24 and date to 08 July 2009
Greg Ungerer (2):
fec: remove extra ";" from definition names
fec: fix definition of 5272 version of FEC_X_DES_ACTIVE register
Hin-Tak Leung (1):
zd1211rw: adding SONY IFU-WLM2 (054c:0257) as a zd1211b device
Jarek Poplawski (1):
ipv4: Fix fib_trie rebalancing, part 4 (root thresholds)
Jaswinder Singh Rajput (1):
includecheck fix: include/linux, rfkill.h
Jay Sternberg (1):
Atheros Kconfig needs to be dependent on WLAN_80211
Jiri Olsa (2):
net: adding memory barrier to the poll and receive callbacks
memory barrier: adding smp_mb__after_lock
Jiri Slaby (1):
Wireless: nl80211, fix lock imbalance
Johannes Berg (4):
hp-wmi: fix rfkill bug
cfg80211: fix refcount leak
mac80211_hwsim: avoid NULL access
mac80211: fix docbook
Larry Finger (2):
b43/b43legacy: fix radio LED initialization
p54: tx refused but queue active
Luciano Coelho (1):
mac80211: minstrel: avoid accessing negative indices in rix_to_ndx()
Pablo Bitton (1):
davinci_emac: fix kernel oops when changing MAC address while interface is down
Pascal Terjan (1):
zd1211rw: 07b8:6001 is a ZD1211B
Roland Dreier (1):
cxgb3: Fix crash caused by stashing wrong netdev_queue
Samuel Ortiz (1):
iwmc3200wifi: add Kconfig help
Vasanthakumar Thiagarajan (1):
ath9k: Fix leak in tx descriptor
Yi Zou (1):
ixgbe: Fix coexistence of FCoE and Flow Director in 82599
Documentation/DocBook/mac80211.tmpl | 2 -
arch/x86/include/asm/spinlock.h | 4 ++
drivers/net/cxgb3/cxgb3_main.c | 3 +-
drivers/net/davinci_emac.c | 12 ++++-
drivers/net/fec.h | 12 ++--
drivers/net/igb/e1000_82575.c | 4 ++
drivers/net/ixgbe/ixgbe_dcb_nl.c | 6 ++
drivers/net/ixgbe/ixgbe_main.c | 19 ++++---
drivers/net/r6040.c | 9 ++-
drivers/net/wireless/ath/Kconfig | 1 +
drivers/net/wireless/ath/ath9k/xmit.c | 9 +++-
drivers/net/wireless/b43/b43.h | 1 +
drivers/net/wireless/b43/main.c | 7 ++-
drivers/net/wireless/b43/pcmcia.c | 1 +
drivers/net/wireless/b43legacy/b43legacy.h | 1 +
drivers/net/wireless/b43legacy/main.c | 7 ++-
drivers/net/wireless/iwmc3200wifi/Kconfig | 9 ++++
drivers/net/wireless/mac80211_hwsim.c | 1 +
drivers/net/wireless/p54/p54common.c | 5 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 3 +-
drivers/platform/x86/hp-wmi.c | 2 +-
drivers/ssb/pcmcia.c | 6 ++-
include/linux/rfkill.h | 1 -
include/linux/spinlock.h | 5 ++
include/net/sock.h | 69 ++++++++++++++++++++++++++++
net/atm/common.c | 6 +-
net/core/datagram.c | 2 +-
net/core/netpoll.c | 2 +-
net/core/sock.c | 8 ++--
net/dccp/output.c | 2 +-
net/dccp/proto.c | 2 +-
net/ipv4/fib_trie.c | 4 +-
net/ipv4/tcp.c | 2 +-
net/iucv/af_iucv.c | 4 +-
net/mac80211/mesh_hwmp.c | 2 +-
net/mac80211/rc80211_minstrel.c | 5 ++-
net/rxrpc/af_rxrpc.c | 4 +-
net/unix/af_unix.c | 8 ++--
net/wireless/nl80211.c | 1 +
net/wireless/scan.c | 1 -
40 files changed, 192 insertions(+), 60 deletions(-)
^ permalink raw reply
* Re: 2.6.31-rc2: Reported regressions from 2.6.30
From: Andres Freund @ 2009-07-10 2:10 UTC (permalink / raw)
To: John Dykstra, Rafael J. Wysocki
Cc: Eric Sesterhenn, Linux Kernel Mailing List, Adrian Bunk,
Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <1247190417.7306.2.camel@merlyn>
Hi John, Hi Rafael,
On Friday 10 July 2009 03:46:57 John Dykstra wrote:
> On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote:
> > There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race
> > in
> > networking in 2.6.31-rc1+195 (possibly caused by netem)
>
> There is some similarity between this soft lockup and the one reported
> in http://www.spinics.net/lists/netdev/msg100957.html. In both, the
> process is doing both sends and receives on raw sockets.
The issue turned out to be a hrtimer bug - i dont see anything like it in your
trace. If you still want to test the fix, its
de907e8432b08f2d5966c36e0747e97c0e596810 in -tip (or
http://lkml.org/lkml/2009/7/9/150)
Rafael: In case youre reading this, I guess you can mark that bug as resolved.
Andres
^ permalink raw reply
* Re: 2.6.31-rc2: Reported regressions from 2.6.30
From: John Dykstra @ 2009-07-10 1:46 UTC (permalink / raw)
To: Andres Freund
Cc: Eric Sesterhenn, Rafael J. Wysocki, Linux Kernel Mailing List,
Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <200907070325.51439.andres@anarazel.de>
On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote:
> There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race
> in
> networking in 2.6.31-rc1+195 (possibly caused by netem)
There is some similarity between this soft lockup and the one reported
in http://www.spinics.net/lists/netdev/msg100957.html. In both, the
process is doing both sends and receives on raw sockets.
-- John
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/5] Add support for software UDP fragmentation offload(UFO)
From: Herbert Xu @ 2009-07-10 1:04 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: David Miller, netdev
In-Reply-To: <1247162981.8649.89.camel@w-sridhar.beaverton.ibm.com>
On Thu, Jul 09, 2009 at 11:09:41AM -0700, Sridhar Samudrala wrote:
> The following set of patches fixes support for UDP fragmentation offload
> in the core networking stack to send/receive large UDP packets over UFO
> enabled devices and fallback to software UFO when the outgoing device
> doesn't support UFO.
> These patches enable setting UFO on virtio-net and tap devices and allow
> large UDP packets to be sent between guest to host and inter guest under
> KVM.
>
> [PATCH net-next-2.6 1/5] udpv4: Handle large incoming UDP/IPv4 packets and support software UFO.
> [PATCH net-next-2.6 2/5] udpv6: Fix HW checksum support for outgoing UFO packets
> [PATCH net-next-2.6 3/5] udpv6: Fix gso_size setting in ip6_ufo_append_data
> [PATCH net-next-2.6 4/5] udpv6: Remove unused skb argument of ipv6_select_ident()
> [PATCH net-next-2.6 5/5] udpv6: Handle large incoming UDP/IPv6 packets and support software UFO
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: sk_lock: inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage
From: Herbert Xu @ 2009-07-10 0:59 UTC (permalink / raw)
To: David Miller
Cc: fengguang.wu-ral2JQCrhuEAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090709.171355.09466097.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Jul 09, 2009 at 05:13:55PM -0700, David Miller wrote:
>
> I think this specific case needs more thinking.
>
> If the allocation fails, and it's GFP_ATOMIC, we are going to yield()
> (which sleeps) and loop endlessly waiting for the allocation to
> succeed.
Indeed. We could do one of the following:
1) Preallocate, either universally or conditinally on sk_allocation.
2) Set a bit somewhere to indicate FIN and retry the allocation as
part of retransmit.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: [patch 0/3] net: Sanitizing hrtimer usage in net/sched/sch_cbq.c
From: David Miller @ 2009-07-10 0:39 UTC (permalink / raw)
To: tglx; +Cc: netdev, linux-kernel, kaber, peterz
In-Reply-To: <20090709215455.703939259@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
Date: Thu, 09 Jul 2009 21:59:18 -0000
> While looking at the "Soft-Lockup/Race in networking in 2.6.31-rc1+195
> ( possibly caused by netem)" issue (http://lkml.org/lkml/2009/7/2/519)
> I noticed some serious problems in the hrtimer related code of
> net/sched/sched/sch_cbq.c.
>
> The following patch series addresses these.
>
> I'm not entirely sure whether patch [1/3] covers all possible
> concurrent modifications, but it fixes the most obvious ones. The
> remaining details are left to the networking experts.
>
> Patches [1/3] and [2/3] might be stable material as well.
Thanks a lot for these paches Thomas, I'll look at them more
closely.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: Fix coexistence of FCoE and Flow Director in 82599
From: David Miller @ 2009-07-10 0:17 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou
In-Reply-To: <20090709122944.962.54056.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 09 Jul 2009 05:29:50 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Fix coexistence of Fiber Channel over Ethernet (FCoE) and Flow Director (FDIR)
> in 82599 and remove the disabling of FDIR when FCoE is enabled.
>
> Currently, FDIR is turned off when FCoE is enabled under the assumption that
> FCoE is always enabled with DCB being turned on. However, FDIR does not have
> to be turned off all the time when FCoE is enabled since FCoE can be enabled
> without DCB being turned on, e.g., use link pause only. This patch makes sure
> that when DCB is turned on or off, FDIR is turned on or off correspondingly;
> and when FCoE is enabled, it does not disable FDIR, rather, it will have FDIR
> set up properly so FCoE and FDIR can coexist regardless of DCB being on or off.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH for 2.6.31] cxgb3: Fix crash caused by stashing wrong netdev_queue
From: David Miller @ 2009-07-10 0:16 UTC (permalink / raw)
To: divy; +Cc: rdreier, netdev
In-Reply-To: <4A565DE9.3040504@chelsio.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Thu, 09 Jul 2009 14:15:21 -0700
> Roland Dreier wrote:
>> Commit c3a8c5b6 ("cxgb3: move away from LLTX") exposed a bug in how
>> cxgb3 looks up the netdev_queue it stashes away in a qset during
>> initialization. For multiport devices, the TX queue index it uses is
>> offset by the first_qset index of each port. This leads to a crash
>> once LLTX is removed, since hard_start_xmit is called with one TX
>> queue lock held, while the TX reclaim timer task grabs a different
>> (wrong) TX queue lock when it frees skbs.
>>
>> Fix this by removing the first_qset offset used to look up the TX
>> queue passed into t3_sge_alloc_qset() from setup_sge_qsets().
>>
>
> Thanks Roland!
> You were very fast to fix it, you beat us.
>
> Acked-by: Divy Le Ray <divy@chelsio.com>
>
>> Signed-off-by: Roland Dreier <rolandd@cisco.com>
Applied.
^ 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