Re: [PATCH 1/3] Bridge: RCU barriers
On Mon, Jan 23, 2006 at 12:05:26PM -0800, Stephen Hemminger wrote:
Use RCU macro's to ensure barrier safety on the bridge
receive path.
Thanks for working on this Stephen.
--- br-fix.orig/net/bridge/br_if.c
+++ br-fix/net/bridge/br_if.c
@@ -124,7 +124,7 @@ static void del_nbp(struct net_bridge_po
struct net_bridge *br = p-br;
struct net_device *dev = p-dev;
- dev-br_port = NULL;
+ rcu_assign_pointer(dev-br_port, NULL);
I think this barrier is in the wrong place. On the deletion path what
we want to achieve is separate the zeroing of dev-br_port and the
actual freeing of the br_port object through a quiescent state. This
is already achieved by the RCU call further down.
On the other hand, when we set dev-br_port in the first instance,
we do need the barrier. So we need to turn the br_port assignment
in new_nbp into an rcu_assign_pointer. In fact, we also need to
rearrange the code there so that we're 100% sure that the bridge
port is fully initialised before we assign dev-br_port. This is
because as soon as that assignment is made packets may start getting
delivered to the bridge via this device.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100 oops on resume
On St 25-01-06 16:28:48, Jesse Brandeburg wrote: On 1/25/06, Jesse Brandeburg [EMAIL PROTECTED] wrote: On 1/25/06, Olaf Kirch [EMAIL PROTECTED] wrote: On Wed, Jan 25, 2006 at 10:02:40AM +0100, Olaf Kirch wrote: I'm not sure what the right fix would be. e100_resume would probably have to call e100_alloc_cbs early on, while e100_up should avoid calling it a second time if nic-cbs_avail != 0. A tentative patch for testing is attached. Reportedly, the patch fixes the crash on resume. Cool, thanks for the research, I have a concern about this however. its an interesting patch, but it raises the question why does e100_init_hw need to be called at all in resume? I looked back through our history and that init_hw call has always been there. I think its incorrect, but its taking me a while to set up a system with the ability to resume. everywhere else in the driver alloc_cbs is called before init_hw so it just seems like a long standing bug. comments? anyone want to test? i compile tested this, but it is untested. Okay I reproduced the issue on 2.6.15.1 (with S1 sleep) and was able to show that my patch that just removes e100_init_hw works okay for me. Let me know how it goes for you, I think this is a good fix. S1 preserves hardware state, .suspend/.resume routines can be NULL for S1. Try with swsusp or S3. Pavel -- Thanks, Sharp! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
On Wednesday 25 January 2006 17:44, Stuffed Crust wrote: On Mon, Jan 23, 2006 at 03:32:32PM +0100, Johannes Berg wrote: Shouldn't you BSS-filter management packets too? Filtering on BSSID is necessary for management frames, especially when multicast management frames are thrown into the mix. ieee80211_rx_mgt can do any filtering necessary. Foreign mgmt packets, if properly used, can provide us with constantly updated info about local wireless neighborhood: available Ad-hoc networks and BSSes, signal quality of APs etc. Something resembling constantly running scan. For example, acx driver does exactly this. Note that typically mgmt traffic is rather low and processing it (instead of dropping) won't add much overhead. For example, STAs are supposed to respect broadcast disassoc/deauth messages, but of course should ignore them if they're not destined for the local BSSID. This filtering can (should) be done in ieee80211_rx_mgt. The only extra-BSS management frames that should not be dropped are are beacons and probe responses. That said, probe responses are directed so our A1 (RA) filter will probably drop the frame if it is not destined for us. -- vda - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Q: link up/down, netif_carrier_on/off tx_timeout
Hi all, I work with the fec driver (used with embedded linuxes), and I am not very satisfied of the behaviour regarding link down / link up. So here are my questions : 1. When/where should netif_carrierr_on/off or another similar routine be called ? 2. If the above are called properly, will tx_timeout be called, and when ? Thanks for listening Philippe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dhcp over ipsec with linux 2.6
Marco Berizzi wrote: I would like to deploy dhcp over ipsec with openswan 2.4.x running on linux 2.6.15.1. To achieve this solution I need dhcp relay agent running on the ipsec gateway box (there will be also the dhcp server on the same box). I'm using the native linux 2.6 ipsec (no KLIPS) so there is no virtual devices. ISC dhcp relay agent need to know which interface should listen (-i flag). With KLIPS I set '-i ipsecX' interface. What should I specify when I'm using the native 2.6 stack? You can use ipip or gre tunnels over IPsec and use these devices. If you're using ISC dhcrelay you'll need to patch the BPF expressions to handle the link type correctly. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] sky2: version 0.14
On Wed, Jan 25, 2006 at 04:28:44PM -0800, Stephen Hemminger wrote:
Mostly a collection of bug fixes. The most critical is the pci express
fix. Also adds Message Signaled Interrupt and entropy support.
Patches seemed to be mangled. Actually having a version I want
people to test tarball would be nice (for other drivers too!) for
those too lazy to play around with git :)
Index: sky2-1.0/drivers/net/sky2.c
===
--- sky2-1.0.orig/drivers/net/sky2.c
+++ sky2-1.0/drivers/net/sky2.c
@@ -2003,19 +2003,16 @@ static void sky2_hw_intr(struct sky2_hw
if (status Y2_IS_PCI_EXP) {
/* PCI-Express uncorrectable Error occurred */
- u32 pex_err;
-
- pci_read_config_dword(hw-pdev, PEX_UNC_ERR_STAT, pex_err);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Netlink] DEBUG socket or device?
Hi Mathieu, Here is a patch that add a netlink virtual interface. Through a hook in af_netlink.c every packets are duplicated and sent to that interface. Thus userspace sniffers can capture them. Security people will cry, but sometimes we need good troubleshooting means in userland. Yes, the deed is to enable netlink troubleshooting from kernel and userland My guess, that the direction is interesting, whereas another way is to use socket communication for such packet-log/sniffing. Netfilter is using netlink sockets to output to userland packets. It might be, that arranging a DEBUG NETLINK socket to direct to it, when enabled, copies of all netlink messages (better to exclude a really bulk traffic like netfilter packet log), will be a more standardized solution. Thus, the hook in netlink_sendmsg will just send a one more copy of a unicast and include the DEBUG_NETLINK socket to a multicast. Sniffing kernel packets via such netlink sockets actually may be extended for the unix-domain traffic as well. What do you think? -- Sincerely, --- Robert Iakobashvili, coroberti at gmail dot com NAVIGARE NECESSE EST -- nldev.patch Description: Binary data
[IPV4]: Always set fl.proto in ip_route_newports
Fix xfrm lookup in ip_route_newports for a very special case.
IPv6 needs a similar fix, it doesn't reroute at all after
selecting new ports, I'll send a patch for that soon.
[IPV4]: Always set fl.proto in ip_route_newports
ip_route_newports uses the struct flowi from the struct rtable returned
by ip_route_connect for the new route lookup and just replaces the port
numbers if they have changed. If an IPsec policy exists which doesn't match
port 0 the struct flowi won't have the proto field set and no xfrm lookup
is done for the changed ports.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 5c4a611fe550de7b6fae4059786d95afbdb8a145
tree b7b63ab4ea015b1d2aabcae6c8a0719fcaa21d5b
parent f079e83652e2e8409b8aeb30571d375101d572c6
author Patrick McHardy [EMAIL PROTECTED] Thu, 26 Jan 2006 14:58:13 +0100
committer Patrick McHardy [EMAIL PROTECTED] Thu, 26 Jan 2006 14:58:13 +0100
include/net/route.h |5 +++--
net/ipv4/tcp_ipv4.c |2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index e3e5436..9c04f15 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -170,8 +170,8 @@ static inline int ip_route_connect(struc
return ip_route_output_flow(rp, fl, sk, 0);
}
-static inline int ip_route_newports(struct rtable **rp, u16 sport, u16 dport,
- struct sock *sk)
+static inline int ip_route_newports(struct rtable **rp, u8 protocol,
+ u16 sport, u16 dport, struct sock *sk)
{
if (sport != (*rp)-fl.fl_ip_sport ||
dport != (*rp)-fl.fl_ip_dport) {
@@ -180,6 +180,7 @@ static inline int ip_route_newports(stru
memcpy(fl, (*rp)-fl, sizeof(fl));
fl.fl_ip_sport = sport;
fl.fl_ip_dport = dport;
+ fl.proto = protocol;
ip_rt_put(*rp);
*rp = NULL;
return ip_route_output_flow(rp, fl, sk, 0);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 6ea3539..1ac35a6 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -236,7 +236,7 @@ int tcp_v4_connect(struct sock *sk, stru
if (err)
goto failure;
- err = ip_route_newports(rt, inet-sport, inet-dport, sk);
+ err = ip_route_newports(rt, IPPROTO_TCP, inet-sport, inet-dport, sk);
if (err)
goto failure;
[GIT] DECnet: Fix for big-endian machines
Please pull Steve's git repository from http://git.kernel.org/pub/scm/linux/kernel/git/steve/decnet-2.6.17.git diffstat: include/linux/dn.h | 44 - include/net/dn.h | 105 - include/net/dn_dev.h | 88 +- include/net/dn_fib.h | 22 include/net/dn_neigh.h |4 - include/net/dn_nsp.h | 72 ++-- include/net/dn_route.h | 12 ++-- include/net/flow.h |8 +-- net/decnet/af_decnet.c | 18 +++ net/decnet/dn_dev.c| 34 ++--- net/decnet/dn_fib.c|8 +-- net/decnet/dn_neigh.c | 24 - net/decnet/dn_nsp_in.c | 28 +- net/decnet/dn_nsp_out.c| 38 +++--- net/decnet/dn_route.c | 57 +++--- net/decnet/dn_rules.c | 18 +++ net/decnet/dn_table.c | 12 ++-- net/decnet/sysctl_net_decnet.c | 12 ++-- 18 files changed, 303 insertions(+), 301 deletions(-) The changelogs are: commit f23c6e3a983757bec46060dca87a1f450ee3e61f Author: Patrick Caulfield [EMAIL PROTECTED] Date: Thu Jan 26 10:01:09 2006 + [DECnet] Patch to fix recvmsg() flag check This patch means that 64bit kernel/32bit userland platforms will now work correctly with DECnet. Signed-off-by: Patrick Caulfield [EMAIL PROTECTED] Signed-off-by: Steven Whitehouse [EMAIL PROTECTED] commit b985479aaeb16dae921566544a480f770d3b0ff5 Author: Steven Whitehouse [EMAIL PROTECTED] Date: Sun Jan 15 14:59:49 2006 + sdn_family in DECnet sockaddr_dn should be in native order This corrects a bug in the previous patch where sdn_family was changed to network byte order, as it ought to be in native byte order. Signed-off-by: Steven Whitehouse [EMAIL PROTECTED] commit e1fa0ae3abbbf9cb8411584d0666589593e4936b Author: Steven Whitehouse [EMAIL PROTECTED] Date: Fri Jan 13 21:21:03 2006 + Endian annotation and fixes for DECnet. The typedef for dn_address has been removed in favour of using __le16 or __u16 directly as appropriate. All the DECnet header files are updated accordingly. The byte ordering of dn_eth2dn() and dn_dn2eth() are both changed since just about all their callers wanted network order rather than host order, so the conversion is now done in the functions themselves. Several missed endianess conversions have been picked up during the conversion process. The nh_gw field in struct dn_fib_info has been changed from a 32 bit field to 16 bits as it ought to be. One or two cases of using htons rather than dn_htons in the routing code have been found and fixed. There are still a few warnings to fix, but this patch deals with the important cases. Signed-off-by: Steven Whitehouse [EMAIL PROTECTED] Thanks, -- patrick - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV4]: Always set fl.proto in ip_route_newports
Patrick McHardy wrote:
[IPV4]: Always set fl.proto in ip_route_newports
ip_route_newports uses the struct flowi from the struct rtable returned
by ip_route_connect for the new route lookup and just replaces the port
numbers if they have changed. If an IPsec policy exists which doesn't match
port 0 the struct flowi won't have the proto field set and no xfrm lookup
is done for the changed ports.
I missed DCCP in my last patch, new one attached.
[IPV4]: Always set fl.proto in ip_route_newports
ip_route_newports uses the struct flowi from the struct rtable returned
by ip_route_connect for the new route lookup and just replaces the port
numbers if they have changed. If an IPsec policy exists which doesn't match
port 0 the struct flowi won't have the proto field set and no xfrm lookup
is done for the changed ports.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 6c05f125a47adff9450f835fb35b5c51cc43743b
tree 2ae57d6375f0c69b26bcb43eb745f80971441959
parent e5a3397323130b01becc4efbf025a5386775e83d
author Patrick McHardy [EMAIL PROTECTED] Thu, 26 Jan 2006 15:23:11 +0100
committer Patrick McHardy [EMAIL PROTECTED] Thu, 26 Jan 2006 15:23:11 +0100
include/net/route.h |5 +++--
net/dccp/ipv4.c |3 ++-
net/ipv4/tcp_ipv4.c |2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index e3e5436..9c04f15 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -170,8 +170,8 @@ static inline int ip_route_connect(struc
return ip_route_output_flow(rp, fl, sk, 0);
}
-static inline int ip_route_newports(struct rtable **rp, u16 sport, u16 dport,
- struct sock *sk)
+static inline int ip_route_newports(struct rtable **rp, u8 protocol,
+ u16 sport, u16 dport, struct sock *sk)
{
if (sport != (*rp)-fl.fl_ip_sport ||
dport != (*rp)-fl.fl_ip_dport) {
@@ -180,6 +180,7 @@ static inline int ip_route_newports(stru
memcpy(fl, (*rp)-fl, sizeof(fl));
fl.fl_ip_sport = sport;
fl.fl_ip_dport = dport;
+ fl.proto = protocol;
ip_rt_put(*rp);
*rp = NULL;
return ip_route_output_flow(rp, fl, sk, 0);
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 00f9832..dc0487b 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -119,7 +119,8 @@ int dccp_v4_connect(struct sock *sk, str
if (err != 0)
goto failure;
- err = ip_route_newports(rt, inet-sport, inet-dport, sk);
+ err = ip_route_newports(rt, IPPROTO_DCCP, inet-sport, inet-dport,
+ sk);
if (err != 0)
goto failure;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 6ea3539..1ac35a6 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -236,7 +236,7 @@ int tcp_v4_connect(struct sock *sk, stru
if (err)
goto failure;
- err = ip_route_newports(rt, inet-sport, inet-dport, sk);
+ err = ip_route_newports(rt, IPPROTO_TCP, inet-sport, inet-dport, sk);
if (err)
goto failure;
Re: [PATCH RESEND 3/6] e1000: Added functions to save and restore config
Jesse Brandeburg wrote: On Mon, 23 Jan 2006, Ingo Oeser wrote: Jeff Kirsher wrote: These functions help restore the driver to active configuration when coming out of resume for power management. Shouldn't this problem be fixed in the PCI layer of Linux? PS: CC'ed maintainer of Linux PCI core I recently saw some patches for pci express go by that may actually fix this issue, but until then, this fix in the driver gets us most of the way there. When the subsystem is fixed, we can decide if this code is superfluous and remove it. Agreed. I just wanted to point out the need for such functions to the PCI maintainer and either get a Use function foo() for this!, I have feature $BAR in my queue for this. or Not yet implemented!. Finally I have no objections to fixing the issue in the driver until the PCI layer of Linux offers this functionality itself. Regards Ingo Oeser - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: Fix H-TCP accounting
This fixes the accounting in H-TCP, the ccount variable is also adjusted a few lines above this one. This line was not supposed to be there and wasn't there in the patches originally submitted, the four patches submitted were merged to one and in that merge the bug was introduced. Signed-Off-By: Baruch Even [EMAIL PROTECTED] -- net/ipv4/tcp_htcp.c |1 - 1 file changed, 1 deletion(-) Index: 2.6-git/net/ipv4/tcp_htcp.c === --- 2.6-git.orig/net/ipv4/tcp_htcp.c +++ 2.6-git/net/ipv4/tcp_htcp.c @@ -230,7 +230,6 @@ static void htcp_cong_avoid(struct sock if (tp-snd_cwnd tp-snd_cwnd_clamp) tp-snd_cwnd++; tp-snd_cwnd_cnt = 0; - ca-ccount++; } } } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPv6: to take care of permanent routes
When adding a route, expiration attribute may be 0. In my understanding,
it means the route never expires and rt6i_expires should be 0, and not
the current time. If right, attached patch should fix the issue.
Well, please drop RTF_EXPIRES also. Thanks.
Following patch drops this flag. As you can see, it requires to set the
flag back to RTF_EXPIRES in ndisc_router_discovery(), because
rt6_add_dflt_router() asks a new route with RTF_EXPIRES flag set and
rtmsg_info = 0.
The issue is ndisc_router_discovery() sets itself rt6i_expires itself
with the router lifetime found in RA.
A better fix could be to pass the lifetime in nb HZ to
rt6_add_dflt_router(), what do you think ?
Regards,
Jean-Mickael
Signed-off-by: [EMAIL PROTECTED]
--- route.c.origWed Jan 25 16:12:52 2006
+++ route.c Thu Jan 26 15:49:23 2006
@@ -948,7 +948,10 @@
}
rt-u.dst.obsolete = -1;
- rt-rt6i_expires = jiffies + clock_t_to_jiffies(rtmsg-rtmsg_info);
+ if (rtmsg-rtmsg_info == 0)
+ rt-rt6i_expires = 0;
+ else
+ rt-rt6i_expires = jiffies +
clock_t_to_jiffies(rtmsg-rtmsg_info);
if (nlh (r = NLMSG_DATA(nlh))) {
rt-rt6i_protocol = r-rtm_protocol;
} else {
@@ -1070,6 +1073,9 @@
rt-rt6i_flags = rtmsg-rtmsg_flags;
install_route:
+ if (rt-rt6i_expires == 0)
+ rt-rt6i_flags = ~RTF_EXPIRES;
+
if (rta rta[RTA_METRICS-1]) {
int attrlen = RTA_PAYLOAD(rta[RTA_METRICS-1]);
struct rtattr *attr = RTA_DATA(rta[RTA_METRICS-1]);
--- ndisc.c.origThu Jan 26 16:29:03 2006
+++ ndisc.c Thu Jan 26 16:29:40 2006
@@ -1151,8 +1151,10 @@
neigh-flags |= NTF_ROUTER;
}
- if (rt)
+ if (rt) {
rt-rt6i_expires = jiffies + (HZ * lifetime);
+ rt-rt6i_flags |= RTF_EXPIRES;
+ }
if (ra_msg-icmph.icmp6_hop_limit) {
in6_dev-cnf.hop_limit = ra_msg-icmph.icmp6_hop_limit;
Re: IPv6: to take care of permanent routes
In article [EMAIL PROTECTED] (at Thu, 26 Jan 2006 16:35:08 +0100),
Jean-Mickael Guerin [EMAIL PROTECTED] says:
Following patch drops this flag. As you can see, it requires to set the
flag back to RTF_EXPIRES in ndisc_router_discovery(), because
rt6_add_dflt_router() asks a new route with RTF_EXPIRES flag set and
rtmsg_info = 0.
The issue is ndisc_router_discovery() sets itself rt6i_expires itself
with the router lifetime found in RA.
Probably, the caller should not set RTF_EXPIRES when allocating
new one. Instead, set rt6i_expires and RTF_EXPIRES afterwards
(as your patch does).
And, please make your patch so that we can apply it by patch -p1
at the top directory of the tree; e.g.
% diff -u linux-2.6.15.{orig,fix}/net/ipv6/route.c fix.patch
Thank you.
--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dhcp over ipsec with linux 2.6
Patrick McHardy wrote: Marco Berizzi wrote: I would like to deploy dhcp over ipsec with openswan 2.4.x running on linux 2.6.15.1. To achieve this solution I need dhcp relay agent running on the ipsec gateway box (there will be also the dhcp server on the same box). I'm using the native linux 2.6 ipsec (no KLIPS) so there is no virtual devices. ISC dhcp relay agent need to know which interface should listen (-i flag). With KLIPS I set '-i ipsecX' interface. What should I specify when I'm using the native 2.6 stack? You can use ipip or gre tunnels over IPsec and use these devices. I can't use ipip or gre tunnels over IPsec because the other peer doesn't support them :-(( If you're using ISC dhcrelay you'll need to patch the BPF expressions to handle the link type correctly. Thanks for the response. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dhcp over ipsec with linux 2.6
Marco Berizzi wrote: Patrick McHardy wrote: Marco Berizzi wrote: I would like to deploy dhcp over ipsec with openswan 2.4.x running on linux 2.6.15.1. To achieve this solution I need dhcp relay agent running on the ipsec gateway box (there will be also the dhcp server on the same box). I'm using the native linux 2.6 ipsec (no KLIPS) so there is no virtual devices. ISC dhcp relay agent need to know which interface should listen (-i flag). With KLIPS I set '-i ipsecX' interface. What should I specify when I'm using the native 2.6 stack? You can use ipip or gre tunnels over IPsec and use these devices. I can't use ipip or gre tunnels over IPsec because the other peer doesn't support them :-(( I think its also possible to change dhcrelay to use regular UDP sockets instead of AF_PACKET sockets, which should work fine on the real device. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPv6: to take care of permanent routes
Probably, the caller should not set RTF_EXPIRES when allocating
new one. Instead, set rt6i_expires and RTF_EXPIRES afterwards
(as your patch does).
It makes sense.
And, please make your patch so that we can apply it by patch -p1
at the top directory of the tree; e.g.
% diff -u linux-2.6.15.{orig,fix}/net/ipv6/route.c fix.patch
Here it is.
Signed-off-by: [EMAIL PROTECTED]
--
--- linux-2.6.15-orig/net/ipv6/ndisc.c 2006-01-03 04:21:10.0 +0100
+++ linux-2.6.15/net/ipv6/ndisc.c 2006-01-26 17:51:49.811283931 +0100
@@ -1119,8 +1119,10 @@
neigh-flags |= NTF_ROUTER;
}
- if (rt)
+ if (rt) {
rt-rt6i_expires = jiffies + (HZ * lifetime);
+ rt-rt6i_flags |= RTF_EXPIRES;
+ }
if (ra_msg-icmph.icmp6_hop_limit) {
in6_dev-cnf.hop_limit = ra_msg-icmph.icmp6_hop_limit;
--- linux-2.6.15-orig/net/ipv6/route.c 2006-01-03 04:21:10.0 +0100
+++ linux-2.6.15/net/ipv6/route.c 2006-01-26 17:51:21.606054467 +0100
@@ -832,7 +832,10 @@
}
rt-u.dst.obsolete = -1;
- rt-rt6i_expires = jiffies + clock_t_to_jiffies(rtmsg-rtmsg_info);
+ if (rtmsg-rtmsg_info == 0)
+ rt-rt6i_expires = 0;
+ else
+ rt-rt6i_expires = jiffies +
clock_t_to_jiffies(rtmsg-rtmsg_info);
if (nlh (r = NLMSG_DATA(nlh))) {
rt-rt6i_protocol = r-rtm_protocol;
} else {
@@ -954,6 +957,9 @@
rt-rt6i_flags = rtmsg-rtmsg_flags;
install_route:
+ if (rt-rt6i_expires == 0)
+ rt-rt6i_flags = ~RTF_EXPIRES;
+
if (rta rta[RTA_METRICS-1]) {
int attrlen = RTA_PAYLOAD(rta[RTA_METRICS-1]);
struct rtattr *attr = RTA_DATA(rta[RTA_METRICS-1]);
@@ -1307,7 +1313,7 @@
rtmsg.rtmsg_type = RTMSG_NEWROUTE;
ipv6_addr_copy(rtmsg.rtmsg_gateway, gwaddr);
rtmsg.rtmsg_metric = 1024;
- rtmsg.rtmsg_flags = RTF_GATEWAY | RTF_ADDRCONF | RTF_DEFAULT | RTF_UP |
RTF_EXPIRES;
+ rtmsg.rtmsg_flags = RTF_GATEWAY | RTF_ADDRCONF | RTF_DEFAULT | RTF_UP;
rtmsg.rtmsg_ifindex = dev-ifindex;
Re: wireless-2.6 status (25 January 2006)
Hi John, On Wed, 25 Jan 2006, ext John W. Linville wrote: I still have a number of other branches in the wireless-2.6 tree. I am using those branches to collect out of stream drivers and developments such as the softmac code and the alternative 802.11 stack from Devicescape. I was wondering what's the reason for not having the madwifi stack there as well. I haven't seen anyone sending patches for it, but is that the only reason ? Cheers, Samuel. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Bridge: RCU barriers
On Thu, 26 Jan 2006 19:45:06 +1100 Herbert Xu [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 12:05:26PM -0800, Stephen Hemminger wrote: Use RCU macro's to ensure barrier safety on the bridge receive path. Thanks for working on this Stephen. --- br-fix.orig/net/bridge/br_if.c +++ br-fix/net/bridge/br_if.c @@ -124,7 +124,7 @@ static void del_nbp(struct net_bridge_po struct net_bridge *br = p-br; struct net_device *dev = p-dev; - dev-br_port = NULL; + rcu_assign_pointer(dev-br_port, NULL); I think this barrier is in the wrong place. On the deletion path what we want to achieve is separate the zeroing of dev-br_port and the actual freeing of the br_port object through a quiescent state. This is already achieved by the RCU call further down. That breaks because of the race (found by Xen) where an interface is being deleted from a bridge and the device is being removed. br_del_if rmmod device netlink event br_device_event ... On the other hand, when we set dev-br_port in the first instance, we do need the barrier. So we need to turn the br_port assignment in new_nbp into an rcu_assign_pointer. In fact, we also need to rearrange the code there so that we're 100% sure that the bridge port is fully initialised before we assign dev-br_port. This is because as soon as that assignment is made packets may start getting delivered to the bridge via this device. Cheers, -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, Jan 26, 2006 at 07:27:08PM +0200, Samuel Ortiz wrote: On Wed, 25 Jan 2006, ext John W. Linville wrote: I still have a number of other branches in the wireless-2.6 tree. I was wondering what's the reason for not having the madwifi stack there as well. I haven't seen anyone sending patches for it, but is that the only reason ? Well, at least part of the answer is I'm not done yet. I am still collecting code and figuring-out how to get it all into one tree. But, the main answer has to do with the intellectual property (i.e. copyright) issues concerning the HAL. My understanding is that the HAL currently used by the madwifi stack is not available under a license compatible with being included in the Linux kernel. Am I mistaken? I think it is very important to get a driver into the kernel which supports the Atheros hardware. At present, the driver from www.ath-driver.org seems the most promising. Although, some have expressed legal concerns about it as well. Anyone have any clarifying opinions about that driver? Are there any other options for supporting the Atheros hardware within the kernel? Thanks, John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
John W. Linville wrote: On Thu, Jan 26, 2006 at 07:27:08PM +0200, Samuel Ortiz wrote: On Wed, 25 Jan 2006, ext John W. Linville wrote: I still have a number of other branches in the wireless-2.6 tree. I was wondering what's the reason for not having the madwifi stack there as well. I haven't seen anyone sending patches for it, but is that the only reason ? Well, at least part of the answer is I'm not done yet. I am still collecting code and figuring-out how to get it all into one tree. But, the main answer has to do with the intellectual property (i.e. copyright) issues concerning the HAL. My understanding is that the HAL currently used by the madwifi stack is not available under a license compatible with being included in the Linux kernel. Am I mistaken? It appears to be the case. It might be technically possible to hack up madwifi as a module w/out the HAL and force end-users to download and install the HAL (and taint their kernel) to have a useful setup. That would go against much of what Linux stands for though, so I doubt it would be acceptable. If someone has a reverse-engineered HAL that might could be used as well. I think it is very important to get a driver into the kernel which supports the Atheros hardware. At present, the driver from www.ath-driver.org seems the most promising. Although, some have expressed legal concerns about it as well. Anyone have any clarifying opinions about that driver? Are there any other options for supporting the Atheros hardware within the kernel? None that I've found. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/4] net: Percpufy frequently used variables on struct proto
The following patches change struct proto.memory_allocated, proto.sockets_allocated to use per-cpu counters. This patchset also switches the proto.inuse percpu varible to use alloc_percpu, instead of NR_CPUS * cacheline size padding. We saw 5 % improvement in apache bench requests per second with this patchset, on a multi nic 8 way 3.3 GHZ IBM x460 Xeon server. Patches follow. Thanks, Kiran - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100 oops on resume
On Wed, Jan 25, 2006 at 04:28:48PM -0800, Jesse Brandeburg wrote: Okay I reproduced the issue on 2.6.15.1 (with S1 sleep) and was able to show that my patch that just removes e100_init_hw works okay for me. Let me know how it goes for you, I think this is a good fix. worked for me in the Compaq Armada e500 and reportedly also fixed the SONY that originally uncovered it. Will be in the next SUSE betas, so if anything breaks, we'll notice it. Thanks. -- Stefan Seyfried \ I didn't want to write for pay. I QA / RD Team Mobile Devices \ wanted to be paid for what I write. SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
Change the atomic_t sockets_allocated member of struct proto to a
per-cpu counter.
Signed-off-by: Pravin B. Shelar [EMAIL PROTECTED]
Signed-off-by: Ravikiran Thirumalai [EMAIL PROTECTED]
Signed-off-by: Shai Fultheim [EMAIL PROTECTED]
Index: linux-2.6.16-rc1/include/net/sock.h
===
--- linux-2.6.16-rc1.orig/include/net/sock.h2006-01-24 14:37:45.0
-0800
+++ linux-2.6.16-rc1/include/net/sock.h 2006-01-24 17:35:34.0 -0800
@@ -543,7 +543,7 @@ struct proto {
/* Memory pressure */
void(*enter_memory_pressure)(void);
struct percpu_counter *memory_allocated; /* Current allocated
memory. */
- atomic_t*sockets_allocated; /* Current number of
sockets. */
+ int *sockets_allocated; /* Current number of
sockets (percpu counter). */
/*
* Pressure flag: try to collapse.
@@ -579,6 +579,24 @@ struct proto {
} stats[NR_CPUS];
};
+static inline int read_sockets_allocated(struct proto *prot)
+{
+ int total = 0;
+ int cpu;
+ for_each_cpu(cpu)
+ total += *per_cpu_ptr(prot-sockets_allocated, cpu);
+ return total;
+}
+
+static inline void mod_sockets_allocated(int *sockets_allocated, int count)
+{
+ (*per_cpu_ptr(sockets_allocated, get_cpu())) += count;
+ put_cpu();
+}
+
+#define inc_sockets_allocated(c) mod_sockets_allocated(c, 1)
+#define dec_sockets_allocated(c) mod_sockets_allocated(c, -1)
+
extern int proto_register(struct proto *prot, int alloc_slab);
extern void proto_unregister(struct proto *prot);
Index: linux-2.6.16-rc1/include/net/tcp.h
===
--- linux-2.6.16-rc1.orig/include/net/tcp.h 2006-01-24 14:37:45.0
-0800
+++ linux-2.6.16-rc1/include/net/tcp.h 2006-01-24 17:05:34.0 -0800
@@ -221,7 +221,7 @@ extern int sysctl_tcp_tso_win_divisor;
extern int sysctl_tcp_abc;
extern struct percpu_counter tcp_memory_allocated;
-extern atomic_t tcp_sockets_allocated;
+extern int *tcp_sockets_allocated;
extern int tcp_memory_pressure;
/*
Index: linux-2.6.16-rc1/net/core/sock.c
===
--- linux-2.6.16-rc1.orig/net/core/sock.c 2006-01-24 14:37:45.0
-0800
+++ linux-2.6.16-rc1/net/core/sock.c2006-01-24 16:47:55.0 -0800
@@ -771,7 +771,7 @@ struct sock *sk_clone(const struct sock
newsk-sk_sleep = NULL;
if (newsk-sk_prot-sockets_allocated)
- atomic_inc(newsk-sk_prot-sockets_allocated);
+
inc_sockets_allocated(newsk-sk_prot-sockets_allocated);
}
out:
return newsk;
@@ -1620,7 +1620,7 @@ static void proto_seq_printf(struct seq_
%2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c
%2c %2c %2c %2c %2c %2c\n,
proto-name,
proto-obj_size,
- proto-sockets_allocated != NULL ?
atomic_read(proto-sockets_allocated) : -1,
+ proto-sockets_allocated != NULL ?
read_sockets_allocated(proto) : -1,
proto-memory_allocated != NULL ?
percpu_counter_read(proto-memory_allocated) :
-1,
proto-memory_pressure != NULL ? *proto-memory_pressure ?
yes : no : NI,
Index: linux-2.6.16-rc1/net/core/stream.c
===
--- linux-2.6.16-rc1.orig/net/core/stream.c 2006-01-24 14:37:45.0
-0800
+++ linux-2.6.16-rc1/net/core/stream.c 2006-01-24 16:20:22.0 -0800
@@ -243,7 +243,7 @@ int sk_stream_mem_schedule(struct sock *
return 1;
if (!*sk-sk_prot-memory_pressure ||
- sk-sk_prot-sysctl_mem[2]
atomic_read(sk-sk_prot-sockets_allocated) *
+ sk-sk_prot-sysctl_mem[2] read_sockets_allocated(sk-sk_prot) *
sk_stream_pages(sk-sk_wmem_queued +
atomic_read(sk-sk_rmem_alloc)
+
sk-sk_forward_alloc))
Index: linux-2.6.16-rc1/net/ipv4/proc.c
===
--- linux-2.6.16-rc1.orig/net/ipv4/proc.c 2006-01-24 14:37:45.0
-0800
+++ linux-2.6.16-rc1/net/ipv4/proc.c2006-01-24 16:20:22.0 -0800
@@ -63,7 +63,7 @@ static int sockstat_seq_show(struct seq_
socket_seq_show(seq);
seq_printf(seq, TCP: inuse %d orphan %d tw %d alloc %d mem %lu\n,
fold_prot_inuse(tcp_prot), atomic_read(tcp_orphan_count),
- tcp_death_row.tw_count, atomic_read(tcp_sockets_allocated),
+ tcp_death_row.tw_count, read_sockets_allocated(tcp_prot),
percpu_counter_read(tcp_memory_allocated));
[patch 2/4] net: Percpufy frequently used variables -- struct proto.memory_allocated
Change struct proto-memory_allocated to a batching per-CPU counter
(percpu_counter) from an atomic_t. A batching counter is better than a
plain per-CPU counter as this field is read often.
Signed-off-by: Pravin B. Shelar [EMAIL PROTECTED]
Signed-off-by: Ravikiran Thirumalai [EMAIL PROTECTED]
Signed-off-by: Shai Fultheim [EMAIL PROTECTED]
Index: linux-2.6.16-rc1mm3/include/net/sock.h
===
--- linux-2.6.16-rc1mm3.orig/include/net/sock.h 2006-01-25 16:25:16.0
-0800
+++ linux-2.6.16-rc1mm3/include/net/sock.h 2006-01-25 16:56:59.0
-0800
@@ -48,6 +48,7 @@
#include linux/netdevice.h
#include linux/skbuff.h /* struct sk_buff */
#include linux/security.h
+#include linux/percpu_counter.h
#include linux/filter.h
@@ -541,8 +542,9 @@ struct proto {
/* Memory pressure */
void(*enter_memory_pressure)(void);
- atomic_t*memory_allocated; /* Current allocated
memory. */
+ struct percpu_counter *memory_allocated; /* Current allocated
memory. */
atomic_t*sockets_allocated; /* Current number of
sockets. */
+
/*
* Pressure flag: try to collapse.
* Technical note: it is used by multiple contexts non atomically.
Index: linux-2.6.16-rc1mm3/include/net/tcp.h
===
--- linux-2.6.16-rc1mm3.orig/include/net/tcp.h 2006-01-25 16:25:16.0
-0800
+++ linux-2.6.16-rc1mm3/include/net/tcp.h 2006-01-25 16:56:59.0
-0800
@@ -220,7 +220,7 @@ extern int sysctl_tcp_moderate_rcvbuf;
extern int sysctl_tcp_tso_win_divisor;
extern int sysctl_tcp_abc;
-extern atomic_t tcp_memory_allocated;
+extern struct percpu_counter tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
extern int tcp_memory_pressure;
Index: linux-2.6.16-rc1mm3/net/core/sock.c
===
--- linux-2.6.16-rc1mm3.orig/net/core/sock.c2006-01-25 16:25:16.0
-0800
+++ linux-2.6.16-rc1mm3/net/core/sock.c 2006-01-25 16:56:59.0 -0800
@@ -1616,12 +1616,13 @@ static char proto_method_implemented(con
static void proto_seq_printf(struct seq_file *seq, struct proto *proto)
{
- seq_printf(seq, %-9s %4u %6d %6d %-3s %6u %-3s %-10s
+ seq_printf(seq, %-9s %4u %6d %6lu %-3s %6u %-3s %-10s
%2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c
%2c %2c %2c %2c %2c %2c\n,
proto-name,
proto-obj_size,
proto-sockets_allocated != NULL ?
atomic_read(proto-sockets_allocated) : -1,
- proto-memory_allocated != NULL ?
atomic_read(proto-memory_allocated) : -1,
+ proto-memory_allocated != NULL ?
+ percpu_counter_read(proto-memory_allocated) :
-1,
proto-memory_pressure != NULL ? *proto-memory_pressure ?
yes : no : NI,
proto-max_header,
proto-slab == NULL ? no : yes,
Index: linux-2.6.16-rc1mm3/net/core/stream.c
===
--- linux-2.6.16-rc1mm3.orig/net/core/stream.c 2006-01-25 16:25:16.0
-0800
+++ linux-2.6.16-rc1mm3/net/core/stream.c 2006-01-25 16:56:59.0
-0800
@@ -17,6 +17,7 @@
#include linux/signal.h
#include linux/tcp.h
#include linux/wait.h
+#include linux/percpu.h
#include net/sock.h
/**
@@ -196,11 +197,11 @@ EXPORT_SYMBOL(sk_stream_error);
void __sk_stream_mem_reclaim(struct sock *sk)
{
if (sk-sk_forward_alloc = SK_STREAM_MEM_QUANTUM) {
- atomic_sub(sk-sk_forward_alloc / SK_STREAM_MEM_QUANTUM,
- sk-sk_prot-memory_allocated);
+ percpu_counter_mod_bh(sk-sk_prot-memory_allocated,
+ -(sk-sk_forward_alloc /
SK_STREAM_MEM_QUANTUM));
sk-sk_forward_alloc = SK_STREAM_MEM_QUANTUM - 1;
if (*sk-sk_prot-memory_pressure
- (atomic_read(sk-sk_prot-memory_allocated)
+ (percpu_counter_read(sk-sk_prot-memory_allocated)
sk-sk_prot-sysctl_mem[0]))
*sk-sk_prot-memory_pressure = 0;
}
@@ -213,23 +214,26 @@ int sk_stream_mem_schedule(struct sock *
int amt = sk_stream_pages(size);
sk-sk_forward_alloc += amt * SK_STREAM_MEM_QUANTUM;
- atomic_add(amt, sk-sk_prot-memory_allocated);
+ percpu_counter_mod_bh(sk-sk_prot-memory_allocated, amt);
/* Under limit. */
- if (atomic_read(sk-sk_prot-memory_allocated)
sk-sk_prot-sysctl_mem[0]) {
+ if (percpu_counter_read(sk-sk_prot-memory_allocated)
+ sk-sk_prot-sysctl_mem[0]) {
if (*sk-sk_prot-memory_pressure)
*sk-sk_prot-memory_pressure = 0;
[patch 1/4] net: Percpufy frequently used variables -- add percpu_counter_mod_bh
Add percpu_counter_mod_bh for using these counters safely from
both softirq and process context.
Signed-off by: Pravin B. Shelar [EMAIL PROTECTED]
Signed-off by: Ravikiran G Thirumalai [EMAIL PROTECTED]
Signed-off by: Shai Fultheim [EMAIL PROTECTED]
Index: linux-2.6.16-rc1/include/linux/percpu_counter.h
===
--- linux-2.6.16-rc1.orig/include/linux/percpu_counter.h2006-01-25
11:53:56.0 -0800
+++ linux-2.6.16-rc1/include/linux/percpu_counter.h 2006-01-25
12:09:41.0 -0800
@@ -11,6 +11,7 @@
#include linux/smp.h
#include linux/threads.h
#include linux/percpu.h
+#include linux/interrupt.h
#ifdef CONFIG_SMP
@@ -102,4 +103,11 @@ static inline void percpu_counter_dec(st
percpu_counter_mod(fbc, -1);
}
+static inline void percpu_counter_mod_bh(struct percpu_counter *fbc, long
amount)
+{
+ local_bh_disable();
+ percpu_counter_mod(fbc, amount);
+ local_bh_enable();
+}
+
#endif /* _LINUX_PERCPU_COUNTER_H */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100 oops on resume
On Thu, Jan 26, 2006 at 08:02:37PM +0100, Stefan Seyfried wrote: Will be in the next SUSE betas, so if anything breaks, we'll notice it. I doubt it. As Jesse mentioned, e100_hw_init is called from e100_up, so the call from e100_resume was really superfluous. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: It appears to be the case. It might be technically possible to hack up madwifi as a module w/out the HAL and force end-users to download and install the HAL (and taint their kernel) to have a useful setup. That would go against much of what Linux stands for though, so I doubt it would be acceptable. If someone has a reverse-engineered HAL that might could be used as well. I don't think that would fly based on past precedents. Leaving some kind of hook for the proprietary binary isn't allowed (see the PWC camera driver problems from a year or so back), and you can't have a module in the kernel that won't build unless you pull down another .o file to link against or whatever. What we have seen is permitted is a driver that requires a closed binary firmware to be loaded to operate (ipw2x00, prism54). I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. signature.asc Description: This is a digitally signed message part
Re: wireless-2.6 status (25 January 2006)
David Hollis wrote: On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: It appears to be the case. It might be technically possible to hack up madwifi as a module w/out the HAL and force end-users to download and install the HAL (and taint their kernel) to have a useful setup. That would go against much of what Linux stands for though, so I doubt it would be acceptable. If someone has a reverse-engineered HAL that might could be used as well. I don't think that would fly based on past precedents. Leaving some kind of hook for the proprietary binary isn't allowed (see the PWC camera driver problems from a year or so back), and you can't have a module in the kernel that won't build unless you pull down another .o file to link against or whatever. What we have seen is permitted is a driver that requires a closed binary firmware to be loaded to operate (ipw2x00, prism54). I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. The HAL is not real firmware..just normal kernel code. I wonder if you could get around this by using a sort of CPU emulator and/or virtual machine and load the HAL 'firmware' into that? Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote: David Hollis wrote: I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. The HAL is not real firmware..just normal kernel code. I wonder if you could get around this by using a sort of CPU emulator and/or virtual machine and load the HAL 'firmware' into that? brainstorm Any chance the driver could be rearchitected w/ the HAL functionality moved into a userland helper? I haven't even looked at the driver to see if this could be practical...? /brainstorm -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PCI Error Recovery: ixgb network device driver
Hi,
Sorry for late response, I was trying to find some h/w so as
to retest this before responding. (Which I wasn't able to
find, and so haven't retested yet).
On Thu, Jan 19, 2006 at 05:23:07AM +0100, Andi Kleen was heard to remark:
+#ifdef XXX_CONFIG_IXGB_EEH_RECOVERY
+ if(unlikely(icr==EEH_IO_ERROR_VALUE(4))) {
+ if (eeh_slot_is_isolated (adapter-pdev))
+ // disable_irq_nosync (adapter-pdev-irq);
+ return IRQ_NONE; /* Not our interrupt */
So does the return belong below the first or the second if()? It certainly
looks weird.
This is left-over crud (its not compiled) that I should have removed
from the patch. I had left it in as a note to self because, at one
point, it cured a hang.
Background: (I think you get this but let me repeat):
A variety of device drivers have a design flaw in that they will
poll an interrupt status register in an infinite loop in the
interrupt handler, waiting for a certain value to be set/cleared.
This would be a deadly behaviour for any PCMCIA card that might get
yanked at any time. Similarly, its a problem for PCI error recovery:
when the PCI device is frozen, all further reads return 0xff,
and so the interrupt status won't ever change. With just the right
timing, one hangs in a spinloop with interrupts disabled. :(
And returning IRQ_NONE looks wrong too - if means if
the hardware is broken and there is nobody else on the same interrupt
then the kernel will complain about buggy drivers, which is not true
here. Probably it needs a new IRQ_ERR return value or somesuch that
stops the complaining and acts otherwise like IRQ_NONE.
Ah!! I was struggling with trying to figure out the right way of
dealing with this case. I kept at it with various hacky attempts,
none terribly satisfying. I'll take a look at the new return code
idea.
--linas
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Bridge: RCU barriers
On Thu, Jan 26, 2006 at 09:41:00AM -0800, Stephen Hemminger wrote:
--- br-fix.orig/net/bridge/br_if.c
+++ br-fix/net/bridge/br_if.c
@@ -124,7 +124,7 @@ static void del_nbp(struct net_bridge_po
struct net_bridge *br = p-br;
struct net_device *dev = p-dev;
- dev-br_port = NULL;
+ rcu_assign_pointer(dev-br_port, NULL);
I think this barrier is in the wrong place. On the deletion path what
we want to achieve is separate the zeroing of dev-br_port and the
actual freeing of the br_port object through a quiescent state. This
is already achieved by the RCU call further down.
That breaks because of the race (found by Xen) where an interface
is being deleted from a bridge and the device is being removed.
br_del_if
rmmod device
netlink event
br_device_event
...
Sorry, I don't get it. How does adding a barrier in del_nbp
fix this bug?
In fact, as far as I can see, you need to add a pair of
rcu_read_lock/rcu_read_unlock in br_device_event to make it
work.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: If someone has a reverse-engineered HAL that might could be used as well. From a quick look at the HAL asm code (mips-le), I think symbol names are obfuscated. So reverse engineering is Not Easy (tm). -- Greetings Michael. pgp14dkWxsSrf.pgp Description: PGP signature
Re: [PATCH netdev-2.6 30/39] e1000: Added variable to handle return values for pci_enable_* functions
On Wed, Jan 11, Jeff Kirsher wrote:
Added variable to handle return values for pci_enable_* functions
This was to fix compilation warnings. Also added log messages when
pci_enable_* functions return with an error.
I object to this patch.
Useless error messages for unhandled return values. Please revert that
part.
No idea if every system in the world is supposed to implement D3 and
friends. But for me it always returns -22. Maybe because I'm short on
A20 gates.
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 75cd6df..8207db4 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4382,6 +4382,7 @@ e1000_suspend(struct pci_dev *pdev, pm_m
struct e1000_adapter *adapter = netdev_priv(netdev);
uint32_t ctrl, ctrl_ext, rctl, manc, status;
uint32_t wufc = adapter-wol;
+ int retval = 0;
netif_device_detach(netdev);
@@ -4427,13 +4428,21 @@ e1000_suspend(struct pci_dev *pdev, pm_m
E1000_WRITE_REG(adapter-hw, WUC, E1000_WUC_PME_EN);
E1000_WRITE_REG(adapter-hw, WUFC, wufc);
- pci_enable_wake(pdev, 3, 1);
- pci_enable_wake(pdev, 4, 1); /* 4 == D3 cold */
+ retval = pci_enable_wake(pdev, PCI_D3hot, 1);
+ if (retval)
+ DPRINTK(PROBE, ERR, Error enabling D3 wake\n);
+ retval = pci_enable_wake(pdev, PCI_D3cold, 1);
+ if (retval)
+ DPRINTK(PROBE, ERR, Error enabling D3 cold wake\n);
} else {
E1000_WRITE_REG(adapter-hw, WUC, 0);
E1000_WRITE_REG(adapter-hw, WUFC, 0);
- pci_enable_wake(pdev, 3, 0);
- pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
+ retval = pci_enable_wake(pdev, PCI_D3hot, 0);
+ if (retval)
+ DPRINTK(PROBE, ERR, Error enabling D3 wake\n);
+ retval = pci_enable_wake(pdev, PCI_D3cold, 0); /* 4 == D3 cold
*/
+ if (retval)
+ DPRINTK(PROBE, ERR, Error enabling D3 cold wake\n);
}
...
--
short story of a lazy sysadmin:
alias appserv=wotan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Bridge: RCU barriers
On Fri, Jan 27, 2006 at 07:33:24AM +1100, herbert wrote:
That breaks because of the race (found by Xen) where an interface
is being deleted from a bridge and the device is being removed.
br_del_if
rmmod device
netlink event
br_device_event
...
Sorry, I don't get it. How does adding a barrier in del_nbp
fix this bug?
In fact, as far as I can see, you need to add a pair of
rcu_read_lock/rcu_read_unlock in br_device_event to make it
work.
Actually, this race shouldn't exist anyway because both br_del_if
and br_device_event are meant to be called under the RTNL. So
what's going on here?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] net/tipc/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
- name_table.c: tipc_nametbl_print()
- name_table.c: tipc_nametbl_dump()
- net.c: tipc_net_next_node()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
net/tipc/bcast.c |9 +
net/tipc/cluster.c| 11 +--
net/tipc/discover.c |8
net/tipc/name_table.c | 27 ++-
net/tipc/net.c|3 ++-
net/tipc/node.c |2 +-
6 files changed, 35 insertions(+), 25 deletions(-)
--- linux-2.6.16-rc1-mm3-full/net/tipc/bcast.c.old 2006-01-26
06:56:41.0 +0100
+++ linux-2.6.16-rc1-mm3-full/net/tipc/bcast.c 2006-01-26 06:57:33.0
+0100
@@ -314,7 +314,8 @@
* Only tipc_net_lock set.
*/
-void tipc_bclink_peek_nack(u32 dest, u32 sender_tag, u32 gap_after, u32 gap_to)
+static void tipc_bclink_peek_nack(u32 dest, u32 sender_tag, u32 gap_after,
+ u32 gap_to)
{
struct node *n_ptr = tipc_node_find(dest);
u32 my_after, my_to;
@@ -525,9 +526,9 @@
* Returns 0 if packet sent successfully, non-zero if not
*/
-int tipc_bcbearer_send(struct sk_buff *buf,
- struct tipc_bearer *unused1,
- struct tipc_media_addr *unused2)
+static int tipc_bcbearer_send(struct sk_buff *buf,
+ struct tipc_bearer *unused1,
+ struct tipc_media_addr *unused2)
{
static int send_count = 0;
--- linux-2.6.16-rc1-mm3-full/net/tipc/cluster.c.old2006-01-26
06:57:51.0 +0100
+++ linux-2.6.16-rc1-mm3-full/net/tipc/cluster.c2006-01-26
06:58:31.0 +0100
@@ -44,9 +44,8 @@
#include msg.h
#include bearer.h
-void tipc_cltr_multicast(struct cluster *c_ptr, struct sk_buff *buf,
-u32 lower, u32 upper);
-struct sk_buff *tipc_cltr_prepare_routing_msg(u32 data_size, u32 dest);
+static void tipc_cltr_multicast(struct cluster *c_ptr, struct sk_buff *buf,
+ u32 lower, u32 upper);
struct node **tipc_local_nodes = 0;
struct node_map tipc_cltr_bcast_nodes = {0,{0,}};
@@ -229,7 +228,7 @@
*Routing table management: See description in node.c
*/
-struct sk_buff *tipc_cltr_prepare_routing_msg(u32 data_size, u32 dest)
+static struct sk_buff *tipc_cltr_prepare_routing_msg(u32 data_size, u32 dest)
{
u32 size = INT_H_SIZE + data_size;
struct sk_buff *buf = buf_acquire(size);
@@ -495,8 +494,8 @@
* tipc_cltr_multicast - multicast message to local nodes
*/
-void tipc_cltr_multicast(struct cluster *c_ptr, struct sk_buff *buf,
-u32 lower, u32 upper)
+static void tipc_cltr_multicast(struct cluster *c_ptr, struct sk_buff *buf,
+ u32 lower, u32 upper)
{
struct sk_buff *buf_copy;
struct node *n_ptr;
--- linux-2.6.16-rc1-mm3-full/net/tipc/discover.c.old 2006-01-26
06:59:53.0 +0100
+++ linux-2.6.16-rc1-mm3-full/net/tipc/discover.c 2006-01-26
07:00:05.0 +0100
@@ -110,10 +110,10 @@
* @b_ptr: ptr to bearer issuing message
*/
-struct sk_buff *tipc_disc_init_msg(u32 type,
- u32 req_links,
- u32 dest_domain,
- struct bearer *b_ptr)
+static struct sk_buff *tipc_disc_init_msg(u32 type,
+ u32 req_links,
+ u32 dest_domain,
+ struct bearer *b_ptr)
{
struct sk_buff *buf = buf_acquire(DSC_H_SIZE);
struct tipc_msg *msg;
--- linux-2.6.16-rc1-mm3-full/net/tipc/name_table.c.old 2006-01-26
07:00:49.0 +0100
+++ linux-2.6.16-rc1-mm3-full/net/tipc/name_table.c 2006-01-26
07:03:54.0 +0100
@@ -46,7 +46,7 @@
#include cluster.h
#include bcast.h
-int tipc_nametbl_size = 1024; /* must be a power of 2 */
+static int tipc_nametbl_size = 1024; /* must be a power of 2 */
/**
* struct sub_seq - container for all published instances of a name sequence
@@ -142,7 +142,7 @@
* tipc_subseq_alloc - allocate a specified number of sub-sequence structures
*/
-struct sub_seq *tipc_subseq_alloc(u32 cnt)
+static struct sub_seq *tipc_subseq_alloc(u32 cnt)
{
u32 sz = cnt * sizeof(struct sub_seq);
struct sub_seq *sseq = (struct sub_seq *)kmalloc(sz, GFP_ATOMIC);
@@ -158,7 +158,8 @@
* Allocates a single sub-sequence structure and sets it to all 0's.
*/
-struct name_seq *tipc_nameseq_create(u32 type, struct hlist_head *seq_head)
+static struct name_seq *tipc_nameseq_create(u32 type,
+ struct hlist_head *seq_head)
{
struct name_seq *nseq =
(struct name_seq *)kmalloc(sizeof(*nseq), GFP_ATOMIC);
@@ -243,9 +244,11 @@
* tipc_nameseq_insert_publ -
*/
[2/10] remove ISA legacy functions: drivers/net/arcnet/
From: Al Viro [EMAIL PROTECTED]
sanitized probing code, made sure we claim regions before poking into
them (original tried that to some extent, but hadn't got it right),
switched to ioremap() use in probing.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/arcnet/arc-rimi.c | 68 +++--
drivers/net/arcnet/com90xx.c | 132 +
2 files changed, 143 insertions(+), 57 deletions(-)
6a0100f551bbd751fba9d68575dcb15e5554e130
diff --git a/drivers/net/arcnet/arc-rimi.c b/drivers/net/arcnet/arc-rimi.c
--- a/drivers/net/arcnet/arc-rimi.c
+++ b/drivers/net/arcnet/arc-rimi.c
@@ -97,25 +97,44 @@ static int __init arcrimi_probe(struct n
must specify the shmem and irq!\n);
return -ENODEV;
}
+ if (dev-dev_addr[0] == 0) {
+ BUGMSG(D_NORMAL, You need to specify your card's station
+ ID!\n);
+ return -ENODEV;
+ }
/*
-* Grab the memory region at mem_start for BUFFER_SIZE bytes.
+* Grab the memory region at mem_start for MIRROR_SIZE bytes.
* Later in arcrimi_found() the real size will be determined
* and this reserve will be released and the correct size
* will be taken.
*/
- if (!request_mem_region(dev-mem_start, BUFFER_SIZE, arcnet (90xx))) {
+ if (!request_mem_region(dev-mem_start, MIRROR_SIZE, arcnet (90xx))) {
BUGMSG(D_NORMAL, Card memory already allocated\n);
return -ENODEV;
}
- if (dev-dev_addr[0] == 0) {
- release_mem_region(dev-mem_start, BUFFER_SIZE);
- BUGMSG(D_NORMAL, You need to specify your card's station
- ID!\n);
- return -ENODEV;
- }
return arcrimi_found(dev);
}
+static int check_mirror(unsigned long addr, size_t size)
+{
+ void __iomem *p;
+ int res = -1;
+
+ if (!request_mem_region(addr, size, arcnet (90xx)))
+ return -1;
+
+ p = ioremap(addr, size);
+ if (p) {
+ if (readb(p) == TESTvalue)
+ res = 1;
+ else
+ res = 0;
+ iounmap(p);
+ }
+
+ release_mem_region(addr, size);
+ return res;
+}
/*
* Set up the struct net_device associated with this card. Called after
@@ -125,19 +144,28 @@ static int __init arcrimi_found(struct n
{
struct arcnet_local *lp;
unsigned long first_mirror, last_mirror, shmem;
+ void __iomem *p;
int mirror_size;
int err;
+ p = ioremap(dev-mem_start, MIRROR_SIZE);
+ if (!p) {
+ release_mem_region(dev-mem_start, MIRROR_SIZE);
+ BUGMSG(D_NORMAL, Can't ioremap\n);
+ return -ENODEV;
+ }
+
/* reserve the irq */
if (request_irq(dev-irq, arcnet_interrupt, 0, arcnet (RIM I), dev))
{
- release_mem_region(dev-mem_start, BUFFER_SIZE);
+ iounmap(p);
+ release_mem_region(dev-mem_start, MIRROR_SIZE);
BUGMSG(D_NORMAL, Can't get IRQ %d!\n, dev-irq);
return -ENODEV;
}
shmem = dev-mem_start;
- isa_writeb(TESTvalue, shmem);
- isa_writeb(dev-dev_addr[0], shmem + 1);/* actually the node ID
*/
+ writeb(TESTvalue, p);
+ writeb(dev-dev_addr[0], p + 1);/* actually the node ID */
/* find the real shared memory start/end points, including mirrors */
@@ -146,17 +174,18 @@ static int __init arcrimi_found(struct n
* 2k (or there are no mirrors at all) but on some, it's 4k.
*/
mirror_size = MIRROR_SIZE;
- if (isa_readb(shmem) == TESTvalue
-isa_readb(shmem - mirror_size) != TESTvalue
-isa_readb(shmem - 2 * mirror_size) == TESTvalue)
- mirror_size *= 2;
+ if (readb(p) == TESTvalue
+check_mirror(shmem - MIRROR_SIZE, MIRROR_SIZE) == 0
+check_mirror(shmem - 2 * MIRROR_SIZE, MIRROR_SIZE) == 1)
+ mirror_size = 2 * MIRROR_SIZE;
- first_mirror = last_mirror = shmem;
- while (isa_readb(first_mirror) == TESTvalue)
+ first_mirror = shmem - mirror_size;
+ while (check_mirror(first_mirror, mirror_size) == 1)
first_mirror -= mirror_size;
first_mirror += mirror_size;
- while (isa_readb(last_mirror) == TESTvalue)
+ last_mirror = shmem + mirror_size;
+ while (check_mirror(last_mirror, mirror_size) == 1)
last_mirror += mirror_size;
last_mirror -= mirror_size;
@@ -181,7 +210,8 @@ static int __init arcrimi_found(struct n
* with the correct size. There is a VERY slim chance this could
* fail.
*/
- release_mem_region(shmem, BUFFER_SIZE);
+ iounmap(p);
+
[5/10] remove ISA legacy functions: drivers/net/hp-plus.c
From: Al Viro [EMAIL PROTECTED]
switch to ioremap()
Adrian Bunk:
The order of the hunks in the patch was slightly rearranged due to an
unrelated change in the driver.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/hp-plus.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
202702a915ccef02d54b57e39a4545e4f310ac76
diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
--- a/drivers/net/hp-plus.c
+++ b/drivers/net/hp-plus.c
@@ -256,6 +257,12 @@ static int __init hpp_probe1(struct net_
ei_status.block_output = hpp_mem_block_output;
ei_status.get_8390_hdr = hpp_mem_get_8390_hdr;
dev-mem_start = mem_start;
+ ei_status.mem = ioremap(mem_start,
+ (HP_STOP_PG - HP_START_PG)*256);
+ if (!ei_status.mem) {
+ retval = -ENOMEM;
+ goto out;
+ }
ei_status.rmem_start = dev-mem_start + TX_PAGES/2*256;
dev-mem_end = ei_status.rmem_end
= dev-mem_start + (HP_STOP_PG - HP_START_PG)*256;
@@ -268,8 +275,10 @@ static int __init hpp_probe1(struct net_
retval = register_netdev(dev);
if (retval)
- goto out;
+ goto out1;
return 0;
+out1:
+ iounmap(ei_status.mem);
out:
release_region(ioaddr, HP_IO_EXTENT);
return retval;
@@ -378,7 +387,7 @@ hpp_mem_get_8390_hdr(struct net_device *
outw((ring_page8), ioaddr + HPP_IN_ADDR);
outw(option_reg ~(MemDisable + BootROMEnb), ioaddr + HPP_OPTION);
- isa_memcpy_fromio(hdr, dev-mem_start, sizeof(struct e8390_pkt_hdr));
+ memcpy_fromio(hdr, ei_status.mem, sizeof(struct e8390_pkt_hdr));
outw(option_reg, ioaddr + HPP_OPTION);
hdr-count = (le16_to_cpu(hdr-count) + 3) ~3;/* Round up
allocation. */
}
@@ -397,7 +406,7 @@ hpp_mem_block_input(struct net_device *d
Also note that we *can't* use eth_io_copy_and_sum() because
it will not always copy count bytes (e.g. padded IP). */
- isa_memcpy_fromio(skb-data, dev-mem_start, count);
+ memcpy_fromio(skb-data, ei_status.mem, count);
outw(option_reg, ioaddr + HPP_OPTION);
}
@@ -422,7 +431,7 @@ hpp_mem_block_output(struct net_device *
outw(start_page 8, ioaddr + HPP_OUT_ADDR);
outw(option_reg ~(MemDisable + BootROMEnb), ioaddr + HPP_OPTION);
- isa_memcpy_toio(dev-mem_start, buf, (count + 3) ~3);
+ memcpy_toio(ei_status.mem, buf, (count + 3) ~3);
outw(option_reg, ioaddr + HPP_OPTION);
return;
@@ -541,6 +541,7 @@ static int __init do_hpp_probe(struct ne
static void cleanup_card(struct net_device *dev)
{
/* NB: hpp_close() handles free_irq */
+ iounmap(ei_status.mem);
release_region(dev-base_addr - NIC_OFFSET, HP_IO_EXTENT);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[6/10] remove ISA legacy functions: drivers/net/hp100.c
From: Al Viro [EMAIL PROTECTED]
hp100 has -mem_ptr_virt set for all memory-mapped cases; removed
rudiment of old version that used ioremap() only when physical
address wasn't an ISA one. These days it's simply a dead code.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/hp100.c | 30 --
1 files changed, 8 insertions(+), 22 deletions(-)
c9a2c709fa782a0dd7b1bbb0160b325e446ae523
diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -1718,17 +1718,10 @@ static int hp100_start_xmit(struct sk_bu
hp100_outw(i, FRAGMENT_LEN);/* and first/only fragment length*/
if (lp-mode == 2) {/* memory mapped */
- if (lp-mem_ptr_virt) { /* high pci memory was remapped */
- /* Note: The J2585B needs alignment to 32bits here! */
- memcpy_toio(lp-mem_ptr_virt, skb-data, (skb-len + 3)
~3);
- if (!ok_flag)
- memset_io(lp-mem_ptr_virt, 0,
HP100_MIN_PACKET_SIZE - skb-len);
- } else {
- /* Note: The J2585B needs alignment to 32bits here! */
- isa_memcpy_toio(lp-mem_ptr_phys, skb-data, (skb-len
+ 3) ~3);
- if (!ok_flag)
- isa_memset_io(lp-mem_ptr_phys, 0,
HP100_MIN_PACKET_SIZE - skb-len);
- }
+ /* Note: The J2585B needs alignment to 32bits here! */
+ memcpy_toio(lp-mem_ptr_virt, skb-data, (skb-len + 3) ~3);
+ if (!ok_flag)
+ memset_io(lp-mem_ptr_virt, 0, HP100_MIN_PACKET_SIZE -
skb-len);
} else {/* programmed i/o */
outsl(ioaddr + HP100_REG_DATA32, skb-data,
(skb-len + 3) 2);
@@ -1798,10 +1791,7 @@ static void hp100_rx(struct net_device *
/* First we get the header, which contains information about
the */
/* actual length of the received packet. */
if (lp-mode == 2) {/* memory mapped mode */
- if (lp-mem_ptr_virt) /* if memory was remapped */
- header = readl(lp-mem_ptr_virt);
- else
- header = isa_readl(lp-mem_ptr_phys);
+ header = readl(lp-mem_ptr_virt);
} else /* programmed i/o */
header = hp100_inl(DATA32);
@@ -1833,13 +1823,9 @@ static void hp100_rx(struct net_device *
ptr = skb-data;
/* Now transfer the data from the card into that area */
- if (lp-mode == 2) {
- if (lp-mem_ptr_virt)
- memcpy_fromio(ptr,
lp-mem_ptr_virt,pkt_len);
- /* Note alignment to 32bit transfers */
- else
- isa_memcpy_fromio(ptr,
lp-mem_ptr_phys, pkt_len);
- } else /* io mapped */
+ if (lp-mode == 2)
+ memcpy_fromio(ptr, lp-mem_ptr_virt,pkt_len);
+ else/* io mapped */
insl(ioaddr + HP100_REG_DATA32, ptr, pkt_len
2);
skb-protocol = eth_type_trans(skb, dev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Netlink] DEBUG socket or device?
It might be, that arranging a DEBUG NETLINK socket to direct to it, when enabled, copies of all netlink messages (better to exclude a really bulk traffic like netfilter packet log) That emphasizes the need to know the identity of the source emitting the packet. I see in RFC3549 : Process ID (PID): 32 bits The PID of the process sending the message. The PID is used by the kernel to multiplex to the correct sockets. A PID of zero is used when sending messages to user space from the kernel. However what is actually implemented is the opposite. Anyone willing to comment that ? Having the source pid could have be cool for filtering purpose. , will be a more standardized solution. Thus, the hook in netlink_sendmsg will just send a one more copy of a unicast and include the DEBUG_NETLINK socket to a multicast. I'm not sure I get it. What do you mean by include DEBUG_NETLINK socket to a multicast ? It looks like a cycling problem using another netlink socket to transport netlink traffic. Redirecting the traffic to a net device is interesting in a way because you already have userspace tools (sniffers), and just need to add netlink protocol dissectors to them. With the ability to send to an interface, you could imagine doing stuff like sending netlink messages over a network. Looks like one of netlink2 features... Sniffing kernel packets via such netlink sockets actually may be extended for the unix-domain traffic as well. sure, that may be extended to unix sockets without too much difficulties. What I wonder is if people are really interested in such a debug feature. Cheers. -- Mathieu Geli - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Bridge: RCU barriers
On Fri, 27 Jan 2006 09:29:12 +1100 Herbert Xu [EMAIL PROTECTED] wrote: On Fri, Jan 27, 2006 at 07:33:24AM +1100, herbert wrote: That breaks because of the race (found by Xen) where an interface is being deleted from a bridge and the device is being removed. br_del_if rmmod device netlink event br_device_event ... Sorry, I don't get it. How does adding a barrier in del_nbp fix this bug? In fact, as far as I can see, you need to add a pair of rcu_read_lock/rcu_read_unlock in br_device_event to make it work. Actually, this race shouldn't exist anyway because both br_del_if and br_device_event are meant to be called under the RTNL. So what's going on here? Well, it was before I changed del_nbp to set dev-br_port to NULL. So what br_del_if would get called twice for same port. -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Bridge: RCU barriers
Plan B:
1. Use p-br (the back pointer) as the RCU sentinel
2. Keep dev-br_port set until after the RCU transition
3. Order operations so we don't have to worry about p-br being NULL
in the case of STP timers.
Untested. Probably excessive use of rcu() macros. Since it is only
needed in cases where no locks held (ie. !(RTNL | br_lock))
--- br-fix.orig/net/bridge/br_fdb.c
+++ br-fix/net/bridge/br_fdb.c
@@ -67,9 +67,9 @@ static __inline__ void fdb_delete(struct
br_fdb_put(f);
}
-void br_fdb_changeaddr(struct net_bridge_port *p, const unsigned char *newaddr)
+void br_fdb_changeaddr(struct net_bridge *br, struct net_bridge_port *p,
+ const unsigned char *newaddr)
{
- struct net_bridge *br = p-br;
int i;
spin_lock_bh(br-hash_lock);
--- br-fix.orig/net/bridge/br_if.c
+++ br-fix/net/bridge/br_if.c
@@ -79,24 +79,31 @@ static int port_cost(struct net_device *
*/
static void port_carrier_check(void *arg)
{
- struct net_bridge_port *p = arg;
+ struct net_device *dev = arg;
+ struct net_bridge_port *p;
+ struct net_bridge *br;
rtnl_lock();
- if (netif_carrier_ok(p-dev)) {
- u32 cost = port_cost(p-dev);
+ if ((p = dev-br_port) == NULL ||
+ (br = rcu_dereference(p-br)) == NULL)
+ goto done;
- spin_lock_bh(p-br-lock);
+ if (netif_carrier_ok(dev)) {
+ u32 cost = port_cost(dev);
+
+ spin_lock_bh(br-lock);
if (p-state == BR_STATE_DISABLED) {
p-path_cost = cost;
br_stp_enable_port(p);
}
- spin_unlock_bh(p-br-lock);
+ spin_unlock_bh(br-lock);
} else {
- spin_lock_bh(p-br-lock);
+ spin_lock_bh(br-lock);
if (p-state != BR_STATE_DISABLED)
br_stp_disable_port(p);
- spin_unlock_bh(p-br-lock);
+ spin_unlock_bh(br-lock);
}
+done:
rtnl_unlock();
}
@@ -104,7 +111,7 @@ static void destroy_nbp(struct net_bridg
{
struct net_device *dev = p-dev;
- p-br = NULL;
+ dev-br_port = NULL;
p-dev = NULL;
dev_put(dev);
@@ -119,29 +126,25 @@ static void destroy_nbp_rcu(struct rcu_h
}
/* called with RTNL */
-static void del_nbp(struct net_bridge_port *p)
+static void del_nbp(struct net_bridge *br, struct net_bridge_port *p)
{
- struct net_bridge *br = p-br;
- struct net_device *dev = p-dev;
-
- dev-br_port = NULL;
- dev_set_promiscuity(dev, -1);
+ dev_set_promiscuity(p-dev, -1);
cancel_delayed_work(p-carrier_check);
- flush_scheduled_work();
spin_lock_bh(br-lock);
br_stp_disable_port(p);
+ list_del_rcu(p-list);
spin_unlock_bh(br-lock);
br_fdb_delete_by_port(br, p);
- list_del_rcu(p-list);
-
del_timer_sync(p-message_age_timer);
del_timer_sync(p-forward_delay_timer);
del_timer_sync(p-hold_timer);
+ rcu_assign_pointer(p-br, NULL);
+
call_rcu(p-rcu, destroy_nbp_rcu);
}
@@ -152,7 +155,7 @@ static void del_br(struct net_bridge *br
list_for_each_entry_safe(p, n, br-port_list, list) {
br_sysfs_removeif(p);
- del_nbp(p);
+ del_nbp(br, p);
}
del_timer_sync(br-gc_timer);
@@ -249,7 +252,7 @@ static struct net_bridge_port *new_nbp(s
p-port_no = index;
br_init_port(p);
p-state = BR_STATE_DISABLED;
- INIT_WORK(p-carrier_check, port_carrier_check, p);
+ INIT_WORK(p-carrier_check, port_carrier_check, dev);
kobject_init(p-kobj);
return p;
@@ -386,7 +389,7 @@ int br_add_if(struct net_bridge *br, str
destroy_nbp(p);
else if ((err = br_sysfs_addif(p)))
- del_nbp(p);
+ del_nbp(br, p);
else {
dev_set_promiscuity(dev, 1);
@@ -415,7 +418,7 @@ int br_del_if(struct net_bridge *br, str
return -EINVAL;
br_sysfs_removeif(p);
- del_nbp(p);
+ del_nbp(br, p);
spin_lock_bh(br-lock);
br_stp_recalculate_bridge_id(br);
--- br-fix.orig/net/bridge/br_input.c
+++ br-fix/net/bridge/br_input.c
@@ -46,17 +46,19 @@ int br_handle_frame_finish(struct sk_buf
{
const unsigned char *dest = eth_hdr(skb)-h_dest;
struct net_bridge_port *p = skb-dev-br_port;
- struct net_bridge *br = p-br;
+ struct net_bridge *br;
struct net_bridge_fdb_entry *dst;
int passedup = 0;
+ br = rcu_dereference(p-br);
+ if (!br)
+ goto drop;
+
/* insert into forwarding database after filtering to avoid spoofing */
- br_fdb_update(p-br, p, eth_hdr(skb)-h_source);
+ br_fdb_update(br, p, eth_hdr(skb)-h_source);
- if (p-state == BR_STATE_LEARNING) {
-
Re: wireless-2.6 status (25 January 2006)
Michael Buesch wrote: On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: If someone has a reverse-engineered HAL that might could be used as well. From a quick look at the HAL asm code (mips-le), I think symbol names are obfuscated. So reverse engineering is Not Easy (tm). No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Bridge: RCU barriers
On Thu, Jan 26, 2006 at 03:01:00PM -0800, Stephen Hemminger wrote:
Well, it was before I changed del_nbp to set dev-br_port to NULL.
So what br_del_if would get called twice for same port.
Right. I wasn't questioning the zeroing of dev-br_port. I was
just saying that placing a barrier using rcu_assign_pointer when
you're setting it to NULL is useless because the mechanism that is
required here is the quiescent state.
On the other hand, when we set dev-br_port to a non-NULL value
we do need the barrier.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Bridge: RCU barriers
On Thu, Jan 26, 2006 at 03:05:54PM -0800, Stephen Hemminger wrote:
Plan B:
1. Use p-br (the back pointer) as the RCU sentinel
2. Keep dev-br_port set until after the RCU transition
3. Order operations so we don't have to worry about p-br being NULL
in the case of STP timers.
This sounds like a good plan. I'll go over it later today.
Thanks Stephen,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
Michael Buesch wrote: On Friday 27 January 2006 00:10, you wrote: No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. I don't know. The bcm firmware may have a way to keep users from doing (very) wrong things, as evidently the intel wifi firmware does. It seems that the Atheros firmware is not smart enough to enforce enough restrictions. As to who could be found at fault..I'm not sure. But since all the rest of madwifi is open-source (and seems to get good support from Atheros), I can't really see why they'd close the HAL just for the hell of it. At any rate, any wisdom I might have on the matter was picked up from reading their FAQ..so you might want to just check that out directly. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
Cum 27 Oca 2006 01:45 tarihinde, Michael Buesch şunları yazmıştı: On Friday 27 January 2006 00:10, you wrote: Michael Buesch wrote: On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: If someone has a reverse-engineered HAL that might could be used as well. From a quick look at the HAL asm code (mips-le), I think symbol names are obfuscated. So reverse engineering is Not Easy (tm). No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. Well with a simple analogy, selling knife is illegal too, so you can go and kill someone with that knife... /ismail - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wireless-2.6 status (25 January 2006)
In order to get FCC certification the manufacturer must ensure there is no easy way for the user to tune to illegal frequencies. Broadcom has done their job - it was not easy to reverse engineer their driver. Now the cat is out of the bag. The open source driver is not illegal - although it may be illegal to use it - since the chipset and driver were likely certified together. I'm no expert in FCC regulation, so take all of this with a pinch of salt. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Thursday, January 26, 2006 3:46 PM To: Ben Greear Cc: David Hollis; John W. Linville; Samuel Ortiz; netdev@vger.kernel.org Subject: Re: wireless-2.6 status (25 January 2006) On Friday 27 January 2006 00:10, you wrote: Michael Buesch wrote: On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: If someone has a reverse-engineered HAL that might could be used as well. From a quick look at the HAL asm code (mips-le), I think symbol names are obfuscated. So reverse engineering is Not Easy (tm). No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Friday 27 January 2006 01:04, you wrote: In order to get FCC certification the manufacturer must ensure there is no easy way for the user to tune to illegal frequencies. Broadcom has done their job - it was not easy to reverse engineer their driver. Now the cat is out of the bag. The open source driver is not illegal - although it may be illegal to use it - since the chipset and driver were likely certified together. I'm no expert in FCC regulation, so take all of this with a pinch of salt. Ah, I see your point. I remember something like the following from the old 2.4 days (no idea if it still applies to the 2.6 drivers). An MD5 checksum of the lowlevel HiSax ISDN drivers was certified. So if you modify the source (which is allowed by the GPL), you would loose certification. -- Greetings Michael. pgpFcQO1Obgsg.pgp Description: PGP signature
Re: [IPV4]: Always set fl.proto in ip_route_newports
On Thu, Jan 26, 2006 at 03:25:17PM +0100, Patrick McHardy wrote:
[IPV4]: Always set fl.proto in ip_route_newports
ip_route_newports uses the struct flowi from the struct rtable returned
by ip_route_connect for the new route lookup and just replaces the port
numbers if they have changed. If an IPsec policy exists which doesn't match
port 0 the struct flowi won't have the proto field set and no xfrm lookup
is done for the changed ports.
Thanks Patrick, the patch looks good to me. However, I think the rationale
given above isn't quite right. If the original dst is actually IPsec, the
protocol field should always be set regardless of whether the policy that
triggered it has a protocol or not.
So I thnk the case where it's really needed is if the original dst is not
IPsec. In that case the protocol won't be set since the routing cache
doesn't have it as a key.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]ip_options_fragment() has no effect on fragmentation
[1]Summary of the problem:
ip_options_fragment() has no effect on fragmentation
[2]Full description of the problem:
When I send IPv4 packet(contain Record Route Option) which need to be
fragmented to the router, the router can not fragment it correctly.
After fragmented by router, the second fragmentation still contain Record
Route Option. Refer to RFC791, Record Route Option must Not be copied on
fragmentation, goes in first fragment only.
ip_options_fragment() is the implemental function, but there are some BUGs
in it:
ip_option.c: line 207:
void ip_options_fragment(struct sk_buff * skb)
{
unsigned char * optptr = skb-nh.raw;
struct ip_options * opt = (IPCB(skb)-opt);...
optptr get a error pointer to the ipv4 options, now it is pointer to the
IPv4 header, correct is as following:
unsigned char * optptr = skb-nh.raw + sizeof(struct iphdr);
Following is the patch：
--- linux-2.6.15.1/net/ipv4/ip_options.c.orig 2006-01-27 09:14:33.463612696
+0900
+++ linux-2.6.15.1/net/ipv4/ip_options.c 2006-01-27 09:12:21.857619848 +0900
@@ -207,7 +207,7 @@
void ip_options_fragment(struct sk_buff * skb)
{
-unsigned char * optptr = skb-nh.raw;
+unsigned char * optptr = skb-nh.raw + sizeof(struct iphdr);
struct ip_options * opt = (IPCB(skb)-opt);
int l = opt-optlen;
int optlen;
Regards
--
Wei Yongjun
FUJITSU INTERNAL：7124-2865
[EMAIL PROTECTED]
--
ip_options_fragment.patch
Description: Binary data
Re: wireless-2.6 status (25 January 2006)
John W. Linville wrote: On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote: David Hollis wrote: I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. The HAL is not real firmware..just normal kernel code. I wonder if you could get around this by using a sort of CPU emulator and/or virtual machine and load the HAL 'firmware' into that? brainstorm Any chance the driver could be rearchitected w/ the HAL functionality moved into a userland helper? I haven't even looked at the driver to see if this could be practical...? /brainstorm OpenBSD has an open source HAL, IIRC. You could use that as reference, if nothing else. There are apparently several variant of the chip, making some level of abstraction useful in this case, not just for hiding hardware details. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
Ben Greear wrote: Michael Buesch wrote: On Friday 27 January 2006 00:10, you wrote: No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. I don't know. The bcm firmware may have a way to keep users from doing (very) wrong things, as evidently the intel wifi firmware does. It seems that the Atheros firmware is not smart enough to enforce enough restrictions. As to who could be found at fault..I'm not sure. But since all the rest of madwifi is open-source (and seems to get good support from Atheros), I can't really see why they'd close the HAL just for the hell of it. This issue will come up again and again. Linux needs to provide functionality a la ieee80211_geo, whereby you can choose from acceptable frequencies for your location. As Alan Cox has pointed out, this may be a /etc setting, something that may be overridden by the AP. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
wireless geo stuff (was Re: wireless-2.6 status (25 January 2006))
Simon Barber wrote: In order to get FCC certification the manufacturer must ensure there is no easy way for the user to tune to illegal frequencies. Broadcom has done their job - it was not easy to reverse engineer their driver. Now the cat is out of the bag. The open source driver is not illegal - although it may be illegal to use it - since the chipset and driver were likely certified together. I'm no expert in FCC regulation, so take all of this with a pinch of salt. First, kernel developers should do the best they can to provide facilities to limit the frequencies, including sane and safe defaults for the softmac cases. It just makes sense to do that, from a friendly neighbor and don't operate out of spec perspective, if nothing else. It's damned _rude_ to use channels other than the ones selected by the Responsible Authority. Some ham radio operator -- like me -- might be using that frequency to carry on a pleasant Morse code conversation with someone else halfway across the world. Linux software shalt not be rude. :) Second, if someone takes steps to disable these safeguards we build in, that's akin to putting illegal crystals into a radio, or tuning a transmitter to police/emergency bands. Finally, binary-only software is clearly _not_ a barrier to this sort of circumvention. Reverse engineering x86 software is a skill that's very widespread, relative to other sorts of reverse engineering. Reverse engineering tools for the x86 are very mature these days, having had two decades to grow and flourish. If the _hardware_ can be programmed maliciously, there's not a whole lot you can do about it... particularly when the hardware manufacturer chooses a method of obfuscation (x86 code) practically designed for easy analysis. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.15-rc 1/1] sundance: Really read addr 0
Arnaldo Carvalho de Melo wrote: Hi Jeff, Please apply: Make phy 0 actually be read, as it is not being right now as we have: int mii_status = mdio_read(dev, phy, MII_BMSR); int phyx = phy 0x1f; When we should have instead: int phyx = phy 0x1f; int mii_status = mdio_read(dev, phyx, MII_BMSR); so that when phy, in the end of the (phy = 1; phy = 32...) loop gets to 32 phyx gets to 0, i.e. we were reading at 32, when the intended read was for 0. Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.
On Wed, Jan 25, 2006 at 08:12:02PM +, Eric W. Biederman wrote:
Unfortunately because we have already call rt6_ifdown() the route is
not found in the routing table, the dst_free does not decrement the
count and is therefore unable to free the dst entry because the count
is still elevated.
If rt6_ifdown has already kicked the route out, then the dst ref count
should be zero. Even if someone is still holding onto it dst_free will
attach the entry to the GC list which means that it'll be freed when it
eventually does hit zero.
The ref count held by ipv6_ifa_notify is dropped by ip6_del_rt in case
of an error.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fib_rules w. RCU lock [PATCH]
From: Robert Olsson [EMAIL PROTECTED]
Date: Thu, 22 Dec 2005 10:51:46 +0100
@@ -219,28 +230,27 @@
if (rta[RTA_FLOW-1])
memcpy(new_r-r_tclassid, RTA_DATA(rta[RTA_FLOW-1]), 4);
#endif
-
- rp = fib_rules;
+ r = (struct fib_rule *) fib_rules.first;
if (!new_r-r_preference) {
- r = fib_rules;
- if (r (r = r-r_next) != NULL) {
- rp = fib_rules-r_next;
+ if (r r-hlist.next != NULL) {
+ r = (struct fib_rule *) r-hlist.next;
if (r-r_preference)
new_r-r_preference = r-r_preference - 1;
}
}
I don't think this is right.
fib_rules.first is a pointer to the hlist_node (within the fib_rule)
not the fib_rule itself.
- for (r=fib_rules; r; r=r-r_next) {
+ hlist_for_each_entry(r, node, fib_rules, hlist) {
if (r-r_ifindex == dev-ifindex) {
- write_lock_bh(fib_rules_lock);
+ preempt_disable();
r-r_ifindex = -1;
- write_unlock_bh(fib_rules_lock);
+ preempt_enable();
}
}
What is the preempt_disable() actually protecting here?
It's a simple assignment to -1, and since the disable
occurs inside the ifindex test, it is not protecting
that either.
- for (r=fib_rules; r; r=r-r_next) {
+ hlist_for_each_entry(r, node, fib_rules, hlist) {
if (r-r_ifindex == -1 strcmp(dev-name, r-r_ifname) == 0) {
- write_lock_bh(fib_rules_lock);
+ preempt_disable();
r-r_ifindex = dev-ifindex;
- write_unlock_bh(fib_rules_lock);
+ preempt_enable();
}
}
Same situation here.
Otherwise, it looks OK :-)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 5672] New: cannot get socket once accept(2) has failed due to EMFILE/ENFILE
From: David S. Miller [EMAIL PROTECTED]
Date: Thu, 01 Dec 2005 18:51:19 -0800 (PST)
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 1 Dec 2005 10:51:55 -0800
Detail of issue is old:
http://oss.sgi.com/archives/netdev/2004-11/msg00573.html
Once accept fails on EMFILE/ENFILE you cannot get the socket even if you
free up
fd's and retry...
I want to apply something like what is in that netdev posting. It
does make accept() more robust, but there is still a hole.
...
If we take an -EFAULT at the end of sys_accept(), we'll lose the
socket in that case as well, even with the above mentioned fix.
But we have to fully complete the -accept() call before doing
the write back to userspace.
I haven't found a way to solve the -EFAULT problem, but we should
fix the ENFILE/EMFILE issue since we can, this has sat on the
backburner long enough :-)
So I just the following into the net-2.6.17 tree.
diff-tree dc326c4936f41911046b2dc72cbe04053e9680d6 (from
d52610bd92bb915a741098cc9b7fa23a5629fc10)
Author: David S. Miller [EMAIL PROTECTED]
Date: Thu Jan 26 20:45:15 2006 -0800
[NET]: Do not lose accepted socket when -ENFILE/-EMFILE.
Try to allocate the struct file and an unused file
descriptor before we try to pull a newly accepted
socket out of the protocol layer.
Based upon a patch by Prassana Meda.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/net/socket.c b/net/socket.c
index b38a263..8d4032a 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -351,8 +351,8 @@ static struct dentry_operations sockfs_d
/*
* Obtains the first available file descriptor and sets it up for use.
*
- * This function creates file structure and maps it to fd space
- * of current process. On success it returns file descriptor
+ * These functions create file structures and maps them to fd space
+ * of the current process. On success it returns file descriptor
* and file struct implicitly stored in sock-file.
* Note that another thread may close file descriptor before we return
* from this function. We use the fact that now we do not refer
@@ -365,52 +365,67 @@ static struct dentry_operations sockfs_d
* but we take care of internal coherence yet.
*/
-int sock_map_fd(struct socket *sock)
+static int sock_alloc_fd(struct file **filep)
{
int fd;
- struct qstr this;
- char name[32];
-
- /*
-* Find a file descriptor suitable for return to the user.
-*/
fd = get_unused_fd();
- if (fd = 0) {
+ if (likely(fd = 0)) {
struct file *file = get_empty_filp();
- if (!file) {
+ if (unlikely(!file)) {
put_unused_fd(fd);
- fd = -ENFILE;
- goto out;
+ return -ENFILE;
}
+ *filep = file;
+ } else
+ *filep = NULL;
+ return fd;
+}
- this.len = sprintf(name, [%lu], SOCK_INODE(sock)-i_ino);
- this.name = name;
- this.hash = SOCK_INODE(sock)-i_ino;
-
- file-f_dentry = d_alloc(sock_mnt-mnt_sb-s_root, this);
- if (!file-f_dentry) {
- put_filp(file);
+static int sock_attach_fd(struct socket *sock, struct file *file)
+{
+ struct qstr this;
+ char name[32];
+
+ this.len = sprintf(name, [%lu], SOCK_INODE(sock)-i_ino);
+ this.name = name;
+ this.hash = SOCK_INODE(sock)-i_ino;
+
+ file-f_dentry = d_alloc(sock_mnt-mnt_sb-s_root, this);
+ if (unlikely(!file-f_dentry))
+ return -ENOMEM;
+
+ file-f_dentry-d_op = sockfs_dentry_operations;
+ d_add(file-f_dentry, SOCK_INODE(sock));
+ file-f_vfsmnt = mntget(sock_mnt);
+ file-f_mapping = file-f_dentry-d_inode-i_mapping;
+
+ sock-file = file;
+ file-f_op = SOCK_INODE(sock)-i_fop = socket_file_ops;
+ file-f_mode = FMODE_READ | FMODE_WRITE;
+ file-f_flags = O_RDWR;
+ file-f_pos = 0;
+ file-private_data = sock;
+
+ return 0;
+}
+
+int sock_map_fd(struct socket *sock)
+{
+ struct file *newfile;
+ int fd = sock_alloc_fd(newfile);
+
+ if (likely(fd = 0)) {
+ int err = sock_attach_fd(sock, newfile);
+
+ if (unlikely(err 0)) {
+ fput(newfile);
put_unused_fd(fd);
- fd = -ENOMEM;
- goto out;
+ return err;
}
- file-f_dentry-d_op = sockfs_dentry_operations;
- d_add(file-f_dentry, SOCK_INODE(sock));
- file-f_vfsmnt = mntget(sock_mnt);
- file-f_mapping = file-f_dentry-d_inode-i_mapping;
-
- sock-file = file;
- file-f_op = SOCK_INODE(sock)-i_fop = socket_file_ops;
- file-f_mode
Re: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
* Herbert Xu wrote: Does the problem go away if you disable conntrack by unloading its module? Please try to capture the offending ICMP packet with tcpdump and show us what it looks like. Well, there are no problems if SuSEfirewall2 is disabled. But have a look at the loaded modules: ipt_MASQUERADE 3968 1 pppoe 15360 2 pppox 4616 1 pppoe af_packet 23240 2 ppp_generic30740 6 pppoe,pppox slhc7040 1 ppp_generic ipt_TOS 2816 28 ipt_TCPMSS 4800 2 ipt_LOG 7232 55 ipt_limit 2880 55 ipt_pkttype 1984 4 ipt_state 2240 46 ip6t_LOG8000 1 ip6t_limit 3008 1 ip6t_REJECT 5824 3 ipt_REJECT 5952 3 iptable_mangle 3200 1 iptable_nat 8836 1 iptable_filter 3264 1 ip6table_mangle 2752 0 ip_nat_ftp 3776 0 ip_nat 18284 3 ipt_MASQUERADE,iptable_nat,ip_nat_ftp ip_conntrack_ftp8240 1 ip_nat_ftp ip_conntrack 51020 6 ipt_MASQUERADE,ipt_state,iptable_nat,ip_nat_ftp,ip_nat,ip_conntrack_ftp ip_tables 24088 11 ipt_MASQUERADE,ipt_TOS,ipt_TCPMSS,ipt_LOG,ipt_limit,ipt_pkttype,ipt_state,ipt_REJECT,iptable_mangle,iptable_nat,iptable_filter ip6table_filter 3136 1 ip6_tables 25624 5 ip6t_LOG,ip6t_limit,ip6t_REJECT,ip6table_mangle,ip6table_filter ipv6 271712 14 ip6t_REJECT How should I unload ip_conntrack alone? * Stephen Hemminger wrote: Does it always show up on icmp only? What are the iptables rules (iptables -L) As far as I can see, all my sky2 problems are gone with -K rx off. So here is more information. I executed the following script: logger Starting test logger Executing ethtool -K eth0 rx off ethtool -K eth0 rx off logger Executing tcpdump -i eth0 -vv tcpdumpfile tcpdump -i eth0 -vv tcpdumpfile logger Executing host www.suse.com host www.suse.com logger Sleeping 2 seconds sleep 2 logger Executing ping -c 2 195.135.220.3 ping -c 2 195.135.220.3 logger Sleeping 2 seconds sleep 2 logger Executing ethtool -K eth0 rx on ethtool -K eth0 rx on logger Sleeping 2 seconds sleep 2 logger Executing host www.suse.com host www.suse.com logger Sleeping 2 seconds sleep 2 logger Executing ping -c 2 195.135.220.3 ping -c 2 195.135.220.3 logger Sleeping 2 seconds sleep 2 logger Executing ethtool -K eth0 rx off ethtool -K eth0 rx off logger Sleeping 2 seconds sleep 2 logger killall tcpdump killall tcpdump logger End of test The first host and ping worked fine, after the ethtool -K eth0 rx on the host www.suse.com timed out with ;; connection timed out; no servers could be reached and the ping 195.135.220.3 provoked the stack traces you see in sky2syslog. I attach the syslog for the time of the test, the output of iptables -L and the output of tcpdump as the very long lines included would be hard to read with linebreaks. No, I did _not_ delete anything from the tcpdump file. cu, Knut Jan 27 06:29:38 linux knut: Starting test Jan 27 06:29:38 linux knut: Executing ethtool -K eth0 rx off Jan 27 06:29:38 linux knut: Executing tcpdump -i eth0 -vv tcpdumpfile Jan 27 06:29:38 linux knut: Executing host www.suse.com Jan 27 06:29:38 linux kernel: [ 403.606906] device eth0 entered promiscuous mode Jan 27 06:29:38 linux knut: Sleeping 2 seconds Jan 27 06:29:40 linux knut: Executing ping -c 2 195.135.220.3 Jan 27 06:29:41 linux dhcpd: icmp.c(274): trace_write_packet with null trace type Jan 27 06:29:42 linux dhcpd: icmp.c(274): trace_write_packet with null trace type Jan 27 06:29:42 linux knut: Sleeping 2 seconds Jan 27 06:29:44 linux knut: Executing ethtool -K eth0 rx on Jan 27 06:29:44 linux knut: Sleeping 2 seconds Jan 27 06:29:46 linux knut: Executing host www.suse.com Jan 27 06:29:46 linux kernel: [ 406.693484] SFW2-INext-DROP-DEFLT-INV IN=dsl0 OUT= MAC= SRC=217.237.150.33 DST=84.171.112.100 LEN=74 TOS=0x10 PREC=0x00 TTL=57 ID=5 PROTO=UDP SPT=53 DPT=1076 LEN=54 Jan 27 06:29:47 linux kernel: [ 407.125112] SFW2-INext-DROP-DEFLT-INV IN=dsl0 OUT= MAC= SRC=217.237.150.33 DST=84.171.112.100 LEN=116 TOS=0x10 PREC=0x00 TTL=57 ID=24213 PROTO=UDP SPT=53 DPT=1078 LEN=96 Jan 27 06:29:58 linux knut: Sleeping 2 seconds Jan 27 06:30:00 linux knut: Executing ping -c 2 195.135.220.3 Jan 27 06:30:00 linux kernel: [ 412.693613] dsl0: hw csum failure. Jan 27 06:30:00 linux kernel: [ 412.693615] [c0104007] dump_stack+0x17/0x20 Jan 27 06:30:00 linux kernel: [ 412.693628] [c03b2961] netdev_rx_csum_fault+0x31/0x40 Jan 27 06:30:00 linux kernel: [ 412.693632] [c03b00ea] __skb_checksum_complete+0x5a/0x60 Jan 27 06:30:00 linux kernel: [ 412.693635] [f88d892e] icmp_error+0x10e/0x1e0 [ip_conntrack] Jan 27 06:30:00 linux kernel: [ 412.693644] [f88d5d82] ip_conntrack_in+0x72/0x240 [ip_conntrack] Jan 27 06:30:00 linux kernel: [
TCP slow start
Hi All, Looking at the TCP stack code it seems that if the variable snd_cwnd snd_ssthresh, TCP would move to congestion avoidance. Is that correct? Are there any other constraints as far as linux implementation goes? Will that condition hold even if there has been no packet drop or dup acks received. For example if through some module i make snd_ssthresh = max(snd_cwnd/2,2), will TCP go to congestion avoidance even though there has been no loss indication? Thanks in advance. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
