Re: [PATCH 20/20] iscsi: support for swapping over iSCSI.
On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote: Peter Zijlstra wrote: Implement sht-swapdev() for iSCSI. This method takes care of reserving the extra memory needed and marking all relevant sockets with SOCK_VMIO. When used for swapping, TCP socket creation is done under GFP_MEMALLOC and the TCP connect is done with SOCK_VMIO to ensure their success. Also the netlink userspace interface is marked SOCK_VMIO, this will ensure that even under pressure we can still communicate with the daemon (which runs as mlockall() and needs no additional memory to operate). Netlink requests are handled under the new PF_MEM_NOWAIT when a swapper is present. This ensures that the netlink socket will not block. User-space will need to retry failed requests. The TCP receive path is handled under PF_MEMALLOC for SOCK_VMIO sockets. This makes sure we do not block the critical socket, and that we do not fail to process incomming data. Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] CC: Mike Christie [EMAIL PROTECTED] --- drivers/scsi/iscsi_tcp.c| 103 +++- drivers/scsi/scsi_transport_iscsi.c | 23 +++- include/scsi/libiscsi.h |1 include/scsi/scsi_transport_iscsi.h |2 4 files changed, 113 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/scsi/iscsi_tcp.c === --- linux-2.6.orig/drivers/scsi/iscsi_tcp.c +++ linux-2.6/drivers/scsi/iscsi_tcp.c @@ -42,6 +42,7 @@ #include scsi/scsi_host.h #include scsi/scsi.h #include scsi/scsi_transport_iscsi.h +#include scsi/scsi_device.h #include iscsi_tcp.h @@ -845,9 +846,13 @@ iscsi_tcp_data_recv(read_descriptor_t *r int rc; struct iscsi_conn *conn = rd_desc-arg.data; struct iscsi_tcp_conn *tcp_conn = conn-dd_data; - int processed; + int processed = 0; char pad[ISCSI_PAD_LEN]; struct scatterlist sg; + unsigned long pflags = current-flags; + + if (sk_has_vmio(tcp_conn-sock-sk)) + current-flags |= PF_MEMALLOC; Is this too late or not needed or what is it for? This function gets run from the network layer's softirq and at this point we have a skbuff with data that we want to process. The iscsi layer also does not allocate memory for read or write IO in this path. I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); I think we would want to set this flag at a lower level. Something closer to where the skbuf is allocated? Is that the skbuff you were talking about? If so, I'd need to carve a path to pass the swapper information. I had that in a previous patch, but that was large and ugly. I had to go carrying gfp_t flags all through that call chain. I could try again if you prefer that. - 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
[RFC] genetlink custom attribute type
This patch adds an NLA_CUSTOM_CHECK type for netlink attributes
in order to be able to centrally define new attribute structures
instead of having to check these special types in each function
that uses such an attribute.
nl80211 will benefit from this because it needs an information
element attribute with a fixed type|length|value structure defined
in IEEE 802.11 which ought to be checked when passing an IE from
userspace.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- wireless-dev.orig/include/net/netlink.h 2006-09-13 22:06:09.979647141
+0200
+++ wireless-dev/include/net/netlink.h 2006-09-13 22:06:11.329647141 +0200
@@ -159,6 +159,7 @@ enum {
NLA_MSECS,
NLA_NESTED,
NLA_NUL_STRING,
+ NLA_CUSTOM_CHECK,
__NLA_TYPE_MAX,
};
@@ -176,6 +177,8 @@ enum {
*NLA_STRING Maximum length of string
*NLA_NUL_STRING Maximum length of string (excluding NUL)
*NLA_FLAG Unused
+ *NLA_CUSTOM_CHECK Unused, check function must be assigned,
+ * it must return 0 if the attribute is valid
*All otherExact length of attribute payload
*
* Example:
@@ -183,11 +186,13 @@ enum {
* [ATTR_FOO] = { .type = NLA_U16 },
* [ATTR_BAR] = { .type = NLA_STRING, len = BARSIZ },
* [ATTR_BAZ] = { .len = sizeof(struct mystruct) },
+ * [ATTR_CST] = { .type = NLA_CUSTOM_CHECK, .check = my_check },
* };
*/
struct nla_policy {
u16 type;
u16 len;
+ int (*check)(struct nlattr *nla);
};
extern voidnetlink_run_queue(struct sock *sk, unsigned int *qlen,
--- wireless-dev.orig/net/netlink/attr.c2006-09-13 22:06:05.889647141
+0200
+++ wireless-dev/net/netlink/attr.c 2006-09-13 22:06:11.329647141 +0200
@@ -67,6 +67,9 @@ static int validate_nla(struct nlattr *n
}
break;
+ case NLA_CUSTOM_CHECK:
+ BUG_ON(!pt-check);
+ return pt-check(nla);
default:
if (pt-len)
minlen = pt-len;
-
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: ieee80211 and devices which decrypt in hardware
On Wed, 2006-09-13 at 18:35 -0400, Daniel Drake wrote: + /* If the device does decryption but leaves the IV in place then we: +* need to kill it. */: + if (!can_be_decrypted (fc IEEE80211_FCTL_PROTECTED)): + hdrlen += 4;: That might work, unless there are devices that leave the protected bit set but do strip the IV/ICV... 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: [RFC] genetlink custom attribute type
* Johannes Berg [EMAIL PROTECTED] 2006-09-14 09:44 This patch adds an NLA_CUSTOM_CHECK type for netlink attributes in order to be able to centrally define new attribute structures instead of having to check these special types in each function that uses such an attribute. nl80211 will benefit from this because it needs an information element attribute with a fixed type|length|value structure defined in IEEE 802.11 which ought to be checked when passing an IE from userspace. Looks good, we have to watch the size of struct nla_policy though. This bumps the size from 4 bytes to 16 bytes on 64bit architectures which might become a problem since we always use ATTR_MAX sized arrays. - 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 for system lockups in 2.6.18-rcX caused by bcm43xx
On 12-09-2006 00:04, Jeff Garzik wrote: John W. Linville wrote: ... Not too explicitly, but I think Andrew mentions it in The Perfect Patch: http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt While you are looking, you might review Jeff's version of the same idea: http://linux.yyz.us/patch-format.html And also Documentation/SubmittingPatches, which ATM seems to have more detail than either page. Jeff Attachments are discouraged, but some corporate mail systems provide no other way to send patches. I thought they didn't read this but now I understand for whom Mozilla Firefox is breaking all those lines with no mercy! Jarek P. - 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 for system lockups in 2.6.18-rcX caused by bcm43xx
On Thu, Sep 14, 2006 at 10:25:32AM +0200, Jarek Poplawski wrote: ... Attachments are discouraged, but some corporate mail systems provide no other way to send patches. I thought they didn't read this but now I understand for whom Mozilla Firefox is breaking all those lines with no mercy! Mozilla Thunderbird. Sorry. Jarek P. - 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 8/12] smc911x: Fix external phy detect routine
On Wednesday 13 September 2006 22:02, Francois Romieu wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] :
9115-an1212.pdf, page 23 - http://www.smsc.com/main/anpdf/an1212.pdf
The existence of external PHYs is determined by reading
the same two PHY registers at PHY addresses 0x02 through 0x30. If values of
[...]
- for (phyaddr = 1; phyaddr 32; ++phyaddr) {
+ for (phyaddr = 2; phyaddr 30; ++phyaddr) {
Is 30 inclusive or not ?
You are right, inclusive...
--
Bora SAHIN
-
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: 2.6.18-rc6 memory mapped pcap truncates outgoing TCP packets, but not icmp
On Wed, Sep 13, 2006 at 08:44:21PM +0200, Patrick McHardy wrote: Are you using TSO on the outgoing device? If so please try to log the packet using iptables to see if it really is a TSO packet. Good catch! I turned off TSO and things are working fine again. Is this a known problem, should it be documented or fixed? I'm more than willing to write up some warnings should this be a good idea. Thanks Patrick! I can do without TSO but not without mmapped pcap! Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - 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 12/12] smc911x: afc_cfg calculation is wrong at case 5
On Wednesday 13 September 2006 22:02, Francois Romieu wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] : [...] BACKDUR calculation is wrong at case 5. Also some cosmetic around smc911x_probe... If you are in a mood for cosmetic, feel free to turn some unsigned long ioaddr into something more void __iomem *ioaddr and store it in the private part of the device struct instead of dev-base_addr. like struct smc911x_local *lp = netdev_priv(dev); void __iomem *ioaddr = lp-base_addr; ? [...] @@ -1977,7 +1975,7 @@ case 4:/* 11520 Rx Data Fifo Size */ lp-afc_cfg=0x00783C9F;break; case 5:/* 10560 Rx Data Fifo Size */ - lp-afc_cfg=0x006E374F;break; + lp-afc_cfg=0x006E378F;break; Not your fault but the break statement is misplaced. One line below? Thanks for all of your comments. I will create a new set of patches... -- Bora SAHIN - 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: [RFC] genetlink custom attribute type
On Thu, 2006-09-14 at 10:14 +0200, Thomas Graf wrote: Looks good, we have to watch the size of struct nla_policy though. This bumps the size from 4 bytes to 16 bytes on 64bit architectures which might become a problem since we always use ATTR_MAX sized arrays. Yes, I'm aware of that, but I couldn't think of a way to handle it well. I thought about using a second array containing just the check functions, and then (ab)using `len' to index into it but that didn't seem clean enough. Can you think of something better? 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: [PATCH 12/12] smc911x: afc_cfg calculation is wrong at case 5
@@ -1977,7 +1975,7 @@ case 4:/* 11520 Rx Data Fifo Size */ lp-afc_cfg=0x00783C9F;break; case 5:/* 10560 Rx Data Fifo Size */ - lp-afc_cfg=0x006E374F;break; + lp-afc_cfg=0x006E378F;break; Not your fault but the break statement is misplaced. Or one space ahead? like lp-afc_cfg=0x006E378F; break; -- Bora SAHIN - 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] EtherIP tunnel driver (RFC 3378)
On Thu, Sep 14, 2006 at 11:21:22AM +1000, Philip Craig wrote: Joerg Roedel wrote: +To configure tunnels an extra tool is required. You can download +it from http://zlug.fh-zwickau.de/~joro/projects/ under the +EtherIP section. If unsure, say N. To obtain a list of tunnels, this tool calls SIOCGETTUNNEL (SIOCDEVPRIVATE + 0) for every device in /proc/net/dev. I don't think this is safe, but I don't have a solution for you. You are right. But this is the way the ipip driver does it. In the case of ipip it is safe, because it is visible as a tunnel interface to userspace. But my driver registers its devices as Ethernet (it has to, otherwise the devices will not be usable in a bridge). There is no safe way to distinguish between real Ethernet devices and devices registered by my driver. I think about implementing an ioctl to fetch a list of all EtherIP tunnel devices from the driver. Is there a reason why you have a separate tool rather than modifying iproute2? I wrote an own tool for testing. At development I wanted to concentrate on the driver and not how to modify iproute2. But when the driver becomes stable and may be included I will add it to iproute2. I don't know if you are aware of this older etherip patch by Lennert Buytenhek: http://www.wantstofly.org/~buytenh/etherip/ I found this patch after I wrote my own and read the discussions about it. The patch by Lennert Buytenhek has the same problem of identifing tunnel devices. Futhermore, his driver handles ICMP and cares about the payload of the Ethernet packet it transmits (it looks, if the payload ist IPv4 or IPv6). Further it is configurable to set the DF flag in outgoing packets. First I think the handling of layer 3 protocols is beyond the scope of tunnel which transmits layer 2 packets. Second this behavior may break the transport of non-IP payload in the Ethernet packets since the Ethernet payload protocol may not know the concept of a path MTU and needs the full Ethernet MTU of 1500. This is the reason my driver never sets the DF flag in outgoing packets. Regards, Joerg Roedel - 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: 2.6.18-rc6 memory mapped pcap truncates outgoing TCP packets, but not icmp
bert hubert wrote: On Wed, Sep 13, 2006 at 08:44:21PM +0200, Patrick McHardy wrote: Are you using TSO on the outgoing device? If so please try to log the packet using iptables to see if it really is a TSO packet. Good catch! I turned off TSO and things are working fine again. Is this a known problem, should it be documented or fixed? I'm more than willing to write up some warnings should this be a good idea. It appears to be intentionally, but I don't see a reason for it. Can you try if this patch makes it work as expected? [PACKET]: Don't truncate non-linear skbs with mmaped IO Non-linear skbs are truncated to their linear part with mmaped IO. Fix by using skb_copy_bits instead of memcpy. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit 6e184976552a407c331f9b4e52b2c26fcae46ee7 tree 1bb4fc2b65179a51e795dc07908277b83cc0921a parent 9f737633e6ee54fc174282d49b2559bd2208391d author Patrick McHardy [EMAIL PROTECTED] Thu, 14 Sep 2006 11:59:09 +0200 committer Patrick McHardy [EMAIL PROTECTED] Thu, 14 Sep 2006 11:59:09 +0200 net/packet/af_packet.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index f9cef36..4172a52 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -626,8 +626,6 @@ static int tpacket_rcv(struct sk_buff *s if ((int)snaplen 0) snaplen = 0; } - if (snaplen skb-len-skb-data_len) - snaplen = skb-len-skb-data_len; spin_lock(sk-sk_receive_queue.lock); h = (struct tpacket_hdr *)packet_lookup_frame(po, po-head); @@ -644,7 +642,7 @@ static int tpacket_rcv(struct sk_buff *s status = ~TP_STATUS_LOSING; spin_unlock(sk-sk_receive_queue.lock); - memcpy((u8*)h + macoff, skb-data, snaplen); + skb_copy_bits(skb, 0, (u8*)h + macoff, snaplen); h-tp_len = skb-len; h-tp_snaplen = snaplen;
[RFC 1/3] cfg80211/nl80211 core
This patch adds cfg80211/nl80211, a netlink based configuration
system for wireless hardware.
It currently features a few helper commands and commands to
add and remove virtual interfaces and to inject packets.
Support for nl80211 in d80211 is in a follow-up patch.
There should be support for notifications, but we need to figure
out if we remove the sysfs based add/remove virtual interface
thing completely or allow the driver to create a notification
through some new API here.
Modulo file renames and a bit of split ups, it is identical to previous
versions.
It requires the patches in
http://marc.theaimsgroup.com/?l=linux-netdevm=115625436628696w=2
and
http://marc.theaimsgroup.com/?l=linux-netdevm=115625168405439w=2
(the latter doesn't apply cleanly against wireless-dev, but you can
safely ignore the pieces that don't, at least for wireless testing :) )
It also requires the NLA_PUT_FLAG patch I did:
http://marc.theaimsgroup.com/?l=linux-netdevm=115650333420169w=2
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- wireless-dev.orig/net/Kconfig 2006-09-13 22:05:53.359647141 +0200
+++ wireless-dev/net/Kconfig2006-09-13 22:06:10.529647141 +0200
@@ -250,6 +250,9 @@ source net/ieee80211/Kconfig
config WIRELESS_EXT
bool
+config CFG80211
+ tristate
+
endif # if NET
endmenu # Networking
--- wireless-dev.orig/net/Makefile 2006-09-13 22:05:53.389647141 +0200
+++ wireless-dev/net/Makefile 2006-09-13 22:06:10.529647141 +0200
@@ -44,6 +44,7 @@ obj-$(CONFIG_ECONET) += econet/
obj-$(CONFIG_VLAN_8021Q) += 8021q/
obj-$(CONFIG_IP_DCCP) += dccp/
obj-$(CONFIG_IP_SCTP) += sctp/
+obj-$(CONFIG_CFG80211) += wireless/
obj-$(CONFIG_D80211) += d80211/
obj-$(CONFIG_IEEE80211)+= ieee80211/
obj-$(CONFIG_TIPC) += tipc/
--- /dev/null 1970-01-01 00:00:00.0 +
+++ wireless-dev/net/wireless/Makefile 2006-09-13 22:06:10.529647141 +0200
@@ -0,0 +1,4 @@
+obj-$(CONFIG_CFG80211) += cfg80211.o
+
+cfg80211-objs := \
+ core.o nl80211.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ wireless-dev/net/wireless/nl80211.c 2006-09-13 22:06:10.529647141 +0200
@@ -0,0 +1,395 @@
+/*
+ * This is the new netlink-based wireless configuration interface.
+ *
+ * Copyright 2006 Johannes Berg [EMAIL PROTECTED]
+ */
+
+#include linux/if.h
+#include linux/module.h
+#include linux/err.h
+#include net/genetlink.h
+#include net/cfg80211.h
+#include linux/mutex.h
+#include linux/list.h
+#include core.h
+#include nl80211.h
+
+/* the netlink family */
+static struct genl_family nl80211_fam = {
+ .id = GENL_ID_GENERATE, /* don't bother with a hardcoded ID */
+ .name = nl80211, /* have users key off the name instead */
+ .hdrsize = 0, /* no private header */
+ .version = 1, /* no particular meaning now */
+ .maxattr = NL80211_ATTR_MAX,
+};
+
+/* policy for the attributes */
+static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
+ [NL80211_ATTR_IFINDEX] = { .type = NLA_U32 },
+ [NL80211_ATTR_WIPHY] = { .type = NLA_U32 },
+ [NL80211_ATTR_FLAGS] = { .type = NLA_U32 },
+ [NL80211_ATTR_QUEUE] = { .type = NLA_U32 },
+ [NL80211_ATTR_FRAME] = { .type = NLA_STRING,
+.len = NL80211_MAX_FRAME_LEN },
+ [NL80211_ATTR_IFNAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ-1 },
+ [NL80211_ATTR_IFTYPE] = { .type = NLA_U32 },
+};
+
+/* netlink command implementations */
+
+#define CHECK_CMD(ptr, cmd)\
+ if (drv-ops-ptr) \
+ NLA_PUT_FLAG(msg, NL80211_CMD_##cmd);
+
+static int nl80211_get_cmdlist(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_driver *drv;
+ struct sk_buff *msg;
+ void *hdr;
+ int err;
+ struct nlattr *start;
+
+ drv = cfg80211_get_drv_from_info(info);
+ if (IS_ERR(drv))
+ return PTR_ERR(drv);
+
+ hdr = nl80211msg_new(msg, info-snd_pid, info-snd_seq, 0,
+NL80211_CMD_NEW_CMDLIST);
+ if (IS_ERR(hdr)) {
+ err = PTR_ERR(hdr);
+ goto put_drv;
+ }
+
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY, drv-wiphy);
+
+ start = nla_nest_start(msg, NL80211_ATTR_CMDS);
+ if (!start)
+ goto nla_put_failure;
+
+ /* unconditionally allow some common commands we handle centrally */
+ NLA_PUT_FLAG(msg, NL80211_CMD_GET_CMDLIST);
+ NLA_PUT_FLAG(msg, NL80211_CMD_GET_WIPHYS);
+ NLA_PUT_FLAG(msg, NL80211_CMD_GET_INTERFACES);
+
+ CHECK_CMD(inject_packet, INJECT);
+ CHECK_CMD(add_virtual_intf, ADD_VIRTUAL_INTERFACE);
+ CHECK_CMD(del_virtual_intf, DEL_VIRTUAL_INTERFACE);
+
+ nla_nest_end(msg, start);
+
+ genlmsg_end(msg, hdr);
+
+ err = genlmsg_unicast(msg, info-snd_pid);
+ goto
[RFC 2/3] make d80211 use cfg80211
This patch makes d80211 partially configurable using the
infrastructure that nl80211 provides. So far, it allows
packet injection and adding/removing virtual interfaces.
Also identical to previous patches except for the file and Kconfig
renames that nl80211/cfg80211 went through.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- wireless-dev.orig/net/d80211/Kconfig2006-09-13 22:06:09.209647141
+0200
+++ wireless-dev/net/d80211/Kconfig 2006-09-13 22:06:12.559647141 +0200
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select CFG80211
---help---
This option enables the hardware independent IEEE 802.11
networking stack.
--- wireless-dev.orig/net/d80211/Makefile 2006-09-13 22:06:09.219647141
+0200
+++ wireless-dev/net/d80211/Makefile2006-09-13 22:06:12.559647141 +0200
@@ -8,6 +8,7 @@ obj-$(CONFIG_D80211) += 80211.o rate_con
sta_info.o \
wep.o \
wpa.o \
+ ieee80211_cfg.o \
ieee80211_scan.o \
ieee80211_sta.o \
ieee80211_dev.o \
--- wireless-dev.orig/net/d80211/ieee80211.c2006-09-13 22:06:09.209647141
+0200
+++ wireless-dev/net/d80211/ieee80211.c 2006-09-13 22:06:12.569647141 +0200
@@ -20,6 +20,7 @@
#include net/iw_handler.h
#include linux/compiler.h
#include linux/bitmap.h
+#include linux/nl80211.h
#include net/d80211.h
#include net/d80211_common.h
@@ -32,6 +33,7 @@
#include wme.h
#include aes_ccm.h
#include ieee80211_led.h
+#include ieee80211_cfg.h
/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
/* Ethernet-II snap header (RFC1042 for most EtherTypes) */
@@ -354,6 +356,16 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021
{
struct rate_control_extra extra;
+ /* FIXME
+ if (tx-dev == tx-local-mdev
+ (inject rate set)) {
+ a
+ tx-u.tx.rate = ...
+ etc etc
+ return TXRX_CONTINUE;
+ }
+ */
+
memset(extra, 0, sizeof(extra));
extra.mgmt_data = tx-sdata
tx-sdata-type == IEEE80211_IF_TYPE_MGMT;
@@ -759,6 +771,13 @@ ieee80211_tx_h_misc(struct ieee80211_txr
u16 dur;
struct ieee80211_tx_control *control = tx-u.tx.control;
+ /* FIXME
+ if (tx-dev == tx-local-mdev) {
+ set up retry limit, ...
+ based on injection parameters
+ }
+ */
+
if (!is_multicast_ether_addr(hdr-addr1)) {
if (tx-skb-len + FCS_LEN tx-local-rts_threshold
tx-local-rts_threshold IEEE80211_MAX_RTS_THRESHOLD) {
@@ -884,6 +903,9 @@ ieee80211_tx_h_check_assoc(struct ieee80
#endif /* CONFIG_D80211_VERBOSE_DEBUG */
u32 sta_flags;
+ if (unlikely(tx-dev == tx-local-mdev))
+ return TXRX_CONTINUE;
+
if (unlikely(tx-local-sta_scanning != 0)
((tx-fc IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT ||
(tx-fc IEEE80211_FCTL_STYPE) != IEEE80211_STYPE_PROBE_REQ))
@@ -987,6 +1009,12 @@ static void purge_old_ps_buffers(struct
static inline ieee80211_txrx_result
ieee80211_tx_h_multicast_ps_buf(struct ieee80211_txrx_data *tx)
{
+ /* FIXME
+ if (unlikely(tx-dev == tx-local-mdev
+ (inject flags) NL80211_FLAG_NOBUFFER))
+ return TXRX_CONTINUE;
+ */
+
/* broadcast/multicast frame */
/* If any of the associated stations is in power save mode,
* the frame is buffered to be sent after DTIM beacon frame */
@@ -1414,11 +1442,12 @@ static int ieee80211_master_start_xmit(s
control.ifindex = odev-ifindex;
control.type = osdata-type;
- control.req_tx_status = pkt_data-req_tx_status;
- control.do_not_encrypt = pkt_data-do_not_encrypt;
+ control.req_tx_status = !!(pkt_data-flags NL80211_FLAG_TXSTATUS);
+ control.do_not_encrypt = !(pkt_data-flags NL80211_FLAG_ENCRYPT);
control.pkt_type =
- pkt_data-pkt_probe_resp ? PKT_PROBE_RESP : PKT_NORMAL;
- control.requeue = pkt_data-requeue;
+ (pkt_data-internal_flags TX_FLAG_PROBERESP) ?
+ PKT_PROBE_RESP : PKT_NORMAL;
+ control.requeue = !!(pkt_data-internal_flags TX_FLAG_REQUEUE);
control.queue = pkt_data-queue;
ret = ieee80211_tx(odev, skb, control,
@@ -1594,8 +1623,10 @@ static int ieee80211_subif_start_xmit(st
pkt_data = (struct ieee80211_tx_packet_data *)skb-cb;
memset(pkt_data, 0, sizeof(struct ieee80211_tx_packet_data));
pkt_data-ifindex = sdata-dev-ifindex;
- pkt_data-mgmt_iface = (sdata-type == IEEE80211_IF_TYPE_MGMT);
- pkt_data-do_not_encrypt = no_encrypt;
+ if (sdata-type == IEEE80211_IF_TYPE_MGMT)
+ pkt_data-internal_flags |= TX_FLAG_INJECTED;
+ if (!no_encrypt)
+ pkt_data-flags |= NL80211_FLAG_ENCRYPT;
skb-dev = sdata-master;
[RFC 3/3] cfg80211 thoughts on configuration
This is some preliminary code how I'm currently thinking (and that might
change radically :) ) configuration might look like.
It uses the patch I previously posted to make genetlink attributes
custom-definable.
--- wireless-dev.orig/include/linux/nl80211.h 2006-09-13 22:06:10.539647141
+0200
+++ wireless-dev/include/linux/nl80211.h2006-09-13 22:06:11.919647141
+0200
@@ -45,6 +45,47 @@ enum {
/* get list of all interfaces belonging to a wiphy */
NL80211_CMD_NEW_INTERFACES,
+ /* configure device */
+ NL80211_CMD_CONFIGURE,
+
+ /* request configuration */
+ NL80211_CMD_GET_CONFIG,
+
+ /* configuration sent from kernel */
+ NL80211_CMD_CONFIGURATION,
+
+ /* initiate scan */
+ NL80211_CMD_INITIATE_SCAN,
+
+ /* scan result (kernel - userspace) */
+ NL80211_CMD_SCAN_RESULT,
+
+ /* change roaming control */
+ NL80211_CMD_SET_ROAMING_CONTROL,
+
+ /* get roaming control setting */
+ NL80211_CMD_GET_ROAMING_CONTROL,
+
+ /* set access point BSSID for userspace roaming */
+ NL80211_CMD_SET_BSSID,
+
+ /* get current association information, if not associated then
+* the BSSID attribute is not present in response */
+ NL80211_CMD_GET_ASSOCIATION,
+
+ /* association notification/response to GET_BSSID */
+ NL80211_CMD_ASSOCIATION_CHANGED,
+
+ /* disassociate from current AP */
+ NL80211_CMD_DISASSOCIATE,
+
+ /* deauth from current AP */
+ NL80211_CMD_DEAUTH,
+
+ /* re-associate with current settings
+* (SSID and BSSID if roaming control in userspace) */
+ NL80211_CMD_REASSOCIATE,
+
/* add commands here */
/* used to define NL80211_CMD_MAX below */
@@ -88,6 +129,36 @@ enum {
/* wiphy list */
NL80211_ATTR_WIPHY_LIST,
+ /* attributes used for configuration */
+ /* network ID (pre 802.11 HW) */
+ NL80211_ATTR_NETWORK_ID,
+
+ /* channel, 1-14 are B/G */
+ NL80211_ATTR_CHANNEL,
+
+ /* receiver sensitivity in dBm */
+ NL80211_ATTR_RX_SENSITIVITY,
+
+ /* BSSID to associate to, only used when roaming control
+* is in userspace */
+ NL80211_ATTR_BSSID,
+
+ /* SSID of ESS to associate to */
+ NL80211_ATTR_SSID,
+
+ /* transmit power in mW */
+ NL80211_ATTR_TRANSMIT_POWER,
+
+ /* fragmentation threshold in bytes */
+ NL80211_ATTR_FRAG_THRESHOLD,
+
+ /* one or more information elements */
+ NL80211_ATTR_INFORMATION_ELEMENT,
+
+ NL80211_ATTR_ROAMING_CONTROL,
+
+ NL80211_ATTR_SCAN_TYPE,
+
/* add attributes here */
/* used to define NL80211_ATTR_MAX below */
@@ -134,4 +205,13 @@ enum {
};
#define NL80211_IFTYPE_MAX (__NL80211_IFTYPE_AFTER_LAST - 1)
+enum {
+ NL80211_ROAMING_CONTROL_KERNEL,
+ NL80211_ROAMING_CONTROL_USERSPACE,
+
+ /* keep last */
+ __NL80211_ROAMING_CONTROL_AFTER_LAST
+};
+#define NL80211_ROAMING_CONTROL_MAX (__NL80211_ROAMING_CONTROL_AFTER_LAST-1)
+
#endif /* __LINUX_NL80211_H */
--- wireless-dev.orig/include/net/cfg80211.h2006-09-13 22:06:10.539647141
+0200
+++ wireless-dev/include/net/cfg80211.h 2006-09-13 22:06:11.919647141 +0200
@@ -14,6 +14,30 @@
*/
/**
+ * struct cfg80211_config - description of a configuration (request)
+ */
+struct cfg80211_config {
+ /* first fields with 'internal' validity */
+
+ /* SSID to use, valid if not NULL. change forces reassociation */
+ u8 *ssid;
+
+ /* now fields with explicit validity */
+#define CFG80211_CFG_VALID_NWID(10)
+#define CFG80211_CFG_VALID_RX_SENSITIVITY (11)
+#define CFG80211_CFG_VALID_TRANSMIT_POWER (12)
+#define CFG80211_CFG_VALID_FRAG_THRESHOLD (13)
+#define CFG80211_CFG_VALID_CHANNEL (14)
+ unsigned int valid;
+
+ u16 network_id;
+ s32 rx_sensitivity;
+ u32 transmit_power;
+ u32 fragmentation_threshold;
+ u32 channel;
+};
+
+/**
* struct cfg80211_ops - backend description for wireless configuration
*
* This struct is registered by fullmac card drivers and/or wireless stacks
@@ -35,6 +59,26 @@
* @add_virtual_intf: create a new virtual interface with the given name
*
* @del_virtual_intf: remove the virtual interface determined by ifindex.
+ *
+ * @configure: configure the given interface as requested in the config struct.
+ *must not ignore any configuration item, if something is
+ *is requested that cannot be fulfilled return an error
+ *
+ * @get_config: fill the given config structure with the current configuration
+ *
+ * @reassociate: reassociate with current settings (SSID, BSSID if
+ * userspace roaming is enabled)
+ *
+ * @disassociate: disassociate from current AP
+ *
+ * @deauth: deauth from current AP
+ *
+ * @initiate_scan: ...
+ *
+ * @set_roaming: set who gets to control roaming
+ *
+ *
Re: 2.6.18-rc6 memory mapped pcap truncates outgoing TCP packets, but not icmp
Hello! [PACKET]: Don't truncate non-linear skbs with mmaped IO Non-linear skbs are truncated to their linear part with mmaped IO. Fix by using skb_copy_bits instead of memcpy. Ack. I remember this trick. The idea was that I needed only TCP header in any case and it was perfect cutoff. This hack was not supposed to survive. :-) Alexey - 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
ipsec policy with netfilter mark value
Hello everybody. I would like to know if is it possible to create an ipsec policy based on the mark value inizialized by netfilter. This is my problem: I need to route VoIP packets from hosts connected to the private networks (A B) to the QoS routers, without encrypting them. 'Normal' packets are encrypted delivered by the ipsec tunnel through the 'Internet router'. I was thinking to mark them with netfilter (matching on dscp value) and then create an ipsec policy based on that mark value. TIA ___ private network A | / |/ | | +-+-+ | | | linux | | ipsec | | gateway | | | +--+-+--+ | | ++ | | |Internet| | | +--+ |+-+ +-+QoS enabled router| | router | +--+ ++ || || || || || ||\ || || \___ipsec tunnel ||\ ||net A = net B|| \___QoS WAN network || || net A = net B || || ++ || |Internet| +--+ |+-+ +-+QoS enabled router| | router | | | +--+ ++ | | | | +--+-+--+ | | | linux | | ipsec | | gateway | | | +-+-+ | | |\ | \___ private network B - 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] EtherIP tunnel driver (RFC 3378)
Joerg Roedel wrote: On Thu, Sep 14, 2006 at 11:21:22AM +1000, Philip Craig wrote: Joerg Roedel wrote: + To configure tunnels an extra tool is required. You can download + it from http://zlug.fh-zwickau.de/~joro/projects/ under the + EtherIP section. If unsure, say N. To obtain a list of tunnels, this tool calls SIOCGETTUNNEL (SIOCDEVPRIVATE + 0) for every device in /proc/net/dev. I don't think this is safe, but I don't have a solution for you. You are right. But this is the way the ipip driver does it. In the case of ipip it is safe, because it is visible as a tunnel interface to userspace. But my driver registers its devices as Ethernet (it has to, otherwise the devices will not be usable in a bridge). There is no safe way to distinguish between real Ethernet devices and devices registered by my driver. I think about implementing an ioctl to fetch a list of all EtherIP tunnel devices from the driver. Just do what ipip and gre do, use a network device with a fixed name for the ioctl (you already have the ethip0 device for this purpose it appears). Is there a reason why you have a separate tool rather than modifying iproute2? I wrote an own tool for testing. At development I wanted to concentrate on the driver and not how to modify iproute2. But when the driver becomes stable and may be included I will add it to iproute2. The iproute changes are only a few lines, just add the ethip0 device to the do_add, do_del, ... commands and set the protocol to IPPROTO_ETHERIP when an etherip tunnel is requested. - 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] make ipv4 multicast packets only get delivered to sockets that are joined to group
Hello! No, it returns 1 (allow) if there are no filters to explicitly filter it. I wrote that code. :-) I see. It did not behave this way old times. From your mails I understood that current behaviour matches another implementations (BSD whatever), is it true? Alexey - 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: [d80211] some issues regarding iwconfig parameters sequence
On Wed, 2006-09-13 at 14:00 -0700, mabbas wrote: Hi I have some problem connecting if I don't follow some parameters sequence in iwconfig command for example if I issues the following # iwconfig wlan0 essid test ap xx:xx:xx:xx:xx:xx #iwconfif wlan0 channel 9 Any reason you don't stick all the commands on one iwconfig line, or why you don't do the channel first? Some operations with WEXT are undefined, and I think command ordering is one of them. However, I believe that the card/driver should be keeping all the attributes set, and any time an attribute changes that would break a current association or operation (like locking the channel), then the card/driver should be restarting association/auth with the new attribute set. in d80211 if essid and bssid set it will start authentication with default channel and authentication will timeout then after the second command kicks in to tune to the right channel the retry counter of authentication will be at maximum and we wont authenticate, same problem exist for IBSS it will start searching but once we call #iwconfif wlan0 channel 9 this will stop scanning and we stop IBSS searching . I That seems wrong; once you set the channel, d80211 should be resetting the current assoc/auth stuff, and restarting the association with the current parameters/attributes from scratch, but now only on channel 9. WEXT didn't really have a good way to package a full set of association/auth parameters; the commit-handler stuff kind of did that, but if the commands got broken up then the semantics of what happened when were pretty undefined. Dan attached a patch for workaround this problem. I am not sure this is the right way to fix just attached to illustrate the problem. Mohamed - 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] vlan support for pktgen
Francesco Fondelli writes: The attached patch allows pktgen to produce 802.1Q and Q-in-Q tagged frames. I have used it for stress test a bridge and seems ok to me. Unfortunately I have no access to net-2.6.x git tree so the diff is against 2.6.17.13. If you have a moment look over it, I think this feature could be useful for someone else. Thanks a lot, code seems code seems straight forward but I'm not to experienced with VLAN hacking and need find some test environment when I got a chance, maybe someone else has better opportunities to verify. Cheers. --ro - 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: more nl80211 stuff
On Thu, 2006-09-14 at 12:46 +0200, Johannes Berg wrote: Hi, Last night I thought a bit more about configuration handling with cfg80211/nl80211 and have refined the original framework to be more split into cfg80211 and nl80211 stuff. Can you describe a bit more what the scope of each of nl80211 and cfg80211 is? Not sure I entirely understand the split and where the line is drawn. Thanks, Dan As a followup, I'll post three patches, the first two are essentially the original ones respun, while the third one represents my current thoughts (a bit less I guess) on actual configuration and WE compatibility. 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 - 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: more nl80211 stuff
On Thu, 2006-09-14 at 09:41 -0400, Dan Williams wrote: Can you describe a bit more what the scope of each of nl80211 and cfg80211 is? Not sure I entirely understand the split and where the line is drawn. Basically, I figured that cfg80211 is the kernel-internal interface and nl80211 is just the primary userspace interface with WE compatibility being a second one and possibly partial configurability in configfs later. All drivers need to care about is cfg80211, hence I made the split explicit. 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
[patch] d80211: allow vlan interfaces to receive ToDS frames
Interfaces of type IEEE80211_IF_TYPE_VLAN are similar to AP
interfaces. One difference is stations are bound to a particular
vlan interface after authentication/association based on
management policy (for example a radius server).
Interfaces of type IEEE80211_IF_TYPE_VLAN need to be able to
receive ToDS frames.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -2353,7 +2353,8 @@ ieee80211_rx_h_data(struct ieee80211_txr
memcpy(dst, hdr-addr3, ETH_ALEN);
memcpy(src, hdr-addr2, ETH_ALEN);
- if (unlikely(sdata-type != IEEE80211_IF_TYPE_AP)) {
+ if (unlikely(sdata-type != IEEE80211_IF_TYPE_AP
+sdata-type != IEEE80211_IF_TYPE_VLAN)) {
printk(KERN_DEBUG %s: dropped ToDS frame (BSSID=
MAC_FMT SA= MAC_FMT DA= MAC_FMT )\n,
dev-name, MAC_ARG(hdr-addr1),
--
-
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] vlan support for pktgen
On 9/14/06, Robert Olsson [EMAIL PROTECTED] wrote: Thanks a lot, code seems code seems straight forward but I'm not to experienced with VLAN hacking and need find some test environment when I got a chance, maybe someone else has better opportunities to verify. Cheers. --ro ok BTW I wrote a patch for ethereal (new name's wireshark, www.wireshark.org) in order to parse pktgen data, I'll submit it to wireshark ml later, it should be checked in next release. You might find it useful when toying with pktgen ;-) Ciao FF - 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
Could not remove vlan with PPPoE sessions
Hello! When using vconfig rem command to delete vlan device, on which kernel-mode PPPoE session were active, vconfig and all pppd processes froze in D state with all networking operation stuck, rendering the box non-functional. Kernel started to print message: unregister_netdevice: waiting for vlan0154 to become free. Usage count = 3 in a loop until reboot. This was kernel 2.6.18-rc7 on AMD64 box. It said 'Usage count = 3' and there were exactly 3 pppd processes using vlan0154 interface and stuck in D state. ~ :wq With best regards, Vladimir Savkin. - 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: ieee80211 and devices which decrypt in hardware
On Thursday 14 September 2006 00:35, Daniel Drake wrote: Michael Buesch wrote: Does it strip ICV and FCS? The driver always strips FCS (unconditionally). The device does not strip ICV even when hardware decryption is in use, it gets included at the end of the frame, and I guess we should also handle that. You should skb_trim it, or otherwise it will be included in the payload, which will result in various weird bugs. -- 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: [PATCH]:[XFRM] BEET mode
On Thu, 14 Sep 2006 13:25:49 +0300 (EEST) Miika Komu wrote: Below is a fixed version of the announced patch. I hope this one is ok. Yes, the split line is fixed now. I suppose that this applies to Dave's netdev git tree? That would explain why I get lots of patch errors when I try to apply it to 2.6.18-rc7... or it could be that the surrounding patch context lines have too many leading spaces for some reason. That's what it looks like to me. Did you take the patch from the mailing list and try to apply it to your unpatched tree? linux-2618-rc7work dryrun ~/beet-mode.patch 1 out of 1 hunk FAILED -- saving rejects to file include/linux/in.h.rej 2 out of 2 hunks FAILED -- saving rejects to file include/linux/ip.h.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/ipsec.h.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/xfrm.h.rej 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/Kconfig.rej 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/Makefile.rej 2 out of 2 hunks FAILED -- saving rejects to file net/ipv4/esp4.c.rej 2 out of 2 hunks FAILED -- saving rejects to file net/ipv4/ipcomp.c.rej 1 out of 1 hunk FAILED -- saving rejects to file net/ipv6/Kconfig.rej 1 out of 1 hunk FAILED -- saving rejects to file net/ipv6/Makefile.rej 2 out of 2 hunks FAILED -- saving rejects to file net/ipv6/ipcomp6.c.rej 1 out of 1 hunk FAILED -- saving rejects to file net/xfrm/xfrm_user.c.rej --- ~Randy - 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] natsemi: Messages being noisy
Hi there, Ingo Oeser wrote: I get the following message when trying to transfer big files (via FTP or SCP) since Linux 2.6.16.27. It didn't happen with Linux 2.6.13.4. [702238.242237] eth1: increased tx threshold, txcfg 0xd0f01008. [702238.242649] eth1: increased tx threshold, txcfg 0xd0f0100a. What about putting this message at the message level DEBUG or even under pr_debug()? Now I even know, that this happens together with a small disruption of traffic, which makes applications hang for a second or less. Is it possible to have the maximum value right from the start? May I tune it somewhere to be the maximum from the start? Would you accept patches for this? 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
Re: [PATCH] natsemi: Messages being noisy
On Thu, Sep 14, 2006 at 05:39:08PM +0200, Ingo Oeser wrote: Hi there, Ingo Oeser wrote: I get the following message when trying to transfer big files (via FTP or SCP) since Linux 2.6.16.27. It didn't happen with Linux 2.6.13.4. [702238.242237] eth1: increased tx threshold, txcfg 0xd0f01008. [702238.242649] eth1: increased tx threshold, txcfg 0xd0f0100a. What about putting this message at the message level DEBUG or even under pr_debug()? Now I even know, that this happens together with a small disruption of traffic, which makes applications hang for a second or less. Is it possible to have the maximum value right from the start? May I tune it somewhere to be the maximum from the start? Would you accept patches for this? This will (if I recall) increase transmit latency. It's a fine line. You might tune it up, but this fallback path probably should not be removed.. - 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]:[XFRM] BEET mode
I suppose that this applies to Dave's netdev git tree? That would explain why I get lots of patch errors when I try to apply it to 2.6.18-rc7... Actually we made the patch against linux/kernel/git/acme/net-2.6.19.git is that the wrong branch? -- Diego - 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]:[XFRM] BEET mode
On Thu, 14 Sep 2006 18:52:26 +0300 Diego Beltrami wrote: I suppose that this applies to Dave's netdev git tree? That would explain why I get lots of patch errors when I try to apply it to 2.6.18-rc7... Actually we made the patch against linux/kernel/git/acme/net-2.6.19.git is that the wrong branch? I can answer, but it won't be authoritative, so someone else should also answer. I would expect patches to be made against DaveM's 2.6.19 git or 2.6.x git trees: http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=summary http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.git;a=summary although the acme tree may be tracking DaveM's tree(s) closely. --- ~Randy - 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] make ipv4 multicast packets only get delivered to sockets that are joined to group
Alexey Kuznetsov [EMAIL PROTECTED] wrote on 09/14/2006 03:30:37 AM: Hello! No, it returns 1 (allow) if there are no filters to explicitly filter it. I wrote that code. :-) I see. It did not behave this way old times. From your mails I understood that current behaviour matches another implementations (BSD whatever), is it true? Hi, Alexey, If you mean IPv6 code in current BSD derivatives, I don't know. The IPv6 behaviour was different from IPv4 on Linux and was changed for compatibility with IPv4 (discussion on netdev agreed that binding should determine socket delivery, not group membership, or simply that there was no reason to be different from long-standing IPv4 practice). The IPv4 code is that way for compatibility with everything else since about ~4.3BSD (with the possible exception of Solaris 8, apparently). FWIW, I think Deering's original interpretation is correct. Adding a multicast address to an interface by joining a group is little different from adding a unicast address via SIOCSIFADDR, which certainly does affect packets delivered to the machine and to any INADDR_ANY-bound socket. Binding to the multicast address and not INADDR_ANY will give you only packets for that group, if that's what you want, just as in the unicast address-specific bind. +-DLS - 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.6.17][Trivial] net/dccp: update references to standards
[DCCP]: Update documentation references. Updates the references to spec documents throughout the code, taking into account that * the DCCP, CCID 2, and CCID 3 drafts all became RFCs in March this year * RFC 1063 was obsoleted by RFC 1191 * draft-ietf-tcpimpl-pmtud-0x.txt was published as an Informational RFC, RFC 2923 on 2000-09-22. All references verified; patches against stable and Torvald's tree. Signed-off-by: Gerrit Renker [EMAIL PROTECTED] -- dccp/Kconfig |4 ++-- dccp/ackvec.c | 12 ++-- dccp/ackvec.h |3 +-- dccp/ccids/Kconfig | 19 +-- dccp/ccids/ccid2.c |2 +- dccp/ccids/ccid3.c |3 +-- dccp/dccp.h|2 +- dccp/input.c |4 ++-- dccp/ipv4.c|4 ++-- dccp/ipv6.c|2 +- dccp/options.c |2 +- dccp/proto.c |2 +- dccp/timer.c |5 ++--- ipv4/tcp_output.c |2 +- 14 files changed, 31 insertions(+), 35 deletions(-) diff --git a/net/dccp/Kconfig b/net/dccp/Kconfig index 859e335..2c345c0 100644 --- a/net/dccp/Kconfig +++ b/net/dccp/Kconfig @@ -4,9 +4,9 @@ menu DCCP Configuration (EXPERIMENTAL) config IP_DCCP tristate The DCCP Protocol (EXPERIMENTAL) ---help--- - Datagram Congestion Control Protocol + Datagram Congestion Control Protocol (RFC 4340) - From draft-ietf-dccp-spec-11 http://www.icir.org/kohler/dcp/draft-ietf-dccp-spec-11.txt. + From http://www.ietf.org/rfc/rfc4340.txt The Datagram Congestion Control Protocol (DCCP) is a transport protocol that implements bidirectional, unicast connections of diff --git a/net/dccp/ackvec.c b/net/dccp/ackvec.c index 8c211c5..bce3501 100644 --- a/net/dccp/ackvec.c +++ b/net/dccp/ackvec.c @@ -113,7 +113,7 @@ #endif memcpy(to, from, len); /* -* From draft-ietf-dccp-spec-11.txt: +* From RFC 4340, A.2: * * For each acknowledgement it sends, the HC-Receiver will add an * acknowledgement record. ack_seqno will equal the HC-Receiver @@ -225,7 +225,7 @@ static inline int dccp_ackvec_set_buf_he } /* - * Implements the draft-ietf-dccp-spec-11.txt Appendix A + * Implements RFC 4340, Appendix A */ int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk, const u64 ackno, const u8 state) @@ -238,7 +238,7 @@ int dccp_ackvec_add(struct dccp_ackvec * * We may well decide to do buffer compression, etc, but for now lets * just drop. * -* From Appendix A: +* From Appendix A.1.1 (`New Packets'): * * Of course, the circular buffer may overflow, either when the * HC-Sender is sending data at a very high rate, when the @@ -275,9 +275,9 @@ int dccp_ackvec_add(struct dccp_ackvec * /* * A.1.2. Old Packets * -* When a packet with Sequence Number S arrives, and -* S = buf_ackno, the HC-Receiver will scan the table -* for the byte corresponding to S. (Indexing structures +* When a packet with Sequence Number S = buf_ackno +* arrives, the HC-Receiver will scan the table for +* the byte corresponding to S. (Indexing structures * could reduce the complexity of this scan.) */ u64 delta = dccp_delta_seqno(ackno, av-dccpav_buf_ackno); diff --git a/net/dccp/ackvec.h b/net/dccp/ackvec.h index 0adf4b5..8b48a0a 100644 --- a/net/dccp/ackvec.h +++ b/net/dccp/ackvec.h @@ -28,8 +28,7 @@ #define DCCP_ACKVEC_LEN_MASK 0x3F /* 00 /** struct dccp_ackvec - ack vector * - * This data structure is the one defined in the DCCP draft - * Appendix A. + * This data structure is the one defined in RFC 4340, Appendix A. * * @dccpav_buf_head - circular buffer head * @dccpav_buf_tail - circular buffer tail diff --git a/net/dccp/ccids/Kconfig b/net/dccp/ccids/Kconfig index ca00191..b4a4724 100644 --- a/net/dccp/ccids/Kconfig +++ b/net/dccp/ccids/Kconfig @@ -22,11 +22,11 @@ config IP_DCCP_CCID2 for lost packets, would prefer CCID 2 to CCID 3. On-line games may also prefer CCID 2. - CCID 2 is further described in: - http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid2-10.txt + CCID 2 is further described in RFC 4341, + http://www.ietf.org/rfc/rfc4341.txt - This text was extracted from: - http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt + This text was extracted from RFC 4340 (sec. 10.1), + http://www.ietf.org/rfc/rfc4340.txt If in doubt, say M. @@ -45,15 +45,14 @@ config IP_DCCP_CCID3 suitable than CCID 2 for applications such streaming media where a relatively smooth sending rate is of importance. - CCID 3 is further
Re: [PATCH 2.6.17][Trivial] net/dccp: update references to standards
Sorry kmail garbled this, clean text below. - Gerrit -- diff --git a/net/dccp/Kconfig b/net/dccp/Kconfig index 859e335..2c345c0 100644 --- a/net/dccp/Kconfig +++ b/net/dccp/Kconfig @@ -4,9 +4,9 @@ menu DCCP Configuration (EXPERIMENTAL) config IP_DCCP tristate The DCCP Protocol (EXPERIMENTAL) ---help--- - Datagram Congestion Control Protocol + Datagram Congestion Control Protocol (RFC 4340) - From draft-ietf-dccp-spec-11 http://www.icir.org/kohler/dcp/draft-ietf-dccp-spec-11.txt. + From http://www.ietf.org/rfc/rfc4340.txt The Datagram Congestion Control Protocol (DCCP) is a transport protocol that implements bidirectional, unicast connections of diff --git a/net/dccp/ackvec.c b/net/dccp/ackvec.c index 8c211c5..bce3501 100644 --- a/net/dccp/ackvec.c +++ b/net/dccp/ackvec.c @@ -113,7 +113,7 @@ #endif memcpy(to, from, len); /* -* From draft-ietf-dccp-spec-11.txt: +* From RFC 4340, A.2: * * For each acknowledgement it sends, the HC-Receiver will add an * acknowledgement record. ack_seqno will equal the HC-Receiver @@ -225,7 +225,7 @@ static inline int dccp_ackvec_set_buf_he } /* - * Implements the draft-ietf-dccp-spec-11.txt Appendix A + * Implements RFC 4340, Appendix A */ int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk, const u64 ackno, const u8 state) @@ -238,7 +238,7 @@ int dccp_ackvec_add(struct dccp_ackvec * * We may well decide to do buffer compression, etc, but for now lets * just drop. * -* From Appendix A: +* From Appendix A.1.1 (`New Packets'): * * Of course, the circular buffer may overflow, either when the * HC-Sender is sending data at a very high rate, when the @@ -275,9 +275,9 @@ int dccp_ackvec_add(struct dccp_ackvec * /* * A.1.2. Old Packets * -* When a packet with Sequence Number S arrives, and -* S = buf_ackno, the HC-Receiver will scan the table -* for the byte corresponding to S. (Indexing structures +* When a packet with Sequence Number S = buf_ackno +* arrives, the HC-Receiver will scan the table for +* the byte corresponding to S. (Indexing structures * could reduce the complexity of this scan.) */ u64 delta = dccp_delta_seqno(ackno, av-dccpav_buf_ackno); diff --git a/net/dccp/ackvec.h b/net/dccp/ackvec.h index 0adf4b5..8b48a0a 100644 --- a/net/dccp/ackvec.h +++ b/net/dccp/ackvec.h @@ -28,8 +28,7 @@ #define DCCP_ACKVEC_LEN_MASK 0x3F /* 00 /** struct dccp_ackvec - ack vector * - * This data structure is the one defined in the DCCP draft - * Appendix A. + * This data structure is the one defined in RFC 4340, Appendix A. * * @dccpav_buf_head - circular buffer head * @dccpav_buf_tail - circular buffer tail diff --git a/net/dccp/ccids/Kconfig b/net/dccp/ccids/Kconfig index ca00191..b4a4724 100644 --- a/net/dccp/ccids/Kconfig +++ b/net/dccp/ccids/Kconfig @@ -22,11 +22,11 @@ config IP_DCCP_CCID2 for lost packets, would prefer CCID 2 to CCID 3. On-line games may also prefer CCID 2. - CCID 2 is further described in: - http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid2-10.txt + CCID 2 is further described in RFC 4341, + http://www.ietf.org/rfc/rfc4341.txt - This text was extracted from: - http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt + This text was extracted from RFC 4340 (sec. 10.1), + http://www.ietf.org/rfc/rfc4340.txt If in doubt, say M. @@ -45,15 +45,14 @@ config IP_DCCP_CCID3 suitable than CCID 2 for applications such streaming media where a relatively smooth sending rate is of importance. - CCID 3 is further described in: - - http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid3-11.txt. + CCID 3 is further described in RFC 4342, + http://www.ietf.org/rfc/rfc4342.txt The TFRC congestion control algorithms were initially described in - RFC 3448. + RFC 3448 (http://www.ietf.org/rfc/rfc3448.txt). - This text was extracted from: - http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt + This text was extracted from RFC 4340 (sec. 10.2), + http://www.ietf.org/rfc/rfc4340.txt If in doubt, say M. diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c index e961562..95a9647 100644 --- a/net/dccp/ccids/ccid2.c +++ b/net/dccp/ccids/ccid2.c @@ -23,7 +23,7 @@ */ /* - * This implementation should follow: draft-ietf-dccp-ccid2-10.txt + * This implementation should follow RFC 4341 * * BUGS: * - sequence
Re: 802.1D/Linux STP issue
Steve/Brian - You've probably seen Mick Seaman's comments on this by now - as he points out in his email, tinkering with existing STP implementations is not likely to be a rewarding exercise and I would encourage you not to go there. I would suggest that it would be a much more valuable exercise for the Linux community to replace the existing STP support with an implementation of RSTP. Regards, Tony At 02:06 14/09/2006, Stephen Hemminger wrote: On Wed, 13 Sep 2006 15:58:49 -0700 Brian Braunstein [EMAIL PROTECTED] wrote: hi stephen and tony, i have been in contact with both of you and i figured it would make sense to get you to in contact on this issue, so here's the story: stephen is the maintainer of the linux spanning tree bridging code, an implementation of 802.1D-1998 that has very wide spread use. tony is the chair of the IEEE802.1 working group. i am trying to get my patch submitted in the linux kernel to fix a bug in the way STP behaves. stephen and i discovered that the flaw is actually in the IEEE802.1D-1998 spec, and that the linux implementation was merely following this. i contacted tony to try to see if we can get an update to the 802.1D-1998 spec, as this is what is implemented in the linux kernel, but tony said that the 1998 standard is obsolete, will not be updated, and that the 2004 RSTP spec should be used. so here's a review of what i've come across: first lets start with the bug in the 802.1D-1998 spec 1998 - 8.6.2.2 Record Configuration Information - Use you will notice that if the path cost ever goes up and everything else is held constant, the BPDU will be dropped and the network not react to the change, and the dropping of the BPDUs will make it seem like the link is down. now lets look at the equivalent section in the 8021.D-2004 spec: 2004 - 17.6 Priority vector calculations as you can see here, this bug has been fixed, because the last condition takes care of the problem, if the config message is received from the same designated bridge and designated port, then the config message is processed. so path cost increases will be recorded and reacted to. the issue is whether or not the linux kernel should go with the 1998 or 2004 spec. i would assume that the goal is to make the linux implmentation a functional implementation of the original STP, not a complete rewrite to conform to all of RSTP, so lets look at what the new standard says for normal legacy STP, to see if the bug is fixed there as well: 2004 - 17.4 STP compatibility this section seems to say that an RSTP bridge will revert to STP as defined in section 8. so then we go to section 8... 2004 - 8 Spanning tree algorithm protocol this one then refers to 802.1D-1998 for the STP spec, but also says that it is obsolete and RSTP should be used so this is a bit confusing. section 17.4 says use STP to interoperate with legacy bridges, then section 8 either says use the 1998 spec, or don't use STP at all, but if bugs in the 1998 spec cannot be correct, what are we to do with the linux code? i can write the patch to implement the new algorithm from 2004-17.6 to replace the algorithm from 1998-8.6.2.2. thanks for you help guys, hopefully we can get this bug fixed up soon, you both have been great about timely responses and it is much appreciated. Brian Braunstein 858.245.0434 I have no problem fixing the code to be spec noncompliant, there are several case where we implement the right thing rather than the standard way. I just want to make sure any such changes don't have unintended consequences. - 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] make ipv4 multicast packets only get delivered to sockets that are joined to group
On Thu, 2006-09-14 at 08:39 -0700, David Stevens wrote: Alexey Kuznetsov [EMAIL PROTECTED] wrote on 09/14/2006 03:30:37 AM: Hello! No, it returns 1 (allow) if there are no filters to explicitly filter it. I wrote that code. :-) I see. It did not behave this way old times. From your mails I understood that current behaviour matches another implementations (BSD whatever), is it true? Hi, Alexey, If you mean IPv6 code in current BSD derivatives, I don't know. The IPv6 behaviour was different from IPv4 on Linux and was changed for compatibility with IPv4 (discussion on netdev agreed that binding should determine socket delivery, not group membership, or simply that there was no reason to be different from long-standing IPv4 practice). The IPv4 code is that way for compatibility with everything else since about ~4.3BSD (with the possible exception of Solaris 8, apparently). FWIW, I think Deering's original interpretation is correct. Adding a multicast address to an interface by joining a group is little different from adding a unicast address via SIOCSIFADDR, which certainly does affect packets delivered to the machine and to any INADDR_ANY-bound socket. Binding to the multicast address and not INADDR_ANY will give you only packets for that group, if that's what you want, just as in the unicast address-specific bind. +-DLS There was an IETF daft quite a while ago that proposed something similar to the patch that originated this thread. In case anyone is curious, here is the link: http://tools.ietf.org/wg/ipv6/draft-arunt-ipv6-multicast-filtering-rules-01.txt That work got a few positive comments, but didn't really go anywhere. -vlad - 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: [d80211] some issues regarding iwconfig parameters sequence
Dan Williams wrote: On Wed, 2006-09-13 at 14:00 -0700, mabbas wrote: Hi I have some problem connecting if I don't follow some parameters sequence in iwconfig command for example if I issues the following # iwconfig wlan0 essid test ap xx:xx:xx:xx:xx:xx #iwconfif wlan0 channel 9 Any reason you don't stick all the commands on one iwconfig line, or why you don't do the channel first? Some operations with WEXT are undefined, and I think command ordering is one of them. However, I believe that the card/driver should be keeping all the attributes set, and any time an attribute changes that would break a current association or operation (like locking the channel), then the card/driver should be restarting association/auth with the new attribute set. the driver/card do not do any authentication itself. d80211 will start the authentication for us and I don't think it is a good idea to redo the same thing that d80211 already has. I don't mind to stick the commands on one iwconfig but still it will break in IBSS if the channel parameter was last and also user will complain about it, I can force it on them. in d80211 if essid and bssid set it will start authentication with default channel and authentication will timeout then after the second command kicks in to tune to the right channel the retry counter of authentication will be at maximum and we wont authenticate, same problem exist for IBSS it will start searching but once we call #iwconfif wlan0 channel 9 this will stop scanning and we stop IBSS searching . I That seems wrong; once you set the channel, d80211 should be resetting the current assoc/auth stuff, and restarting the association with the current parameters/attributes from scratch, but now only on channel 9. WEXT didn't really have a good way to package a full set of association/auth parameters; the commit-handler stuff kind of did that, but if the commands got broken up then the semantics of what happened when were pretty undefined. Dan attached a patch for workaround this problem. I am not sure this is the right way to fix just attached to illustrate the problem. Mohamed - 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 - 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: [RFC 2/3] make d80211 use cfg80211
Hi Johannes,
Does the packet injection allow hostapd to use nl80211 instead of the
wlan0ap interface to send management frames? Important features for this
include requesting a transmit status - i.e. the ability for
hostapd/wpa_supplicant to know if the frame got acked or not.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Johannes Berg
Sent: Thursday, September 14, 2006 3:50 AM
To: netdev@vger.kernel.org
Cc: John W. Linville; Michael Buesch; Jean Tourrilhes; Jiri Benc; James
P. Ketrenos; Mohamed Abbas; Ulrich Kunitz; Daniel Drake
Subject: [RFC 2/3] make d80211 use cfg80211
This patch makes d80211 partially configurable using the infrastructure
that nl80211 provides. So far, it allows packet injection and
adding/removing virtual interfaces.
Also identical to previous patches except for the file and Kconfig
renames that nl80211/cfg80211 went through.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- wireless-dev.orig/net/d80211/Kconfig2006-09-13
22:06:09.209647141 +0200
+++ wireless-dev/net/d80211/Kconfig 2006-09-13 22:06:12.559647141
+0200
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select CFG80211
---help---
This option enables the hardware independent IEEE 802.11
networking stack.
--- wireless-dev.orig/net/d80211/Makefile 2006-09-13
22:06:09.219647141 +0200
+++ wireless-dev/net/d80211/Makefile2006-09-13 22:06:12.559647141
+0200
@@ -8,6 +8,7 @@ obj-$(CONFIG_D80211) += 80211.o rate_con
sta_info.o \
wep.o \
wpa.o \
+ ieee80211_cfg.o \
ieee80211_scan.o \
ieee80211_sta.o \
ieee80211_dev.o \
--- wireless-dev.orig/net/d80211/ieee80211.c2006-09-13
22:06:09.209647141 +0200
+++ wireless-dev/net/d80211/ieee80211.c 2006-09-13 22:06:12.569647141
+0200
@@ -20,6 +20,7 @@
#include net/iw_handler.h
#include linux/compiler.h
#include linux/bitmap.h
+#include linux/nl80211.h
#include net/d80211.h
#include net/d80211_common.h
@@ -32,6 +33,7 @@
#include wme.h
#include aes_ccm.h
#include ieee80211_led.h
+#include ieee80211_cfg.h
/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
/* Ethernet-II snap header (RFC1042 for most EtherTypes) */ @@ -354,6
+356,16 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021 {
struct rate_control_extra extra;
+ /* FIXME
+ if (tx-dev == tx-local-mdev
+ (inject rate set)) {
+ a
+ tx-u.tx.rate = ...
+ etc etc
+ return TXRX_CONTINUE;
+ }
+ */
+
memset(extra, 0, sizeof(extra));
extra.mgmt_data = tx-sdata
tx-sdata-type == IEEE80211_IF_TYPE_MGMT; @@ -759,6
+771,13 @@ ieee80211_tx_h_misc(struct ieee80211_txr
u16 dur;
struct ieee80211_tx_control *control = tx-u.tx.control;
+ /* FIXME
+ if (tx-dev == tx-local-mdev) {
+ set up retry limit, ...
+ based on injection parameters
+ }
+ */
+
if (!is_multicast_ether_addr(hdr-addr1)) {
if (tx-skb-len + FCS_LEN tx-local-rts_threshold
tx-local-rts_threshold
IEEE80211_MAX_RTS_THRESHOLD) { @@ -884,6 +903,9 @@
ieee80211_tx_h_check_assoc(struct ieee80 #endif /*
CONFIG_D80211_VERBOSE_DEBUG */
u32 sta_flags;
+ if (unlikely(tx-dev == tx-local-mdev))
+ return TXRX_CONTINUE;
+
if (unlikely(tx-local-sta_scanning != 0)
((tx-fc IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT ||
(tx-fc IEEE80211_FCTL_STYPE) !=
IEEE80211_STYPE_PROBE_REQ)) @@ -987,6 +1009,12 @@ static void
purge_old_ps_buffers(struct static inline ieee80211_txrx_result
ieee80211_tx_h_multicast_ps_buf(struct ieee80211_txrx_data *tx) {
+ /* FIXME
+ if (unlikely(tx-dev == tx-local-mdev
+ (inject flags) NL80211_FLAG_NOBUFFER))
+ return TXRX_CONTINUE;
+ */
+
/* broadcast/multicast frame */
/* If any of the associated stations is in power save mode,
* the frame is buffered to be sent after DTIM beacon frame */
@@ -1414,11 +1442,12 @@ static int ieee80211_master_start_xmit(s
control.ifindex = odev-ifindex;
control.type = osdata-type;
- control.req_tx_status = pkt_data-req_tx_status;
- control.do_not_encrypt = pkt_data-do_not_encrypt;
+ control.req_tx_status = !!(pkt_data-flags
NL80211_FLAG_TXSTATUS);
+ control.do_not_encrypt = !(pkt_data-flags
NL80211_FLAG_ENCRYPT);
control.pkt_type =
- pkt_data-pkt_probe_resp ? PKT_PROBE_RESP : PKT_NORMAL;
- control.requeue = pkt_data-requeue;
+ (pkt_data-internal_flags TX_FLAG_PROBERESP) ?
+ PKT_PROBE_RESP : PKT_NORMAL;
+ control.requeue = !!(pkt_data-internal_flags
TX_FLAG_REQUEUE);
control.queue = pkt_data-queue;
ret =
Re: [PATCH 2/12] smc911x: Fix SMC_WRITE_EEPROM_CMD macro
[EMAIL PROTECTED] [EMAIL PROTECTED] : [...] Do you think if I convert them(smc911x.h) to static inline, would that be correct ? Yes. You can probably forget 'inline'. -- 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
[PATCH] bridge: add ETH_HLEN to packet_length
In br_dev_queue_push_xmit, why is the check to drop mtu oversized
packets not checking for enough room for the impending ETH_HLEN size
skb_push? In some code currently under development, we are seeing
skb_under_panic being called from the skb_push(skb, ETH_HLEN) in that
code. It seems to me it would be better to drop those skbs than panic.
Attached is a patch to do this.
Thanks,
Jon
Signed-off-by: Jon Mason [EMAIL PROTECTED]
diff -r b1d36669f98d net/bridge/br_forward.c
--- a/net/bridge/br_forward.c Mon Sep 4 03:00:04 2006 +
+++ b/net/bridge/br_forward.c Thu Sep 14 13:18:04 2006 -0500
@@ -29,7 +29,8 @@ static inline int should_deliver(const s
static inline unsigned packet_length(const struct sk_buff *skb)
{
- return skb-len - (skb-protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
+ return skb-len - ETH_HLEN -
+ (skb-protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
}
int br_dev_queue_push_xmit(struct sk_buff *skb)
-
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: [Bugme-new] [Bug 7159] New: No networking on a machine with Ethernet Pro 100 and Realtek 8139
(Switching from bugzilla to email - please retain all Cc's) On Thu, 14 Sep 2006 11:04:03 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=7159 Summary: No networking on a machine with Ethernet Pro 100 and Realtek 8139 Kernel Version: 2.6.16, 2.6.17, 2.6.18-rc6 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.8 Distribution: Debian Hardware Environment: Dual-PIII, Ethernet Pro 100 and Realtek 8139 PCI interfaces Software Environment: Debian Etch (Testing) Problem Description: The network is not reachable, though the kernel does seem to sense line presence on both interfaces. On boot, udev/discover loads e100, 8139cp and 8139too. /etc/modules does not have any network modules (needs eepro100 for 2.6.8, but I removed it, no change). The relevant lspci listings are: 00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05) 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Both interfaces work fine under 2.6.8 as long as eepro100 is loaded. More information (lspci -v, /proc/interrupts, /proc/ioports) can be found at the Debian bug: http://bugs.debian.org/386972 Steps to reproduce: Boot, try to use network. This is all a bit peculiar. I'd be assuming that you're not getting any interrupts through for those NICs. Could you please check /proc/interrupts, see if the interrupt counts related to the NICs can be made to increase? Also, the full `dmesg -s 100' output might help. We might also get some interesting info if you can compile your own kernel, build thsoe net drivers into vmlinux, capture the dmesg output. If it _is_ an IRQ problem then you might find that fiddling with ACPI helps: disable it in config or boot with `acpi=off', see if that helps. Also try booting with the `pci=routeirq' option. There are various options described under acpi= and pci= in Documentation/kernel-parameters.txt which it would be useful for you to experiment with. - 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] bcm43xx: fix netdev watchdog timeouts
The setup for running long periodic work has a bug that leads to netdev watchdog tx timeouts. This change eliminates the timeouts. systems. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Acked-by: Larry Finger [EMAIL PROTECTED] --- John, Please apply this to wireless-2.6. It would be great if this patch were to be included in 2.6.19. Thanks, Larry Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c === --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c @@ -3169,8 +3169,7 @@ static void bcm43xx_periodic_work_handle * be preemtible. */ mutex_lock(bcm-mutex); - netif_stop_queue(bcm-net_dev); - synchronize_net(); + netif_tx_disable(bcm-net_dev); spin_lock_irqsave(bcm-irq_lock, flags); bcm43xx_mac_suspend(bcm); if (bcm43xx_using_pio(bcm)) - 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] bcm43xx: fix netdev watchdog timeouts
On Thu, Sep 14, 2006 at 08:28:54AM -0500, Larry Finger wrote: Please apply this to wireless-2.6. It would be great if this patch were to be included in 2.6.19. I suppose you mean 2.6.18? It would also be nice if your bcm43xx locks up machine patch were to be included in 2.6.18 together with this patch or we will see regression reports against 2.6.17. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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] bcm43xx: fix netdev watchdog timeouts
Erik Mouw wrote: On Thu, Sep 14, 2006 at 08:28:54AM -0500, Larry Finger wrote: Please apply this to wireless-2.6. It would be great if this patch were to be included in 2.6.19. I suppose you mean 2.6.18? It would also be nice if your bcm43xx locks up machine patch were to be included in 2.6.18 together with this patch or we will see regression reports against 2.6.17. This section in wireless 2.6 already differed by quite a bit from that in 2.6.18-rcX. As a result, John Linville thinks that applying this patch to 2.6.18 would lead to messiness in the git trees and has recommended that I hold the patch until it can be sent to the stable maintainers for inclusion in 2.6.18.y. Yes there will be a regression against 2.6.17. Larry - 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] bcm43xx-softmac: improve wrong firmware message
On Tue, Sep 12, 2006 at 05:06:05PM -0500, Larry Finger wrote: Martin Langer wrote: Why not writing both (ucode rev and driver version)? Something like from version 4.x binary drivers (rev0x128).\n BTW, if anybody needs the relationship between ucode revsion and driver version then he should look at the table here: http://www.langerland.de/linux/bcm43xx/firmware.html I could do that; however, I think this error message may have a short life as I'm just now looking at Michael's v4 firmware revisions for d80211 with an eye toward porting them to softmac. John - what do you think? Let's just take the new/current patch as-is. Someone who understands rev 0x128 should be able to find the message in the code for himself... :-) 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
[PATCH] bcm43xx: fix bcm43xx lockups and netdev timeouts in 2.6.18-rcX
In 2.6.18-rc7, the section that prepares for preemptible periodic work
has two bugs. The first is due to an improper locking sequence that leads
to frozen systems. The second causes netdev watchdog timeouts. Both
are fixed.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch has been taken against 2.6.18-rc7. It changes more lines
than would be absolutely necessary to affect the fix; however, it
ends up with this section looking exactly like the current code (with
pending patches) that is in wireless-2.6. That way, it should not
mess up any git trees.
Larry
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3182,39 +3182,37 @@ static void bcm43xx_periodic_work_handle
/* Periodic work will take a long time, so we want it to
* be preemtible.
*/
- bcm43xx_lock_irqonly(bcm, flags);
- netif_stop_queue(bcm-net_dev);
+ mutex_lock(bcm-mutex);
+ netif_tx_disable(bcm-net_dev);
+ spin_lock_irqsave(bcm-irq_lock, flags);
+ bcm43xx_mac_suspend(bcm);
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_freeze_txqueues(bcm);
savedirqs = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
- bcm43xx_unlock_irqonly(bcm, flags);
- bcm43xx_lock_noirq(bcm);
+ spin_unlock_irqrestore(bcm-irq_lock, flags);
bcm43xx_synchronize_irq(bcm);
} else {
/* Periodic work should take short time, so we want low
* locking overhead.
*/
- bcm43xx_lock_irqsafe(bcm, flags);
+ mutex_lock(bcm-mutex);
+ spin_lock_irqsave(bcm-irq_lock, flags);
}
do_periodic_work(bcm);
if (badness BADNESS_LIMIT) {
- bcm43xx_lock_irqonly(bcm, flags);
- if (likely(bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED)) {
- tasklet_enable(bcm-isr_tasklet);
- bcm43xx_interrupt_enable(bcm, savedirqs);
- if (bcm43xx_using_pio(bcm))
- bcm43xx_pio_thaw_txqueues(bcm);
- }
+ spin_lock_irqsave(bcm-irq_lock, flags);
+ tasklet_enable(bcm-isr_tasklet);
+ bcm43xx_interrupt_enable(bcm, savedirqs);
+ if (bcm43xx_using_pio(bcm))
+ bcm43xx_pio_thaw_txqueues(bcm);
+ bcm43xx_mac_enable(bcm);
netif_wake_queue(bcm-net_dev);
- mmiowb();
- bcm43xx_unlock_irqonly(bcm, flags);
- bcm43xx_unlock_noirq(bcm);
- } else {
- mmiowb();
- bcm43xx_unlock_irqsafe(bcm, flags);
}
+ mmiowb();
+ spin_unlock_irqrestore(bcm-irq_lock, flags);
+ mutex_unlock(bcm-mutex);
}
static void bcm43xx_periodic_tasks_delete(struct bcm43xx_private *bcm)
-
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 20/20] iscsi: support for swapping over iSCSI.
Peter Zijlstra wrote: On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote: Peter Zijlstra wrote: Implement sht-swapdev() for iSCSI. This method takes care of reserving the extra memory needed and marking all relevant sockets with SOCK_VMIO. When used for swapping, TCP socket creation is done under GFP_MEMALLOC and the TCP connect is done with SOCK_VMIO to ensure their success. Also the netlink userspace interface is marked SOCK_VMIO, this will ensure that even under pressure we can still communicate with the daemon (which runs as mlockall() and needs no additional memory to operate). Netlink requests are handled under the new PF_MEM_NOWAIT when a swapper is present. This ensures that the netlink socket will not block. User-space will need to retry failed requests. The TCP receive path is handled under PF_MEMALLOC for SOCK_VMIO sockets. This makes sure we do not block the critical socket, and that we do not fail to process incomming data. Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] CC: Mike Christie [EMAIL PROTECTED] --- drivers/scsi/iscsi_tcp.c| 103 +++- drivers/scsi/scsi_transport_iscsi.c | 23 +++- include/scsi/libiscsi.h |1 include/scsi/scsi_transport_iscsi.h |2 4 files changed, 113 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/scsi/iscsi_tcp.c === --- linux-2.6.orig/drivers/scsi/iscsi_tcp.c +++ linux-2.6/drivers/scsi/iscsi_tcp.c @@ -42,6 +42,7 @@ #include scsi/scsi_host.h #include scsi/scsi.h #include scsi/scsi_transport_iscsi.h +#include scsi/scsi_device.h #include iscsi_tcp.h @@ -845,9 +846,13 @@ iscsi_tcp_data_recv(read_descriptor_t *r int rc; struct iscsi_conn *conn = rd_desc-arg.data; struct iscsi_tcp_conn *tcp_conn = conn-dd_data; - int processed; + int processed = 0; char pad[ISCSI_PAD_LEN]; struct scatterlist sg; + unsigned long pflags = current-flags; + + if (sk_has_vmio(tcp_conn-sock-sk)) + current-flags |= PF_MEMALLOC; Is this too late or not needed or what is it for? This function gets run from the network layer's softirq and at this point we have a skbuff with data that we want to process. The iscsi layer also does not allocate memory for read or write IO in this path. I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I think we would want to set this flag at a lower level. Something closer to where the skbuf is allocated? Is that the skbuff you were talking about? If so, I'd need to carve a path to pass the swapper information. I had that in a previous patch, but that was large and ugly. I had to go carrying gfp_t flags all through that call chain. In my original post I was just concerned about the sk_buff that gets passed to the iscsi layer in iscsi_tcp_data_recv. I was wondering if the chunk of code in the network layer or network driver that allocated that skbuff needed to set PF_MEMALLOC. - 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 20/20] iscsi: support for swapping over iSCSI.
On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote: Peter Zijlstra wrote: On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote: Peter Zijlstra wrote: Implement sht-swapdev() for iSCSI. This method takes care of reserving the extra memory needed and marking all relevant sockets with SOCK_VMIO. When used for swapping, TCP socket creation is done under GFP_MEMALLOC and the TCP connect is done with SOCK_VMIO to ensure their success. Also the netlink userspace interface is marked SOCK_VMIO, this will ensure that even under pressure we can still communicate with the daemon (which runs as mlockall() and needs no additional memory to operate). Netlink requests are handled under the new PF_MEM_NOWAIT when a swapper is present. This ensures that the netlink socket will not block. User-space will need to retry failed requests. The TCP receive path is handled under PF_MEMALLOC for SOCK_VMIO sockets. This makes sure we do not block the critical socket, and that we do not fail to process incomming data. Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] CC: Mike Christie [EMAIL PROTECTED] --- drivers/scsi/iscsi_tcp.c| 103 +++- drivers/scsi/scsi_transport_iscsi.c | 23 +++- include/scsi/libiscsi.h |1 include/scsi/scsi_transport_iscsi.h |2 4 files changed, 113 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/scsi/iscsi_tcp.c === --- linux-2.6.orig/drivers/scsi/iscsi_tcp.c +++ linux-2.6/drivers/scsi/iscsi_tcp.c @@ -42,6 +42,7 @@ #include scsi/scsi_host.h #include scsi/scsi.h #include scsi/scsi_transport_iscsi.h +#include scsi/scsi_device.h #include iscsi_tcp.h @@ -845,9 +846,13 @@ iscsi_tcp_data_recv(read_descriptor_t *r int rc; struct iscsi_conn *conn = rd_desc-arg.data; struct iscsi_tcp_conn *tcp_conn = conn-dd_data; - int processed; + int processed = 0; char pad[ISCSI_PAD_LEN]; struct scatterlist sg; + unsigned long pflags = current-flags; + + if (sk_has_vmio(tcp_conn-sock-sk)) + current-flags |= PF_MEMALLOC; Is this too late or not needed or what is it for? This function gets run from the network layer's softirq and at this point we have a skbuff with data that we want to process. The iscsi layer also does not allocate memory for read or write IO in this path. I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I already have such a patch, look at: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/iscsi_vmio.patch but what conditional do you want to use for PF_MEMALLOC, an unconditional setting will be highly unpopular. Hmm, perhaps you could key it of sk_has_vmio(nls)... I think we would want to set this flag at a lower level. Something closer to where the skbuf is allocated? Is that the skbuff you were talking about? If so, I'd need to carve a path to pass the swapper information. I had that in a previous patch, but that was large and ugly. I had to go carrying gfp_t flags all through that call chain. In my original post I was just concerned about the sk_buff that gets passed to the iscsi layer in iscsi_tcp_data_recv. I was wondering if the chunk of code in the network layer or network driver that allocated that skbuff needed to set PF_MEMALLOC. (yeah I got that) No, that got allocated because its a receive skb and !sk_vmio_socks(), and got passed up because sk_has_vmio(iscsi_tcp_conn-sock-sk). - 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 20/20] iscsi: support for swapping over iSCSI.
On Thu, 2006-09-14 at 22:35 +0200, Peter Zijlstra wrote: On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote: I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I already have such a patch, look at: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/iscsi_vmio.patch but what conditional do you want to use for PF_MEMALLOC, an unconditional setting will be highly unpopular. Hmm, perhaps you could key it of sk_has_vmio(nls)... On second thought, not such a good idea, that will still be too course. You only want to force feed stuff originating from sk_has_vmio(iscsi_tcp_conn-sock-sk) connections, not all connectections as soon as there is a swapper in the system. In order to preserve that information you need extra state, abusing this process flags is as good as propagating __GFP_EMERGENCY down the call chain with extra gfp_t arguments, perhaps even better, since it will make sure we catch all allocations. - 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] bridge: add ETH_HLEN to packet_length
Jon Mason wrote:
In br_dev_queue_push_xmit, why is the check to drop mtu oversized
packets not checking for enough room for the impending ETH_HLEN size
skb_push? In some code currently under development, we are seeing
skb_under_panic being called from the skb_push(skb, ETH_HLEN) in that
code. It seems to me it would be better to drop those skbs than panic.
Attached is a patch to do this.
Thanks,
Jon
Signed-off-by: Jon Mason [EMAIL PROTECTED]
diff -r b1d36669f98d net/bridge/br_forward.c
--- a/net/bridge/br_forward.c Mon Sep 4 03:00:04 2006 +
+++ b/net/bridge/br_forward.c Thu Sep 14 13:18:04 2006 -0500
@@ -29,7 +29,8 @@ static inline int should_deliver(const s
static inline unsigned packet_length(const struct sk_buff *skb)
{
- return skb-len - (skb-protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
+ return skb-len - ETH_HLEN -
+ (skb-protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
}
packet_length() is a wrong place to do that, mtu has nothing to do with
skb headroom.
--Mika
-
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 driver timeout problems
Thanks a lot Michael, it seems to have resolved the issue, at least we were not able to reproduce it again after changing this flag. I will update this thread if the issue reoccurs. Michael Chan wrote: On Mon, 2006-09-11 at 11:18 -0700, sunny12 wrote: A restart of the network using /etc/init.d/network restart does the trick and the device works again. I dont think this is related to the TSO problem reported earlier because I believe its disabled by default. TSO may be on by default on eth0 where you have a 5721. Check with ethtool -k eth0. Turn it off if it is on by doing ethtool -K eth0 tso off. - 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 -- View this message in context: http://www.nabble.com/tg3-driver-timeout-problems-tf2254084.html#a6315074 Sent from the netdev forum at Nabble.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: 802.1D/Linux STP issue
On Thu, Sep 14, 2006 at 05:51:50PM +0100, Tony Jeffree wrote: Steve/Brian - You've probably seen Mick Seaman's comments on this by now - as he points out in his email, tinkering with existing STP implementations is not likely to be a rewarding exercise and I would encourage you not to go there. I would suggest that it would be a much more valuable exercise for the Linux community to replace the existing STP support with an implementation of RSTP. While we are at it can we rip it out of the kernel and develop a user-space daemon that does it instead? Setting the spanning-tree state of a port could be done with a simple ioctl (well not too simple because it would be good to support multiple STP instances so someone could code up 802.1w support and the kernel interface would already be there). Thoughts? - 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 driver timeout problems
sunny12 wrote: Thanks a lot Michael, it seems to have resolved the issue, at least we were not able to reproduce it again after changing this flag. I will update this thread if the issue reoccurs. That's good to know. When you upgrade to the next 2.6.18 kernel, you can re-enable TSO because the latest driver has the workaround for this problem. - 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: 802.1D/Linux STP issue
On Thu, 14 Sep 2006 17:51:50 +0100 Tony Jeffree [EMAIL PROTECTED] wrote: Steve/Brian - You've probably seen Mick Seaman's comments on this by now - as he points out in his email, tinkering with existing STP implementations is not likely to be a rewarding exercise and I would encourage you not to go there. I would suggest that it would be a much more valuable exercise for the Linux community to replace the existing STP support with an implementation of RSTP. Regards, Tony Work is already in progress to do RSTP (by several different people), but the effort is going slowly. - 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: [d80211] connecting to B-mode AP
Why is it necessary to set phymode to B? - a G client can connect perfectly well to a B AP. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mabbas Sent: Thursday, September 14, 2006 4:25 PM To: netdev@vger.kernel.org Subject: [d80211] connecting to B-mode AP When I connect to b-mode only AP and then run iwconf it shows it as a G-mode AP. I guess when we set frequency it look through all the modes and set the mode to the first channel it founds. since B and G share the same frequencies it will set phymode to G. How can we force it to set phymode to the AP we are associating with. - 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 - 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] bridge: add ETH_HLEN to packet_length
On Thu, Sep 14, 2006 at 11:53:48PM +0300, Mika Penttil? wrote:
Jon Mason wrote:
In br_dev_queue_push_xmit, why is the check to drop mtu oversized
packets not checking for enough room for the impending ETH_HLEN size
skb_push? In some code currently under development, we are seeing
skb_under_panic being called from the skb_push(skb, ETH_HLEN) in that
code. It seems to me it would be better to drop those skbs than panic.
Attached is a patch to do this.
Thanks,
Jon
Signed-off-by: Jon Mason [EMAIL PROTECTED]
diff -r b1d36669f98d net/bridge/br_forward.c
--- a/net/bridge/br_forward.cMon Sep 4 03:00:04 2006 +
+++ b/net/bridge/br_forward.cThu Sep 14 13:18:04 2006 -0500
@@ -29,7 +29,8 @@ static inline int should_deliver(const s
static inline unsigned packet_length(const struct sk_buff *skb)
{
-return skb-len - (skb-protocol == htons(ETH_P_8021Q) ? VLAN_HLEN :
0);
+return skb-len - ETH_HLEN -
+(skb-protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
}
packet_length() is a wrong place to do that, mtu has nothing to do with
skb headroom.
Oops, you are 100% correct. So what would be the best way to handle
this, as a panic is pretty nasty? Wouldn't it be better to check the
packet to see if there is sufficient headroom, BUG, and then drop it
(or allocate a new packet with sufficient headroom and proceed with
the skb_push)?
Thanks,
Jon
--Mika
-
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
[IPROUTE]: Add support for routing rule fwmark masks
Kernel support for this is in net-2.6.19. The output format
of rule listing is unchanged when no masks are used.
[IPROUTE]: Add support for routing rule fwmark masks
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit e733fab0168bd659cef3158113c762c3c080471f
tree 011f330145c58c61dc8e47bbe71b6075a3727a76
parent af1b6a41d4c7ed8aab98cfdcdafd55ec6c638b07
author Patrick McHardy [EMAIL PROTECTED] Fri, 15 Sep 2006 02:29:47 +0200
committer Patrick McHardy [EMAIL PROTECTED] Fri, 15 Sep 2006 02:29:47 +0200
include/linux/rtnetlink.h |1 +
ip/iprule.c | 25 +
man/man8/ip.8 |2 +-
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index d63578c..2e38a9f 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -263,6 +263,7 @@ enum rtattr_type_t
RTA_SESSION,
RTA_MP_ALGO,
RTA_TABLE,
+ RTA_FWMASK,
__RTA_MAX
};
diff --git a/ip/iprule.c b/ip/iprule.c
index 6caf573..f59df0b 100644
--- a/ip/iprule.c
+++ b/ip/iprule.c
@@ -36,7 +36,7 @@ static void usage(void) __attribute__((n
static void usage(void)
{
fprintf(stderr, Usage: ip rule [ list | add | del | flush ] SELECTOR
ACTION\n);
- fprintf(stderr, SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ]
[ fwmark FWMARK ]\n);
+ fprintf(stderr, SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ]
[ fwmark FWMARK[/MASK] ]\n);
fprintf(stderr, [ dev STRING ] [ pref NUMBER ]\n);
fprintf(stderr, ACTION := [ table TABLE_ID ]\n);
fprintf(stderr, [ prohibit | reject | unreachable ]\n);
@@ -123,8 +123,17 @@ static int print_rule(const struct socka
SPRINT_BUF(b1);
fprintf(fp, tos %s , rtnl_dsfield_n2a(r-rtm_tos, b1,
sizeof(b1)));
}
- if (tb[RTA_PROTOINFO]) {
- fprintf(fp, fwmark %#x ,
*(__u32*)RTA_DATA(tb[RTA_PROTOINFO]));
+ if (tb[RTA_PROTOINFO] || tb[RTA_FWMASK]) {
+ __u32 mark = 0, mask = 0;
+
+ if (tb[RTA_PROTOINFO])
+ mark = *(__u32*)RTA_DATA(tb[RTA_PROTOINFO]);
+
+ if (tb[RTA_FWMASK]
+ (mask = *(__u32*)RTA_DATA(tb[RTA_FWMASK])) != 0x)
+ fprintf(fp, fwmark 0x%x/0x%x , mark, mask);
+ else
+ fprintf(fp, fwmark 0x%x , mark);
}
if (tb[RTA_IIF]) {
@@ -243,11 +252,19 @@ static int iprule_modify(int cmd, int ar
invarg(TOS value is invalid\n, *argv);
req.r.rtm_tos = tos;
} else if (strcmp(*argv, fwmark) == 0) {
- __u32 fwmark;
+ char *slash;
+ __u32 fwmark, fwmask;
NEXT_ARG();
+ if ((slash = strchr(*argv, '/')) != NULL)
+ *slash = '\0';
if (get_u32(fwmark, *argv, 0))
invarg(fwmark value is invalid\n, *argv);
addattr32(req.n, sizeof(req), RTA_PROTOINFO, fwmark);
+ if (slash) {
+ if (get_u32(fwmask, slash+1, 0))
+ invarg(fwmask value is invalid\n,
slash+1);
+ addattr32(req.n, sizeof(req), RTA_FWMASK,
fwmask);
+ }
} else if (matches(*argv, realms) == 0) {
__u32 realm;
NEXT_ARG();
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 12da6d5..a9132da 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -223,7 +223,7 @@ throw | unreachable | prohibit
.B tos
.IR TOS ] [
.B fwmark
-.IR FWMARK ] [
+.IR FWMARK[/MASK] ] [
.B dev
.IR STRING ] [
.B pref
Re: [PATCH] bridge: add ETH_HLEN to packet_length
On Thu, 14 Sep 2006 13:27:54 -0500 Jon Mason [EMAIL PROTECTED] wrote: In br_dev_queue_push_xmit, why is the check to drop mtu oversized packets not checking for enough room for the impending ETH_HLEN size skb_push? In some code currently under development, we are seeing skb_under_panic being called from the skb_push(skb, ETH_HLEN) in that code. It seems to me it would be better to drop those skbs than panic. Attached is a patch to do this. Thanks, Jon This is bridge code, it assumes that any device that claims to be a ethernet device has done the proper reservation. What device are you using? - 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 20/20] iscsi: support for swapping over iSCSI.
Peter Zijlstra wrote: On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote: Peter Zijlstra wrote: On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote: Peter Zijlstra wrote: Implement sht-swapdev() for iSCSI. This method takes care of reserving the extra memory needed and marking all relevant sockets with SOCK_VMIO. When used for swapping, TCP socket creation is done under GFP_MEMALLOC and the TCP connect is done with SOCK_VMIO to ensure their success. Also the netlink userspace interface is marked SOCK_VMIO, this will ensure that even under pressure we can still communicate with the daemon (which runs as mlockall() and needs no additional memory to operate). Netlink requests are handled under the new PF_MEM_NOWAIT when a swapper is present. This ensures that the netlink socket will not block. User-space will need to retry failed requests. The TCP receive path is handled under PF_MEMALLOC for SOCK_VMIO sockets. This makes sure we do not block the critical socket, and that we do not fail to process incomming data. Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] CC: Mike Christie [EMAIL PROTECTED] --- drivers/scsi/iscsi_tcp.c| 103 +++- drivers/scsi/scsi_transport_iscsi.c | 23 +++- include/scsi/libiscsi.h |1 include/scsi/scsi_transport_iscsi.h |2 4 files changed, 113 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/scsi/iscsi_tcp.c === --- linux-2.6.orig/drivers/scsi/iscsi_tcp.c +++ linux-2.6/drivers/scsi/iscsi_tcp.c @@ -42,6 +42,7 @@ #include scsi/scsi_host.h #include scsi/scsi.h #include scsi/scsi_transport_iscsi.h +#include scsi/scsi_device.h #include iscsi_tcp.h @@ -845,9 +846,13 @@ iscsi_tcp_data_recv(read_descriptor_t *r int rc; struct iscsi_conn *conn = rd_desc-arg.data; struct iscsi_tcp_conn *tcp_conn = conn-dd_data; - int processed; + int processed = 0; char pad[ISCSI_PAD_LEN]; struct scatterlist sg; + unsigned long pflags = current-flags; + + if (sk_has_vmio(tcp_conn-sock-sk)) + current-flags |= PF_MEMALLOC; Is this too late or not needed or what is it for? This function gets run from the network layer's softirq and at this point we have a skbuff with data that we want to process. The iscsi layer also does not allocate memory for read or write IO in this path. I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I already have such a patch, look at: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/iscsi_vmio.patch You are drowning me in patches :) I did not see that one. I was still commenting on this patch :) The new patch looks ok. but what conditional do you want to use for PF_MEMALLOC, an unconditional setting will be highly unpopular. Hmm, perhaps you could key it of sk_has_vmio(nls)... Yes. - 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 20/20] iscsi: support for swapping over iSCSI.
Mike Christie wrote: Peter Zijlstra wrote: On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote: Peter Zijlstra wrote: On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote: Peter Zijlstra wrote: Implement sht-swapdev() for iSCSI. This method takes care of reserving the extra memory needed and marking all relevant sockets with SOCK_VMIO. When used for swapping, TCP socket creation is done under GFP_MEMALLOC and the TCP connect is done with SOCK_VMIO to ensure their success. Also the netlink userspace interface is marked SOCK_VMIO, this will ensure that even under pressure we can still communicate with the daemon (which runs as mlockall() and needs no additional memory to operate). Netlink requests are handled under the new PF_MEM_NOWAIT when a swapper is present. This ensures that the netlink socket will not block. User-space will need to retry failed requests. The TCP receive path is handled under PF_MEMALLOC for SOCK_VMIO sockets. This makes sure we do not block the critical socket, and that we do not fail to process incomming data. Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] CC: Mike Christie [EMAIL PROTECTED] --- drivers/scsi/iscsi_tcp.c| 103 +++- drivers/scsi/scsi_transport_iscsi.c | 23 +++- include/scsi/libiscsi.h |1 include/scsi/scsi_transport_iscsi.h |2 4 files changed, 113 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/scsi/iscsi_tcp.c === --- linux-2.6.orig/drivers/scsi/iscsi_tcp.c +++ linux-2.6/drivers/scsi/iscsi_tcp.c @@ -42,6 +42,7 @@ #include scsi/scsi_host.h #include scsi/scsi.h #include scsi/scsi_transport_iscsi.h +#include scsi/scsi_device.h #include iscsi_tcp.h @@ -845,9 +846,13 @@ iscsi_tcp_data_recv(read_descriptor_t *r int rc; struct iscsi_conn *conn = rd_desc-arg.data; struct iscsi_tcp_conn *tcp_conn = conn-dd_data; -int processed; +int processed = 0; char pad[ISCSI_PAD_LEN]; struct scatterlist sg; +unsigned long pflags = current-flags; + +if (sk_has_vmio(tcp_conn-sock-sk)) +current-flags |= PF_MEMALLOC; Is this too late or not needed or what is it for? This function gets run from the network layer's softirq and at this point we have a skbuff with data that we want to process. The iscsi layer also does not allocate memory for read or write IO in this path. I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I already have such a patch, look at: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/iscsi_vmio.patch You are drowning me in patches :) I did not see that one. I was still commenting on this patch :) The new patch looks ok. Oh, I think you need a sock_put to go with netlink lookup (lookup does a hold). - 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 20/20] iscsi: support for swapping over iSCSI.
Peter Zijlstra wrote: On Thu, 2006-09-14 at 22:35 +0200, Peter Zijlstra wrote: On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote: I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I already have such a patch, look at: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/iscsi_vmio.patch but what conditional do you want to use for PF_MEMALLOC, an unconditional setting will be highly unpopular. Hmm, perhaps you could key it of sk_has_vmio(nls)... On second thought, not such a good idea, that will still be too course. You only want to force feed stuff originating from sk_has_vmio(iscsi_tcp_conn-sock-sk) connections, not all connectections as soon as there is a swapper in the system. You can move the iscsi_session-swapper field to the iscsi_cls_session and have iscsi_swapdev take a iscsi_cls_session and set that flag. iscsi_recv_pdu and iscsi_conn_error and all the llds can then access this bit. In order to preserve that information you need extra state, abusing this process flags is as good as propagating __GFP_EMERGENCY down the call chain with extra gfp_t arguments, perhaps even better, since it will make sure we catch all allocations. - 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 20/20] iscsi: support for swapping over iSCSI.
On Thu, 2006-09-14 at 16:03 -0500, Mike Christie wrote: Mike Christie wrote: Peter Zijlstra wrote: On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote: Peter Zijlstra wrote: On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote: Peter Zijlstra wrote: Implement sht-swapdev() for iSCSI. This method takes care of reserving the extra memory needed and marking all relevant sockets with SOCK_VMIO. When used for swapping, TCP socket creation is done under GFP_MEMALLOC and the TCP connect is done with SOCK_VMIO to ensure their success. Also the netlink userspace interface is marked SOCK_VMIO, this will ensure that even under pressure we can still communicate with the daemon (which runs as mlockall() and needs no additional memory to operate). Netlink requests are handled under the new PF_MEM_NOWAIT when a swapper is present. This ensures that the netlink socket will not block. User-space will need to retry failed requests. The TCP receive path is handled under PF_MEMALLOC for SOCK_VMIO sockets. This makes sure we do not block the critical socket, and that we do not fail to process incomming data. Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] CC: Mike Christie [EMAIL PROTECTED] --- drivers/scsi/iscsi_tcp.c| 103 +++- drivers/scsi/scsi_transport_iscsi.c | 23 +++- include/scsi/libiscsi.h |1 include/scsi/scsi_transport_iscsi.h |2 4 files changed, 113 insertions(+), 16 deletions(-) Index: linux-2.6/drivers/scsi/iscsi_tcp.c === --- linux-2.6.orig/drivers/scsi/iscsi_tcp.c +++ linux-2.6/drivers/scsi/iscsi_tcp.c @@ -42,6 +42,7 @@ #include scsi/scsi_host.h #include scsi/scsi.h #include scsi/scsi_transport_iscsi.h +#include scsi/scsi_device.h #include iscsi_tcp.h @@ -845,9 +846,13 @@ iscsi_tcp_data_recv(read_descriptor_t *r int rc; struct iscsi_conn *conn = rd_desc-arg.data; struct iscsi_tcp_conn *tcp_conn = conn-dd_data; - int processed; + int processed = 0; char pad[ISCSI_PAD_LEN]; struct scatterlist sg; + unsigned long pflags = current-flags; + + if (sk_has_vmio(tcp_conn-sock-sk)) + current-flags |= PF_MEMALLOC; Is this too late or not needed or what is it for? This function gets run from the network layer's softirq and at this point we have a skbuff with data that we want to process. The iscsi layer also does not allocate memory for read or write IO in this path. I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I already have such a patch, look at: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/iscsi_vmio.patch You are drowning me in patches :) I did not see that one. I was still commenting on this patch :) The new patch looks ok. Oh, I think you need a sock_put to go with netlink lookup (lookup does a hold). D'0h again, I'd forgotten I'd used it there too. hit refresh :-) - 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.18-rc4] aoe [04/13]: zero copy write 1 of 2
[EMAIL PROTECTED] [EMAIL PROTECTED] 20060822212150.
[EMAIL PROTECTED] [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
User-Agent: Mutt/1.5.11+cvs20060126
Hi. Back in August I sent out some patches for the aoe driver, and
Alan objected to the direct setting of skb-len in one of them. I
asked whether he was suggesting that we use something like this
instead of setting skb-len:
skb-data_len = 0;
skb_trim(skb, 0);
skb_put(skb, sizeof *h + sizeof *ah + DEFAULTBCNT);
... and Alan said that was acceptible because it takes care of
skb-tail, checks for overflow, and is more future proof.
So I took some time to implement the necessary changes, but then it
became apparent that there was a problem.
The skb_trim and skb_put macros are only for non-linear skbuffs, but
we are only using the area inside the skbuff itself for packet
headers, not data.
When we do something like this:
if (bio_data_dir(buf-bio) == WRITE) {
skb_fill_page_desc(skb, 0, bv-bv_page, buf-bv_off, bcnt);
ah.aflags |= AOEAFL_WRITE;
skb-len += bcnt;
skb-data_len = bcnt;
t-wpkts++;
... skb-tail isn't really relevant, because we are only using the
pre-allocated part of the skbuff for headers, and the headers aren't
expanding here. Other parts of the kernel that aren't putting data in
the skbuff itself set the skb-len directly.
e1000_main.c
ip_output.c
tcp.c
ip6_output.c
So is it correct for the callers of skb_fill_page_desc to set skb-len
or is another interface needed besides skb_put/skb_trim? Such a new
interface would be able to maintain the consistency of the skbuff
fields without assuming that the data is in the skbuff itself.
If a new interface is needed, then it seems like we should set
skb-len in this patch until the new interface is ready.
--
Ed L Cashin [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 20/20] iscsi: support for swapping over iSCSI.
Mike Christie wrote: Peter Zijlstra wrote: On Thu, 2006-09-14 at 22:35 +0200, Peter Zijlstra wrote: On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote: I thought I found allocations in that path, lemme search... found this: iscsi_tcp_data_recv() iscsi_data_rescv() iscsi_complete_pdu() __iscsi_complete_pdu() iscsi_recv_pdu() alloc_skb( GFP_ATOMIC); You are right that is for the netlink interface. Could we move the PF_MEMALLOC setting and clearing to iscsi_recv_pdu and and add it to iscsi_conn_error in scsi_transport_iscsi.c so that iscsi_iser and qla4xxx will have it set when they need it. I will send a patch for this along with a way to have the netlink sock vmio set for all iscsi drivers that need it. I already have such a patch, look at: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/iscsi_vmio.patch but what conditional do you want to use for PF_MEMALLOC, an unconditional setting will be highly unpopular. Hmm, perhaps you could key it of sk_has_vmio(nls)... On second thought, not such a good idea, that will still be too course. You only want to force feed stuff originating from sk_has_vmio(iscsi_tcp_conn-sock-sk) connections, not all connectections as soon as there is a swapper in the system. You can move the iscsi_session-swapper field to the iscsi_cls_session and have iscsi_swapdev take a iscsi_cls_session and set that flag. iscsi_recv_pdu and iscsi_conn_error and all the llds can then access this bit. In order to preserve that information you need extra state, abusing this process flags is as good as propagating __GFP_EMERGENCY down the call chain with extra gfp_t arguments, perhaps even better, since it will make sure we catch all allocations. Oh yeah, on the send side we also allocate some memory for the netlink interface if there is a connection error (iscsi_conn_failure - iscsi_conn_error). And when that is called from the transmit side we can change the GFP_ATOMICs to GFP_NOIOs since we have process context. So I am just saying we need to set that flag in a couple more places (if you set it in iscsi_conn_error if iscsi_cls_session-swapper is set then don't worry about it), and that I need to change iscsi_conn_failure and iscsi_conn_error to take a gfp_t as an argument (or do a in_interrupt or something) so we can use GFP_NOIO in the transmit code. - 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] EtherIP tunnel driver (RFC 3378)
Patrick McHardy wrote: Joerg Roedel wrote: On Thu, Sep 14, 2006 at 11:21:22AM +1000, Philip Craig wrote: Joerg Roedel wrote: + To configure tunnels an extra tool is required. You can download + it from http://zlug.fh-zwickau.de/~joro/projects/ under the + EtherIP section. If unsure, say N. To obtain a list of tunnels, this tool calls SIOCGETTUNNEL (SIOCDEVPRIVATE + 0) for every device in /proc/net/dev. I don't think this is safe, but I don't have a solution for you. You are right. But this is the way the ipip driver does it. In the case of ipip it is safe, because it is visible as a tunnel interface to userspace. But my driver registers its devices as Ethernet (it has to, otherwise the devices will not be usable in a bridge). There is no safe way to distinguish between real Ethernet devices and devices registered by my driver. I think about implementing an ioctl to fetch a list of all EtherIP tunnel devices from the driver. Just do what ipip and gre do, use a network device with a fixed name for the ioctl (you already have the ethip0 device for this purpose it appears). That fixed name device isn't used to get a list of tunnels. Instead, ipip and gre read /proc/net/dev, and check for ARPHRD_TUNNEL or ARPHRD_IPGRE. This won't work for etherip because it uses ARPHRD_ETHER, which isn't specific to etherip tunnels. A new ioctl to get a list could be added (this ioctl would use the fixed name device), is that acceptable? - 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]:[XFRM] BEET mode
On Thu, Sep 14, 2006 at 09:09:07AM -0700, Randy.Dunlap wrote:
http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=summary
Yes please use this one until 2.6.18 is released.
Thanks,
--
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
