[RFC][PATCH 56/75] net: drivers/net/saa9730.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/saa9730.c linux-work2/drivers/net/saa9730.c
--- linux-work-clean/drivers/net/saa9730.c 2006-03-20 06:53:29.0
+0100
+++ linux-work2/drivers/net/saa9730.c 2006-08-17 05:16:21.0 +0200
@@ -1131,7 +1131,7 @@ static struct pci_driver saa9730_driver
static int __init saa9730_init(void)
{
- return pci_module_init(&saa9730_driver);
+ return pci_register_driver(&saa9730_driver);
}
static void __exit saa9730_cleanup(void)
-
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][PATCH 60/75] net: drivers/net/sk98lin/skge.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/sk98lin/skge.c
linux-work2/drivers/net/sk98lin/skge.c
--- linux-work-clean/drivers/net/sk98lin/skge.c 2006-08-16 22:41:17.0
+0200
+++ linux-work2/drivers/net/sk98lin/skge.c 2006-08-17 05:16:39.0
+0200
@@ -5133,7 +5133,7 @@ static struct pci_driver skge_driver = {
static int __init skge_init(void)
{
- return pci_module_init(&skge_driver);
+ return pci_register_driver(&skge_driver);
}
static void __exit skge_exit(void)
-
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][PATCH 31/75] net: drivers/net/wireless/ipw2100.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/wireless/ipw2100.c linux-work2/drivers/net/wireless/ipw2100.c --- linux-work-clean/drivers/net/wireless/ipw2100.c 2006-08-16 22:41:00.0 +0200 +++ linux-work2/drivers/net/wireless/ipw2100.c 2006-08-17 05:20:12.0 +0200 @@ -6531,7 +6531,7 @@ static int __init ipw2100_init(void) printk(KERN_INFO DRV_NAME ": %s, %s\n", DRV_DESCRIPTION, DRV_VERSION); printk(KERN_INFO DRV_NAME ": %s\n", DRV_COPYRIGHT); - ret = pci_module_init(&ipw2100_pci_driver); + ret = pci_register_driver(&ipw2100_pci_driver); #ifdef CONFIG_IPW2100_DEBUG ipw2100_debug_level = debug; - 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][PATCH 42/75] net: drivers/net/ns83820.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/ns83820.c linux-work2/drivers/net/ns83820.c
--- linux-work-clean/drivers/net/ns83820.c 2006-08-16 22:41:17.0
+0200
+++ linux-work2/drivers/net/ns83820.c 2006-08-17 05:15:34.0 +0200
@@ -2336,7 +2336,7 @@ static struct pci_driver driver = {
static int __init ns83820_init(void)
{
printk(KERN_INFO "ns83820.c: National Semiconductor DP83820 10/100/1000
driver.\n");
- return pci_module_init(&driver);
+ return pci_register_driver(&driver);
}
static void __exit ns83820_exit(void)
-
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][PATCH 54/75] net: net/rrunner.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/rrunner.c linux-work2/drivers/net/rrunner.c
--- linux-work-clean/drivers/net/rrunner.c 2006-08-16 22:41:00.0
+0200
+++ linux-work2/drivers/net/rrunner.c 2006-08-17 05:16:04.0 +0200
@@ -1736,7 +1736,7 @@ static struct pci_driver rr_driver = {
static int __init rr_init_module(void)
{
- return pci_module_init(&rr_driver);
+ return pci_register_driver(&rr_driver);
}
static void __exit rr_cleanup_module(void)
-
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][PATCH 4/75] net: drivers/net/8139too.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/8139too.c linux-work2/drivers/net/8139too.c --- linux-work-clean/drivers/net/8139too.c 2006-08-16 22:40:59.0 +0200 +++ linux-work2/drivers/net/8139too.c 2006-08-17 05:13:30.0 +0200 @@ -2629,7 +2629,7 @@ static int __init rtl8139_init_module (v printk (KERN_INFO RTL8139_DRIVER_NAME "\n"); #endif - return pci_module_init (&rtl8139_pci_driver); + return pci_register_driver(&rtl8139_pci_driver); } - 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][PATCH 50/75] net: drivers/net/wan/pci200syn.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/wan/pci200syn.c linux-work2/drivers/net/wan/pci200syn.c --- linux-work-clean/drivers/net/wan/pci200syn.c2006-08-16 22:41:00.0 +0200 +++ linux-work2/drivers/net/wan/pci200syn.c 2006-08-17 05:19:56.0 +0200 @@ -476,7 +476,7 @@ static int __init pci200_init_module(voi printk(KERN_ERR "pci200syn: Invalid PCI clock frequency\n"); return -EINVAL; } - return pci_module_init(&pci200_pci_driver); + return pci_register_driver(&pci200_pci_driver); } - 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][PATCH 18/75] net: drivers/net/tulip/dmfe.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/tulip/dmfe.c linux-work2/drivers/net/tulip/dmfe.c --- linux-work-clean/drivers/net/tulip/dmfe.c 2006-08-16 22:41:00.0 +0200 +++ linux-work2/drivers/net/tulip/dmfe.c2006-08-17 05:18:50.0 +0200 @@ -2039,7 +2039,7 @@ static int __init dmfe_init_module(void) if (HPNA_NoiseFloor > 15) HPNA_NoiseFloor = 0; - rc = pci_module_init(&dmfe_driver); + rc = pci_register_driver(&dmfe_driver); if (rc < 0) return rc; - 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][PATCH 16/75] net: drivers/net/defxx.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/defxx.c linux-work2/drivers/net/defxx.c
--- linux-work-clean/drivers/net/defxx.c2006-08-16 22:40:59.0
+0200
+++ linux-work2/drivers/net/defxx.c 2006-08-17 05:14:19.0 +0200
@@ -3444,7 +3444,7 @@ static int __init dfx_init(void)
{
int rc_pci, rc_eisa;
- rc_pci = pci_module_init(&dfx_driver);
+ rc_pci = pci_register_driver(&dfx_driver);
if (rc_pci >= 0) dfx_have_pci = 1;
rc_eisa = dfx_eisa_init();
-
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] nl80211 + packet injection with it and d80211
Hey,
This is a patch laying the groundwork for nl80211. I've decided to
implement it below net/wireless/ so that when we add further things like
configfs support for some things that can just be added there.
Currently, it lays the groundwork for netlink userspace communication.
None of the attribute stuff and configuration stuff I talked about is
implemented yet, nor anything like having wext go over netlink
obviously.
This patch now serves mainly to illustrate how I intend to multiplex
everything. Also, as added bonus, it implements packet injection over
netlink into the d80211 stack :) NB: missing is tx status notification
via netlink. The patch was large enough already.
I'd appreciate any feedback on the implementation.
johannes
--- /dev/null 1970-01-01 00:00:00.0 +
+++ wireless-dev/include/net/nl80211.h 2006-08-17 11:07:18.0 +0200
@@ -0,0 +1,55 @@
+#ifndef __NET_NL80211_H
+#define __NET_NL80211_H
+
+#include
+#include
+#include
+#include
+
+/*
+ * 802.11 netlink in-kernel interface
+ *
+ * Copyright 2006 Johannes Berg <[EMAIL PROTECTED]>
+ */
+
+/**
+ * struct nl80211_call - backend call for wireless configuration
+ *
+ * An array of pointers to &struct nl80211_call is registered
+ * by each backend (driver or wireless stack) within
+ * &struct nl80211_driver.
+ *
+ * @doit: see &struct genl_ops doit
+ * @dumpit: see &struct genl_ops dumpit
+ */
+struct nl80211_call {
+ int (*doit)(struct sk_buff *skb,
+ struct genl_info *info);
+ int (*dumpit)(struct sk_buff *skb,
+ struct netlink_callback *cb);
+};
+
+/**
+ * struct nl80211_driver - backend description for wireless configuration
+ *
+ * This struct is registered by fullmac card drivers and/or wireless stacks
+ * in order to handle configuration requests on their interfaces.
+ *
+ * @get_calls_for_ifindex: return an array of size NL80211_CMD_MAX
+ *with an entry for each
+ */
+struct nl80211_driver {
+ struct nl80211_call** (*get_calls_for_ifindex)(int ifindex);
+
+ /* private: */
+ struct list_head driver_list;
+};
+
+extern void nl80211_register_driver(struct nl80211_driver *drv);
+extern void nl80211_unregister_driver(struct nl80211_driver *drv);
+extern void *nl80211hdr_put(struct sk_buff *skb, u32 pid,
+ u32 seq, int flags, u8 cmd);
+extern void *nl80211msg_new(struct sk_buff **skb, u32 pid,
+ u32 seq, int flags, u8 cmd);
+
+#endif /* __NET_NL80211_H */
--- wireless-dev.orig/net/Kconfig 2006-08-15 12:27:10.0 +0200
+++ wireless-dev/net/Kconfig2006-08-15 12:30:45.0 +0200
@@ -250,6 +250,9 @@
config WIRELESS_EXT
bool
+config NETLINK_80211
+ tristate
+
endif # if NET
endmenu # Networking
--- wireless-dev.orig/net/Makefile 2006-08-15 12:30:56.0 +0200
+++ wireless-dev/net/Makefile 2006-08-15 12:31:13.0 +0200
@@ -44,6 +44,7 @@
obj-$(CONFIG_VLAN_8021Q) += 8021q/
obj-$(CONFIG_IP_DCCP) += dccp/
obj-$(CONFIG_IP_SCTP) += sctp/
+obj-$(CONFIG_NETLINK_80211)+= wireless/
obj-$(CONFIG_D80211) += d80211/
obj-$(CONFIG_IEEE80211)+= ieee80211/
obj-$(CONFIG_TIPC) += tipc/
--- wireless-dev.orig/net/d80211/Kconfig2006-08-16 15:39:44.0
+0200
+++ wireless-dev/net/d80211/Kconfig 2006-08-16 15:39:48.0 +0200
@@ -3,6 +3,7 @@
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NETLINK_80211
---help---
This option enables the hardware independent IEEE 802.11
networking stack.
--- /dev/null 1970-01-01 00:00:00.0 +
+++ wireless-dev/net/wireless/Makefile 2006-08-15 14:43:42.0 +0200
@@ -0,0 +1,4 @@
+obj-$(CONFIG_NETLINK_80211) += cfg80211.o
+
+cfg80211-objs := \
+ nl80211.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ wireless-dev/net/wireless/nl80211.c 2006-08-17 15:32:13.0 +0200
@@ -0,0 +1,209 @@
+/*
+ * This is the new netlink-based wireless configuration interface.
+ *
+ * Copyright 2006 Johannes Berg <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Johannes Berg");
+MODULE_LICENSE("GPL");
+
+static LIST_HEAD(nl80211_drv_list);
+static DEFINE_MUTEX(nl80211_drv_mutex);
+
+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,
+};
+
+static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
+ [NL80211_ATTR_IFINDEX] = { .type = NLA_U32 },
+ [NL80211_ATTR_FLAGS] = { .type = NLA_U32 },
+ [NL80211_ATTR_CMDS] = { .type = NLA_STRING },
+ [N
time stamps of skb packets in NF_HOOKS callbacks
Hello, I am using NF_HOOKS (a "PRE_ROUTING" hook). When I try to print the time stamps (sec and usec) of skb packets which I recieve in the hook callback I get 0. Other skb fileds are correct. According to my understanding, the time stamp should be updated when the packet is received. Isn't it so ? Any idea why am I getting "0" for tstamp fields (tstamp is a field in sk_buff and is an intance of skb_timeval). (what I mean is that the values of skb->tstamp.off_sec and skb>tstamp.off_usec are both 0 , for ongoing incoming packets) Regards, John - 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] mark sk98lin driver for removal
On Tue, Aug 15, 2006 at 02:42:32PM -0400, Michael Stone wrote: On Tue, Aug 15, 2006 at 11:03:40AM -0700, Stephen Hemminger wrote: The driver has always supported both ports as separate devices. If you want to use bonding or fail over that is available in generic kernel. ok, I'll test that in the next few days. The testing didn't get far; the SK-9844 isn't supported either (same "unsupported phy" message). :01:06.0 Ethernet controller: Syskonnect (Schneider & Koch) SK-98xx Gigabit Ethernet Server Adapter (rev 12) Subsystem: Syskonnect (Schneider & Koch) SK-9844 Gigabit Ethernet Server Adapter (SK-NET GE-SX dual link) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Re: Possible leak of multicast source filter sctructure
"Michal Ruzicka" <[EMAIL PROTECTED]> wrote on 08/17/2006 05:26:35 AM: > I've reviewed your patch (the IPv4 part of it) and I think I can say that > our soulutions are actually quite similar. > But I can come up with one difference that I'd like know your opinion on. If you have a duplicated address and the application is not using interface index to identify the interface, then which one you join or leave on is not unique, and which one you'll get is not defined. It is, in fact, an error to leave the group on an interface with a different index, and the duplicate scenario has effectively changed the meaning of that address's interface. In the same scenario, if you have not deleted any interfaces and attempt to leave the group, your code may get the "pppY" interface from ip_mc_find_dev(), not have a matching index for the group you actually joined, and will return EADDRNOTAVAIL rather than leaving the group you joined on. In both cases, it'd simply be an error for an application to be using address to identify the interface when that is not unique. If the addresses are used (or reused) on multiple interfaces, the application has to use interface index to work properly. +-DLS > Suppose the following situatuion: > > 1) create pppX interface: > IP: A.B.C.D > > 2) join a multicast group by address: A.B.C.D > ASSUMPTION: no other interface with the same IP address exists; > the result should be that the group is joined on the pppX interface > > 3) create pppY interface > IP: A.B.C.D (Yes the same IP, not unusual on ppp links.) > > 4) delete the pppX interace > > 5) attempt to leave the multicast group by address: A.B.C.D > > 6) * if your algorthim is used -EADDRNOTAVAIL is returned >* if mine is used the multicast group is left on the pppX interface > > Surely this won't be a common problem but I think it's worth pointing out > here. > > Michal > - > 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] d80211 LED handling
On Fri, 11 Aug 2006 09:55:53 +0200, Johannes Berg wrote:
> However, I'm not sure where I should call the _init and _exit functions
> and if I really should be using the local struct. It seems I shouldn't
> be and should be using the master interface directly or something.
Leds are not interface-specific but card-specific, so using
ieee80211_local is the right way.
Comments:
How is the driver supposed to add its led handlers?
Using generic led triggers is probably interesting for cases when system
has some separate led. It won't help drivers which need to handle leds
on the card itself. In the former case you may want all of wireless
cards in the system to be connected to one led. I don't see how this is
easily possible with this patch. In the latter case, you want to call
callback provided by the driver and not to use generic led triggers at
all.
> [...]
> +config D80211_LEDS
> + bool "Enable LED triggers"
> + select LEDS_TRIGGERS
Is it really necessary to have this as a configurable option?
> [...]
> + name = (char*) local->rx_led+1;
This doesn't seem correct.
> + snprintf(name, IFNAMSIZ + 2, "%srx", local->mdev->name);
Name of interface may change at any time. Using it for fixed identifier
is not a good idea. In addition, nothing prevents you from ending up
with two different led triggers with the same name:
1. modprobe card1
2. ieee80211_led_init(card1)<- card1 is "wmaster0"
3. ip link set wmaster0 name mysupercard
4. modprobe card2
5. ieee80211_led_init(card2)<- card2 is "wmaster0"
> + if (led_trigger_register(local->rx_led)) {
> [...]
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
-
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: time stamps of skb packets in NF_HOOKS callbacks
On Thu, Aug 17, 2006 at 05:37:15PM +0300, John Que ([EMAIL PROTECTED]) wrote: > Hello, > I am using NF_HOOKS (a "PRE_ROUTING" hook). > When I try to print the time stamps (sec and usec) of skb packets > which I recieve > in the hook callback I get 0. Other skb fileds are correct. > According to my understanding, the time stamp should be updated > when the packet is received. Isn't it so ? Any idea why am I getting > "0" for tstamp fields (tstamp is a field in sk_buff and is an intance > of skb_timeval). Timestamps are disabled by default, if you have sockets which enable SO_TIMESTAMP or netfilter queue target and other agents which can enable it, you will see updated values in skb->tstamp. -- Evgeniy Polyakov - 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: proposal for new wireless configuration API
The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, guaranteed to be a monotonically increasing function of signal strength. You don't get to know anything about the scale, or linearity of the function. In essence RSSI is a vendor specific value, of no known units. Not very useful unless you know some card specific details to help interpret it. Now some cards return a signal strength in dBm as the RSSI - note that this fits the requirements of a RSSI measure just fine. RCPI is simply a more tightly specified signal strength measure. Just saying that a RSSI value is not very useful. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 12:20 AM To: Simon Barber Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes Subject: RE: proposal for new wireless configuration API On Wed, 2006-08-16 at 11:02 -0700, Simon Barber wrote: > I'd suggest that the new signal strength measure should be defined as > 'RCPI' - the 'Received Channel Power Indicator' - which is defined in > IEEE 802.11k (the Radio Measurements amendment to 802.11). Except that we unfortunately have no way of getting this with all the reverse engineered devices :) Hence, I guess we should then have multiple different possibilities. A device reporting RCPI would be better than just reporting RSSI, but that's still better than nothing... 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][PATCH 47/75] net: drivers/net/wireless/orinoco_tmd.c pci_module_init to pci_register_driver conversion
>
> Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
Fine with me.
Signed-off-by: Joerg Dorchain <[EMAIL PROTECTED]>
>
> diff -uprN -X linux-work/Documentation/dontdiff
> linux-work-clean/drivers/net/wireless/orinoco_tmd.c
> linux-work2/drivers/net/wireless/orinoco_tmd.c
> --- linux-work-clean/drivers/net/wireless/orinoco_tmd.c 2006-08-16
> 22:41:00.0 +0200
> +++ linux-work2/drivers/net/wireless/orinoco_tmd.c2006-08-17
> 05:20:37.0 +0200
> @@ -228,7 +228,7 @@ MODULE_LICENSE("Dual MPL/GPL");
> static int __init orinoco_tmd_init(void)
> {
> printk(KERN_DEBUG "%s\n", version);
> - return pci_module_init(&orinoco_tmd_driver);
> + return pci_register_driver(&orinoco_tmd_driver);
> }
>
> static void __exit orinoco_tmd_exit(void)
>
-
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][PATCH 51/75] net: drivers/net/pci-skeleton.c pci_module_init to pci_register_driver conversion
Jeff Garzik wrote:
> Please just send one big patch that converts all drivers/net drivers at
> once.
>
> Jeff
>
>
>
>
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/3c59x.c linux-work2/drivers/net/3c59x.c
--- linux-work-clean/drivers/net/3c59x.c2006-08-16 22:41:16.0
+0200
+++ linux-work2/drivers/net/3c59x.c 2006-08-17 05:13:16.0 +0200
@@ -3170,7 +3170,7 @@ static int __init vortex_init(void)
{
int pci_rc, eisa_rc;
- pci_rc = pci_module_init(&vortex_driver);
+ pci_rc = pci_register_driver(&vortex_driver);
eisa_rc = vortex_eisa_init();
if (pci_rc == 0)
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/8139cp.c linux-work2/drivers/net/8139cp.c
--- linux-work-clean/drivers/net/8139cp.c 2006-08-16 22:41:16.0
+0200
+++ linux-work2/drivers/net/8139cp.c2006-08-17 05:13:25.0 +0200
@@ -2098,7 +2098,7 @@ static int __init cp_init (void)
#ifdef MODULE
printk("%s", version);
#endif
- return pci_module_init (&cp_driver);
+ return pci_register_driver(&cp_driver);
}
static void __exit cp_exit (void)
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/8139too.c linux-work2/drivers/net/8139too.c
--- linux-work-clean/drivers/net/8139too.c 2006-08-16 22:40:59.0
+0200
+++ linux-work2/drivers/net/8139too.c 2006-08-17 05:13:30.0 +0200
@@ -2629,7 +2629,7 @@ static int __init rtl8139_init_module (v
printk (KERN_INFO RTL8139_DRIVER_NAME "\n");
#endif
- return pci_module_init (&rtl8139_pci_driver);
+ return pci_register_driver(&rtl8139_pci_driver);
}
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/acenic.c linux-work2/drivers/net/acenic.c
--- linux-work-clean/drivers/net/acenic.c 2006-08-17 00:10:47.0
+0200
+++ linux-work2/drivers/net/acenic.c2006-08-17 05:13:37.0 +0200
@@ -725,7 +725,7 @@ static struct pci_driver acenic_pci_driv
static int __init acenic_init(void)
{
- return pci_module_init(&acenic_pci_driver);
+ return pci_register_driver(&acenic_pci_driver);
}
static void __exit acenic_exit(void)
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/amd8111e.c linux-work2/drivers/net/amd8111e.c
--- linux-work-clean/drivers/net/amd8111e.c 2006-08-16 22:40:59.0
+0200
+++ linux-work2/drivers/net/amd8111e.c 2006-08-17 05:13:42.0 +0200
@@ -2158,7 +2158,7 @@ static struct pci_driver amd8111e_driver
static int __init amd8111e_init(void)
{
- return pci_module_init(&amd8111e_driver);
+ return pci_register_driver(&amd8111e_driver);
}
static void __exit amd8111e_cleanup(void)
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/arcnet/com20020-pci.c
linux-work2/drivers/net/arcnet/com20020-pci.c
--- linux-work-clean/drivers/net/arcnet/com20020-pci.c 2006-08-16
22:41:17.0 +0200
+++ linux-work2/drivers/net/arcnet/com20020-pci.c 2006-08-17
05:13:48.0 +0200
@@ -178,7 +178,7 @@ static struct pci_driver com20020pci_dri
static int __init com20020pci_init(void)
{
BUGLVL(D_NORMAL) printk(VERSION);
- return pci_module_init(&com20020pci_driver);
+ return pci_register_driver(&com20020pci_driver);
}
static void __exit com20020pci_cleanup(void)
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/b44.c linux-work2/drivers/net/b44.c
--- linux-work-clean/drivers/net/b44.c 2006-08-16 22:40:59.0 +0200
+++ linux-work2/drivers/net/b44.c 2006-08-17 05:13:54.0 +0200
@@ -2354,7 +2354,7 @@ static int __init b44_init(void)
dma_desc_align_mask = ~(dma_desc_align_size - 1);
dma_desc_sync_size = max_t(unsigned int, dma_desc_align_size,
sizeof(struct dma_desc));
- return pci_module_init(&b44_driver);
+ return pci_register_driver(&b44_driver);
}
static void __exit b44_cleanup(void)
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/bnx2.c linux-work2/drivers/net/bnx2.c
--- linux-work-clean/drivers/net/bnx2.c 2006-08-16 22:41:17.0 +0200
+++ linux-work2/drivers/net/bnx2.c 2006-08-17 05:14:02.0 +0200
@@ -6015,7 +6015,7 @@ static struct pci_driver bnx2_pci_driver
static int __init bnx2_init(void)
{
- return pci_module_init(&bnx2_pci_driver);
+ return pci_register_driver(&bnx2_pci_driver);
}
static void __exit bnx2_cleanup(void)
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/cassini.c linux-work2/drivers/net/cassini.c
--- linux-work-clean/drivers/net/cassini.c 2006-08-16 22:41:17.0
+0200
+++ linux-work2/drivers/net/cassini.c 2006-08-17 05:14:07.0 +0200
@@ -5245,7 +5245,7 @@ static int __init cas_init(void)
else
link_transition_time
[RFC][PATCH 13/75] net: drivers/net/chelsio/cxgb2.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/chelsio/cxgb2.c
linux-work2/drivers/net/chelsio/cxgb2.c
--- linux-work-clean/drivers/net/chelsio/cxgb2.c2006-08-16
22:40:59.0 +0200
+++ linux-work2/drivers/net/chelsio/cxgb2.c 2006-08-17 05:14:12.0
+0200
@@ -1243,7 +1243,7 @@ static struct pci_driver driver = {
static int __init t1_init_module(void)
{
- return pci_module_init(&driver);
+ return pci_register_driver(&driver);
}
static void __exit t1_cleanup_module(void)
-
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][PATCH 21/75] net: drivers/net/e100.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/e100.c linux-work2/drivers/net/e100.c --- linux-work-clean/drivers/net/e100.c 2006-08-16 22:41:17.0 +0200 +++ linux-work2/drivers/net/e100.c 2006-08-17 05:14:31.0 +0200 @@ -2820,7 +2820,7 @@ static int __init e100_init_module(void) printk(KERN_INFO PFX "%s, %s\n", DRV_DESCRIPTION, DRV_VERSION); printk(KERN_INFO PFX "%s\n", DRV_COPYRIGHT); } - return pci_module_init(&e100_driver); + return pci_register_driver(&e100_driver); } static void __exit e100_cleanup_module(void) - 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][PATCH 2/75] net: drivers/net/3c59x.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/3c59x.c linux-work2/drivers/net/3c59x.c
--- linux-work-clean/drivers/net/3c59x.c2006-08-16 22:41:16.0
+0200
+++ linux-work2/drivers/net/3c59x.c 2006-08-17 05:13:16.0 +0200
@@ -3170,7 +3170,7 @@ static int __init vortex_init(void)
{
int pci_rc, eisa_rc;
- pci_rc = pci_module_init(&vortex_driver);
+ pci_rc = pci_register_driver(&vortex_driver);
eisa_rc = vortex_eisa_init();
if (pci_rc == 0)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] IP100A correct init and close step
Jesse Huang wrote: From: Jesse Huang <[EMAIL PROTECTED]> correct init and close step Change Logs: correct init and close step --- drivers/net/sundance.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) b5e343a17f5d70d1cc9a4ba20d366bab355f64a6 diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c index f63871a..c7c22f0 100755 --- a/drivers/net/sundance.c +++ b/drivers/net/sundance.c @@ -830,6 +830,11 @@ #endif iowrite8(0x01, ioaddr + DebugCtrl1); netif_start_queue(dev); + // 04/19/2005 Jesse fix for complete initial step + spin_lock(&np->lock); + reset_tx(dev); + spin_unlock(&np->lock); + NAK -- ineffective locking. If you need locking here, you must use spin_lock_irqsave() @@ -1654,7 +1659,10 @@ static int netdev_close(struct net_devic /* Disable interrupts by clearing the interrupt mask. */ iowrite16(0x, ioaddr + IntrEnable); - + + // 04/19/2005 Jesse fix for complete initial step + writew(0x500, ioaddr + DMACtrl); NAK: 1) date and author information is already present in the kernel changelog. It should not be present in the source code. 2) The comment (or patch description) fails to describe -why- this change is needed. It only described what is being changes, which is already obvious from reading the source 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 1/6] IP100A, add end of pci id table
On Thu, Aug 17, 2006 at 03:00:47PM -0400, Jesse Huang wrote:
> Add "0," and "NULL," to sundance_pci_tbl and pci_id_table.
> @@ -212,7 +212,7 @@ static const struct pci_device_id sundan
> { 0x1186, 0x1002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4 },
> { 0x13F0, 0x0201, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5 },
> { 0x13F0, 0x0200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 6 },
> - { }
> + { 0,}
> };
> MODULE_DEVICE_TABLE(pci, sundance_pci_tbl);
>
> @@ -231,7 +231,7 @@ static const struct pci_id_info pci_id_t
> {"D-Link DL10050-based FAST Ethernet Adapter"},
> {"Sundance Technology Alta"},
> {"IC Plus Corporation IP100A FAST Ethernet Adapter"},
> - { } /* terminate list. */
> + { NULL,}/* terminate list. */
They are already properly terminated. You don't have to do anything.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] IP100A Remove CONFIG_SUNDANCE_MMIO, mask of mapping address
Jesse Huang wrote: -/* Work-around for Kendin chip bugs. */ -#ifndef CONFIG_SUNDANCE_MMIO -#define USE_IO_OPS 1 -#endif Why? This simply eliminates the ability of the user to set the driver configuration at Kconfig time, requiring them to edit the driver to achieve the same functionality. @@ -491,10 +487,13 @@ #endif if (pci_request_regions(pdev, DRV_NAME)) goto err_out_netdev; - ioaddr = pci_iomap(pdev, bar, netdev_io_size); + ioaddr =(void __iomem *) + ((unsigned long)pci_iomap(pdev, bar, netdev_io_size) & + 0xff80); NAK, this is very wrong. pci_iomap() returns a "cookie", which you are not allowed to modify in any way. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 40/75] net: drivers/net/natsemi.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/natsemi.c linux-work2/drivers/net/natsemi.c --- linux-work-clean/drivers/net/natsemi.c 2006-08-16 22:41:17.0 +0200 +++ linux-work2/drivers/net/natsemi.c 2006-08-17 05:15:22.0 +0200 @@ -3275,7 +3275,7 @@ static int __init natsemi_init_mod (void printk(version); #endif - return pci_module_init (&natsemi_driver); + return pci_register_driver(&natsemi_driver); } static void __exit natsemi_exit_mod (void) - 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][PATCH 15/75] net: drivers/net/tulip/de4x5.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/tulip/de4x5.c linux-work2/drivers/net/tulip/de4x5.c --- linux-work-clean/drivers/net/tulip/de4x5.c 2006-08-16 22:41:17.0 +0200 +++ linux-work2/drivers/net/tulip/de4x5.c 2006-08-17 05:18:44.0 +0200 @@ -5755,7 +5755,7 @@ static int __init de4x5_module_init (voi int err = 0; #ifdef CONFIG_PCI - err = pci_module_init (&de4x5_pci_driver); + err = pci_register_driver(&de4x5_pci_driver); #endif #ifdef CONFIG_EISA err |= eisa_driver_register (&de4x5_eisa_driver); - 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][PATCH 24/75] net: drivers/net/wan/farsync.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/wan/farsync.c linux-work2/drivers/net/wan/farsync.c --- linux-work-clean/drivers/net/wan/farsync.c 2006-08-16 22:41:00.0 +0200 +++ linux-work2/drivers/net/wan/farsync.c 2006-08-17 05:19:37.0 +0200 @@ -2697,7 +2697,7 @@ fst_init(void) for (i = 0; i < FST_MAX_CARDS; i++) fst_card_array[i] = NULL; spin_lock_init(&fst_work_q_lock); - return pci_module_init(&fst_driver); + return pci_register_driver(&fst_driver); } static void __exit - 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][PATCH 10/75] net: drivers/net/bnx2.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/bnx2.c linux-work2/drivers/net/bnx2.c
--- linux-work-clean/drivers/net/bnx2.c 2006-08-16 22:41:17.0 +0200
+++ linux-work2/drivers/net/bnx2.c 2006-08-17 05:14:02.0 +0200
@@ -6015,7 +6015,7 @@ static struct pci_driver bnx2_pci_driver
static int __init bnx2_init(void)
{
- return pci_module_init(&bnx2_pci_driver);
+ return pci_register_driver(&bnx2_pci_driver);
}
static void __exit bnx2_cleanup(void)
-
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][PATCH 34/75] net: drivers/net/ixgb/ixgb_main.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/ixgb/ixgb_main.c linux-work2/drivers/net/ixgb/ixgb_main.c --- linux-work-clean/drivers/net/ixgb/ixgb_main.c 2006-08-16 22:41:17.0 +0200 +++ linux-work2/drivers/net/ixgb/ixgb_main.c2006-08-17 05:15:16.0 +0200 @@ -173,7 +173,7 @@ ixgb_init_module(void) printk(KERN_INFO "%s\n", ixgb_copyright); - return pci_module_init(&ixgb_driver); + return pci_register_driver(&ixgb_driver); } module_init(ixgb_init_module); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] IP100A, add end of pci id table
Jesse Huang wrote:
@@ -212,7 +212,7 @@ static const struct pci_device_id sundan
{ 0x1186, 0x1002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4 },
{ 0x13F0, 0x0201, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5 },
{ 0x13F0, 0x0200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 6 },
- { }
+ { 0,}
};
MODULE_DEVICE_TABLE(pci, sundance_pci_tbl);
@@ -231,7 +231,7 @@ static const struct pci_id_info pci_id_t
{"D-Link DL10050-based FAST Ethernet Adapter"},
{"Sundance Technology Alta"},
{"IC Plus Corporation IP100A FAST Ethernet Adapter"},
- { } /* terminate list. */
+ { NULL,}/* terminate list. */
NAK.
An empty array element "{ }" implies NULL. It is the kernel standard to
prefer "{ }" over an explicit initialization. Looks cleaner.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 28/75] net: drivers/net/hp100.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/hp100.c linux-work2/drivers/net/hp100.c --- linux-work-clean/drivers/net/hp100.c2006-08-16 22:41:17.0 +0200 +++ linux-work2/drivers/net/hp100.c 2006-08-17 05:15:07.0 +0200 @@ -3031,7 +3031,7 @@ static int __init hp100_module_init(void goto out2; #endif #ifdef CONFIG_PCI - err = pci_module_init(&hp100_pci_driver); + err = pci_register_driver(&hp100_pci_driver); if (err && err != -ENODEV) goto out3; #endif - 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][PATCH 43/75] net: drivers/net/tokenring/olympic.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/tokenring/olympic.c
linux-work2/drivers/net/tokenring/olympic.c
--- linux-work-clean/drivers/net/tokenring/olympic.c2006-08-16
22:41:00.0 +0200
+++ linux-work2/drivers/net/tokenring/olympic.c 2006-08-17 05:18:24.0
+0200
@@ -1771,7 +1771,7 @@ static struct pci_driver olympic_driver
static int __init olympic_pci_init(void)
{
- return pci_module_init (&olympic_driver) ;
+ return pci_register_driver(&olympic_driver);
}
static void __exit olympic_pci_cleanup(void)
-
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][PATCH 26/75] net: drivers/net/forcedeth.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/forcedeth.c linux-work2/drivers/net/forcedeth.c
--- linux-work-clean/drivers/net/forcedeth.c2006-08-16 22:41:17.0
+0200
+++ linux-work2/drivers/net/forcedeth.c 2006-08-17 05:15:01.0 +0200
@@ -4668,7 +4668,7 @@ static struct pci_driver driver = {
static int __init init_nic(void)
{
printk(KERN_INFO "forcedeth.c: Reverse Engineered nForce ethernet
driver. Version %s.\n", FORCEDETH_VERSION);
- return pci_module_init(&driver);
+ return pci_register_driver(&driver);
}
static void __exit exit_nic(void)
-
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: bonding: cannot remove certain named devices
Xavier Bestel ([EMAIL PROTECTED]) said: > > I think it's sane to avoid control characters and unicode/iso*, since they > > can interfere with log output or analysis. I only thought about the kernel > > itself and the corresponding userspace tools, which should handle any > > character sequence just fine or could be easily fixed. > > Why not simply retricting chars to isalnum() ones ? People might want to use things like '-', '_', etc. Realistically, any filtering that is done with names has the chance of breaking 'working' configs that date back to 2.4. Bill - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.17] net/ipv6/udp.c: remove duplicate udp_get_port code
Hi, In article <[EMAIL PROTECTED]> (at Thu, 17 Aug 2006 10:56:40 -0400 (EDT)), James Morris <[EMAIL PROTECTED]> says: > On Thu, 17 Aug 2006, [EMAIL PROTECTED] wrote: > > > - if (inet2->num == snum && > > - sk2 != sk && > > - !ipv6_only_sock(sk2) && > > - (!sk2->sk_bound_dev_if || > > -!sk->sk_bound_dev_if || > > -sk2->sk_bound_dev_if == sk->sk_bound_dev_if) && > > > > + sk_for_each(sk2, node, head) > > + if (inet_sk(sk2)->num == snum&& > > + sk2 != sk&& > > + (!sk2->sk_reuse|| !sk->sk_reuse) && > > + (!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if > > +|| sk2->sk_bound_dev_if == sk->sk_bound_dev_if) && > > > Doesn't this change the behavior for IPV6_V6ONLY sockets ? It is tested in ipv4_rcv_saddr_equal() (called vi saddr_cmp), isn't it? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.17] net/ipv6/udp.c: remove duplicate udp_get_port code
On Thu, 17 Aug 2006, [EMAIL PROTECTED] wrote: > - if (inet2->num == snum && > - sk2 != sk && > - !ipv6_only_sock(sk2) && > - (!sk2->sk_bound_dev_if || > - !sk->sk_bound_dev_if || > - sk2->sk_bound_dev_if == sk->sk_bound_dev_if) && > + sk_for_each(sk2, node, head) > + if (inet_sk(sk2)->num == snum&& > + sk2 != sk&& > + (!sk2->sk_reuse|| !sk->sk_reuse) && > + (!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if > + || sk2->sk_bound_dev_if == sk->sk_bound_dev_if) && Doesn't this change the behavior for IPV6_V6ONLY sockets ? - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 9/75] net: drivers/net/b44.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> diff -uprN -X linux-work/Documentation/dontdiff linux-work-clean/drivers/net/b44.c linux-work2/drivers/net/b44.c --- linux-work-clean/drivers/net/b44.c 2006-08-16 22:40:59.0 +0200 +++ linux-work2/drivers/net/b44.c 2006-08-17 05:13:54.0 +0200 @@ -2354,7 +2354,7 @@ static int __init b44_init(void) dma_desc_align_mask = ~(dma_desc_align_size - 1); dma_desc_sync_size = max_t(unsigned int, dma_desc_align_size, sizeof(struct dma_desc)); - return pci_module_init(&b44_driver); + return pci_register_driver(&b44_driver); } static void __exit b44_cleanup(void) - 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][PATCH 19/75] net: drivers/net/wan/dscc4.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/wan/dscc4.c linux-work2/drivers/net/wan/dscc4.c
--- linux-work-clean/drivers/net/wan/dscc4.c2006-08-16 22:41:00.0
+0200
+++ linux-work2/drivers/net/wan/dscc4.c 2006-08-17 05:19:30.0 +0200
@@ -2062,7 +2062,7 @@ static struct pci_driver dscc4_driver =
static int __init dscc4_init_module(void)
{
- return pci_module_init(&dscc4_driver);
+ return pci_register_driver(&dscc4_driver);
}
static void __exit dscc4_cleanup_module(void)
-
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][PATCH 5/75] net: drivers/net/acenic.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/acenic.c linux-work2/drivers/net/acenic.c
--- linux-work-clean/drivers/net/acenic.c 2006-08-17 00:10:47.0
+0200
+++ linux-work2/drivers/net/acenic.c2006-08-17 05:13:37.0 +0200
@@ -725,7 +725,7 @@ static struct pci_driver acenic_pci_driv
static int __init acenic_init(void)
{
- return pci_module_init(&acenic_pci_driver);
+ return pci_register_driver(&acenic_pci_driver);
}
static void __exit acenic_exit(void)
-
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][PATCH 17/75] net: drivers/net/dl2k.c pci_module_init to pci_register_driver conversion
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
diff -uprN -X linux-work/Documentation/dontdiff
linux-work-clean/drivers/net/dl2k.c linux-work2/drivers/net/dl2k.c
--- linux-work-clean/drivers/net/dl2k.c 2006-08-16 22:41:17.0 +0200
+++ linux-work2/drivers/net/dl2k.c 2006-08-17 05:14:25.0 +0200
@@ -1815,7 +1815,7 @@ static struct pci_driver rio_driver = {
static int __init
rio_init (void)
{
- return pci_module_init (&rio_driver);
+ return pci_register_driver(&rio_driver);
}
static void __exit
-
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][PATCH 0/75] pci_module_init to pci_register_driver conversion
On Thu, Aug 17, 2006 at 08:35:12AM -0400, Jeff Garzik wrote: > Greg KH wrote: > >On Thu, Aug 17, 2006 at 04:26:35AM +, Michal Piotrowski wrote: > >>Hi, > >> > >>pci_module_init is obsolete. > >> > >>This patch series converts pci_module_init to pci_register_driver. > >> > >> > >>Can I remove this? > >> > >>include/linux/pci.h:385 > >>/* > >> * pci_module_init is obsolete, this stays here till we fix up all usages > >> of it > >> * in the tree. > >> */ > >>#define pci_module_init pci_register_driver > > > >As repeated numerous times, it's up to the network developers if they > >will take this or not. > > > >I'll hold off on taking this series, please push it through the driver > >subsystem maintainers. > > It's already in subsystem trees, in fact. Great, it can wait until 2.6.19. > But it is most definitely not 2.6.18-rc material :) Agreed. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
Evgeniy Polyakov wrote: Just for clarification - it will be completely impossible to login using openssh or some other priveledge separation protocol to the machine due to the nature of unix sockets. So you will be unable to manage your storage system just because it is in OOM - it is not what is expected from reliable system. The system is not OOM, it is in reclaim, a transient condition that will be resolved in normal course by IO progress. However you raise an excellent point: if there is any remote management that we absolutely require to be available while remote IO is interrupted - manual failover for example - then we must supply a means of carrying out such remote administration, that is guaranteed not to deadlock on a normal mode memory request. This ends up as a new network stack feature I think, and probably a theoretical one for the time being since we don't actually know of any such mandatory login that must be carried out while remote disk IO is suspended. That is why you are not allowed to depend on main system's allocator problems. That is why network can have it's own allocator. Please check your assumptions. Do you understand how PF_MEMALLOC works, and where it gets its reserve memory from? But really, if you expect to run reliable block IO to Zanzibar over an ssh tunnel through a firewall, then you might also consider taking up bungie jumping with the cord tied to your neck. Just pure openssh for control connection (admin should be able to login). And the admin will be able to, but in the cluster stack itself we don't bless such stupidity as emailing an admin to ask for a login in order to break a tie over which node should take charge of DLM recovery. No, you can't since openssh and any other priveledge separation mechanisms use adtional sockets to transfer data between it's parts, unix sockets require page sized allocation frequently which will endup with 8k allocation in slab. You will not be able to login using openssh. *** The system is not OOM, it is in reclaim, a transient condition *** Which Peter already told you! Please, let's get our facts straight, then we can look intelligently at whether your work is appropriate to solve the block IO network starvation problem that Peter and I are working on. Regards, Daniel - 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 and sta_aid for AP functionality
On Mon, 14 Aug 2006 10:19:24 +0200, Johannes Berg wrote: > Looking through the code, I notice that above (a) and (b) can be > collapsed into just keeping track of the TIM throughout the code. I > suppose that's meant by the comment above? Then we can't add the check > for saying 'hey you stupid userspace that AID is already used' but > that's ok I guess. > > If you can confirm that my analysis is correct I'd be willing to try > making this change. You understand it right (or at least the same way as me :-)) and this effort would be highly appreciated. Thanks, Jiri -- Jiri Benc SUSE Labs - 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: proposal for new wireless configuration API
On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote: > On Tuesday 15 August 2006 20:14, Dan Williams wrote: > > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: > > > On Tuesday 15 August 2006 18:29, Dan Williams wrote: > > > > o Separate attributes for channel and frequency > > > > > > No, channel and freq is the same. It's just another name > > > for the same child. I would say we only want to deal with channel numbers > > > in the API. That's much easier, as we don't have to deal with this > > > fixed-point (or even floating point) mess. Look at WE for the > > > fixed-point mess. > > > > Right, I don't have a problem with only using one or the other; but we > > _HAVE_ to provide a function in the driver that allows userspace > > programs to convert channel <-> frequency both ways, like you suggest > > below. Obviously the channel/frequency mapping isn't the same > > everywhere. > > > > [ or is it? I'd be very uncomfortable using the same channel #s > > everywhere unless some IEEE spec states exactly what the channel #s are > > for every frequency range that wireless stuff operates in ] > > The channel<->freq mapping is stable. We may need to double check this... It is already clear that WiMax, ZigBee and pre-802.11 HW don't use the same channel<->freq mapping as 802.11. Further, I remember somebody (was it Jouni) mentioning that some variations of 802.11 have different channel mappings. But, we would need to check that. > > No argument here; as long as we provide the mapping function in the > > driver for each card. > > Hm, I don't know if I understand this correctly. > You want to implement the mapping function in every driver > or in the d80211 stack? A simple mapping table is probably enough, similar to what we already have. Jean - 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][PATCH 0/9] Network receive deadlock prevention for NBD
On Thu, Aug 17, 2006 at 11:01:52AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > *** The system is not OOM, it is in reclaim, a transient condition *** It does not matter how condition when not every user can get memory is called. And actually no one can know in advance how long it will be. > Which Peter already told you! Please, let's get our facts straight, > then we can look intelligently at whether your work is appropriate to > solve the block IO network starvation problem that Peter and I are > working on. I got openssh as example of situation when system does not know in advance, what sockets must be marked as critical. OpenSSH works with network and unix sockets in parallel, so you need to hack openssh code to be able to allow it to use reserve when there is not enough memory. Actually all sockets must be able to get data, since kernel can not diffirentiate between telnetd and a process which will receive an ack for swapped page or other significant information. So network must behave separately from main allocator in that period of time, but since it is possible that reserve can be not filled or has not enough space or something other, it must be preallocated in far advance and should be quite big, but then why netwrok should use it at all, when being separated from main allocations solves the problem? I do not argue that your approach is bad or does not solve the problem, I'm just trying to show that further evolution of that idea eventually ends up in separated allocator (as long as all most robust systems separate operations), which can improve things in a lot of other sides too. > Regards, > > Daniel -- Evgeniy Polyakov - 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][PATCH 0/9] Network receive deadlock prevention for NBD
On Thu, 2006-08-17 at 22:42 +0400, Evgeniy Polyakov wrote: > On Thu, Aug 17, 2006 at 11:01:52AM -0700, Daniel Phillips ([EMAIL PROTECTED]) > wrote: > > *** The system is not OOM, it is in reclaim, a transient condition *** > > It does not matter how condition when not every user can get memory is > called. And actually no one can know in advance how long it will be. Well, we have a direct influence here, we're working on code-paths that are called from reclaim. If we stall, the box is dead. > > Which Peter already told you! Please, let's get our facts straight, > > then we can look intelligently at whether your work is appropriate to > > solve the block IO network starvation problem that Peter and I are > > working on. > > I got openssh as example of situation when system does not know in > advance, what sockets must be marked as critical. > OpenSSH works with network and unix sockets in parallel, so you need to > hack openssh code to be able to allow it to use reserve when there is > not enough memory. OpenSSH or any other user-space program will never ever have the problem we are trying to solve. Nor could it be fixed the way we are solving it, user-space programs can be stalled indefinite. We are concerned with kernel services, and the continued well being of the kernel, not user-space. (well therefore indirectly also user-space of course) > Actually all sockets must be able to get data, since > kernel can not diffirentiate between telnetd and a process which will > receive an ack for swapped page or other significant information. Oh, but it does, the kernel itself controls those sockets: NBD / iSCSI and AoE are all kernel services, not user-space. And it is the core of our work to provide this information to the kernel; to distinguish these few critical sockets. > So network must behave separately from main allocator in that period of > time, but since it is possible that reserve can be not filled or has not > enough space or something other, it must be preallocated in far advance > and should be quite big, but then why netwrok should use it at all, when > being separated from main allocations solves the problem? You still need to guarantee data-paths to these services, and you need to make absolutely sure that your last bit of memory is used to service these critical sockets, not some random blocked user-space process. You cannot pre-allocate enough memory _ever_ to satisfy the total capacity of the network stack. You _can_ allot a certain amount of memory to the network stack (avoiding DoS), and drop packets once you exceed that. But still, you need to make sure these few critical _kernel_ services get their data. > I do not argue that your approach is bad or does not solve the problem, > I'm just trying to show that further evolution of that idea eventually > ends up in separated allocator (as long as all most robust systems > separate operations), which can improve things in a lot of other sides > too. Not a separate allocator per-se, separate socket group, they are serviced by the kernel, they will never refuse to process data, and it is critical for the continued well-being of your kernel that they get their data. Also, I do not think people would like it if say 100M of their 1G system just disappears, never to used again for eg. page-cache in periods of low network traffic. - 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][PATCH 50/75] net: drivers/net/wan/pci200syn.c pci_module_init to pci_register_driver conversion
Michal Piotrowski <[EMAIL PROTECTED]> writes: > +++ linux-work2/drivers/net/wan/wanxl.c > +++ linux-work2/drivers/net/wan/pci200syn.c > - return pci_module_init(&pci200_pci_driver); > + return pci_register_driver(&pci200_pci_driver); Ok. Rozumiem, ze Jeff zrobi to w jednym, duzym batchu? -- Krzysztof Halasa - 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][PATCH 0/9] Network receive deadlock prevention for NBD
On Thu, Aug 17, 2006 at 09:15:14PM +0200, Peter Zijlstra ([EMAIL PROTECTED]) wrote: > > I got openssh as example of situation when system does not know in > > advance, what sockets must be marked as critical. > > OpenSSH works with network and unix sockets in parallel, so you need to > > hack openssh code to be able to allow it to use reserve when there is > > not enough memory. > > OpenSSH or any other user-space program will never ever have the problem > we are trying to solve. Nor could it be fixed the way we are solving it, > user-space programs can be stalled indefinite. We are concerned with > kernel services, and the continued well being of the kernel, not > user-space. (well therefore indirectly also user-space of course) You limit your system here - it is possible that userspace should send some command when kernel agent requires some negotiation. And even for them it is possible to require ARP request and/or ICMP processing. > > Actually all sockets must be able to get data, since > > kernel can not diffirentiate between telnetd and a process which will > > receive an ack for swapped page or other significant information. > > Oh, but it does, the kernel itself controls those sockets: NBD / iSCSI > and AoE are all kernel services, not user-space. And it is the core of > our work to provide this information to the kernel; to distinguish these > few critical sockets. As I stated above it is not enough. And even if you will cover all kernel-only network allocations, which are used for your selected datapath, problem still there - admin is unable to connect although it can be critical connection too. > > So network must behave separately from main allocator in that period of > > time, but since it is possible that reserve can be not filled or has not > > enough space or something other, it must be preallocated in far advance > > and should be quite big, but then why netwrok should use it at all, when > > being separated from main allocations solves the problem? > > You still need to guarantee data-paths to these services, and you need > to make absolutely sure that your last bit of memory is used to service > these critical sockets, not some random blocked user-space process. > > You cannot pre-allocate enough memory _ever_ to satisfy the total > capacity of the network stack. You _can_ allot a certain amount of > memory to the network stack (avoiding DoS), and drop packets once you > exceed that. But still, you need to make sure these few critical > _kernel_ services get their data. Feel free to implement any receiving policy inside _separated_ allocator to meet your needs, but if allocator depends on main system's memory conditions it is always possible that it will fail to make forward progress. > > I do not argue that your approach is bad or does not solve the problem, > > I'm just trying to show that further evolution of that idea eventually > > ends up in separated allocator (as long as all most robust systems > > separate operations), which can improve things in a lot of other sides > > too. > > Not a separate allocator per-se, separate socket group, they are > serviced by the kernel, they will never refuse to process data, and it > is critical for the continued well-being of your kernel that they get > their data. You do not know in advance which sockets must be separated (since only in the simplest situation it is the same as in NBD and is kernelspace-only), you can not solve problem with ARP/ICMP/route changes and other control messages, netfilter, IPsec and compression which still can happen in your setup, if something goes wrong and receiving will require additional allocation from network datapath, system is dead, this strict conditions does not allow flexible control over possible connections and does not allow to create additional connections. As far as I understood, it is ok to solve the problem in the exact your case without all or most of the above issues in the setup, but in general some other mechanism should be used, which will not suffer or will allow to control above issues. > Also, I do not think people would like it if say 100M of their 1G system > just disappears, never to used again for eg. page-cache in periods of > low network traffic. Just for clarification: network tree allocator gets 512kb and then increases cache size when it is required. Default value can be changed of course. -- Evgeniy Polyakov - 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][PATCH 50/75] net: drivers/net/wan/pci200syn.c pci_module_init to pci_register_driver conversion
Krzysztof Halasa <[EMAIL PROTECTED]> writes: > Ok. Rozumiem, ze Jeff zrobi to w jednym, duzym batchu? Oops, hit the wrong key. Ok WRT both patches and assume Jeff will apply this all-at-once. -- Krzysztof Halasa - 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: proposal for new wireless configuration API
On Thursday 17 August 2006 21:39, Jean Tourrilhes wrote: > On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote: > > On Tuesday 15 August 2006 20:14, Dan Williams wrote: > > > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: > > > > On Tuesday 15 August 2006 18:29, Dan Williams wrote: > > > > > o Separate attributes for channel and frequency > > > > > > > > No, channel and freq is the same. It's just another name > > > > for the same child. I would say we only want to deal with channel > > > > numbers > > > > in the API. That's much easier, as we don't have to deal with this > > > > fixed-point (or even floating point) mess. Look at WE for the > > > > fixed-point mess. > > > > > > Right, I don't have a problem with only using one or the other; but we > > > _HAVE_ to provide a function in the driver that allows userspace > > > programs to convert channel <-> frequency both ways, like you suggest > > > below. Obviously the channel/frequency mapping isn't the same > > > everywhere. > > > > > > [ or is it? I'd be very uncomfortable using the same channel #s > > > everywhere unless some IEEE spec states exactly what the channel #s are > > > for every frequency range that wireless stuff operates in ] > > > > The channel<->freq mapping is stable. > > We may need to double check this... > It is already clear that WiMax, ZigBee and pre-802.11 HW don't > use the same channel<->freq mapping as 802.11. > Further, I remember somebody (was it Jouni) mentioning that > some variations of 802.11 have different channel mappings. But, we > would need to check that. Yes, I should have been more verbose here. What I meant is: In a particular PHYMODE the channel->freq mapping is stable. That is, if we are in G-PHY mode, the mapping is always stable with channels 1-14. Wimax and so on would be another PHYMODE. The PHYMODE would be selected otherwise (through other netlink attrs or whatever). > > > No argument here; as long as we provide the mapping function in the > > > driver for each card. > > > > Hm, I don't know if I understand this correctly. > > You want to implement the mapping function in every driver > > or in the d80211 stack? > > A simple mapping table is probably enough, similar to what we > already have. Well, a mapping function, because we must look at the different PHYMODEs. -- 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
InfiniBand merge plans for 2.6.19
Here's a short summary of what I plan to merge for 2.6.19. Some of this is already in infiniband.git[1], while some still needs to be merged up. Highlights: o iWARP core support[2]. This updates drivers/infiniband to work with devices that do RDMA over IP/ethernet in addition to InfiniBand devices. As a first user of this support, I also plan to merge the amso1100[3] driver for Ammasso RNIC. I will post this for review one more time after I pull it into my git tree for last minute cleanups. But if you feel this iWARP support should not be merged, please let me know why now. o IBM eHCA driver, which supports IBM pSeries-specific InfiniBand hardware. This is in the ehca branch of infiniband.git, and I will post it for review one more time. My feeling is that more cleanups are certainly possible, but this driver is "good enough to merge" now and has languished out of tree for long enough. I'm certainly happy to merge cleanup patches, though. o mmap()ed userspace work queues for ipath. This is a performance enhancement for QLogic/PathScale HCAs but it does touch core stuff in minor ways. Should not be controversial. o I also have the following minor changes queued in the for-2.6.19 branch of infiniband.git: Ishai Rabinovitz: IB/srp: Add port/device attributes James Lentini: IB/mthca: Include the header we really want Michael S. Tsirkin: IB/mthca: Don't use privileged UAR for kernel access IB/ipoib: Fix flush/start xmit race (from code review) Roland Dreier: IB/uverbs: Use idr_read_cq() where appropriate IB/uverbs: Fix lockdep warning when QP is created with 2 CQs [1] git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git [2] http://thread.gmane.org/gmane.linux.network/40903 [3] http://thread.gmane.org/gmane.linux.drivers.openib/28657 - 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: proposal for new wireless configuration API
On 06-08-17 09:42 Simon Barber wrote: > The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, > guaranteed to be a monotonically increasing function of signal strength. > You don't get to know anything about the scale, or linearity of the > function. In essence RSSI is a vendor specific value, of no known units. > Not very useful unless you know some card specific details to help > interpret it. > > Now some cards return a signal strength in dBm as the RSSI - note that > this fits the requirements of a RSSI measure just fine. RCPI is simply a > more tightly specified signal strength measure. > > Just saying that a RSSI value is not very useful. we are simply not able to deliver RCPI, because we have no idea how RSSI is measured for the ZD1211 device. We had discussions with the vendor developers, but it seemed that their understanding was not really more advanced than our's. There is the same issue for signal quality and signal-to-noise ratio. -- Uli Kunitz - 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: proposal for new wireless configuration API
On 06-08-15 18:38 Michael Buesch wrote: > On Tuesday 15 August 2006 18:29, Dan Williams wrote: > > o Separate attributes for channel and frequency > > No, channel and freq is the same. It's just another name > for the same child. I would say we only want to deal with channel numbers > in the API. That's much easier, as we don't have to deal with this > fixed-point (or even floating point) mess. Look at WE for the > fixed-point mess. > The userspace tools can easily convert freq to channel and back. > And in the kernel, we can easily provide some small function > to convert from channel to khz and back, for example. But I would > like to see the fixed-point stuff in the API vanish. > > > o Method of finding out channel <-> frequency mapping (not all drivers > > support this in the SIOCGIWRANGE handler now) > > Yes, that would be a good idea. > Comes next to the conversion function (see above). Channel to frequency mapping is defined by 802.11. So we could get rid of frequencies totally in the user interface and it will also help with compliance to regulatory rules. Or are here people, who really want to freely transmit on all frequencies their RF might be able to generate? -- Uli Kunitz - 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] Re: Possible leak of multicast source filter sctructure
From: David Stevens <[EMAIL PROTECTED]> Date: Tue, 15 Aug 2006 17:57:58 -0600 > Here's a patch to fix source filter leakage when a device is removed > and a process leaves the group thereafter. (2nd part of prior discussion) > > This patch also includes corresponding fixes for IPv6 multicast source > filters on device removal (1st & 2nd parts of prior discussion, for IPv6). > > Signed-off-by: David L Stevens <[EMAIL PROTECTED]> Patch applied, thanks David. - 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: crash in ipt_do_table
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Tue, 15 Aug 2006 16:01:06 +0200 > Any chance you're also changing your ruleset dynamically? If yes > this patch might help. I've applied this. - 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: bonding: cannot remove certain named devices
From: Xavier Bestel <[EMAIL PROTECTED]> Date: Thu, 17 Aug 2006 09:29:43 +0200 > Why not simply retricting chars to isalnum() ones ? As Bill said that would block things like "-" and "_" which are fine. Bill also mentioned something about "breaking configs going back to 2.4.x" which is bogus because nothing broke when we started blocking "/" and "." and ".." in networking device names during the addition of sysfs support for net devices. Nobody in their right mind puts a space in their network device name. All you "name purists", go rename the block device name that is used for your root partition to something with a space in it, and watch how many startup scripts and command line invocations just explode. There is absolutely no valid argument for allowing spaces in network device names. - 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][PATCH 0/9] Network receive deadlock prevention for NBD
Evgeniy Polyakov wrote: On Thu, Aug 17, 2006 at 09:15:14PM +0200, Peter Zijlstra ([EMAIL PROTECTED]) wrote: I got openssh as example of situation when system does not know in advance, what sockets must be marked as critical. OpenSSH works with network and unix sockets in parallel, so you need to hack openssh code to be able to allow it to use reserve when there is not enough memory. OpenSSH or any other user-space program will never ever have the problem we are trying to solve. Nor could it be fixed the way we are solving it, user-space programs can be stalled indefinite. We are concerned with kernel services, and the continued well being of the kernel, not user-space. (well therefore indirectly also user-space of course) You limit your system here - it is possible that userspace should send some command when kernel agent requires some negotiation. And even for them it is possible to require ARP request and/or ICMP processing. Actually all sockets must be able to get data, since kernel can not diffirentiate between telnetd and a process which will receive an ack for swapped page or other significant information. Oh, but it does, the kernel itself controls those sockets: NBD / iSCSI and AoE are all kernel services, not user-space. And it is the core of our work to provide this information to the kernel; to distinguish these few critical sockets. As I stated above it is not enough. And even if you will cover all kernel-only network allocations, which are used for your selected datapath, problem still there - admin is unable to connect although it can be critical connection too. So network must behave separately from main allocator in that period of time, but since it is possible that reserve can be not filled or has not enough space or something other, it must be preallocated in far advance and should be quite big, but then why netwrok should use it at all, when being separated from main allocations solves the problem? You still need to guarantee data-paths to these services, and you need to make absolutely sure that your last bit of memory is used to service these critical sockets, not some random blocked user-space process. You cannot pre-allocate enough memory _ever_ to satisfy the total capacity of the network stack. You _can_ allot a certain amount of memory to the network stack (avoiding DoS), and drop packets once you exceed that. But still, you need to make sure these few critical _kernel_ services get their data. Feel free to implement any receiving policy inside _separated_ allocator to meet your needs, but if allocator depends on main system's memory conditions it is always possible that it will fail to make forward progress. Wrong. Our main allocator has a special reserve that can be accessed only by a task that has its PF_MEMALLOC flag set. This reserve exists in order to guarantee forward progress in just such situations as the network runs into when it is trying to receive responses from a remote disk. Anything otherwise is a bug. I do not argue that your approach is bad or does not solve the problem, I'm just trying to show that further evolution of that idea eventually ends up in separated allocator (as long as all most robust systems separate operations), which can improve things in a lot of other sides too. Not a separate allocator per-se, separate socket group, they are serviced by the kernel, they will never refuse to process data, and it is critical for the continued well-being of your kernel that they get their data. The memalloc reserve is indeed a separate reserve, however it is a reserve that already exists, and you are busy creating another separate reserve to further partition memory. Partitioning memory is not the direction we should be going, we should be trying to unify our reserves wherever possible, and find ways such as Andrew and others propose to implement "reserve on demand", or in other words, take advantage of "easily freeable" pages. If your allocation code is so much more efficient than slab then why don't you fix slab instead of replicating functionality that already exists elsewhere in the system, and has since day one? You do not know in advance which sockets must be separated (since only in the simplest situation it is the same as in NBD and is kernelspace-only), Yes we do, they are exactly those sockets that lie in the block IO path. The VM cannot deadlock on any others. you can not solve problem with ARP/ICMP/route changes and other control messages, netfilter, IPsec and compression which still can happen in your setup, If you bothered to read the patches you would know that ICMP is indeed handled. ARP I don't think so, we may need to do that since ARP can believably be required for remote disk interface failover. Anybody who designs ssh into remote disk failover is an idiot. Ssh for configuration, monitoring and administration is fine. Ssh for fencing or whatever is just plain stupid, unless the nodes run
Re: [RFC][PATCH 2/9] deadlock prevention core
Andrew Morton wrote: Daniel Phillips <[EMAIL PROTECTED]> wrote: What happened to the case where we just fill memory full of dirty file pages backed by a remote disk? Processes which are dirtying those pages throttle at /proc/sys/vm/dirty_ratio% of memory dirty. So it is not possible to "fill" memory with dirty pages. If the amount of physical memory which is dirty exceeds 40%: bug. Hi Andrew, So we make 400 MB of a 1 GB system unavailable for write caching just to get around the network receive starvation issue? What happens if some in kernel user grabs 68% of kernel memory to do some very important thing, does this starvation avoidance scheme still work? Regards, Daniel - 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
I/OAT configuration ?
Hi, I am trying to use I/OAT on one of the newer woodcrest boxes. But not sure if things are configured properly since there seems to be no change in performance with I/OAT enabled or disabled. Following are the steps followed. 1. MSI (CONFIG_PCI_MSI) is enabled in kernel(2.6.16.21). 2. In kernel DMA configuration, following are enabled. Support for DMA Engines Network: TCP receive copy offload Test DMA Client Intel I/OAT DMA support 3. I manually load the ioatdma driver (modprobe ioatdma) As per some documentation I read, when step #3 is performed successfully, directories dma0chanX is supposed to be created under /sys/class/dma but in my case, this directory stays empty. I don't see any messages in /var/log/messages. Any idea what is missing ? Thanks, Ravi - 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: bonding: cannot remove certain named devices
Ar Iau, 2006-08-17 am 16:23 -0700, ysgrifennodd David Miller: > Nobody in their right mind puts a space in their network device name. It works fine. Been there done that. I'm probably not in my right mind but it causes no problems. Nor btw does UTF-8 naming which is handy if you want to name your devices in Japanese or Arabic... > All you "name purists", go rename the block device name that is used > for your root partition to something with a space in it Works fine. It doesn't work fine for non root volumes (except by label) because of the fstab format but root is ok ! Alan - 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][PATCH 2/9] deadlock prevention core
Daniel Phillips wrote: Andrew Morton wrote: Daniel Phillips <[EMAIL PROTECTED]> wrote: What happened to the case where we just fill memory full of dirty file pages backed by a remote disk? Processes which are dirtying those pages throttle at /proc/sys/vm/dirty_ratio% of memory dirty. So it is not possible to "fill" memory with dirty pages. If the amount of physical memory which is dirty exceeds 40%: bug. So we make 400 MB of a 1 GB system unavailable for write caching just to get around the network receive starvation issue? What happens if some in kernel user grabs 68% of kernel memory to do some very important thing, does this starvation avoidance scheme still work? Also think about eg. scientific calculations, or anonymous memory. People want to be able to use a larger percentage of their memory for dirty data, without swapping... -- What is important? What you want to be true, or what is true? - 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][PATCH 2/9] deadlock prevention core
Daniel Phillips wrote: Andrew Morton wrote: Processes which are dirtying those pages throttle at /proc/sys/vm/dirty_ratio% of memory dirty. So it is not possible to "fill" memory with dirty pages. If the amount of physical memory which is dirty exceeds 40%: bug. So we make 400 MB of a 1 GB system unavailable for write caching just to get around the network receive starvation issue? Excuse me, 600 MB of a 1 GB system :-/ Regards, Daniel - 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: bonding: cannot remove certain named devices
From: Alan Cox <[EMAIL PROTECTED]> Date: Fri, 18 Aug 2006 01:34:43 +0100 > Ar Iau, 2006-08-17 am 16:23 -0700, ysgrifennodd David Miller: > > All you "name purists", go rename the block device name that is used > > for your root partition to something with a space in it > > Works fine. It doesn't work fine for non root volumes (except by label) > because of the fstab format but root is ok ! Check out how your root device would be fsck'd. The command line run by the /etc/init* scripts either doesn't quote the device argument or it consults fstab which as you said has limitations when dealing with spaces. It's either going to do something like $device (this is what debian derived systems do), unquoted, or it will do "fsck -A" which runs into said fstab format limitations (which is what fedora does). Either way the point is that this issue is scattered all over the place. Preventing spaces in the name doesn't prevent the use of names in non- romanized languages any moreso than preventing ".", "..", and "/" already does. - 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][PATCH 2/9] deadlock prevention core
On Thursday August 17, [EMAIL PROTECTED] wrote: > Andrew Morton wrote: > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >>What happened to the case where we just fill memory full of dirty file > >>pages backed by a remote disk? > > > > Processes which are dirtying those pages throttle at > > /proc/sys/vm/dirty_ratio% of memory dirty. So it is not possible to "fill" > > memory with dirty pages. If the amount of physical memory which is dirty > > exceeds 40%: bug. > > Hi Andrew, > > So we make 400 MB of a 1 GB system unavailable for write caching just to > get around the network receive starvation issue? No. We make it unavailable for write caching so it is available for other important things like cached clean pages and executables etc. You have to start throttling some where or you get very bad behaviour. 40% seems a good number, but it is tunable. The fact that it helps with receive starvation is just s bonus. > > What happens if some in kernel user grabs 68% of kernel memory to do some > very important thing, does this starvation avoidance scheme still work? That is a very good question. Is memlocked memory throttled against dirty pages, and does it decrease the space available to the 40% calculation? I don't know. I guess I could look at the code... get_dirty_limits in page_writeback caps 'dirty_ratio' (40 by default, hence the 40%) at unmapped_ratio/2. So yes. If 68% is mapped and locked (I assume that it the situation you are referring to) that leaves 32% unlocked, so the 40% above is reduced to 16% and you should still have 160Meg of breathing space. NeilBrown - 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] eth: docbook comments
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 15 Aug 2006 12:57:59 -0700 > Add docbook style comments to ethernet support. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks Stephen. - 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] eth: indentation and cleanup (revised)
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 15 Aug 2006 14:05:52 -0700 > Run ethernet support through Lindent and fix up. > Applies after docbook comments patch > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks a lot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] IPv4 FIB configuration conversions
From: Thomas Graf <[EMAIL PROTECTED]> Date: Tue, 15 Aug 2006 16:57:23 +0200 > Replaces the rather ugly struct kern_rta + rtmsg with a new > struct fib_config while converting everything to the new netlink > api. Simplifies the FIB module interface quite a bit and allows > changing internals while keeping a stable netlink interface. > > Gets rid of things like passing on netlink_skb_parms all around > the fib code etc. > > Also fixes some memory corruptions that could be triggered via > netlink messages, not sure which would actually lead to an oops > though. All applied, thanks a lot Thomas. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] neighbour: reduce exports
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 15 Aug 2006 12:56:30 -0700 > There are several symbols only used by rtnetlink and since it can > not be a module, there is no reason to export them. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied. > -static __inline__ void neigh_update_hhs(struct neighbour *neigh) > +static void neigh_update_hhs(struct neighbour *neigh) ... > -EXPORT_SYMBOL(neigh_update_hhs); Nice to see we were trying to export a static inline function :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 6936] BUG: warning at net/core/dev.c:1171/skb_checksum_help()
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 16 Aug 2006 11:29:00 +1000 > On Tue, Aug 15, 2006 at 11:29:59AM -0700, [EMAIL PROTECTED] wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=6936 > > It's actually a bug in the bridging code :) > > [BRIDGE]: Disable SG/GSO if TX checksum is off Applied, thanks a lot Herbert. - 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] locking bug in fib_semantics.c
From: Alexey Kuznetsov <[EMAIL PROTECTED]> Date: Thu, 17 Aug 2006 13:36:15 +0400 > Found in 2.4 by Yixin Pan <[EMAIL PROTECTED]>. Why do we need lockdep, > when sharp-sighted eyes are available? :-) Lockdep can only tell us about code paths which actually have been run, so it shows that nobody running lockdep has had a redirect arrive on a non-shared-media device marked for secure redirects :) But such a code path would only need to run once for lockdep to catch it. > > When I read fib_semantics.c of Linux-2.4.32, write_lock(&fib_info_lock) = > > is used in fib_release_info() instead of write_lock_bh(&fib_info_lock). = > > Is the following case possible: a BH interrupts fib_release_info() while = > > holding the write lock, and calls ip_check_fib_default() which calls = > > read_lock(&fib_info_lock), and spin forever. > > Signed-off-by: Alexey Kuznetsov <[EMAIL PROTECTED]> Good spotting. Patch applied, and I'll push this to -stable too. Thanks a lot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bonding: cannot remove certain named devices
David Miller ([EMAIL PROTECTED]) said: > From: Xavier Bestel <[EMAIL PROTECTED]> > Date: Thu, 17 Aug 2006 09:29:43 +0200 > > > Why not simply retricting chars to isalnum() ones ? > > As Bill said that would block things like "-" and "_" which are fine. > > Bill also mentioned something about "breaking configs going back to > 2.4.x" which is bogus because nothing broke when we started blocking > "/" and "." and ".." in networking device names during the addition of > sysfs support for net devices. I was mainly referring to if we started to filter it out to isalnum() - spaces/tab/CR etc. certainly could be filtered. (No idea what would happen with unicode nbsp or other silly things.) Bill - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] network memory allocator.
On Wed, 16 Aug 2006, Andi Kleen wrote: > That's not true on all NUMA systems (that they have a slow interconnect) > I think on x86-64 I would prefer if it was distributed evenly or maybe even > on the CPU who is finally going to process it. > > -Andi "not all NUMA is an Altix" The Altix NUMA interconnect has the same speed as far as I can recall as Hypertransport. It is the distance (real physical cable length) that creates latencies for huge systems. Sadly the Hypertransport is designed to stay on the motherboard. Hypertransport can only be said to be fast because its only used for tinzy winzy systems of a few processors. Are you saying that the design limitations of Hypertransport are an advantage? - 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: bonding: cannot remove certain named devices
Bill Nottingham wrote: David Miller ([EMAIL PROTECTED]) said: From: Xavier Bestel <[EMAIL PROTECTED]> Date: Thu, 17 Aug 2006 09:29:43 +0200 Why not simply retricting chars to isalnum() ones ? As Bill said that would block things like "-" and "_" which are fine. Bill also mentioned something about "breaking configs going back to 2.4.x" which is bogus because nothing broke when we started blocking "/" and "." and ".." in networking device names during the addition of sysfs support for net devices. I was mainly referring to if we started to filter it out to isalnum() - spaces/tab/CR etc. certainly could be filtered. (No idea what would happen with unicode nbsp or other silly things.) Bill How just restrictiting to !isspace() - 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: time stamps of skb packets in NF_HOOKS callbacks
Evgeniy, Thnks, I appreciate your (quick) answer; Following your answer I tried adding a call to net_enable_timestamp() in a module I wrote which use NF_HOOKS. This is what is done , for example, in ipq_rcv_skb(struct sk_buff *skb) in linux-2.6.14 in net/ipv4/netfilter/ip_queue.c. After doing so I get timestamps which are not 0. what I wonder now is : 1) does this have ANY performance implication (when dealing with a high network load which can get to 50,000 packets per second? 2) It does work as I said, but I want to be cautios: Am I permitted to add this method ? are there any implications for adding this method which can create troubles ? I must say that I am NOT On 8/17/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: On Thu, Aug 17, 2006 at 05:37:15PM +0300, John Que ([EMAIL PROTECTED]) wrote: > Hello, > I am using NF_HOOKS (a "PRE_ROUTING" hook). > When I try to print the time stamps (sec and usec) of skb packets > which I recieve > in the hook callback I get 0. Other skb fileds are correct. > According to my understanding, the time stamp should be updated > when the packet is received. Isn't it so ? Any idea why am I getting > "0" for tstamp fields (tstamp is a field in sk_buff and is an intance > of skb_timeval). Timestamps are disabled by default, if you have sockets which enable SO_TIMESTAMP or netfilter queue target and other agents which can enable it, you will see updated values in skb->tstamp. -- Evgeniy Polyakov - 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: time stamps of skb packets in NF_HOOKS callbacks
Evgeniy, Sorry ! ; last sentence in my reply was chopped so here is my message again with this last sentence (complete this time) Thnks, I appreciate your (quick) answer; Following your answer I tried adding a call to net_enable_timestamp() in a module I wrote which use NF_HOOKS. This is what is done , for example, in ipq_rcv_skb(struct sk_buff *skb) in linux-2.6.14 in net/ipv4/netfilter/ip_queue.c. After doing so I get timestamps which are not 0. what I wonder now is : 1) does this have ANY performance implication (when dealing with a high network load which can get to 50,000 packets per second? 2) It does work as I said, but I want to be cautios: Am I permitted to add this method ? are there any implications for adding this method which can create troubles ? I must say that I am NOT changing anywhere the timestamp; it's only for statistics. Regards, John On 8/17/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: On Thu, Aug 17, 2006 at 05:37:15PM +0300, John Que ([EMAIL PROTECTED]) wrote: > Hello, > I am using NF_HOOKS (a "PRE_ROUTING" hook). > When I try to print the time stamps (sec and usec) of skb packets > which I recieve > in the hook callback I get 0. Other skb fileds are correct. > According to my understanding, the time stamp should be updated > when the packet is received. Isn't it so ? Any idea why am I getting > "0" for tstamp fields (tstamp is a field in sk_buff and is an intance > of skb_timeval). Timestamps are disabled by default, if you have sockets which enable SO_TIMESTAMP or netfilter queue target and other agents which can enable it, you will see updated values in skb->tstamp. -- Evgeniy Polyakov - 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: crash in ipt_do_table
David Miller wrote: > From: Patrick McHardy <[EMAIL PROTECTED]> > Date: Tue, 15 Aug 2006 16:01:06 +0200 > > >>Any chance you're also changing your ruleset dynamically? If yes >>this patch might help. > > > I've applied this. Thanks, but it seems you applied the first patch I sent, which was missing the same fix for arp_tables. This patch contains the missing bits. I'm going to send the (combined) patch to -stable as well, this bug seems to have hit quite a few people. [NETFILTER]: arp_tables: fix table locking in arpt_do_table table->private might change because of ruleset changes, don't use it without holding the lock. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit 338fe5c67e8fb799c9e3470331db6f3c60a31b1e tree 2dc15d63244ed18a8035ae483ae2d722e7fbcf62 parent 32ce9bc41528c327b1353713b2108d2213128dee author Patrick McHardy <[EMAIL PROTECTED]> Tue, 15 Aug 2006 16:06:57 +0200 committer Patrick McHardy <[EMAIL PROTECTED]> Tue, 15 Aug 2006 16:06:57 +0200 net/ipv4/netfilter/arp_tables.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c index df4854c..8d1d7a6 100644 --- a/net/ipv4/netfilter/arp_tables.c +++ b/net/ipv4/netfilter/arp_tables.c @@ -236,7 +236,7 @@ unsigned int arpt_do_table(struct sk_buf struct arpt_entry *e, *back; const char *indev, *outdev; void *table_base; - struct xt_table_info *private = table->private; + struct xt_table_info *private; /* ARP header, plus 2 device addresses, plus 2 IP addresses. */ if (!pskb_may_pull((*pskb), (sizeof(struct arphdr) + @@ -248,6 +248,7 @@ unsigned int arpt_do_table(struct sk_buf outdev = out ? out->name : nulldevname; read_lock_bh(&table->lock); + private = table->private; table_base = (void *)private->entries[smp_processor_id()]; e = get_entry(table_base, private->hook_entry[hook]); back = get_entry(table_base, private->underflow[hook]);
Re: crash in ipt_do_table
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Fri, 18 Aug 2006 07:45:59 +0200 > Thanks, but it seems you applied the first patch I sent, which was > missing the same fix for arp_tables. This patch contains the missing > bits. > > I'm going to send the (combined) patch to -stable as well, this bug > seems to have hit quite a few people. I just sent a round of patches to Greg for his 2.6.18 tree, which included the first part, so I'll push this second part to him next. Feel free to queue the whole thing up for -stable, thanks a lot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ip1000: update maintainer information
Hi Pekka: OK, I will generate a patch from to your git. And add sign-off-by in the mail. Thanks for that. Jesse Huang - Original Message - From: "Pekka Enberg" <[EMAIL PROTECTED]> To: "Jesse Huang" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ; ; <[EMAIL PROTECTED]> Sent: Thursday, August 17, 2006 4:26 PM Subject: Re: [PATCH 1/7] ip1000: update maintainer information The patches are missing signed-off-by so please resend. I am starting my vacation on friday so I suggest you send the whole driver as a patch for review at netdev@vger.kernel.org for inclusion. I can apply your patches to git://git.kernel.org/pub/scm/linux/kernel/git/penberg/netdev-ipg-2.6.git if you want, though. Only the first three patches apply and everything starting from "ipg_config_autoneg rewrite' fail. Pekka - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] IP100A, add end of pci id table
Hi Jeff:
Sorry for that. I will remove those. Am I need to resent all of those
patch or send all in one patch?
Jesse Huang.
- Original Message -
From: "Jeff Garzik" <[EMAIL PROTECTED]>
To: "Jesse Huang" <[EMAIL PROTECTED]>
Cc: ; ;
<[EMAIL PROTECTED]>
Sent: Thursday, August 17, 2006 10:45 PM
Subject: Re: [PATCH 1/6] IP100A, add end of pci id table
Jesse Huang wrote:
> @@ -212,7 +212,7 @@ static const struct pci_device_id sundan
> { 0x1186, 0x1002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4 },
> { 0x13F0, 0x0201, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5 },
> { 0x13F0, 0x0200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 6 },
> - { }
> + { 0,}
> };
> MODULE_DEVICE_TABLE(pci, sundance_pci_tbl);
>
> @@ -231,7 +231,7 @@ static const struct pci_id_info pci_id_t
> {"D-Link DL10050-based FAST Ethernet Adapter"},
> {"Sundance Technology Alta"},
> {"IC Plus Corporation IP100A FAST Ethernet Adapter"},
> - { } /* terminate list. */
> + { NULL,} /* terminate list. */
NAK.
An empty array element "{ }" implies NULL. It is the kernel standard to
prefer "{ }" over an explicit initialization. Looks cleaner.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: restrict device names from having whitespace
Don't allow spaces in network device names because it makes
it difficult to provide text interfaces via sysfs.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/core/dev.c | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d95e262..56c8afb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -79,6 +79,7 @@ #include
#include
#include
#include
+#include
#include
#include
#include
@@ -636,10 +637,25 @@ struct net_device * dev_get_by_flags(uns
*/
int dev_valid_name(const char *name)
{
- return !(*name == '\0'
-|| !strcmp(name, ".")
-|| !strcmp(name, "..")
-|| strchr(name, '/'));
+ if (*name == '\0') /* null string */
+ return 0;
+
+ if (*name == '.') {
+ if (name[1] == '\0')/* can't have . in directory */
+ return 0;
+ if (name[1] == '.' && name[2] == '\0')
+ return 0; /* or .. */
+ }
+
+ /* Check for blanks and slash because it confuses sysfs interfaces */
+ do {
+ if (*name == '/')
+ return 0;
+ if (isspace(*name))
+ return 0;
+ } while (*++name);
+
+ return 1;
}
/**
--
1.4.0
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
On Thu, 17 Aug 2006 16:53:01 -0700 Daniel Phillips <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >>What happened to the case where we just fill memory full of dirty file > >>pages backed by a remote disk? > > > > Processes which are dirtying those pages throttle at > > /proc/sys/vm/dirty_ratio% of memory dirty. So it is not possible to "fill" > > memory with dirty pages. If the amount of physical memory which is dirty > > exceeds 40%: bug. > > Hi Andrew, > > So we make 400 MB of a 1 GB system by default - it's runtime configurable. > unavailable for write caching just to > get around the network receive starvation issue? No, it's mainly to avoid latency: to prevent tasks which want to allocate pages from getting stuck behind writeback. > What happens if some in kernel user grabs 68% of kernel memory to do some > very important thing, does this starvation avoidance scheme still work? Well something has to give way. The process might get swapped out a bit, or it might stall in the page allocator because of all the dirty memory. - 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 5/6] IP100A correct init and close step
Hi Jeff: (1)Should I change to : spin_lock_irqsave(&np->lock,flags); reset_tx(dev); spin_lock_irqrestore(&np->lock,flags); (2)I will remove date and author information out of source code comment. - Original Message - From: "Jeff Garzik" <[EMAIL PROTECTED]> To: "Jesse Huang" <[EMAIL PROTECTED]> Cc: ; ; <[EMAIL PROTECTED]> Sent: Thursday, August 17, 2006 10:51 PM Subject: Re: [PATCH 5/6] IP100A correct init and close step Jesse Huang wrote: > From: Jesse Huang <[EMAIL PROTECTED]> > > correct init and close step > > Change Logs: > correct init and close step > > --- > > drivers/net/sundance.c | 10 +- > 1 files changed, 9 insertions(+), 1 deletions(-) > > b5e343a17f5d70d1cc9a4ba20d366bab355f64a6 > diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c > index f63871a..c7c22f0 100755 > --- a/drivers/net/sundance.c > +++ b/drivers/net/sundance.c > @@ -830,6 +830,11 @@ #endif > iowrite8(0x01, ioaddr + DebugCtrl1); > netif_start_queue(dev); > > + // 04/19/2005 Jesse fix for complete initial step > + spin_lock(&np->lock); > + reset_tx(dev); > + spin_unlock(&np->lock); > + NAK -- ineffective locking. If you need locking here, you must use spin_lock_irqsave() > @@ -1654,7 +1659,10 @@ static int netdev_close(struct net_devic > > /* Disable interrupts by clearing the interrupt mask. */ > iowrite16(0x, ioaddr + IntrEnable); > - > + > + // 04/19/2005 Jesse fix for complete initial step > + writew(0x500, ioaddr + DMACtrl); NAK: 1) date and author information is already present in the kernel changelog. It should not be present in the source code. 2) The comment (or patch description) fails to describe -why- this change is needed. It only described what is being changes, which is already obvious from reading the source 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 1/6] IP100A, add end of pci id table
Hi Alexey:
I will remove that. Thanks for that.
Jesse Huang
- Original Message -
From: "Alexey Dobriyan" <[EMAIL PROTECTED]>
To: "Jesse Huang" <[EMAIL PROTECTED]>
Cc: ; ;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, August 17, 2006 11:19 PM
Subject: Re: [PATCH 1/6] IP100A, add end of pci id table
On Thu, Aug 17, 2006 at 03:00:47PM -0400, Jesse Huang wrote:
> Add "0," and "NULL," to sundance_pci_tbl and pci_id_table.
> @@ -212,7 +212,7 @@ static const struct pci_device_id sundan
> { 0x1186, 0x1002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4 },
> { 0x13F0, 0x0201, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5 },
> { 0x13F0, 0x0200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 6 },
> - { }
> + { 0,}
> };
> MODULE_DEVICE_TABLE(pci, sundance_pci_tbl);
>
> @@ -231,7 +231,7 @@ static const struct pci_id_info pci_id_t
> {"D-Link DL10050-based FAST Ethernet Adapter"},
> {"Sundance Technology Alta"},
> {"IC Plus Corporation IP100A FAST Ethernet Adapter"},
> - { } /* terminate list. */
> + { NULL,} /* terminate list. */
They are already properly terminated. You don't have to do anything.
-
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/7] ip1000: remove some default phy params
Hi David: Ok, I will add sign-off-by latter. Thanks for that. Jesse Huang - Original Message - From: "David Gomez" <[EMAIL PROTECTED]> To: "Jesse Huang" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ; Sent: Thursday, August 17, 2006 7:09 PM Subject: Re: [PATCH 2/7] ip1000: remove some default phy params Hi Jesse, On Aug 17 at 03:43:29, Jesse Huang wrote: > From: Jesse Huang <[EMAIL PROTECTED]> > > remove some default phy params > > Change Logs: > remove some default phy params First, thanks for finalling commiting this driver ;). But please resend the patches with "Signed-off-by:" line. I'm not much of a git hacker, but i think you can use 'git-applymbox' to put a signedoff line in your mbox-formatted patches. regards, -- David Gomez Jabber ID: [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] net: restrict device names from having whitespace
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 17 Aug 2006 23:11:27 -0700 > Don't allow spaces in network device names because it makes > it difficult to provide text interfaces via sysfs. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> I have a patch which does this in my tree already Stephen. - 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] d80211 LED handling
On Thu, 2006-08-17 at 17:30 +0200, Jiri Benc wrote: > How is the driver supposed to add its led handlers? The driver just adds an LED device. And then we only need to set the default trigger correctly. > Using generic led triggers is probably interesting for cases when system > has some separate led. It won't help drivers which need to handle leds > on the card itself. In the former case you may want all of wireless > cards in the system to be connected to one led. I don't see how this is > easily possible with this patch. No, that's not possible at all. But we could have a generic 'd80211-all-cards' trigger I suppose. > In the latter case, you want to call > callback provided by the driver and not to use generic led triggers at > all. Why not use the generic trigger anyway? With the right default... > > [...] > > +config D80211_LEDS > > + bool "Enable LED triggers" > > + select LEDS_TRIGGERS > > Is it really necessary to have this as a configurable option? Probably not. > > [...] > > + name = (char*) local->rx_led+1; > > This doesn't seem correct. Hm, yeah, it probably needs to be (char*) (local->rx_led+1). > > + snprintf(name, IFNAMSIZ + 2, "%srx", local->mdev->name); > > Name of interface may change at any time. Using it for fixed identifier > is not a good idea. In addition, nothing prevents you from ending up > with two different led triggers with the same name: > > 1. modprobe card1 > 2. ieee80211_led_init(card1) <- card1 is "wmaster0" > 3. ip link set wmaster0 name mysupercard > 4. modprobe card2 > 5. ieee80211_led_init(card2) <- card2 is "wmaster0" Good point. I guess we'll want to have the wiphy in there instead. 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
