[PATCH 0/2]: UDP-Lite support in Linux 2.6.20
Hi David,
please find attached, in two subsequent emails,
the following two patches:
Patch 1/2: UDP-Lite support for IPv4/IPv6 with
consolidated code for UDP and UDP-Lite
processing.
This is the modified UDP-Lite patch, exactly in the requested
format: UDP and UDP-Lite now use separate object files and rely
on net/ipv{4,6}/udp_impl.h to resolve declaration dependencies.
There is no other change apart from this one, i.e. it is still
the same as I have been posting for RFC earlier.
I would like to see this in 2.6.20.
Patch 2/2: This is an optional optimization intended to make
room by inlining functions into udp_impl.h. I thought
that this would be useful (in particular with regard
to the sockopt functions), as it reduces code size
somewhat.
I have tested both patches on different architectures and with
different configurations (IPV6 = {n|m|y}).
Many thanks,
Gerrit
-
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
[PATCHv2 2/2]: net/ipv{4,6}: reduce code size by inlining
[UDP]: Reduce size of shared code
This patch reduces size of source code files by moving
some of the smaller functions shared by UDP and UDP-Lite
into the header file udp_impl.h, and in-lining these.
It is an optimisation and applies on top of the previous
UDP-Lite patch.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
net/ipv4/udp.c | 74 ++-
net/ipv4/udp_impl.h | 75 +---
net/ipv6/udp.c | 70 ++--
net/ipv6/udp_impl.h | 72 +++--
4 files changed, 136 insertions(+), 155 deletions(-)
--
diff --git a/net/ipv4/udp_impl.h b/net/ipv4/udp_impl.h
index f6f4277..3d12aca 100644
--- a/net/ipv4/udp_impl.h
+++ b/net/ipv4/udp_impl.h
@@ -11,26 +11,81 @@ extern void __udp4_lib_err(struct sk_bu
extern int __udp_lib_get_port(struct sock *sk, unsigned short snum,
struct hlist_head udptable[], int
*port_rover,
int (*)(const struct sock*,const struct
sock*));
-extern int ipv4_rcv_saddr_equal(const struct sock *, const struct sock *);
+static inline int ipv4_rcv_saddr_equal(const struct sock *sk1, const struct
sock *sk2)
+{
+ struct inet_sock *inet1 = inet_sk(sk1), *inet2 = inet_sk(sk2);
-extern int udp_setsockopt(struct sock *sk, int level, int optname,
- char __user *optval, int optlen);
-extern int udp_getsockopt(struct sock *sk, int level, int optname,
- char __user *optval, int __user *optlen);
+ return ( !ipv6_only_sock(sk2)
+ (!inet1-rcv_saddr || !inet2-rcv_saddr ||
+ inet1-rcv_saddr == inet2-rcv_saddr ));
+}
+
+extern int do_udp_setsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int optlen);
+extern int do_udp_getsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user *optlen);
+
+static inline int udp_setsockopt(struct sock *sk, int level, int optname,
+char __user *optval, int optlen)
+{
+ if (level == SOL_UDP || level == SOL_UDPLITE)
+ return do_udp_setsockopt(sk, level, optname, optval, optlen);
+ return ip_setsockopt(sk, level, optname, optval, optlen);
+}
+
+static inline int udp_getsockopt(struct sock *sk, int level, int optname,
+char __user *optval, int __user *optlen)
+{
+ if (level == SOL_UDP || level == SOL_UDPLITE)
+ return do_udp_getsockopt(sk, level, optname, optval, optlen);
+ return ip_getsockopt(sk, level, optname, optval, optlen);
+}
#ifdef CONFIG_COMPAT
-extern int compat_udp_setsockopt(struct sock *sk, int level, int optname,
- char __user *optval, int optlen);
-extern int compat_udp_getsockopt(struct sock *sk, int level, int optname,
- char __user *optval, int __user *optlen);
+static inline int compat_udp_setsockopt(struct sock *sk, int level, int
optname,
+ char __user *optval, int optlen)
+{
+ if (level == SOL_UDP || level == SOL_UDPLITE)
+ return do_udp_setsockopt(sk, level, optname, optval, optlen);
+ return compat_ip_setsockopt(sk, level, optname, optval, optlen);
+}
+static inline int compat_udp_getsockopt(struct sock *sk, int level, int
optname,
+ char __user *optval, int __user *optlen)
+{
+ if (level == SOL_UDP || level == SOL_UDPLITE)
+ return do_udp_getsockopt(sk, level, optname, optval, optlen);
+ return compat_ip_getsockopt(sk, level, optname, optval, optlen);
+}
#endif
+
extern int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr
*msg,
size_t len, int noblock, int flags, int *addr_len);
extern int udp_sendpage(struct sock *sk, struct page *page, int offset,
size_t size, int flags);
extern int udp_queue_rcv_skb(struct sock * sk, struct sk_buff *skb);
-extern int udp_destroy_sock(struct sock *sk);
+
+/*
+ * Throw away all pending data and cancel the corking. Socket is locked.
+ */
+static inline void udp_flush_pending_frames(struct sock *sk)
+{
+ struct udp_sock *up = udp_sk(sk);
+
+ if (up-pending) {
+ up-len = 0;
+ up-pending = 0;
+ ip_flush_pending_frames(sk);
+ }
+}
+
+static inline int udp_destroy_sock(struct sock *sk)
+{
+ lock_sock(sk);
+ udp_flush_pending_frames(sk);
+ release_sock(sk);
+
[PATCH 1/3] [GENL]: Add genlmsg_new() to allocate generic netlink messages
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/include/net/genetlink.h
===
--- net-2.6.20.orig/include/net/genetlink.h 2006-11-14 11:52:29.0
+0100
+++ net-2.6.20/include/net/genetlink.h 2006-11-14 12:23:56.0 +0100
@@ -187,4 +187,15 @@
return NLMSG_ALIGN(genlmsg_msg_size(payload));
}
+/**
+ * genlmsg_new - Allocate a new generic netlink message
+ * @payload: size of the message payload
+ * @flags: the type of memory to allocate.
+ */
+static inline struct sk_buff *genlmsg_new(size_t payload, gfp_t flags)
+{
+ return nlmsg_new(genlmsg_total_size(payload), flags);
+}
+
+
#endif /* __NET_GENERIC_NETLINK_H */
Index: net-2.6.20/kernel/taskstats.c
===
--- net-2.6.20.orig/kernel/taskstats.c 2006-11-14 11:53:44.0 +0100
+++ net-2.6.20/kernel/taskstats.c 2006-11-14 12:23:18.0 +0100
@@ -77,7 +77,7 @@
/*
* If new attributes are added, please revisit this allocation
*/
- skb = nlmsg_new(genlmsg_total_size(size), GFP_KERNEL);
+ skb = genlmsg_new(size, GFP_KERNEL);
if (!skb)
return -ENOMEM;
--
-
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
Generic Netlink Updates
Various simplifications to the generic netlink interface partially based on suggestions by Paul Moore. - 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 2/3] [GENL]: Add genlmsg_reply() to simply unicast replies to requests
A generic netlink user has no interest in knowing how to
address the source of the original request.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/include/net/genetlink.h
===
--- net-2.6.20.orig/include/net/genetlink.h 2006-11-14 12:23:56.0
+0100
+++ net-2.6.20/include/net/genetlink.h 2006-11-14 12:46:16.0 +0100
@@ -150,6 +150,16 @@
}
/**
+ * genlmsg_reply - reply to a request
+ * @skb: netlink message to be sent back
+ * @info: receiver information
+ */
+static inline int genlmsg_reply(struct sk_buff *skb, struct genl_info *info)
+{
+ return genlmsg_unicast(skb, info-snd_pid);
+}
+
+/**
* gennlmsg_data - head of message payload
* @gnlh: genetlink messsage header
*/
Index: net-2.6.20/net/netlabel/netlabel_cipso_v4.c
===
--- net-2.6.20.orig/net/netlabel/netlabel_cipso_v4.c2006-11-14
12:23:43.0 +0100
+++ net-2.6.20/net/netlabel/netlabel_cipso_v4.c 2006-11-14 12:46:02.0
+0100
@@ -568,7 +568,7 @@
genlmsg_end(ans_skb, data);
- ret_val = genlmsg_unicast(ans_skb, info-snd_pid);
+ ret_val = genlmsg_reply(ans_skb, info);
if (ret_val != 0)
goto list_failure;
Index: net-2.6.20/net/netlink/genetlink.c
===
--- net-2.6.20.orig/net/netlink/genetlink.c 2006-11-14 12:23:43.0
+0100
+++ net-2.6.20/net/netlink/genetlink.c 2006-11-14 12:46:02.0 +0100
@@ -529,7 +529,7 @@
goto errout;
}
- err = genlmsg_unicast(msg, info-snd_pid);
+ err = genlmsg_reply(msg, info);
errout:
return err;
}
Index: net-2.6.20/net/netlabel/netlabel_mgmt.c
===
--- net-2.6.20.orig/net/netlabel/netlabel_mgmt.c2006-11-14
12:23:43.0 +0100
+++ net-2.6.20/net/netlabel/netlabel_mgmt.c 2006-11-14 12:46:02.0
+0100
@@ -390,7 +390,7 @@
genlmsg_end(ans_skb, data);
- ret_val = genlmsg_unicast(ans_skb, info-snd_pid);
+ ret_val = genlmsg_reply(ans_skb, info);
if (ret_val != 0)
goto listdef_failure;
return 0;
@@ -512,7 +512,7 @@
genlmsg_end(ans_skb, data);
- ret_val = genlmsg_unicast(ans_skb, info-snd_pid);
+ ret_val = genlmsg_reply(ans_skb, info);
if (ret_val != 0)
goto version_failure;
return 0;
Index: net-2.6.20/net/netlabel/netlabel_unlabeled.c
===
--- net-2.6.20.orig/net/netlabel/netlabel_unlabeled.c 2006-11-14
12:23:43.0 +0100
+++ net-2.6.20/net/netlabel/netlabel_unlabeled.c2006-11-14
12:46:02.0 +0100
@@ -160,7 +160,7 @@
genlmsg_end(ans_skb, data);
- ret_val = genlmsg_unicast(ans_skb, info-snd_pid);
+ ret_val = genlmsg_reply(ans_skb, info);
if (ret_val != 0)
goto list_failure;
return 0;
--
-
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/3] [GENL]: Add genlmsg_put_reply() to simplify building reply headers
By modyfing genlmsg_put() to take a genl_family and by adding
genlmsg_put_reply() the process of constructing the netlink
and generic netlink headers is simplified.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/include/net/genetlink.h
===
--- net-2.6.20.orig/include/net/genetlink.h 2006-11-14 12:46:16.0
+0100
+++ net-2.6.20/include/net/genetlink.h 2006-11-14 12:46:18.0 +0100
@@ -79,34 +79,51 @@
* @skb: socket buffer holding the message
* @pid: netlink pid the message is addressed to
* @seq: sequence number (usually the one of the sender)
- * @type: netlink message type
- * @hdrlen: length of the user specific header
+ * @family: generic netlink family
* @flags netlink message flags
* @cmd: generic netlink command
- * @version: version
*
* Returns pointer to user specific header
*/
static inline void *genlmsg_put(struct sk_buff *skb, u32 pid, u32 seq,
- int type, int hdrlen, int flags,
- u8 cmd, u8 version)
+ struct genl_family *family, int flags, u8 cmd)
{
struct nlmsghdr *nlh;
struct genlmsghdr *hdr;
- nlh = nlmsg_put(skb, pid, seq, type, GENL_HDRLEN + hdrlen, flags);
+ nlh = nlmsg_put(skb, pid, seq, family-id, GENL_HDRLEN +
+ family-hdrsize, flags);
if (nlh == NULL)
return NULL;
hdr = nlmsg_data(nlh);
hdr-cmd = cmd;
- hdr-version = version;
+ hdr-version = family-version;
hdr-reserved = 0;
return (char *) hdr + GENL_HDRLEN;
}
/**
+ * genlmsg_put_reply - Add generic netlink header to a reply message
+ * @skb: socket buffer holding the message
+ * @info: receiver info
+ * @family: generic netlink family
+ * @flags: netlink message flags
+ * @cmd: generic netlink command
+ *
+ * Returns pointer to user specific header
+ */
+static inline void *genlmsg_put_reply(struct sk_buff *skb,
+ struct genl_info *info,
+ struct genl_family *family,
+ int flags, u8 cmd)
+{
+ return genlmsg_put(skb, info-snd_pid, info-snd_seq, family,
+ flags, cmd);
+}
+
+/**
* genlmsg_end - Finalize a generic netlink message
* @skb: socket buffer the message is stored in
* @hdr: user specific header
Index: net-2.6.20/kernel/taskstats.c
===
--- net-2.6.20.orig/kernel/taskstats.c 2006-11-14 12:46:02.0 +0100
+++ net-2.6.20/kernel/taskstats.c 2006-11-14 12:46:18.0 +0100
@@ -85,13 +85,9 @@
int seq = get_cpu_var(taskstats_seqnum)++;
put_cpu_var(taskstats_seqnum);
- reply = genlmsg_put(skb, 0, seq,
- family.id, 0, 0,
- cmd, family.version);
+ reply = genlmsg_put(skb, 0, seq, family, 0, cmd);
} else
- reply = genlmsg_put(skb, info-snd_pid, info-snd_seq,
- family.id, 0, 0,
- cmd, family.version);
+ reply = genlmsg_put_reply(skb, info, family, 0, cmd);
if (reply == NULL) {
nlmsg_free(skb);
return -EINVAL;
Index: net-2.6.20/net/netlabel/netlabel_cipso_v4.c
===
--- net-2.6.20.orig/net/netlabel/netlabel_cipso_v4.c2006-11-14
12:46:02.0 +0100
+++ net-2.6.20/net/netlabel/netlabel_cipso_v4.c 2006-11-14 12:46:18.0
+0100
@@ -457,12 +457,8 @@
ret_val = -ENOMEM;
goto list_failure;
}
- data = netlbl_netlink_hdr_put(ans_skb,
- info-snd_pid,
- info-snd_seq,
- netlbl_cipsov4_gnl_family.id,
- 0,
- NLBL_CIPSOV4_C_LIST);
+ data = genlmsg_put_reply(ans_skb, info, netlbl_cipsov4_gnl_family,
+0, NLBL_CIPSOV4_C_LIST);
if (data == NULL) {
ret_val = -ENOMEM;
goto list_failure;
@@ -607,12 +603,9 @@
struct netlbl_cipsov4_doiwalk_arg *cb_arg = arg;
void *data;
- data = netlbl_netlink_hdr_put(cb_arg-skb,
- NETLINK_CB(cb_arg-nl_cb-skb).pid,
- cb_arg-seq,
- netlbl_cipsov4_gnl_family.id,
- NLM_F_MULTI,
- NLBL_CIPSOV4_C_LISTALL);
+ data = genlmsg_put(cb_arg-skb, NETLINK_CB(cb_arg-nl_cb-skb).pid,
+ cb_arg-seq, netlbl_cipsov4_gnl_family,
+
Re: [Fwd: Re: wan/pc300 bug found]
On 11/14/06, Jeff Garzik [EMAIL PROTECTED] wrote: FYI... I'm certainly willing to remove pc300, if nobody wants it. But I am unsure whether this is a case of vendor doesn't care or users don't care, which are two very different things... Well, I'm not a user of such card, but I know there are many users at least here in Brazil, I guess it should stay. - Arnaldo - 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] NetXen: Fixed /sys mapping between device and driver
Amit S. Kale wrote: Signed-off-by: Amit S. Kale [EMAIL PROTECTED] ACK technical content, but git-applymbox claims the patches are corrupted. Also, please realize that your email subject line is used as a one-line summary for your change, copied directly into the kernel change log. ref http://linux.yyz.us/patch-format.html As such, having two patches with the identical subject NetXen: 1G/10G Ethernet Driver updates is bad form, because it is overly vague, and fails to adequately summarize the changeset. Example summaries: patch #2: NetXen: temp monitoring, de-bloat, support newer firmware patch #3: NetXen: driver cleanup, 64-bit memory fixes - 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/RFC] add netpoll support for gianfar: respin
Vitaly Wool wrote: The patch inlined below adds NET_POLL_CONTROLLER support for gianfar network driver, slightly modified wrt the comments from Andy Fleming. drivers/net/gianfar.c | 33 + 1 file changed, 33 insertions(+) Signed-off-by: Vitaly Wool [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 4/5] Add tsi108/9 On Chip Ethernet device driver support
[EMAIL PROTECTED] wrote: From: Zang Roy-r61911 [EMAIL PROTECTED] Add tsi108/9 on chip Ethernet controller driver support. The driver code collects the feedback of previous posting form the mailing list and gives the update. MPC7448HPC2 platform in arch/powerpc uses tsi108 bridge. The following is a brief description of the Ethernet controller: The Tsi108/9 Ethernet Controller connects Switch Fabric to two independent Gigabit Ethernet ports,E0 and E1. It uses a single Management interface to manage the two physical connection devices (PHYs). Each Ethernet port has its own statistics monitor that tracks and reports key interface statistics. Each port supports a 256-entry hash table for address filtering. In addition, each port is bridged to the Switch Fabric through a 2-Kbyte transmit FIFO and a 4-Kbyte Receive FIFO. Each Ethernet port also has a pair of internal Ethernet DMA channels to support the transmit and receive data flows. The Ethernet DMA channels use descriptors set up in memory, the memory map of the device, and access via the Switch Fabric. The Ethernet Controller’s DMA arbiter handles arbitration for the Switch Fabric. The Controller also has a register bus interface for register accesses and status monitor control. The PMD (Physical Media Device) interface operates in MII, GMII, or TBI modes. The MII mode is used for connecting with 10 or 100 Mbit/s PMDs. The GMII and TBI modes are used to connect with Gigabit PMDs. Internal data flows to and from the Ethernet Controller through the Switch Fabric. Each Ethernet port uses its transmit and receive DMA channels to manage data flows through buffer descriptors that are predefined by the system (the descriptors can exist anywhere in the system memory map). These descriptors are data structures that point to buffers filled with data ready to transmit over Ethernet, or they point to empty buffers ready to receive data from Ethernet. Signed-off-by: Alexandre Bounine [EMAIL PROTECTED] Signed-off-by: Roy Zang [EMAIL PROTECTED] Signed-off-by: Andrew Morton [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 3/5] sundance: solve host error problem in low performance embedded system when continune down and up
[EMAIL PROTECTED] wrote: From: Jesse Huang [EMAIL PROTECTED] Solve host error problem in low performance embedded system when continune down and up. It will cause IP100A DMA TargetAbort. So we need more safe process to up and down IP100A with wait hardware completely stop and software cur_tx/ dirty_tx/cur_task/last_tx be clear. Signed-off-by: Jesse Huang [EMAIL PROTECTED] Signed-off-by: Andrew Morton [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 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
David Miller wrote: From: Ville Nuorvala [EMAIL PROTECTED] Date: Thu, 02 Nov 2006 16:22:07 +0200 Ok, I'll resubmit a patch doesn't send an ICMPv6 error message. Is this coming soon? I'd like to integrate this patch set into net-2.6.20 if I can. No, it was a false alarm as Herbert's patch already addressed the problem. Regards, Ville - 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: [PATCHv2 2/2]: net/ipv{4,6}: reduce code size by inlining
On Tuesday 14 November 2006 09:49, Gerrit Renker wrote: [UDP]: Reduce size of shared code This patch reduces size of source code files by moving some of the smaller functions shared by UDP and UDP-Lite into the header file udp_impl.h, and in-lining these. It is an optimisation and applies on top of the previous UDP-Lite patch. Wouldn't it be better to just call them? They all don't particularly time critical. -Andi - 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: [PATCHv2 2/2]: net/ipv{4,6}: reduce code size by inlining
Quoting Andi Kleen: | On Tuesday 14 November 2006 09:49, Gerrit Renker wrote: | [UDP]: Reduce size of shared code | | This patch reduces size of source code files by moving | some of the smaller functions shared by UDP and UDP-Lite | into the header file udp_impl.h, and in-lining these. | | It is an optimisation and applies on top of the previous | UDP-Lite patch. | | Wouldn't it be better to just call them? They all don't | particularly time critical. This patch was sent as an optional add-on, it is not as important as the other one. You are probably right - I also noted that the gains (in terms of line numbers) are not as high as intended. - 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: bcm43xx-d80211 broadcast reception with WPA
On Wed, 2006-11-15 at 01:40 +1100, Paul TBBle Hampson wrote: bcm43xx-d80211 w/v3 firmware and WEP-104: Garbled _everything_ RX Of course, that's to be expected. WEP only uses broadcast keys, and we knew they were failing in software mode. Hmm, not sure about this, but it sort of confirms my theory -- with v3 firmware we never upload keys to the hw so the hw will successfully decrypt frames with the 'none' algorithm, and the RX path will treat them as though they were decrypted already. johannes - 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: bcm43xx-d80211 broadcast reception with WPA
On Wed, 2006-11-15 at 01:29 +1100, Paul TBBle Hampson wrote: Just to summarise results so far: (Current version) bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX (version from wireless-dev before October 23rd, unsure of exact date) bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX The last item is interesting. The softmac version doesn't include any hw crypto so it never checks the 'decrypt attempted' bit in the RX header afaik, leaving all crypto to hw. I postulated before that the problem is that the firmware sets the 'decrypt attempted' bit even if the key is none, hence the driver tells the d80211 stack that the frame was already decrypted (no decrypt error occurs because in reality the algorithm is 'none'.) You could test this theory by clearing the 'decrypt attempted' bit unconditionally in the RX path before it is ever tested. Then, any wep/aes should no longer work properly with v4 firmware and bcm43xx-d80211, but tkip would. If my theory is correct. johannes - 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
[Fwd: Re: wan/pc300 bug found]
FYI... I'm certainly willing to remove pc300, if nobody wants it. But I am unsure whether this is a case of vendor doesn't care or users don't care, which are two very different things... Jeff ---BeginMessage--- Jeff, As PC300 is not being produced anymore, we decided that the best solution is to remove its driver from the kernel. I will send you a patch to do so, as soon as possible. Best regards, Daniela -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Sun 10/1/2006 1:35 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.org; LKML; Andrew Morton Subject: wan/pc300 bug found The following gcc warning indicates a bug: drivers/net/wan/pc300_drv.c: In function 'cpc_open': drivers/net/wan/pc300_drv.c:2870: warning: 'br' may be used uninitialized in this function clock_rate_calc() is not checked for a negative return value. ---End Message---
Re: bcm43xx-d80211 broadcast reception with WPA
On Wed, Nov 15, 2006 at 01:29:59AM +1100, Paul TBBle Hampson wrote: Just to summarise results so far: (Current version) bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX (version from wireless-dev before October 23rd, unsure of exact date) bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX Still to test: bcm43xx-d80211 w/v3 firmware and WEP-104 bcm43xx-d80211 w/v3 firmware and WEP-104: Garbled _everything_ RX Of course, that's to be expected. WEP only uses broadcast keys, and we knew they were failing in software mode. -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- - 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
[IPv6] iflink: Convert IPv6's RTM_GETLINK to use the new netlink api
By replacing the current method of exporting the device configuration
which included allocating a temporary buffer, copying ipv6_devconf
into it and copying that buffer into the message with a method that
uses nla_reserve() allowing to copy the device configuration directly
into the skb data buffer, a GFP_ATOMIC allocation could be removed.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/net/ipv6/addrconf.c
===
--- net-2.6.20.orig/net/ipv6/addrconf.c 2006-11-14 11:52:24.0 +0100
+++ net-2.6.20/net/ipv6/addrconf.c 2006-11-14 12:51:56.0 +0100
@@ -3360,6 +3360,8 @@
static void inline ipv6_store_devconf(struct ipv6_devconf *cnf,
__s32 *array, int bytes)
{
+ BUG_ON(bytes (DEVCONF_MAX * 4));
+
memset(array, 0, bytes);
array[DEVCONF_FORWARDING] = cnf-forwarding;
array[DEVCONF_HOPLIMIT] = cnf-hop_limit;
@@ -3409,66 +3411,59 @@
static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev,
u32 pid, u32 seq, int event, unsigned int flags)
{
- struct net_device *dev = idev-dev;
- __s32 *array = NULL;
- struct ifinfomsg*r;
- struct nlmsghdr *nlh;
- unsigned char *b = skb-tail;
- struct rtattr *subattr;
- __u32 mtu = dev-mtu;
- struct ifla_cacheinfo ci;
-
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
- r = NLMSG_DATA(nlh);
- r-ifi_family = AF_INET6;
- r-__ifi_pad = 0;
- r-ifi_type = dev-type;
- r-ifi_index = dev-ifindex;
- r-ifi_flags = dev_get_flags(dev);
- r-ifi_change = 0;
+ struct net_device *dev = idev-dev;
+ struct nlattr *conf;
+ struct ifinfomsg *hdr;
+ struct nlmsghdr *nlh;
+ void *protoinfo;
+ struct ifla_cacheinfo ci;
+
+ nlh = nlmsg_put(skb, pid, seq, event, sizeof(*hdr), flags);
+ if (nlh == NULL)
+ return -ENOBUFS;
+
+ hdr = nlmsg_data(nlh);
+ hdr-ifi_family = AF_INET6;
+ hdr-__ifi_pad = 0;
+ hdr-ifi_type = dev-type;
+ hdr-ifi_index = dev-ifindex;
+ hdr-ifi_flags = dev_get_flags(dev);
+ hdr-ifi_change = 0;
- RTA_PUT(skb, IFLA_IFNAME, strlen(dev-name)+1, dev-name);
+ NLA_PUT_STRING(skb, IFLA_IFNAME, dev-name);
if (dev-addr_len)
- RTA_PUT(skb, IFLA_ADDRESS, dev-addr_len, dev-dev_addr);
+ NLA_PUT(skb, IFLA_ADDRESS, dev-addr_len, dev-dev_addr);
- RTA_PUT(skb, IFLA_MTU, sizeof(mtu), mtu);
+ NLA_PUT_U32(skb, IFLA_MTU, dev-mtu);
if (dev-ifindex != dev-iflink)
- RTA_PUT(skb, IFLA_LINK, sizeof(int), dev-iflink);
-
- subattr = (struct rtattr*)skb-tail;
+ NLA_PUT_U32(skb, IFLA_LINK, dev-iflink);
- RTA_PUT(skb, IFLA_PROTINFO, 0, NULL);
+ protoinfo = nla_nest_start(skb, IFLA_PROTINFO);
+ if (protoinfo == NULL)
+ goto nla_put_failure;
- /* return the device flags */
- RTA_PUT(skb, IFLA_INET6_FLAGS, sizeof(__u32), idev-if_flags);
+ NLA_PUT_U32(skb, IFLA_INET6_FLAGS, idev-if_flags);
- /* return interface cacheinfo */
ci.max_reasm_len = IPV6_MAXPLEN;
ci.tstamp = (__u32)(TIME_DELTA(idev-tstamp, INITIAL_JIFFIES) / HZ * 100
+ TIME_DELTA(idev-tstamp, INITIAL_JIFFIES) % HZ * 100 /
HZ);
ci.reachable_time = idev-nd_parms-reachable_time;
ci.retrans_time = idev-nd_parms-retrans_time;
- RTA_PUT(skb, IFLA_INET6_CACHEINFO, sizeof(ci), ci);
-
- /* return the device sysctl params */
- if ((array = kmalloc(DEVCONF_MAX * sizeof(*array), GFP_ATOMIC)) == NULL)
- goto rtattr_failure;
- ipv6_store_devconf(idev-cnf, array, DEVCONF_MAX * sizeof(*array));
- RTA_PUT(skb, IFLA_INET6_CONF, DEVCONF_MAX * sizeof(*array), array);
+ NLA_PUT(skb, IFLA_INET6_CACHEINFO, sizeof(ci), ci);
+
+ conf = nla_reserve(skb, IFLA_INET6_CONF, DEVCONF_MAX * sizeof(s32));
+ if (conf == NULL)
+ goto nla_put_failure;
+ ipv6_store_devconf(idev-cnf, nla_data(conf), nla_len(conf));
/* XXX - Statistics/MC not implemented */
- subattr-rta_len = skb-tail - (u8*)subattr;
- nlh-nlmsg_len = skb-tail - b;
- kfree(array);
- return skb-len;
+ nla_nest_end(skb, protoinfo);
+ return nlmsg_end(skb, nlh);
-nlmsg_failure:
-rtattr_failure:
- kfree(array);
- skb_trim(skb, b - skb-data);
- return -1;
+nla_put_failure:
+ return nlmsg_cancel(skb, nlh);
}
static int inet6_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: bcm43xx-d80211 broadcast reception with WPA
On Sun, Nov 12, 2006 at 09:34:27AM +0100, Michael Buesch wrote: On Sunday 12 November 2006 02:24, Paul TBBle Hampson wrote: On Sat, Nov 11, 2006 at 04:07:05PM +0100, Michael Buesch wrote: On Saturday 11 November 2006 07:32, Paul Hampson wrote: Michael Buesch mb at bu3sch.de writes: On Thursday 09 November 2006 23:23, Paul Hampson wrote: I've been backporting the bcm43xx-d80211 driver to whatever the released 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to current wireless-dev but with a workaround for not having a ieee80211_dev pointer and still using the _tfm interface instead of the _cypher interface.) As of last night's wireless-dev tree bcm43xx, everything seems to be operating fine except incoming broadcast traffic is coming in 14 bytes too long and scrambled. I presume this means it's not decrypting properly... It sounds like a bug in the hardware decryption setup. Are you using TKIP or not? Yes, it's using TKIP. The router docs and the loading of the tkip module when I use the softmac driver agree on this. TKIP is still software encryption. Did you try with WPA-AES, for example, which is hardware encryption? I've just tried with WEP-104, which reports hardware encryption for all four keys. Ah, and also note that you _need_ firmware from a v4 binary driver to have hardware encryption with bcm43xx. Just to summarise results so far: (Current version) bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX (version from wireless-dev before October 23rd, unsure of exact date) bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX Still to test: bcm43xx-d80211 w/v3 firmware and WEP-104 I also tried looking at how the two drivers I've got here are clearing their keys and comparing them to the bcm specs, and there's nothing obviously wrong that I can see. Sadly I can't compare the drivers directly since one is using the v3 specs and one the v4 specs... -_- And to top it off, current wireless-dev's softmac bcm43xx driver doesn't build against 2.6.18, and I'm not yet motivated into munging it into doing so, unless it will have diagnostic advantage to this situation. (It'll require also building a new ieee80211softmac at least) -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpjEPc1lK5rF.pgp Description: PGP signature
[IPv6] prefix: Convert RTM_NEWPREFIX notifications to use the new netlink api
RTM_GETPREFIX is completely unused and is thus removed.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/net/ipv6/addrconf.c
===
--- net-2.6.20.orig/net/ipv6/addrconf.c 2006-11-14 12:51:56.0 +0100
+++ net-2.6.20/net/ipv6/addrconf.c 2006-11-14 12:52:04.0 +0100
@@ -3518,16 +3518,18 @@
}
static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev,
- struct prefix_info *pinfo, u32 pid, u32 seq,
- int event, unsigned int flags)
+struct prefix_info *pinfo, u32 pid, u32 seq,
+int event, unsigned int flags)
{
- struct prefixmsg*pmsg;
- struct nlmsghdr *nlh;
- unsigned char *b = skb-tail;
+ struct prefixmsg *pmsg;
+ struct nlmsghdr *nlh;
struct prefix_cacheinfo ci;
- nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*pmsg), flags);
- pmsg = NLMSG_DATA(nlh);
+ nlh = nlmsg_put(skb, pid, seq, event, sizeof(*pmsg), flags);
+ if (nlh == NULL)
+ return -ENOBUFS;
+
+ pmsg = nlmsg_data(nlh);
pmsg-prefix_family = AF_INET6;
pmsg-prefix_pad1 = 0;
pmsg-prefix_pad2 = 0;
@@ -3535,26 +3537,22 @@
pmsg-prefix_len = pinfo-prefix_len;
pmsg-prefix_type = pinfo-type;
pmsg-prefix_pad3 = 0;
-
pmsg-prefix_flags = 0;
if (pinfo-onlink)
pmsg-prefix_flags |= IF_PREFIX_ONLINK;
if (pinfo-autoconf)
pmsg-prefix_flags |= IF_PREFIX_AUTOCONF;
- RTA_PUT(skb, PREFIX_ADDRESS, sizeof(pinfo-prefix), pinfo-prefix);
+ NLA_PUT(skb, PREFIX_ADDRESS, sizeof(pinfo-prefix), pinfo-prefix);
ci.preferred_time = ntohl(pinfo-prefered);
ci.valid_time = ntohl(pinfo-valid);
- RTA_PUT(skb, PREFIX_CACHEINFO, sizeof(ci), ci);
+ NLA_PUT(skb, PREFIX_CACHEINFO, sizeof(ci), ci);
- nlh-nlmsg_len = skb-tail - b;
- return skb-len;
+ return nlmsg_end(skb, nlh);
-nlmsg_failure:
-rtattr_failure:
- skb_trim(skb, b - skb-data);
- return -1;
+nla_put_failure:
+ return nlmsg_cancel(skb, nlh);
}
static void inet6_prefix_notify(int event, struct inet6_dev *idev,
Index: net-2.6.20/net/core/rtnetlink.c
===
--- net-2.6.20.orig/net/core/rtnetlink.c2006-11-14 11:52:24.0
+0100
+++ net-2.6.20/net/core/rtnetlink.c 2006-11-14 12:52:04.0 +0100
@@ -108,7 +108,6 @@
[RTM_FAM(RTM_NEWTCLASS)]= NLMSG_LENGTH(sizeof(struct tcmsg)),
[RTM_FAM(RTM_NEWTFILTER)] = NLMSG_LENGTH(sizeof(struct tcmsg)),
[RTM_FAM(RTM_NEWACTION)]= NLMSG_LENGTH(sizeof(struct tcamsg)),
- [RTM_FAM(RTM_NEWPREFIX)]= NLMSG_LENGTH(sizeof(struct rtgenmsg)),
[RTM_FAM(RTM_GETMULTICAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)),
[RTM_FAM(RTM_GETANYCAST)] = NLMSG_LENGTH(sizeof(struct rtgenmsg)),
};
Index: net-2.6.20/include/linux/rtnetlink.h
===
--- net-2.6.20.orig/include/linux/rtnetlink.h 2006-11-14 11:52:24.0
+0100
+++ net-2.6.20/include/linux/rtnetlink.h2006-11-14 12:52:04.0
+0100
@@ -81,8 +81,6 @@
RTM_NEWPREFIX = 52,
#define RTM_NEWPREFIX RTM_NEWPREFIX
- RTM_GETPREFIX = 54,
-#define RTM_GETPREFIX RTM_GETPREFIX
RTM_GETMULTICAST = 58,
#define RTM_GETMULTICAST RTM_GETMULTICAST
Index: net-2.6.20/security/selinux/nlmsgtab.c
===
--- net-2.6.20.orig/security/selinux/nlmsgtab.c 2006-11-14 11:52:24.0
+0100
+++ net-2.6.20/security/selinux/nlmsgtab.c 2006-11-14 12:52:04.0
+0100
@@ -60,7 +60,6 @@
{ RTM_DELACTION,NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
{ RTM_GETACTION,NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_NEWPREFIX,NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
- { RTM_GETPREFIX,NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_GETMULTICAST, NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_GETANYCAST, NETLINK_ROUTE_SOCKET__NLMSG_READ },
{ RTM_GETNEIGHTBL, NETLINK_ROUTE_SOCKET__NLMSG_READ },
-
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] Add support for configuring the PHY connection interface
Andy Fleming wrote: Most PHYs connect to an ethernet controller over a GMII or MII interface. However, a growing number are connected over different interfaces, such as RGMII or SGMII. The ethernet driver will tell the PHY what type of connection it is by setting it manually, or passing it in through phy_connect (or phy_attach). Changes include: * Updates to documentation * Updates to other PHY Lib consumers * Changes to PHY Lib to add interface support * Some minor changes to whitespace in phy.h * interface values now passed to gianfar Signed-off-by: Andrew Fleming [EMAIL PROTECTED] ACK technical content, but Applying 'Add support for configuring the PHY connection interface' error: patch failed: arch/powerpc/sysdev/fsl_soc.c:211 error: arch/powerpc/sysdev/fsl_soc.c: patch does not apply - 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: Please pull 'upstream' branch of wireless-2.6
John W. Linville wrote: The following changes since commit d4f748365129ccfc9dadf6fb14331e45e33cc4ed: John W. Linville: Merge branch 'upstream-fixes' into upstream are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream John W. Linville: wireless: clean-up some check return code warnings Larry Finger: bcm43xx: remove badness variable and related routine bcm43xx: Remove useless core enable/disable messages ieee80211softmac: fix verbosity when debug disabled drivers/net/wireless/bcm43xx/bcm43xx_main.c | 56 + drivers/net/wireless/hostap/hostap_pci.c |8 +++- drivers/net/wireless/ipw2100.c|8 +++- drivers/net/wireless/ipw2200.c|8 +++- drivers/net/wireless/orinoco_pci.h|7 +++ drivers/net/wireless/prism54/islpci_hotplug.c | 20 +++-- net/ieee80211/softmac/ieee80211softmac_auth.c | 10 ++-- 7 files changed, 60 insertions(+), 57 deletions(-) pulled - 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] Add support for Marvell 88e1111S and 88e1145
Andy Fleming wrote: This patch requires the new support for configurable PHY interfaces. Changes include: * New support for 88e1145 * New support for 88e111s * Fixing 88e1101 driver to not match non-88e1101 PHYs * Increases in feature support across Marvell PHY product line * Fixes a bunch of whitespace issues found by Lindent Signed-off-by: Andrew Fleming [EMAIL PROTECTED] applied. As your email subject line is copied directly into the kernel changelog, please indicate the area of the kernel you are patching as a prefix (read http://linux.yyz.us/patch-format.html) Example: Subject: PHY: Add support for Marvell 88eS and 88e1145 - 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: bcm43xx-d80211 broadcast reception with WPA
On Tuesday 14 November 2006 15:40, Johannes Berg wrote: On Wed, 2006-11-15 at 01:29 +1100, Paul TBBle Hampson wrote: Just to summarise results so far: (Current version) bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX (version from wireless-dev before October 23rd, unsure of exact date) bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX The last item is interesting. The softmac version doesn't include any hw crypto so it never checks the 'decrypt attempted' bit in the RX header afaik, leaving all crypto to hw. I postulated before that the problem is that the firmware sets the 'decrypt attempted' bit even if the key is none, hence the driver tells the d80211 stack that the frame was already decrypted (no decrypt error occurs because in reality the algorithm is 'none'.) You could test this theory by clearing the 'decrypt attempted' bit unconditionally in the RX path before it is ever tested. Then, any wep/aes should no longer work properly with v4 firmware and bcm43xx-d80211, but tkip would. If my theory is correct. yes, Johannes. The problem is that the decrypt attempted bit is even set for key_none. When I force-disable this codepath, TKIP works perfectly well. I will do a patch for this. There are a few other minor bugs in the crypto stuff, which I will fix, too. Key clearing is not handled 100% correct, etc... -- 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: Network virtualization/isolation
Then a matrix of how each requires what modifications in the network code. Of course all players need to agree that the description is accurate. Is there such a document? cheers, jamal Hi, the attached document describes the network isolation at the layer 2 and at the layer 3, it presents the pros and cons of the different approaches, their common points and the impacted network code. I hope it will be helpful :) Cheers. -- Daniel Isolating and virtualizing the network -- Some definitions: - isolation : This is a restrictive technique which divides a set of the available system objects to smaller subsets assigned to a group of processes. This technique ensures an application will use only a subset of the system resources and will never access other resources. virtualization : This technique gives the illusion to an application that its owns all the system resources instead of a subset of them provided by the isolation. container: it is the name of the base element which brings the isolation and the virtualization where applications are running into. system container: operating system running inside a container. application container : application running inside a container. checkpoint/restart: take a snapshot of a container at a given time and recreate the container from this snapshot. mobility: checkpoint/restart used to move a container to one host to another host. Actually, containers are being developed in the kernel with the following functions : * separate the system resources between containers in order to avoid an application, running into a container, to access the resources outside the container. That facilitates the resources management, ensures the application is jailed and increases the security. * virtualize the resources, that avoids resources conflict between containers, that allows to run several instance of the same servers without modifying its network configuration. * the combination of the isolation and the virtualization is the base for the checkpoint/restart. The checkpoint is easier because the resources are identified by container and the restart is possible because the applications can be recreated with the same resources identifier without conflicts. For example, the application has the pid 1000, it is checkpointed and when it is restarted the same pid is assigned to it and it will not conflict because pids are isolated and virtualized. In all the system resources, the network is one of the biggest part to isolate and virtualize. Some solutions were proposed, with different approaches and different implementations. Layer 2 isolation and virtualization The virtualization acts at the network device level. The routes and the sockets are isolated. Each container has its own network device and its own routes. The network must be configured in each container. This approach brings a very strong isolation and a perfect virtualization for the system containers. - Ingress traffic The packets arrive to the real network device, outside of the container. Depending on the destination, the packets are forwarded to the network device assigned to the container. From this point, the path is the same and the packets go through the routes and the sockets layer because they are isolated into the container. - Outgoing traffic The packets go through the sockets, the routes, the network device assigned to the container and finally to the real device. Implementation: --- Andrey Savochkin, from OpenVZ team, patchset of this approach uses the namespace concept. All the network devices are no longer stored into the dev_base_list but into a list stored into the network namespace structure. Each container has its own network namespace. The network device access has been changed to access the network device list relative to the current namespace's context instead of the global network device list. The same has been made for the routing tables, they are all relatives to the namespace and are no longer global static. The creation of a new network namespace implies the creation of a new set of routing table. After the creation of a container, no network device exists. It is created from outside by the container's parent. The communication between the new container and the outside is done via a special pair device which have each extremities into each namespace. The MAC addresses must be specified and these addresses should be handled by the containers developers in order to ensure MAC unicity. After this network device creation step into each namespace, the network configuration is done as usual, in other words, with a new
Re: [PATCH] WAN: DSCC4 driver requires generic HDLC
Krzysztof Halasa wrote: Another thing, reported recently to me by several people - DSCC4 WAN driver now (and perhaps for the last couple of years+) requires the generic HDLC. I've fixed the Kconfig and moved the DSCC4 option under CONFIG_HDLC so it's consistent visually. Jeff, Francois, I think it's safe to apply. Thanks. Signed-off-by: Krzysztof Halasa [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 take 2] Atmel MACB ethernet driver
Haavard Skinnemoen wrote: Driver for the Atmel MACB on-chip ethernet module. Tested on AVR32/AT32AP7000/ATSTK1000. I've heard rumours that it works with AT91SAM9260 as well, and it may be possible to share some code with the at91_ether driver for AT91RM9200. Hardware documentation can be found in the AT32AP7000 data sheet, which can be downloaded from http://www.atmel.com/dyn/products/datasheets.asp?family_id=682 Changes since previous version: * Probe for PHY ID instead of depending on it being provided through platform_data. * Grab initial ethernet address from the MACB registers instead of depending on platform_data. * Set MII/RMII mode correctly. These changes are mostly about making the driver more compatible with the at91 infrastructure. Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED] applied. Thanks for submitting a nice, clean driver that was so painless to apply to the latest kernel. I wish all vendors were as effective and efficient. 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: Generic Netlink Updates
Thomas Graf wrote: Various simplifications to the generic netlink interface partially based on suggestions by Paul Moore. Acked-by: Paul Moore [EMAIL PROTECTED] These changes all look good to me. -- paul moore linux security @ hp - 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: Network virtualization/isolation
On Tue, 14 Nov 2006, Daniel Lezcano wrote: the attached document describes the network isolation at the layer 2 and at the layer 3, it presents the pros and cons of the different approaches, their common points and the impacted network code. I hope it will be helpful :) What about other network subsystems: xfrm, netfilter, iptables, netlink, etc. ? - James -- James Morris [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
Netpoll client software?
Hi folks, I'm looking for some suggestions for software that uses the kernel's netpoll interface to receive packets. The only in-kernel application that uses netpoll right now is netconsole, and that only sends packets. Used to be, netdump would use the netpoll interface for both transmit and receive, but netdump is gone now, and won't even compile on any recent kernel. I've made some changes to e1000's netpoll code to support some Top Secret Upcoming Hardware, and I would like to be able to validate my changes. Any suggestions? Thanks, Mitch - 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] fix up sysctl_tcp_mem initialization
The initial values of sysctl_tcp_mem are sometimes greater than the total memory in the system (particularly on SMP systems). This patch ensures that tcp_mem[2] is always = 3/4 nr_kernel_pages. However, I wonder if we want to set this differently than the way this patch does it. Depending on how far off the memory size is from a power of two (exactly equal to a power of two is the worst case), and if total memory 128M, it can be substantially less than 3/4. -John Fix up tcp_mem initiail settings to take into account the size of the hash entries (different on SMP and non-SMP systems). Signed-off-by: John Heffner [EMAIL PROTECTED] --- commit d4ef8c8245c0a033622ce9ba9e25d379475254f6 tree 5377b8af0bac3b92161188e7369a84e472b5acb2 parent ea55b7c31b47edf90132baea9a088da3bbe2bb5c author John Heffner [EMAIL PROTECTED] Tue, 14 Nov 2006 14:53:27 -0500 committer John Heffner [EMAIL PROTECTED] Tue, 14 Nov 2006 14:53:27 -0500 net/ipv4/tcp.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 4322318..c05e8ed 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2316,9 +2316,10 @@ void __init tcp_init(void) sysctl_max_syn_backlog = 128; } - sysctl_tcp_mem[0] = 768 order; - sysctl_tcp_mem[1] = 1024 order; - sysctl_tcp_mem[2] = 1536 order; + /* Allow no more than 3/4 kernel memory (usually less) allocated to TCP */ + sysctl_tcp_mem[0] = (1536 / sizeof (struct inet_bind_hashbucket)) order; + sysctl_tcp_mem[1] = sysctl_tcp_mem[0] * 4 / 3; + sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2; limit = ((unsigned long)sysctl_tcp_mem[1]) (PAGE_SHIFT - 7); max_share = min(4UL*1024*1024, limit);
status of route matching work?
Thomas, I came across this comment in DaveM's blog: Next he described a way to do route matching based upon branching rules with a GOTO operation. Only forward GOTOs would be allowed in the tree in order to prevent loops, but this would allow to match on many key components and allow a high level of rule sharing. One nice consequence of Thomas's work is that we can force packets for a local address to still go over a real ethernet device. Some people do this for testing and the current kernel cannot do this. Continually a very ugly patch keeps getting submitted which allowed this but broke a lot of other things. Thomas's ideas allow this to be supported cleanly. And was wondering what the status of this work was. I'm interested in being able to force packets for a local address out a real ethernet device. thanks - kumar - 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
[TG3]: Increase 5906 firmware poll time.
[TG3]: Increase 5906 firmware poll time.
From: Gary Zambrano [EMAIL PROTECTED]
Newer 5906 bootcode needs about 7ms to finish resetting so the poll
firmware loop was changed to maximum 20ms.
Signed-off-by: Gary Zambrano [EMAIL PROTECTED]
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 8f059b7..d4b211c 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -4728,10 +4728,11 @@ static int tg3_poll_fw(struct tg3 *tp)
u32 val;
if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5906) {
- for (i = 0; i 400; i++) {
+ /* Wait up to 20ms for init done. */
+ for (i = 0; i 200; i++) {
if (tr32(VCPU_STATUS) VCPU_STATUS_INIT_DONE)
return 0;
- udelay(10);
+ udelay(100);
}
return -ENODEV;
}
-
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
netpoll patches.
The following changes since commit 5d1be92267c04a86232969710e32b6f99bb4ec12: Peter Zijlstra: [SCTP]: Cleanup of the sctp state table code. are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/netpoll-2.6.20 Stephen Hemminger: netpoll: private skb pool (rev3) netpoll info leak netpoll per device txq netpoll setup error handling netpoll deferred transmit path netpoll retry cleanup netpoll queue cleanup netpoll header cleanup drivers/net/netconsole.c |8 +- include/linux/netpoll.h | 15 ++- net/core/netpoll.c | 233 +- 3 files changed, 121 insertions(+), 135 deletions(-) - 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] qla3xxx: Add support for Qlogic ISP4032 chip.
oops, that patch is borked (line-wrapped). will resend ASAP. Ron Mercer. From 742b2f96f918225560f338b6f975c5c7ae23ba9c Mon Sep 17 00:00:00 2001 From: Ron Mercer [EMAIL PROTECTED] Date: Mon, 13 Nov 2006 13:03:17 -0800 Subject: [PATCH] Add support for Qlogic ISP4032 chip. Remove unused variables. Signed-off-by: Ron Mercer [EMAIL PROTECTED] --- drivers/net/qla3xxx.c | 831 +++-- drivers/net/qla3xxx.h | 107 +- 2 files changed, 614 insertions(+), 324 deletions(-) diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c index ec640f6..902135c 100644 --- a/drivers/net/qla3xxx.c +++ b/drivers/net/qla3xxx.c @@ -22,6 +22,7 @@ #include linux/interrupt.h #include linux/errno.h #include linux/ioport.h #include linux/ip.h +#include linux/in.h #include linux/if_arp.h #include linux/if_ether.h #include linux/netdevice.h @@ -38,7 +39,7 @@ #include qla3xxx.h #define DRV_NAME qla3xxx #define DRV_STRING QLogic ISP3XXX Network Driver -#define DRV_VERSION v2.02.00-k36 +#define DRV_VERSION v2.03.00-k2 #define PFX DRV_NAME ... - 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 notes / pre d80211 merge
0. Introduction Hi, As promised on IRC, here are some thoughts on what d80211 is currently doing and what should in my opinion be changed. I'm writing this now mostly because I think that we have userspace visible issues to sort out *before* we can land in -mm or even mainline with d80211. This discussion is split up as follows: (1) master netdev (2) skb path during rx (3) skb path during tx (4) wiphy concept (5) so it works, what's wrong? (6) d80211 as a protocol? (7) d80211 without master netdev? (8) what about a combination, or other solutions? (9) conclusion (1) through (4) are just a recap of what we currently have to illustrate some things for later. Also serves as a starting point for those not as familiar. Could of course contain errors, I hope not too many. (5) discusses what I think is wrong, while (6) through (8) discuss possible scenarios I came up with to fix it. Note that all these things are long-term. Probably longer than we can wait with a merge, however we should settle on how the userspace interface will look like before the merge. 1. master netdev Currently, we have the 'master' netdev wmasterN which is created as native 802.11 device but is essentially useless. It is exported to userspace but only supports wireless extensions and, depending on what the drivers do, ethtool ops. It isn't really useful for network functionality although outgoing frames can be seen on it. See section (3) for why. Internally, the master netdev is also a virtual access point mode device, but this is only relevant in the RX path I think. Additionally, the master netdev represents the underlying 802.11 hardware when it comes to qdisc manipulation. 2. skb path during rx When a frame is received, it is put into an skb by the lowlevel driver and handed to d80211 by way of __ieee80211_rx() [1]. They then travel through the whole d80211 (pre) rx handlers and finally show up as 802.3 frames in the appropriate virtual device. Note that these frames are never associated with the master netdev, hence won't show up when you run tcpdump or similar on it. The whole rx handler thing could (and should!) be cleaned up quite a lot and can be made more efficient too, but it is purely internal right now so not a big deal. Food for another d80211 note. [1] why we didn't make a static inline ieee80211_rx() that calls an exported __ieee80211_rx() until we get rid of the other ieee80211 is beyond me. Would have been good but I guess we can also just convert all the drivers when we change the name again. 3. skb path during tx This is more complicated. When a frame is created in one of the virtual interfaces, it first goes through through conversion from 802.3 into 802.11, some tx control is added on and the frame is queued to the master netdev. This is why we see outgoing frames in tcpdump. After getting queued to the master netdev, the frame goes through the qdiscs and some more info is tacked on into skb-cb by the 802.11 qdisc. Afterwards, if the frame is not dropped, it shows up in ieee80211_master_start_xmit where skb-cb is copied onto the stack and cleared afterwards. Then, the frame goes through all the tx handlers including fragmentation and encryption and is finally given to the lowlevel driver via the hardware description's tx() call. 4. wiphy concept Straying a bit from the discussion of frames and similar, let me describe the wiphy concept we currently have. Currently, in sysfs we have class/ieee80211/phy%d/ and below that a wealth of information not only about various hardware related things but also, for example, a list of all stations associated to any virtual access points intermixed with those 'stations' that we are associated to on any virtual interface. Also, we here find 'add_iface' and 'remove_iface', knobs to create and destroy virtual interfaces. The second wiphy concept is currently present in cfg80211 which currently requires this concept in the userspace interface and should effectively replace the 'add_iface' and 'remove_iface' hooks and make them more generically available for non-d80211 drivers. I was thinking of ipw2200 when I wrote it which allows adding a monitor device (currently through some config option I think). 5. so it works, what's wrong? Pretty broad question I asked myself here, but let me try to answer it anyway. For one, I think that having the master device in its current form is useless. It sees outgoing frames that are to be sent to the hardware for transmission, and in that way represents the actual underlying hardware. However, it never sees incoming frames, so there again it doesn't represent the hardware. Not seeing incoming frames makes it useless, and even through it sees outgoing frames you cannot send frames to it. Also, if the master netdev is thought of as representing the hardware (which I don't think it fully does), it collides with the notion of the 'wiphy' as described above. The master netdev and wiphy create two orthogonal
Re: Netpoll client software?
On Tue, Nov 14, 2006 at 11:38:58AM -0800, Williams, Mitch A wrote: Hi folks, I'm looking for some suggestions for software that uses the kernel's netpoll interface to receive packets. The only in-kernel application that uses netpoll right now is netconsole, and that only sends packets. Used to be, netdump would use the netpoll interface for both transmit and receive, but netdump is gone now, and won't even compile on any recent kernel. I've made some changes to e1000's netpoll code to support some Top Secret Upcoming Hardware, and I would like to be able to validate my changes. Any suggestions? kgdboe - kgdb over ethernet. There are various patch versions floating around, one of which was in Andrew Morton's -mm kernels. Regards, Bill rugolsky - 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] qla3xxx: Add support for Qlogic ISP4032 chip.
Ron Mercer [EMAIL PROTECTED] : oops, that patch is borked (line-wrapped). will resend ASAP. If you can isolate the support of the new chipset and the cleanups, it will make my life easier. I have got some pending minor changes. -- Ueimor - 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: [TG3]: Increase 5906 firmware poll time.
Michael Chan wrote: [TG3]: Increase 5906 firmware poll time. From: Gary Zambrano [EMAIL PROTECTED] Newer 5906 bootcode needs about 7ms to finish resetting so the poll firmware loop was changed to maximum 20ms. Signed-off-by: Gary Zambrano [EMAIL PROTECTED] Signed-off-by: Michael Chan [EMAIL PROTECTED] ACK, of course, but this brings up something else: what's the status of moving chip reset outside of a spinlock? Currently a reset during operation can trigger the CPU lockup detector and other doo-dads, because you can easily spend a second or two with a spinlock held (a loong time, to hold a spinlock) 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: [TG3]: Increase 5906 firmware poll time.
On Tue, 2006-11-14 at 18:05 -0500, Jeff Garzik wrote: ACK, of course, but this brings up something else: what's the status of moving chip reset outside of a spinlock? Currently a reset during operation can trigger the CPU lockup detector and other doo-dads, because you can easily spend a second or two with a spinlock held (a loong time, to hold a spinlock) Yeah, I will put this in my queue. I have done some of that in the PHY routines and will continue to do more, as those are even worse. - 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 notes / pre d80211 merge
On Tue, 14 Nov 2006 23:19:57 +0100, Johannes Berg wrote: 1. master netdev Currently, we have the 'master' netdev wmasterN which is created as native 802.11 device but is essentially useless. It is exported to userspace but only supports wireless extensions and, depending on what the drivers do, ethtool ops. It isn't really useful for network functionality although outgoing frames can be seen on it. See section (3) for why. I wouldn't say useless. It's actually a hack (and you yourself described in (7) why it is currently necessary). We'll need to live with it or cripple the stack to support only very basic features or rewrite the Linux networking core. Choose your own favorite solution :-) [1] why we didn't make a static inline ieee80211_rx() that calls an exported __ieee80211_rx() until we get rid of the other ieee80211 is beyond me. Would have been good but I guess we can also just convert all the drivers when we change the name again. Yes, it's just temporary and it doesn't matter. 3. skb path during tx This is more complicated. When a frame is created in one of the virtual interfaces, it first goes through through conversion from 802.3 into 802.11, some tx control is added on and the frame is queued to the master netdev. This is why we see outgoing frames in tcpdump. After getting queued to the master netdev, the frame goes through the qdiscs and some more info is tacked on into skb-cb by the 802.11 qdisc. Afterwards, if the frame is not dropped, it shows up in ieee80211_master_start_xmit where skb-cb is copied onto the stack and cleared afterwards. Then, the frame goes through all the tx handlers including fragmentation and encryption and is finally given to the lowlevel driver via the hardware description's tx() call. During the tx handlers phase that copy of skb-cb is extended quite a lot with other information determined in the tx handlers. The result is a structure that doesn't fit into cb anymore. This is a reason for not using cb to pass tx information to drivers. 4. wiphy concept Straying a bit from the discussion of frames and similar, let me describe the wiphy concept we currently have. Currently, in sysfs we have class/ieee80211/phy%d/ and below that a wealth of information not only about various hardware related things but also, for example, a list of all stations associated to any virtual access points intermixed with those 'stations' that we are associated to on any virtual interface. Also, we here find 'add_iface' and 'remove_iface', knobs to create and destroy virtual interfaces. The second wiphy concept is currently present in cfg80211 which currently requires this concept in the userspace interface and should effectively replace the 'add_iface' and 'remove_iface' hooks and make them more generically available for non-d80211 drivers. I was thinking of ipw2200 when I wrote it which allows adding a monitor device (currently through some config option I think). Not a big problem to combine these two wiphys into just one. 5. so it works, what's wrong? Pretty broad question I asked myself here, but let me try to answer it anyway. For one, I think that having the master device in its current form is useless. It sees outgoing frames that are to be sent to the hardware for transmission, and in that way represents the actual underlying hardware. However, it never sees incoming frames, so there again it doesn't represent the hardware. Not seeing incoming frames makes it useless, and even through it sees outgoing frames you cannot send frames to it. Also, if the master netdev is thought of as representing the hardware (which I don't think it fully does), it collides with the notion of the 'wiphy' as described above. Please note that master interface has been always considered as a hack. Of course, this perception can be changed if it's desirable. Personally, I tried to make this interface uninteresting for users as much as possible - so we can tell ordinary users: That's just an annoying internal thing, don't touch it and don't care about it. Of course, advanced users need to care (because of qdiscs). This is not optimal (although I'm not sure there exists an optimal solution here) and I'm not strongly attached to this. The master netdev and wiphy create two orthogonal interfaces to userspace that nonetheless pretty much represent the same thing---the underlying hardware. Yup. As said previously, the master netdev represents the hardware when it comes to qdisc manipulation, but the wiphy represents the hardware when it comes to manipulation of virtual interfaces. I believe that this is fundamentally wrong because they both manipulate operation of the underlying hardware. There is one thing you haven't mentioned and which was probably the key reason for not believing this concept was wrong: we want to make the transition to the new stack as smooth to the users as possible. Users are not used to use the master
RE: [PATCH] qla3xxx: Add support for Qlogic ISP4032 chip.
I will do that. You can expect the isolated chipset changes tomorrow. Cleanup will follow later. Regards, Ron -Original Message- From: Francois Romieu [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 2:50 PM To: Ron Mercer Cc: netdev@vger.kernel.org Subject: Re: [PATCH] qla3xxx: Add support for Qlogic ISP4032 chip. Ron Mercer [EMAIL PROTECTED] : oops, that patch is borked (line-wrapped). will resend ASAP. If you can isolate the support of the new chipset and the cleanups, it will make my life easier. I have got some pending minor changes. -- Ueimor - 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: [TG3]: Increase 5906 firmware poll time.
From: Michael Chan [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 16:05:50 -0800 On Tue, 2006-11-14 at 18:05 -0500, Jeff Garzik wrote: ACK, of course, but this brings up something else: what's the status of moving chip reset outside of a spinlock? Currently a reset during operation can trigger the CPU lockup detector and other doo-dads, because you can easily spend a second or two with a spinlock held (a loong time, to hold a spinlock) Yeah, I will put this in my queue. I have done some of that in the PHY routines and will continue to do more, as those are even worse. Great. I applied this patch, thanks everyone. - 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
Please pull 'upstream-fixes' branch of wireless-2.6
The following changes since commit 0579e303553655245e8a6616bd8b4428b07d63a2:
Linus Torvalds:
Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Zhu Yi:
ieee80211: Fix kernel panic when QoS is enabled
net/ieee80211/ieee80211_tx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee80211/ieee80211_tx.c b/net/ieee80211/ieee80211_tx.c
index ae25449..854fc13 100644
--- a/net/ieee80211/ieee80211_tx.c
+++ b/net/ieee80211/ieee80211_tx.c
@@ -390,7 +390,7 @@ int ieee80211_xmit(struct sk_buff *skb,
* this stack is providing the full 802.11 header, one will
* eventually be affixed to this fragment -- so we must account
* for it when determining the amount of payload space. */
- bytes_per_frag = frag_size - IEEE80211_3ADDR_LEN;
+ bytes_per_frag = frag_size - hdr_len;
if (ieee-config
(CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS))
bytes_per_frag -= IEEE80211_FCS_LEN;
@@ -412,7 +412,7 @@ int ieee80211_xmit(struct sk_buff *skb,
} else {
nr_frags = 1;
bytes_per_frag = bytes_last_frag = bytes;
- frag_size = bytes + IEEE80211_3ADDR_LEN;
+ frag_size = bytes + hdr_len;
}
rts_required = (frag_size ieee-rts
--
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
Please pull 'upstream' branch of wireless-2.6
The following changes since commit 4c5d3c72166676663c3917839a030b86fa758b23:
John W. Linville:
Merge branch 'upstream-fixes' into upstream
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
John W. Linville:
prism54: correct overly aggressive check of return from pci_set_mwi
Larry Finger:
bcm43xx: correct Move IV/ICV stripping into ieee80211_rx
drivers/net/wireless/bcm43xx/bcm43xx_xmit.c |1 +
drivers/net/wireless/prism54/islpci_hotplug.c |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
b/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
index a957bc8..3e24626 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,6 +543,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}
+ frame_ctl = le16_to_cpu(wlhdr-frame_ctl);
switch (WLAN_FC_GET_TYPE(frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
ieee80211_rx_mgt(bcm-ieee, wlhdr, stats);
diff --git a/drivers/net/wireless/prism54/islpci_hotplug.c
b/drivers/net/wireless/prism54/islpci_hotplug.c
index e0bca3a..58257b4 100644
--- a/drivers/net/wireless/prism54/islpci_hotplug.c
+++ b/drivers/net/wireless/prism54/islpci_hotplug.c
@@ -170,8 +170,8 @@ #endif
pci_set_master(pdev);
/* enable MWI */
- if (pci_set_mwi(pdev))
- goto do_pci_release_regions;
+ if (!pci_set_mwi(pdev))
+ printk(KERN_INFO %s: pci_set_mwi(pdev) succeeded\n, DRV_NAME);
/* setup the network device interface and its structure */
if (!(ndev = islpci_setup(pdev))) {
--
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 notes / pre d80211 merge
Hi Jiri, I disagree that the master device is a hack - I also disagree that we should use 802.11 format frames anywhere but internally inside the 802.11 stack. The 802.11 specification does not use 802.11 format frames to communicate with the upper layers - it uses almost exactly the same interface as 802.3 ethernet does. This is a 2 address interface. I believe that using the standard 2 address format to talk with upper layers matches well with the spec and is the right way to do things. If you put 802.11 frame format directly into the L3 protocols then you make all these protocols depend on the MAC - since they will now implement part of the MAC inside the L3 protocol. I don't think this is the right thing to do. I believe that the mapping of 3 and 4 address frames to a particular virtual 2 address port is the right way to do this mapping. It is normal to have a single interface to represent the physical hardware network interface. This is exactly the pattern that many other physical network devices use. Things like sniffing should go on on this physical interface - and the changes that johannes proposes are exactly the right things to enable this. I would go further - and perhaps move some of the meta-data that is in the skb-cb into a d80211 specific hardware header. This would allow sniffers to directly attach to the master device and both send and receive frames complete with the meta data. It would also reduce the amount of cb space we need. Virtual devices could be created in order to use sniffers that use a different hardware header format (with a small performance penalty when using those). Simon -Original Message- From: Jiri Benc [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 6:11 PM To: Johannes Berg Cc: netdev; Jeff Garzik; John W. Linville; Simon Barber; Michael Buesch; Ivo van Doorn; Michael Wu; Jouni Malinen; Daniel Drake; Hong Liu; Luis R. Rodriguez; James Ketrenos; David Kimdon; Udayan Singh Subject: Re: wireless notes / pre d80211 merge On Tue, 14 Nov 2006 23:19:57 +0100, Johannes Berg wrote: 1. master netdev Currently, we have the 'master' netdev wmasterN which is created as native 802.11 device but is essentially useless. It is exported to userspace but only supports wireless extensions and, depending on what the drivers do, ethtool ops. It isn't really useful for network functionality although outgoing frames can be seen on it. See section (3) for why. I wouldn't say useless. It's actually a hack (and you yourself described in (7) why it is currently necessary). We'll need to live with it or cripple the stack to support only very basic features or rewrite the Linux networking core. Choose your own favorite solution :-) [1] why we didn't make a static inline ieee80211_rx() that calls an exported __ieee80211_rx() until we get rid of the other ieee80211 is beyond me. Would have been good but I guess we can also just convert all the drivers when we change the name again. Yes, it's just temporary and it doesn't matter. 3. skb path during tx This is more complicated. When a frame is created in one of the virtual interfaces, it first goes through through conversion from 802.3 into 802.11, some tx control is added on and the frame is queued to the master netdev. This is why we see outgoing frames in tcpdump. After getting queued to the master netdev, the frame goes through the qdiscs and some more info is tacked on into skb-cb by the 802.11 qdisc. Afterwards, if the frame is not dropped, it shows up in ieee80211_master_start_xmit where skb-cb is copied onto the stack and cleared afterwards. Then, the frame goes through all the tx handlers including fragmentation and encryption and is finally given to the lowlevel driver via the hardware description's tx() call. During the tx handlers phase that copy of skb-cb is extended quite a lot with other information determined in the tx handlers. The result is a structure that doesn't fit into cb anymore. This is a reason for not using cb to pass tx information to drivers. 4. wiphy concept Straying a bit from the discussion of frames and similar, let me describe the wiphy concept we currently have. Currently, in sysfs we have class/ieee80211/phy%d/ and below that a wealth of information not only about various hardware related things but also, for example, a list of all stations associated to any virtual access points intermixed with those 'stations' that we are associated to on any virtual interface. Also, we here find 'add_iface' and 'remove_iface', knobs to create and destroy virtual interfaces. The second wiphy concept is currently present in cfg80211 which currently requires this concept in the userspace interface and should effectively replace the 'add_iface' and 'remove_iface' hooks and make them more generically available for non-d80211 drivers. I was thinking of ipw2200 when I wrote it which allows adding a monitor device (currently
Re: [PATCH 2.6.20] [TCP] MD5 Signature Option (RFC2385) support.
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 07:06:36 -0800 (PST) Good point, I agree. Here's the updated and rebased patch. From a3dea6a6b127b3d38932677c8da854b62a20540e Mon Sep 17 00:00:00 2001 From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 09:57:39 +0900 Subject: [PATCH] [TCP]: MD5 Signature Option (RFC2385) support. Based on implementation by Rick Payne. Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] Looks great, patch applied, thanks a lot. - 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: Generic Netlink Updates
From: Paul Moore [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 12:23:59 -0500 Thomas Graf wrote: Various simplifications to the generic netlink interface partially based on suggestions by Paul Moore. Acked-by: Paul Moore [EMAIL PROTECTED] These changes all look good to me. Me too, all applied, thanks Thomas. - 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] iflink: Convert IPv6's RTM_GETLINK to use the new netlink api
From: Thomas Graf [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 15:27:14 +0100 By replacing the current method of exporting the device configuration which included allocating a temporary buffer, copying ipv6_devconf into it and copying that buffer into the message with a method that uses nla_reserve() allowing to copy the device configuration directly into the skb data buffer, a GFP_ATOMIC allocation could be removed. Signed-off-by: Thomas Graf [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: [IPv6] prefix: Convert RTM_NEWPREFIX notifications to use the new netlink api
From: Thomas Graf [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 15:27:43 +0100 RTM_GETPREFIX is completely unused and is thus removed. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Also applied, thanks Thomas. - 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: [PATCHv2 1/2]: [NET]: Supporting UDP-Lite (RFC 3828) in Linux
From: Gerrit Renker [EMAIL PROTECTED]
Date: Tue, 14 Nov 2006 08:48:45 +
[NET]: Supporting UDP-Lite (RFC 3828) in Linux
This is a revision of the previously submitted patch, which alters
the way files are organized and compiled in the following manner:
* UDP and UDP-Lite now use separate object files
* source file dependencies resolved via header files
net/ipv{4,6}/udp_impl.h
* order of inclusion files in udp.c/udplite.c adapted
accordingly
Looks excellent, applied to net-2.6.20, thanks Gerrit.
-
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: [PATCHv2 2/2]: net/ipv{4,6}: reduce code size by inlining
From: Gerrit Renker [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 12:50:33 + Quoting Andi Kleen: | On Tuesday 14 November 2006 09:49, Gerrit Renker wrote: | [UDP]: Reduce size of shared code | | This patch reduces size of source code files by moving | some of the smaller functions shared by UDP and UDP-Lite | into the header file udp_impl.h, and in-lining these. | | It is an optimisation and applies on top of the previous | UDP-Lite patch. | | Wouldn't it be better to just call them? They all don't | particularly time critical. This patch was sent as an optional add-on, it is not as important as the other one. You are probably right - I also noted that the gains (in terms of line numbers) are not as high as intended. I'm not too sure on this one either, so I won't apply this one for now. - 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] fix up sysctl_tcp_mem initialization
From: John Heffner [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 15:02:05 -0500 The initial values of sysctl_tcp_mem are sometimes greater than the total memory in the system (particularly on SMP systems). This patch ensures that tcp_mem[2] is always = 3/4 nr_kernel_pages. This is a genuine bug fix so I'll apply this, thanks for taking care of these corner-case bugs in TCP sizing Jeff. However, I wonder if we want to set this differently than the way this patch does it. Depending on how far off the memory size is from a power of two (exactly equal to a power of two is the worst case), and if total memory 128M, it can be substantially less than 3/4. Longer term, yes, probably a better way exists. So you concern is that when we round to a power of 2 like we do now, we often mis-shoot? - 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: netpoll patches.
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 14 Nov 2006 13:55:00 -0800 The following changes since commit 5d1be92267c04a86232969710e32b6f99bb4ec12: Peter Zijlstra: [SCTP]: Cleanup of the sctp state table code. are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/netpoll-2.6.20 Stephen Hemminger: netpoll: private skb pool (rev3) netpoll info leak netpoll per device txq netpoll setup error handling netpoll deferred transmit path netpoll retry cleanup netpoll queue cleanup netpoll header cleanup Pulled, thanks a lot Stephen. I made a small follow-on patch to tidy up some coding style things I noticed while re-reviewing this work. Thanks again for taming the beast :) - 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: Netpoll client software?
On Tuesday 14 November 2006 20:38, Williams, Mitch A wrote: Hi folks, I'm looking for some suggestions for software that uses the kernel's netpoll interface to receive packets. The only in-kernel application that uses netpoll right now is netconsole, and that only sends packets. There are kgdb version that support debugging over ethernet. That requires sending and receiving. Not sure if it works right now with the version in -mm* though. -Andi - 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
ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
It is my pleasure to announce that the SFLC [1] has assisted the ar5k developers in evaluating the development history of Reyk Floeter's OpenBSD reverse-engineered Atheros HAL, ar5k [2]. SFLC's assessment leads to the conclusion that free software developers should not be worried about using/extending ar5k or porting ar5k to other platforms. In the past there were serious questions raised and even dire warnings made about ar5k's copyright status. The purpose of this statement is to refute those claims and to publicly clarify ar5k's status to developers. SFLC has made independent inquiries with the OpenBSD team regarding the development history of ar5k source. The responses received provide a reasonable basis for SFLC to believe that the OpenBSD developers who worked on ar5k did not misappropriate code, and that the ar5k implementation is OpenBSD's original copyrighted work. This announcement should serve to remove the cloud which has prevented progress towards an in-kernel driver for Atheros hardware. This should be of particular interest to those involved with the DadWifi project [3]. I'd like to take this opportunity to thank the folks at the SFLC for their hard work, and I'd also like to personally thank Luis Rodriguez for the role he played in coordinating contact between the SFLC and the community at large. Thanks! John [1] http://www.softwarefreedom.org/ [2] http://team.vantronix.net/ar5k/ [3] http://marc.theaimsgroup.com/?l=linux-netdevm=116113064513921w=2 -- 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] dccp: remove module exit functions
On 11/13/06, David Miller [EMAIL PROTECTED] wrote: From: Arnaldo Carvalho de Melo [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 16:32:16 -0200 On 11/10/06, James Morris [EMAIL PROTECTED] wrote: On Fri, 10 Nov 2006, James Morris wrote: I wonder if this facility can be integrated more generally into the kernel protocol which people are developing. Ugh, editor screwup. That was meant to be I wonder if this facility can be integrated more generally into the kernel as a kernel hacking option, as this is not the only protocol which people are developing. See: http://www.erg.abdn.ac.uk/users/gerrit/dccp/patch-backlog/09a_release_ctl_socket_at_exit.diff This one requires a bit more thinking, so I'm postponing it for now to get the simple bits in Gerrit's patch queue cherrypicked and sent for Dave. One possible way to handle this is to flag certain sockets such that no refrence counting is done for them against the module. It is an indication that the module will take care of such sockets on cleanup. It seems that this would limit the cost to a test at socket create and destroy time. Yes, but this is not the case currently with Gerrit's proposed patch, I'm postponing it for now, as one has to be very very careful to monitor the TW sockets with iproute2's ss before rmmoding with --force, have to revisit the old unload hack to combine its ideas with SCTP/Gerrit's approach, the old one was ugly, but at least refused to unload before all the TW sockets were gone. - Arnaldo [EMAIL PROTECTED] ~]# rmmod dccp_ipv4 ERROR: Module dccp_ipv4 is in use by [unsafe] [EMAIL PROTECTED] ~]# rmmod --force dccp_ipv4 [ 128.264180] slab error in kmem_cache_destroy(): cache `tw_sock_DCCP': Can't free all objects [ 128.265284] [c0141ea7] kmem_cache_destroy+0x77/0xd0 [ 128.266133] [c0201dcf] proto_unregister+0x8f/0xb0 [ 128.267222] [d085005c] dccp_v4_exit+0x3c/0x5b [dccp_ipv4] [ 128.268050] [c0128458] sys_delete_module+0x158/0x1d0 [ 128.268527] [c0269ada] do_page_fault+0x4ea/0x640 [ 128.269014] [c0102abf] syscall_call+0x7/0xb [ 128.269472] === [EMAIL PROTECTED] ~]# rmmod dccp [ 141.267175] slab error in kmem_cache_destroy(): cache `dccp_bind_bucket': Can't free all objects [ 141.268392] [c0141ea7] kmem_cache_destroy+0x77/0xd0 [ 141.268950] [d0847e93] dccp_fini+0x63/0x70 [dccp] [ 141.270046] [c0128458] sys_delete_module+0x158/0x1d0 [ 141.270530] [c013b6e4] do_munmap+0x1c4/0x230 [ 141.270964] [c0102abf] syscall_call+0x7/0xb [ 141.271414] === Followed by: BIG SNIP [ 147.347021] === [ 147.359334] Code: c3 08 e9 69 ff ff ff eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 55 89 cd 57 56 89 c6 53 8d 04 ca 83 ec 08 8b 10 89 e7 89 14 24 89 62 04 8b 50 04 89 22 89 54 24 04 89 00 8b 14 24 89 40 04 39 [ 147.395025] EIP: [c0115b05] cascade+0x15/0x60 SS:ESP 0068:c0304fa4 [ 147.403619] 0Kernel panic - not syncing: Fatal exception in interrupt [ 147.482149] - 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
