* [net-next 07/10] hamachi/yellowfin: Move the packet engine drivers
From: Jeff Kirsher @ 2011-08-12 10:52 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann, Donald Becker
In-Reply-To: <1313146371-6562-1-git-send-email-jeffrey.t.kirsher@intel.com>
Move the packet engine drivers to drivers/net/ethernet/packetengines/
and the necessary Kconfig and Makefile changes.
CC: Donald Becker <becker@scyld.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/Kconfig | 26 -----------
drivers/net/Makefile | 2 -
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/packetengines/Kconfig | 46 ++++++++++++++++++++
drivers/net/ethernet/packetengines/Makefile | 6 +++
drivers/net/{ => ethernet/packetengines}/hamachi.c | 0
.../net/{ => ethernet/packetengines}/yellowfin.c | 0
8 files changed, 54 insertions(+), 28 deletions(-)
create mode 100644 drivers/net/ethernet/packetengines/Kconfig
create mode 100644 drivers/net/ethernet/packetengines/Makefile
rename drivers/net/{ => ethernet/packetengines}/hamachi.c (100%)
rename drivers/net/{ => ethernet/packetengines}/yellowfin.c (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e8d65fe..99b209e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -541,32 +541,6 @@ config IP1000
To compile this driver as a module, choose M here: the module
will be called ipg. This is recommended.
-config HAMACHI
- tristate "Packet Engines Hamachi GNIC-II support"
- depends on PCI
- select MII
- help
- If you have a Gigabit Ethernet card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as a module, choose M here. The module will be
- called hamachi.
-
-config YELLOWFIN
- tristate "Packet Engines Yellowfin Gigabit-NIC support (EXPERIMENTAL)"
- depends on PCI && EXPERIMENTAL
- select CRC32
- ---help---
- Say Y here if you have a Packet Engines G-NIC PCI Gigabit Ethernet
- adapter or the SYM53C885 Ethernet controller. The Gigabit adapter is
- used by the Beowulf Linux cluster project. See
- <http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html> for more
- information about this driver in particular and Beowulf in general.
-
- To compile this driver as a module, choose M here: the module
- will be called yellowfin. This is recommended.
-
config XILINX_LL_TEMAC
tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"
depends on PPC || MICROBLAZE
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 96112dd..d8c286e 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -19,7 +19,6 @@ obj-$(CONFIG_PLIP) += plip.o
obj-$(CONFIG_ROADRUNNER) += rrunner.o
obj-$(CONFIG_R6040) += r6040.o
-obj-$(CONFIG_YELLOWFIN) += yellowfin.o
obj-$(CONFIG_FEALNX) += fealnx.o
obj-$(CONFIG_SKFP) += skfp/
obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o
@@ -30,7 +29,6 @@ obj-$(CONFIG_SH_ETH) += sh_eth.o
# end link order section
#
-obj-$(CONFIG_HAMACHI) += hamachi.o
obj-$(CONFIG_NET) += Space.o loopback.o
obj-$(CONFIG_NET_SB1000) += sb1000.o
obj-$(CONFIG_HP100) += hp100.o
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 3983e70..140dd73 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -39,6 +39,7 @@ source "drivers/net/ethernet/natsemi/Kconfig"
source "drivers/net/ethernet/8390/Kconfig"
source "drivers/net/ethernet/nuvoton/Kconfig"
source "drivers/net/ethernet/oki-semi/Kconfig"
+source "drivers/net/ethernet/packetengines/Kconfig"
source "drivers/net/ethernet/pasemi/Kconfig"
source "drivers/net/ethernet/qlogic/Kconfig"
source "drivers/net/ethernet/racal/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 873d275..8a97b19 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
obj-$(CONFIG_NET_VENDOR_NUVOTON) += nuvoton/
obj-$(CONFIG_NET_VENDOR_OKI) += oki-semi/
+obj-$(CONFIG_NET_PACKET_ENGINE) += packetengines/
obj-$(CONFIG_NET_VENDOR_PASEMI) += pasemi/
obj-$(CONFIG_NET_VENDOR_QLOGIC) += qlogic/
obj-$(CONFIG_NET_VENDOR_RACAL) += racal/
diff --git a/drivers/net/ethernet/packetengines/Kconfig b/drivers/net/ethernet/packetengines/Kconfig
new file mode 100644
index 0000000..4add1db
--- /dev/null
+++ b/drivers/net/ethernet/packetengines/Kconfig
@@ -0,0 +1,46 @@
+#
+# Packet engine device configuration
+#
+
+config NET_PACKET_ENGINE
+ bool "Packet Engine devices"
+ depends on PCI
+ ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y
+ and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about packet engine devices. If you say Y, you will
+ be asked for your specific card in the following questions.
+
+if NET_PACKET_ENGINE
+
+config HAMACHI
+ tristate "Packet Engines Hamachi GNIC-II support"
+ depends on PCI
+ select MII
+ ---help---
+ If you have a Gigabit Ethernet card of this type, say Y and read
+ the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ To compile this driver as a module, choose M here. The module will be
+ called hamachi.
+
+config YELLOWFIN
+ tristate "Packet Engines Yellowfin Gigabit-NIC support (EXPERIMENTAL)"
+ depends on PCI && EXPERIMENTAL
+ select CRC32
+ ---help---
+ Say Y here if you have a Packet Engines G-NIC PCI Gigabit Ethernet
+ adapter or the SYM53C885 Ethernet controller. The Gigabit adapter is
+ used by the Beowulf Linux cluster project. See
+ <http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html> for more
+ information about this driver in particular and Beowulf in general.
+
+ To compile this driver as a module, choose M here: the module
+ will be called yellowfin. This is recommended.
+
+endif # NET_PACKET_ENGINE
diff --git a/drivers/net/ethernet/packetengines/Makefile b/drivers/net/ethernet/packetengines/Makefile
new file mode 100644
index 0000000..995ccd0
--- /dev/null
+++ b/drivers/net/ethernet/packetengines/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for the Packet Engine network device drivers.
+#
+
+obj-$(CONFIG_HAMACHI) += hamachi.o
+obj-$(CONFIG_YELLOWFIN) += yellowfin.o
diff --git a/drivers/net/hamachi.c b/drivers/net/ethernet/packetengines/hamachi.c
similarity index 100%
rename from drivers/net/hamachi.c
rename to drivers/net/ethernet/packetengines/hamachi.c
diff --git a/drivers/net/yellowfin.c b/drivers/net/ethernet/packetengines/yellowfin.c
similarity index 100%
rename from drivers/net/yellowfin.c
rename to drivers/net/ethernet/packetengines/yellowfin.c
--
1.7.6
^ permalink raw reply related
* [net-next 08/10] octeon: Move the Cavium driver
From: Jeff Kirsher @ 2011-08-12 10:52 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann, David Daney
In-Reply-To: <1313146371-6562-1-git-send-email-jeffrey.t.kirsher@intel.com>
Move the Cavium driver to drivers/net/ethernet/octeon/ and
make the necessary Kconfig and Makefile changes.
CC: David Daney <david.daney@cavium.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: David Daney <david.daney@cavium.com>
---
drivers/net/Kconfig | 2 --
drivers/net/Makefile | 1 -
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/{ => ethernet}/octeon/Kconfig | 6 +++++-
drivers/net/ethernet/octeon/Makefile | 5 +++++
drivers/net/{ => ethernet}/octeon/octeon_mgmt.c | 0
drivers/net/octeon/Makefile | 2 --
8 files changed, 12 insertions(+), 6 deletions(-)
rename drivers/net/{ => ethernet}/octeon/Kconfig (85%)
create mode 100644 drivers/net/ethernet/octeon/Makefile
rename drivers/net/{ => ethernet}/octeon/octeon_mgmt.c (100%)
delete mode 100644 drivers/net/octeon/Makefile
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 99b209e..b896621 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -506,8 +506,6 @@ config LANTIQ_ETOP
help
Support for the MII0 inside the Lantiq SoC
-source "drivers/net/octeon/Kconfig"
-
endif # NET_ETHERNET
#
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d8c286e..648fa5c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -105,5 +105,4 @@ obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
obj-$(CONFIG_WIMAX) += wimax/
obj-$(CONFIG_CAIF) += caif/
-obj-$(CONFIG_OCTEON_MGMT_ETHERNET) += octeon/
obj-$(CONFIG_TILE_NET) += tile/
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 140dd73..70c60ef 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -38,6 +38,7 @@ source "drivers/net/ethernet/myricom/Kconfig"
source "drivers/net/ethernet/natsemi/Kconfig"
source "drivers/net/ethernet/8390/Kconfig"
source "drivers/net/ethernet/nuvoton/Kconfig"
+source "drivers/net/ethernet/octeon/Kconfig"
source "drivers/net/ethernet/oki-semi/Kconfig"
source "drivers/net/ethernet/packetengines/Kconfig"
source "drivers/net/ethernet/pasemi/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8a97b19..929ee29 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_NET_VENDOR_MICREL) += micrel/
obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
obj-$(CONFIG_NET_VENDOR_NUVOTON) += nuvoton/
+obj-$(CONFIG_OCTEON_MGMT_ETHERNET) += octeon/
obj-$(CONFIG_NET_VENDOR_OKI) += oki-semi/
obj-$(CONFIG_NET_PACKET_ENGINE) += packetengines/
obj-$(CONFIG_NET_VENDOR_PASEMI) += pasemi/
diff --git a/drivers/net/octeon/Kconfig b/drivers/net/ethernet/octeon/Kconfig
similarity index 85%
rename from drivers/net/octeon/Kconfig
rename to drivers/net/ethernet/octeon/Kconfig
index 1e56bbf..3de52ff 100644
--- a/drivers/net/octeon/Kconfig
+++ b/drivers/net/ethernet/octeon/Kconfig
@@ -1,10 +1,14 @@
+#
+# Cavium network device configuration
+#
+
config OCTEON_MGMT_ETHERNET
tristate "Octeon Management port ethernet driver (CN5XXX, CN6XXX)"
depends on CPU_CAVIUM_OCTEON
select PHYLIB
select MDIO_OCTEON
default y
- help
+ ---help---
This option enables the ethernet driver for the management
port on Cavium Networks' Octeon CN57XX, CN56XX, CN55XX,
CN54XX, CN52XX, and CN6XXX chips.
diff --git a/drivers/net/ethernet/octeon/Makefile b/drivers/net/ethernet/octeon/Makefile
new file mode 100644
index 0000000..efa41c1
--- /dev/null
+++ b/drivers/net/ethernet/octeon/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Cavium network device drivers.
+#
+
+obj-$(CONFIG_OCTEON_MGMT_ETHERNET) += octeon_mgmt.o
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
similarity index 100%
rename from drivers/net/octeon/octeon_mgmt.c
rename to drivers/net/ethernet/octeon/octeon_mgmt.c
diff --git a/drivers/net/octeon/Makefile b/drivers/net/octeon/Makefile
deleted file mode 100644
index 906edec..0000000
--- a/drivers/net/octeon/Makefile
+++ /dev/null
@@ -1,2 +0,0 @@
-
-obj-$(CONFIG_OCTEON_MGMT_ETHERNET) += octeon_mgmt.o
--
1.7.6
^ permalink raw reply related
* [net-next 09/10] jme: Move the JME driver
From: Jeff Kirsher @ 2011-08-12 10:52 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann, Guo-Fu Tseng
In-Reply-To: <1313146371-6562-1-git-send-email-jeffrey.t.kirsher@intel.com>
Move the JME driver into drivers/net/ethernet/ and make the
necessary Kconfig and Makefile changes.
CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
MAINTAINERS | 2 +-
drivers/net/Kconfig | 12 ------------
drivers/net/Makefile | 1 -
drivers/net/ethernet/Kconfig | 13 +++++++++++++
drivers/net/ethernet/Makefile | 1 +
drivers/net/{ => ethernet}/jme.c | 0
drivers/net/{ => ethernet}/jme.h | 0
7 files changed, 15 insertions(+), 14 deletions(-)
rename drivers/net/{ => ethernet}/jme.c (100%)
rename drivers/net/{ => ethernet}/jme.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 622f4fc..37cbe14 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3591,7 +3591,7 @@ JME NETWORK DRIVER
M: Guo-Fu Tseng <cooldavid@cooldavid.org>
L: netdev@vger.kernel.org
S: Maintained
-F: drivers/net/jme.*
+F: drivers/net/ethernet/jme.*
JOURNALLING FLASH FILE SYSTEM V2 (JFFS2)
M: David Woodhouse <dwmw2@infradead.org>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b896621..996bae0 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -547,18 +547,6 @@ config XILINX_LL_TEMAC
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
-config JME
- tristate "JMicron(R) PCI-Express Gigabit Ethernet support"
- depends on PCI
- select CRC32
- select MII
- ---help---
- This driver supports the PCI-Express gigabit ethernet adapters
- based on JMicron JMC250 chipset.
-
- To compile this driver as a module, choose M here. The module
- will be called jme.
-
endif # NETDEV_1000
#
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 648fa5c..271fc52 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_PHYLIB) += phy/
obj-$(CONFIG_IP1000) += ipg.o
obj-$(CONFIG_CAN) += can/
obj-$(CONFIG_BONDING) += bonding/
-obj-$(CONFIG_JME) += jme.o
obj-$(CONFIG_VMXNET3) += vmxnet3/
#
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 70c60ef..c29c145 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -31,6 +31,19 @@ source "drivers/net/ethernet/ibm/Kconfig"
source "drivers/net/ethernet/intel/Kconfig"
source "drivers/net/ethernet/i825xx/Kconfig"
source "drivers/net/ethernet/xscale/Kconfig"
+
+config JME
+ tristate "JMicron(R) PCI-Express Gigabit Ethernet support"
+ depends on PCI
+ select CRC32
+ select MII
+ ---help---
+ This driver supports the PCI-Express gigabit ethernet adapters
+ based on JMicron JMC250 chipset.
+
+ To compile this driver as a module, choose M here. The module
+ will be called jme.
+
source "drivers/net/ethernet/marvell/Kconfig"
source "drivers/net/ethernet/mellanox/Kconfig"
source "drivers/net/ethernet/micrel/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 929ee29..8495c50 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_NET_VENDOR_IBM) += ibm/
obj-$(CONFIG_NET_VENDOR_INTEL) += intel/
obj-$(CONFIG_NET_VENDOR_I825XX) += i825xx/
obj-$(CONFIG_NET_VENDOR_XSCALE) += xscale/
+obj-$(CONFIG_JME) += jme.o
obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
obj-$(CONFIG_NET_VENDOR_MICREL) += micrel/
diff --git a/drivers/net/jme.c b/drivers/net/ethernet/jme.c
similarity index 100%
rename from drivers/net/jme.c
rename to drivers/net/ethernet/jme.c
diff --git a/drivers/net/jme.h b/drivers/net/ethernet/jme.h
similarity index 100%
rename from drivers/net/jme.h
rename to drivers/net/ethernet/jme.h
--
1.7.6
^ permalink raw reply related
* [net-next 10/10] xilinx/ll_temac: Move the Xilinx drivers
From: Jeff Kirsher @ 2011-08-12 10:52 UTC (permalink / raw)
To: davem
Cc: Jeff Kirsher, netdev, gospo, sassmann, John Williams,
David H. Lynch Jr.
In-Reply-To: <1313146371-6562-1-git-send-email-jeffrey.t.kirsher@intel.com>
Move the Xilinx drivers into drivers/net/ethernet/xilinx/ and
make the necessary Kconfig and Makefile changes.
CC: John Williams <john.williams@petalogix.com>
CC: "David H. Lynch Jr." <dhlii@dlasys.net>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/Kconfig | 15 --------
drivers/net/Makefile | 4 --
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/xilinx/Kconfig | 35 ++++++++++++++++++++
drivers/net/ethernet/xilinx/Makefile | 7 ++++
drivers/net/{ => ethernet/xilinx}/ll_temac.h | 0
drivers/net/{ => ethernet/xilinx}/ll_temac_main.c | 0
drivers/net/{ => ethernet/xilinx}/ll_temac_mdio.c | 0
.../net/{ => ethernet/xilinx}/xilinx_emaclite.c | 0
10 files changed, 44 insertions(+), 19 deletions(-)
create mode 100644 drivers/net/ethernet/xilinx/Kconfig
create mode 100644 drivers/net/ethernet/xilinx/Makefile
rename drivers/net/{ => ethernet/xilinx}/ll_temac.h (100%)
rename drivers/net/{ => ethernet/xilinx}/ll_temac_main.c (100%)
rename drivers/net/{ => ethernet/xilinx}/ll_temac_mdio.c (100%)
rename drivers/net/{ => ethernet/xilinx}/xilinx_emaclite.c (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 996bae0..2607a44 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -493,13 +493,6 @@ config NET_POCKET
the questions about this class of network devices. If you say Y, you
will be asked for your specific device in the following questions.
-config XILINX_EMACLITE
- tristate "Xilinx 10/100 Ethernet Lite support"
- depends on PPC32 || MICROBLAZE
- select PHYLIB
- help
- This driver supports the 10/100 Ethernet Lite from Xilinx.
-
config LANTIQ_ETOP
tristate "Lantiq SoC ETOP driver"
depends on SOC_TYPE_XWAY
@@ -539,14 +532,6 @@ config IP1000
To compile this driver as a module, choose M here: the module
will be called ipg. This is recommended.
-config XILINX_LL_TEMAC
- tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"
- depends on PPC || MICROBLAZE
- select PHYLIB
- help
- This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
- core used in Xilinx Spartan and Virtex FPGAs
-
endif # NETDEV_1000
#
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 271fc52..4c7af02 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -33,10 +33,6 @@ obj-$(CONFIG_NET_SB1000) += sb1000.o
obj-$(CONFIG_HP100) += hp100.o
obj-$(CONFIG_FORCEDETH) += forcedeth.o
-ll_temac-objs := ll_temac_main.o ll_temac_mdio.o
-obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o
-obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
-
obj-$(CONFIG_PPP) += ppp_generic.o
obj-$(CONFIG_PPP_ASYNC) += ppp_async.o
obj-$(CONFIG_PPP_SYNC_TTY) += ppp_synctty.o
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index c29c145..922f4d1 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -82,5 +82,6 @@ source "drivers/net/ethernet/ti/Kconfig"
source "drivers/net/ethernet/toshiba/Kconfig"
source "drivers/net/ethernet/tundra/Kconfig"
source "drivers/net/ethernet/via/Kconfig"
+source "drivers/net/ethernet/xilinx/Kconfig"
endif # ETHERNET
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8495c50..fcecd5f 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -50,3 +50,4 @@ obj-$(CONFIG_NET_VENDOR_TI) += ti/
obj-$(CONFIG_NET_VENDOR_TOSHIBA) += toshiba/
obj-$(CONFIG_NET_VENDOR_TUNDRA) += tundra/
obj-$(CONFIG_NET_VENDOR_VIA) += via/
+obj-$(CONFIG_NET_VENDOR_XILINX) += xilinx/
diff --git a/drivers/net/ethernet/xilinx/Kconfig b/drivers/net/ethernet/xilinx/Kconfig
new file mode 100644
index 0000000..4e3aad4
--- /dev/null
+++ b/drivers/net/ethernet/xilinx/Kconfig
@@ -0,0 +1,35 @@
+#
+# Xilink device configuration
+#
+
+config NET_VENDOR_XILINX
+ bool "Xilinx devices"
+ depends on PPC || PPC32 || MICROBLAZE
+ ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y
+ and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about Xilinx devices. If you say Y, you will be asked
+ for your specific card in the following questions.
+
+if NET_VENDOR_XILINX
+
+config XILINX_EMACLITE
+ tristate "Xilinx 10/100 Ethernet Lite support"
+ depends on (PPC32 || MICROBLAZE)
+ select PHYLIB
+ ---help---
+ This driver supports the 10/100 Ethernet Lite from Xilinx.
+
+config XILINX_LL_TEMAC
+ tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"
+ depends on (PPC || MICROBLAZE)
+ select PHYLIB
+ ---help---
+ This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
+ core used in Xilinx Spartan and Virtex FPGAs
+
+endif # NET_VENDOR_XILINX
diff --git a/drivers/net/ethernet/xilinx/Makefile b/drivers/net/ethernet/xilinx/Makefile
new file mode 100644
index 0000000..5feac73
--- /dev/null
+++ b/drivers/net/ethernet/xilinx/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the Xilink network device drivers.
+#
+
+ll_temac-objs := ll_temac_main.o ll_temac_mdio.o
+obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o
+obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
diff --git a/drivers/net/ll_temac.h b/drivers/net/ethernet/xilinx/ll_temac.h
similarity index 100%
rename from drivers/net/ll_temac.h
rename to drivers/net/ethernet/xilinx/ll_temac.h
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ethernet/xilinx/ll_temac_main.c
similarity index 100%
rename from drivers/net/ll_temac_main.c
rename to drivers/net/ethernet/xilinx/ll_temac_main.c
diff --git a/drivers/net/ll_temac_mdio.c b/drivers/net/ethernet/xilinx/ll_temac_mdio.c
similarity index 100%
rename from drivers/net/ll_temac_mdio.c
rename to drivers/net/ethernet/xilinx/ll_temac_mdio.c
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
similarity index 100%
rename from drivers/net/xilinx_emaclite.c
rename to drivers/net/ethernet/xilinx/xilinx_emaclite.c
--
1.7.6
^ permalink raw reply related
* £980,000:00 Pound
From: info @ 2011-08-12 9:42 UTC (permalink / raw)
£980,000:00 Pound for more info Email: mrwilliam_garry@hotmail.com
^ permalink raw reply
* Re: [net-next 00/10] drivers/net organize Ethernet drivers (5th series)
From: David Miller @ 2011-08-12 11:35 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1313146371-6562-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 12 Aug 2011 03:52:41 -0700
> This is the fifth of seven 10 patch series to move the Ethernet
> drivers into drivers/net/ethernet/
>
> The following are changes since commit 4c78893b3d107e2a053c8f51c526510857c09858:
> cnic: Fix select dependencies in bnx2fc/bnx2i Kconfig.
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/next-organize master
Pulled, thanks Jeff.
^ permalink raw reply
* bridge: accept bridge own MAC address as local
From: Ulrich Weber @ 2011-08-12 11:30 UTC (permalink / raw)
To: davem; +Cc: netdev
bridge: accept bridge own MAC address as local
if MAC address of bridge is manually set (BR_SET_MAC_ADDR). Otherwise
only MAC addresses of bridge members will work if manually set.
Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
---
net/bridge/br_input.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f06ee39..3adabe3 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -93,7 +93,9 @@ int br_handle_frame_finish(struct sk_buff *skb)
skb2 = skb;
br->dev->stats.multicast++;
- } else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
+ } else if ((br->flags & BR_SET_MAC_ADDR &&
+ !compare_ether_addr(br->bridge_id.addr, dest)) ||
+ ((dst = __br_fdb_get(br, dest)) && dst->is_local)) {
skb2 = skb;
/* Do not forward the packet since it's local. */
skb = NULL;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] Proportional Rate Reduction for TCP.
From: Ilpo Järvinen @ 2011-08-12 11:36 UTC (permalink / raw)
To: Nandita Dukkipati
Cc: David S. Miller, Netdev, Tom Herbert, Yuchung Cheng, Matt Mathis
In-Reply-To: <1313134197-5082-1-git-send-email-nanditad@google.com>
> This patch implements Proportional Rate Reduction (PRR) for TCP.
> PRR is an algorithm that determines TCP's sending rate in fast
> recovery. PRR avoids excessive window reductions and aims for
> the actual congestion window size at the end of recovery to be as
> close as possible to the window determined by the congestion control
> algorithm. PRR also improves accuracy of the amount of data sent
> during loss recovery.
>
> The patch implements the recommended flavor of PRR called PRR-SSRB
> (Proportional rate reduction with slow start reduction bound) and
> replaces the existing rate halving algorithm. PRR improves upon the
> existing Linux fast recovery under a number of conditions including:
> 1) burst losses where the losses implicitly reduce the amount of
> outstanding data (pipe) below the ssthresh value selected by the
> congestion control algorithm and,
> 2) losses near the end of short flows where application runs out of
> data to send.
>
> As an example, with the existing rate halving implementation a single
> loss event can cause a connection carrying short Web transactions to
> go into the slow start mode after the recovery. This is because during
> recovery Linux pulls the congestion window down to packets_in_flight+1
> on every ACK. A short Web response often runs out of new data to send
> and its pipe reduces to zero by the end of recovery when all its packets
> are drained from the network. Subsequent HTTP responses using the same
> connection will have to slow start to raise cwnd to ssthresh. PRR on
> the other hand aims for the cwnd to be as close as possible to ssthresh
> by the end of recovery.
>
> A description of PRR and a discussion of its performance can be found at
> the following links:
> - IETF Draft:
> http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
> - IETF Slides:
> http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
> http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
> - Paper to appear in Internet Measurements Conference (IMC) 2011:
> Improving TCP Loss Recovery
> Nandita Dukkipati, Matt Mathis, Yuchung Cheng
>
> Signed-off-by: Nandita Dukkipati <nanditad@google.com>
> ---
> include/linux/tcp.h | 4 +++
> net/ipv4/tcp_input.c | 63 ++++++++++++++++++++++++++++++++++++++++++++----
> net/ipv4/tcp_output.c | 7 ++++-
> 3 files changed, 67 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index 531ede8..dda4f2e1 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -379,6 +379,10 @@ struct tcp_sock {
> u32 snd_cwnd_clamp; /* Do not allow snd_cwnd to grow above this */
> u32 snd_cwnd_used;
> u32 snd_cwnd_stamp;
> + u32 prr_cwnd; /* Congestion window at start of Recovery. */
> + u32 prr_delivered; /* Number of newly delivered packets to
> + * receiver in Recovery. */
> + u32 prr_out; /* Total number of pkts sent during Recovery. */
>
> u32 rcv_wnd; /* Current receiver window */
> u32 write_seq; /* Tail(+1) of data held in tcp send buffer */
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index ea0d218..601eff0 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -2830,9 +2830,14 @@ static int tcp_try_undo_loss(struct sock *sk)
> static inline void tcp_complete_cwr(struct sock *sk)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> - /* Do not moderate cwnd if it's already undone in cwr or recovery */
> - if (tp->undo_marker && tp->snd_cwnd > tp->snd_ssthresh) {
> - tp->snd_cwnd = tp->snd_ssthresh;
> +
> + /* Do not moderate cwnd if it's already undone in cwr or recovery. */
> + if (tp->undo_marker) {
> +
> + if (inet_csk(sk)->icsk_ca_state == TCP_CA_CWR)
> + tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh);
> + else /* PRR */
> + tp->snd_cwnd = tp->snd_ssthresh;
> tp->snd_cwnd_stamp = tcp_time_stamp;
> }
> tcp_ca_event(sk, CA_EVENT_COMPLETE_CWR);
> @@ -2950,6 +2955,39 @@ void tcp_simple_retransmit(struct sock *sk)
> }
> EXPORT_SYMBOL(tcp_simple_retransmit);
>
> +/* This function implements the PRR algorithm, specifcally the PRR-SSRB
> + * (proportional rate reduction with slow start reduction bound) as described in
> + * http://www.ietf.org/id/draft-mathis-tcpm-proportional-rate-reduction-01.txt.
> + * It computes the number of packets to send (sndcnt) based on packets newly
> + * delivered:
> + * 1) If the packets in flight is larger than ssthresh, PRR spreads the
> + * cwnd reductions across a full RTT.
> + * 2) If packets in flight is lower than ssthresh (such as due to excess
> + * losses and/or application stalls), do not perform any further cwnd
> + * reductions, but instead slow start up to ssthresh.
> + */
> +static void tcp_update_cwnd_in_recovery(struct sock *sk, int pkts_delivered,
> + int fast_rexmit, int flag)
> +{
> + struct tcp_sock *tp = tcp_sk(sk);
> + int sndcnt = 0;
> + int delta = tp->snd_ssthresh - tcp_packets_in_flight(tp);
> +
> + if (tcp_packets_in_flight(tp) > tp->snd_ssthresh) {
> + if (WARN_ON(!tp->prr_cwnd))
> + tp->prr_cwnd = 1;
Thanks, this made me to smile when I realized what kind of positive feedback
loop it would cause in a heavily congested environment :-). ...Perhaps any
value below 2 * tp->snd_ssthresh isn't that safe safety relief valve here.
...Of course this condition isn't ever hit with the current code base so
no real harm being done regardless of the value.
> + sndcnt = DIV_ROUND_UP(tp->prr_delivered * tp->snd_ssthresh,
> + tp->prr_cwnd) - tp->prr_out;
What about very large windows ...overflow?
Due to not having lower bound here, the resulting window can end up below
snd_ssthresh in one step if prr_delivered suddently jumps to a value that
is above prr_cnwd?
Also, snd_ssthresh and prr_cwnd are essentially constants over the
whole recovery and yet divide is needed whole the time. ...And in practically
all cases the proportion will be 0.5 (except for the odd number produced
off-by-one thing)?
> + } else {
> + sndcnt = min_t(int, delta,
> + max_t(int, tp->prr_delivered - tp->prr_out,
> + pkts_delivered) + 1);
> + }
> +
> + sndcnt = max(sndcnt, (fast_rexmit ? 1 : 0));
> + tp->snd_cwnd = tcp_packets_in_flight(tp) + sndcnt;
> +}
> +
> /* Process an event, which can update packets-in-flight not trivially.
> * Main goal of this function is to calculate new estimate for left_out,
> * taking into account both packets sitting in receiver's buffer and
> @@ -2961,7 +2999,8 @@ EXPORT_SYMBOL(tcp_simple_retransmit);
> * It does _not_ decide what to send, it is made in function
> * tcp_xmit_retransmit_queue().
> */
> -static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
> +static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
> + int pkts_delivered, int flag)
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
> struct tcp_sock *tp = tcp_sk(sk);
> @@ -3111,13 +3150,17 @@ static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
>
> tp->bytes_acked = 0;
> tp->snd_cwnd_cnt = 0;
> + tp->prr_cwnd = tp->snd_cwnd;
prior_cwnd would make this variable about 1000 times easier to read
without requiring some background.
While at it, I realized that there is some restore window place in the
generic code that assumes "prior_cwnd == 2 * tp->snd_ssthresh" which is
not true with every single cc module.
> + tp->prr_delivered = 0;
> + tp->prr_out = 0;
> tcp_set_ca_state(sk, TCP_CA_Recovery);
> fast_rexmit = 1;
> }
>
> if (do_lost || (tcp_is_fack(tp) && tcp_head_timedout(sk)))
> tcp_update_scoreboard(sk, fast_rexmit);
> - tcp_cwnd_down(sk, flag);
> + tp->prr_delivered += pkts_delivered;
...Is here a bug in the calculation if the recovery was triggered with
_a cumulative ACK_ that had enough SACK blocks?
> + tcp_update_cwnd_in_recovery(sk, pkts_delivered, fast_rexmit, flag);
> tcp_xmit_retransmit_queue(sk);
> }
>
> @@ -3632,6 +3675,11 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
> u32 prior_in_flight;
> u32 prior_fackets;
> int prior_packets;
> + int prior_sacked = tp->sacked_out;
> + /* pkts_delivered is number of packets newly cumulatively acked or
> + * sacked on this ACK.
> + */
> + int pkts_delivered = 0;
If you need a comment like that on variable declaration, maybe its name
could be more obvious, pkts_acked_sacked ?
> int frto_cwnd = 0;
>
> /* If the ack is older than previous acks
> @@ -3703,6 +3751,9 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
> /* See if we can take anything off of the retransmit queue. */
> flag |= tcp_clean_rtx_queue(sk, prior_fackets, prior_snd_una);
> + pkts_delivered = (prior_packets - prior_sacked) -
> + (tp->packets_out - tp->sacked_out);
> +
> if (tp->frto_counter)
> frto_cwnd = tcp_process_frto(sk, flag);
> /* Guarantee sacktag reordering detection against wrap-arounds */
> @@ -3715,7 +3766,7 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
> tcp_may_raise_cwnd(sk, flag))
> tcp_cong_avoid(sk, ack, prior_in_flight);
> tcp_fastretrans_alert(sk, prior_packets - tp->packets_out,
> - flag);
> + pkts_delivered, flag);
> } else {
> if ((flag & FLAG_DATA_ACKED) && !frto_cwnd)
> tcp_cong_avoid(sk, ack, prior_in_flight);
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 882e0b0..ca50408 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1796,11 +1796,13 @@ static int tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> tcp_event_new_data_sent(sk, skb);
>
> tcp_minshall_update(tp, mss_now, skb);
> - sent_pkts++;
> + sent_pkts += tcp_skb_pcount(skb);
>
> if (push_one)
> break;
> }
> + if (inet_csk(sk)->icsk_ca_state == TCP_CA_Recovery)
> + tp->prr_out += sent_pkts;
Is there some harm done if you get rid of the conditionality?
> if (likely(sent_pkts)) {
> tcp_cwnd_validate(sk);
> @@ -2294,6 +2296,9 @@ begin_fwd:
> return;
> NET_INC_STATS_BH(sock_net(sk), mib_idx);
>
> + if (inet_csk(sk)->icsk_ca_state == TCP_CA_Recovery)
> + tp->prr_out += tcp_skb_pcount(skb);
> +
...same here?
> if (skb == tcp_write_queue_head(sk))
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
> inet_csk(sk)->icsk_rto,
Besides the points above, I'm not convinced that we really need all the
across-packet state that is present, some relevant values should be
available before we do any ACK processing (in-flight, cwnd, and more
importantly, the difference between them). ...But I haven't yet
convinced myself of anything particular.
--
i.
^ permalink raw reply
* Re: [PATCH v12 5/6] flexcan: Prefer device tree clock frequency if available.
From: Wolfgang Grandegger @ 2011-08-12 12:22 UTC (permalink / raw)
To: Robin Holt
Cc: Grant Likely, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list
In-Reply-To: <1313138752-24006-6-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On 08/12/2011 10:45 AM, Robin Holt wrote:
> If our CAN device's device tree node has a clock-frequency property,
> then use that value for the can devices clock frequency. If not, fall
> back to asking the platform/mach code for the clock frequency associated
> with the flexcan device.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>From the Socket-CAN point of view, this and the other patches can go in.
Thanks for your effort.
Wolfgang.
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Sven-Haegar Koch @ 2011-08-12 12:22 UTC (permalink / raw)
To: Marc Haber; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20110811205429.GB21307@torres.zugschlus.de>
On Thu, 11 Aug 2011, Marc Haber wrote:
> On Thu, Aug 11, 2011 at 08:17:06AM -0700, Stephen Hemminger wrote:
> > On Thu, 11 Aug 2011 09:06:59 +0200
> > Marc Haber <mh+netdev@zugschlus.de> wrote:
> > > Is that a feature? If so, why does the interface stay pingable after
> > > removing the dummy0 interface from the bridge?
> >
> > Yes, there are no links to send a packet so it seems logical
> > that there would be no carrier.
>
> Yes, but if I can configure an IP address to the bridge I would expect
> it to be reachable even if there are no interfaces in the bridge.
> "Older" kernels used to behave like that.
For me (using kernel 3.0.0) it seems to work as I expect it:
aurora:~# brctl addbr br0
aurora:~# ifconfig br0 192.168.254.1 netmask 255.255.255.0 up
aurora:~# ping 192.168.254.1
PING 192.168.254.1 (192.168.254.1) 56(84) bytes of data.
64 bytes from 192.168.254.1: icmp_req=1 ttl=64 time=0.087 ms
aurora:~# ifconfig br0
br0 Link encap:Ethernet HWaddr 96:e1:ba:9f:91:f9
inet addr:192.168.254.1 Bcast:192.168.254.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
The br0 interface has no carrier / is not "running", exactly like an
ethernet port without a cable.
c'ya
sven-haegar
--
Three may keep a secret, if two of them are dead.
- Ben F.
^ permalink raw reply
* Re: [PATCH] Fix RCU warning in rt_cache_seq_show
From: Paul E. McKenney @ 2011-08-12 12:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Mark Rutland, netdev, David S. Miller, Gergely Kalman
In-Reply-To: <1313133830.2669.34.camel@edumazet-laptop>
On Fri, Aug 12, 2011 at 09:23:50AM +0200, Eric Dumazet wrote:
> Le jeudi 11 août 2011 à 19:32 -0700, Paul E. McKenney a écrit :
> > On Thu, Aug 11, 2011 at 06:58:21PM +0200, Eric Dumazet wrote:
> > > Le mercredi 10 août 2011 à 10:28 +0100, Mark Rutland a écrit :
> > > > > -----Original Message-----
> > > > > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > > > > Sent: 09 August 2011 18:19
> > > > > To: Mark Rutland; Paul E. McKenney
> > > > > Cc: netdev@vger.kernel.org; David S. Miller; Gergely Kalman
> > > > > Subject: Re: [PATCH] Fix RCU warning in rt_cache_seq_show
> > > > >
> > > > > Le mardi 09 août 2011 à 18:02 +0100, Mark Rutland a écrit :
> > > > > > Commit f2c31e32 ("net: fix NULL dereferences in check_peer_redir()")
> > > > > > added rcu protection to dst neighbour, and updated callsites for
> > > > > > dst_{get,set}_neighbour. Unfortunately, it missed rt_cache_seq_show.
> > > > > >
> > > > > > This produces a warning on v3.1-rc1 (on a preemptible kernel, on an
> > > > > > ARM Vexpress A9x4):
> > > > > >
> > > > > > ===================================================
> > > > > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > > > ---------------------------------------------------
> > > > > > include/net/dst.h:91 invoked rcu_dereference_check() without
> > > > > protection!
> > > > > >
> > > > > > other info that might help us debug this:
> > > > > >
> > > > > > rcu_scheduler_active = 1, debug_locks = 0
> > > > > > 2 locks held by proc01/32159:
> > > > > >
> > > > > > stack backtrace:
> > > > > > [<80014880>] (unwind_backtrace+0x0/0xf8) from [<802e5c78>]
> > > > > (rt_cache_seq_show+0x18c/0x1c4)
> > > > > > [<802e5c78>] (rt_cache_seq_show+0x18c/0x1c4) from [<800e0c5c>]
> > > > > (seq_read+0x324/0x4a4)
> > > > > > [<800e0c5c>] (seq_read+0x324/0x4a4) from [<8010786c>]
> > > > > (proc_reg_read+0x70/0x94)
> > > > > > [<8010786c>] (proc_reg_read+0x70/0x94) from [<800c0ba8>]
> > > > > (vfs_read+0xb0/0x144)
> > > > > > [<800c0ba8>] (vfs_read+0xb0/0x144) from [<800c0ea8>]
> > > > > (sys_read+0x40/0x70)
> > > > > > [<800c0ea8>] (sys_read+0x40/0x70) from [<8000e0c0>]
> > > > > (ret_fast_syscall+0x0/0x3c)
> > > > > >
> > > > > > This patch adds calls to rcu_read_{lock,unlock} in rt_cache_seq_show,
> > > > > > protecting the dereferenced variable, and clearing the warning.
> > > > > >
> > > > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > > > > Cc: David S. Miller <davem@davemloft.net>
> > > > > > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > > > > > Cc: Gergely Kalman <synapse@hippy.csoma.elte.hu>
> > > > > > ---
> > > > > > net/ipv4/route.c | 2 ++
> > > > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > > > >
> > > > > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > > > > > index e3dec1c..6699ef7 100644
> > > > > > --- a/net/ipv4/route.c
> > > > > > +++ b/net/ipv4/route.c
> > > > > > @@ -419,6 +419,7 @@ static int rt_cache_seq_show(struct seq_file
> > > > > *seq, void *v)
> > > > > > struct neighbour *n;
> > > > > > int len;
> > > > > >
> > > > > > + rcu_read_lock();
> > > > > > n = dst_get_neighbour(&r->dst);
> > > > > > seq_printf(seq, "%s\t%08X\t%08X\t%8X\t%d\t%u\t%d\t"
> > > > > > "%08X\t%d\t%u\t%u\t%02X\t%d\t%1d\t%08X%n",
> > > > > > @@ -435,6 +436,7 @@ static int rt_cache_seq_show(struct seq_file
> > > > > *seq, void *v)
> > > > > > -1,
> > > > > > (n && (n->nud_state & NUD_CONNECTED)) ? 1 : 0,
> > > > > > r->rt_spec_dst, &len);
> > > > > > + rcu_read_unlock();
> > > > > >
> > > > > > seq_printf(seq, "%*s\n", 127 - len, "");
> > > > > > }
> > > > >
> > > > >
> > > > > Hmm, I though rcu_read_lock_bh() (done by caller of this function) was
> > > > > protecting us here.
> > > >
> > > > Aha. Being a bit trigger-happy, I'd had a quick look at the functions
> > > > mentioned in the backtrace, and not looked at any possible inlining.
> > > >
> > > > This being my first real exposure to RCU, I wasn't aware of the *_bh
> > > > variants. Looking at the documentation (Documentation/RCU/checklist.txt),
> > > > I think the real problem is that we should be using rcu_dereference_bh in
> > > > this case:
> > > >
> > > > > read-side critical sections are delimited by rcu_read_lock()
> > > > > and rcu_read_unlock(), or by similar primitives such as
> > > > > rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
> > > > > the matching rcu_dereference() primitive must be used in order
> > > > > to keep lockdep happy, in this case, rcu_dereference_bh().
> > >
> > > Hmm.
> > >
> > > I do think dst_get_neighbour() should use rcu_dereference(), because
> > > dst->_neighbour are freed by call_rcu().
> > >
> > > The question is : Is following construct [A] safe or not ?
> > >
> > > {
> > > rcu_read_lock_bh();
> > > /* BH are now disabled, and we are not allowed to sleep */
> > > ...
> > >
> > > ptr = rcu_dereference();
> >
> > This should be:
> >
> > ptr = rcu_dereference_bh();
> >
> > As you say below. Never mind! ;-)
> >
> > > ...
> > > rcu_read_unlock_bh();
> > > }
> > >
> > >
> > > I dont really understand why lockdep wants [B] instead :
> > >
> > > {
> > > rcu_read_lock_bh();
> > > ...
> > >
> > > {
> > > rcu_read_lock();
> > > ptr = rcu_dereference();
> >
> > Here you are protected by both RCU and RCU-bh, so you should be able
> > to use either rcu_dereference() or rcu_dereference_bh(). A bit
> > strange to use rcu_dereference_bh(), though. Except perhaps if a
> > pointer to a function was passed in from the outer RCU-bh read-side
> > critical section or something.
> >
> > > rcu_read_unlock();
> > > }
> > > ...
> > > rcu_read_unlock_bh();
> > > }
> > >
> > >
> > >
> > > However, I can understand the other way [C], this is really needed :
> > >
> > > {
> > > rcu_read_lock();
> > > ...
> > >
> > > {
> > > rcu_read_lock_bh();
> > > ptr = rcu_dereference_bh();
> > > rcu_read_unlock_bh();
> > > }
> > > ...
> > > rcu_read_unlock();
> > > }
> > >
> > > I believe [A] should be allowed by lockdep.
> >
> > OK, I'll bite. Why?
> >
>
> Oh well, I assumed local_bh_disable() disables preemption.
>
> It does since day-0
> add_preempt_count(SOFTIRQ_DISABLE_OFFSET);
>
> So following should be safe :
>
> local_bh_disable();
> {
> ptr = rcu_dereference(...);
> use(ptr);
> }
> local_bh_enable();
>
> Maybe they are longterm plans to break this assumption, I dont know.
It would be safe for TINY_RCU and TREE_RCU, but not for either
TINY_PREEMPT_RCU or TREE_PREEMPT_RCU. These last two do not
recognize a preempt-disable region as an RCU read-side critical
section.
Thanx, Paul
^ permalink raw reply
* Re: [net-next RFC PATCH 4/7] tuntap: multiqueue support
From: Eric Dumazet @ 2011-08-12 14:29 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, kvm, mst, qemu-devel, netdev, rusty, linux-kernel,
virtualization, mirq-linux, davem
In-Reply-To: <20110812015520.31613.99890.stgit@intel-e5620-16-2.englab.nay.redhat.com>
Le vendredi 12 août 2011 à 09:55 +0800, Jason Wang a écrit :
>+ rxq = skb_get_rxhash(skb);
>+ if (rxq) {
>+ tfile = rcu_dereference(tun->tfiles[rxq % numqueues]);
>+ if (tfile)
>+ goto out;
>+ }
You can avoid an expensive divide with following trick :
u32 idx = ((u64)rxq * numqueues) >> 32;
> -static struct tun_struct *tun_get(struct file *file)
> +static void tun_detach_all(struct net_device *dev)
> {
> - return __tun_get(file->private_data);
> + struct tun_struct *tun = netdev_priv(dev);
> + struct tun_file *tfile, *tfile_list[MAX_TAP_QUEUES];
> + int i, j = 0;
> +
> + spin_lock(&tun_lock);
> +
> + for (i = 0; i < MAX_TAP_QUEUES && tun->numqueues; i++) {
> + tfile = rcu_dereference_protected(tun->tfiles[i],
> + lockdep_is_held(&tun_lock));
> + if (tfile) {
> + wake_up_all(&tfile->wq.wait);
> + tfile_list[i++] = tfile;
typo here, you want tfile_list[j++] = tfile;
> + rcu_assign_pointer(tun->tfiles[i], NULL);
> + rcu_assign_pointer(tfile->tun, NULL);
> + --tun->numqueues;
> + }
> + }
> + BUG_ON(tun->numqueues != 0);
> + spin_unlock(&tun_lock);
> +
> + synchronize_rcu();
> + for(--j; j >= 0; j--)
> + sock_put(&tfile_list[j]->sk);
> }
>
Could you take a look at net/packet/af_packet.c, to check how David did
the whole fanout thing ?
__fanout_unlink()
Trick is to not leave NULL entries in the tun->tfiles[] array.
It makes things easier in hot path.
^ permalink raw reply
* [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Michal Schmidt @ 2011-08-12 14:33 UTC (permalink / raw)
To: netdev; +Cc: dmitry, vladz
When a VN is configured with invalid Max BW, the error does not have to
be logged repeatedly and fill the logs.
Warn only once when the bad configuration is detected on boot, or when
the configuration changes dynamically from good to bad.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 5 ++---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 21 +++++++++++----------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index c423504..648e165 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1220,6 +1220,7 @@ struct bnx2x {
struct cmng_struct_per_port cmng;
u32 vn_weight_sum;
u32 mf_config[E1HVN_MAX];
+ bool prev_max_cfg_invalid[E1HVN_MAX];
u32 mf2_config[E2_FUNC_MAX];
u32 path_has_ovlan; /* E3 */
u16 mf_ov;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index d724a18..a5216a9 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -841,8 +841,7 @@ u16 bnx2x_get_mf_speed(struct bnx2x *bp)
{
u16 line_speed = bp->link_vars.line_speed;
if (IS_MF(bp)) {
- u16 maxCfg = bnx2x_extract_max_cfg(bp,
- bp->mf_config[BP_VN(bp)]);
+ u16 maxCfg = bnx2x_extract_max_cfg(bp, BP_VN(bp));
/* Calculate the current MAX line speed limit for the MF
* devices
@@ -1153,7 +1152,7 @@ void bnx2x_update_max_mf_config(struct bnx2x *bp, u32 value)
/* load old values */
u32 mf_cfg = bp->mf_config[BP_VN(bp)];
- if (value != bnx2x_extract_max_cfg(bp, mf_cfg)) {
+ if (value != bnx2x_extract_max_cfg(bp, BP_VN(bp))) {
/* leave all but MAX value */
mf_cfg &= ~FUNC_MF_CFG_MAX_BW_MASK;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index 223bfee..6e75c42 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -1473,19 +1473,20 @@ void bnx2x_release_phy_lock(struct bnx2x *bp);
* bnx2x_extract_max_cfg - extract MAX BW part from MF configuration.
*
* @bp: driver handle
- * @mf_cfg: MF configuration
+ * @vn: vnic index
*
*/
-static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
+static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, int vn)
{
- u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
- FUNC_MF_CFG_MAX_BW_SHIFT;
- if (!max_cfg) {
- BNX2X_ERR("Illegal configuration detected for Max BW - "
- "using 100 instead\n");
- max_cfg = 100;
- }
- return max_cfg;
+ u16 max_cfg = (bp->mf_config[vn] & FUNC_MF_CFG_MAX_BW_MASK) >>
+ FUNC_MF_CFG_MAX_BW_SHIFT;
+
+ if (!max_cfg && !bp->prev_max_cfg_invalid[vn])
+ BNX2X_ERR("Illegal configuration detected for Max BW "
+ "on vn %d - using 100 instead\n", vn);
+ bp->prev_max_cfg_invalid[vn] = !max_cfg;
+
+ return max_cfg ?: 100;
}
#endif /* BNX2X_CMN_H */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 1507091..a952f84 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -2335,7 +2335,7 @@ static void bnx2x_init_vn_minmax(struct bnx2x *bp, int vn)
vn_max_rate = 0;
} else {
- u32 maxCfg = bnx2x_extract_max_cfg(bp, vn_cfg);
+ u32 maxCfg = bnx2x_extract_max_cfg(bp, vn);
vn_min_rate = ((vn_cfg & FUNC_MF_CFG_MIN_BW_MASK) >>
FUNC_MF_CFG_MIN_BW_SHIFT) * 100;
^ permalink raw reply related
* Re: [PATCH v4] usbnet/cdc_ncm: Don't use stack variables for DMA
From: Josh Boyer @ 2011-08-12 15:07 UTC (permalink / raw)
To: Oliver Neukum, Alexey ORISHKO; +Cc: gregkh, linux-usb, linux-kernel, netdev
In-Reply-To: <20110808123406.GA2526@zod.bos.redhat.com>
On Mon, Aug 08, 2011 at 08:34:06AM -0400, Josh Boyer wrote:
> The cdc_ncm driver still has a few places where stack variables are
> passed to the cdc_ncm_do_request function. This triggers a stack trace in
> lib/dma-debug.c if the CONFIG_DEBUG_DMA_API option is set.
>
> Adjust these calls to pass parameters that have been allocated with
> kzalloc.
>
> Signed-off-by: Josh Boyer <jwboyer@redhat.com>
> ---
> v4: Rebase against 3.1-rc1
> v3: Fix checkpatch errors
> v2: Fix leak in error path
>
> drivers/net/usb/cdc_ncm.c | 47 ++++++++++++++++++++++++++++++++++++--------
> 1 files changed, 38 insertions(+), 9 deletions(-)
Just curious, but which tree would this be pulled into? usb or net or?
josh
^ permalink raw reply
* TCP port firewall incl. description and english variable names
From: Tonda @ 2011-08-12 15:10 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
Cc: Antoine Steinhauser
Module that is used to open, close or filter specified TCP port by sending certain sequence of UDP packets to predefined UDP ports (password-like firewall). One sequence of UDP ports is the opening key and sending packets successively to them opens the TCP port and the second sequence of UDP ports is the closing key and sending packets successively to them closes the TCP port. If between two UDP packets in the sequence comes more than 16 another UDP packets, the sequence (either opening or closing) is aborted. The configuration and view of affected TCP port, opening and closing key and other firewall parameters is made throw use of sysfs.
Signed-off-by: Antoine Steinhauser <as@strmilov.cz>
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -624,3 +624,7 @@
on the Internet.
If unsure, say N.
+
+config TCPFIREWALL
+ tristate "TCP Firewall controlled by UDP queries"
+ depends on m
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -51,3 +51,4 @@
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
xfrm4_output.o
+obj-$(CONFIG_TCPFIREWALL) += tcpfirewall/
diff --git a/net/ipv4/tcpfirewall/Makefile b/net/ipv4/tcpfirewall/Makefile
--- a/net/ipv4/tcpfirewall/Makefile
+++ b/net/ipv4/tcpfirewall/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TCPFIREWALL) += tcpfirewall.o
diff --git a/net/ipv4/tcpfirewall/tcpfirewall.c b/net/ipv4/tcpfirewall/tcpfirewall.c
--- a/net/ipv4/tcpfirewall/tcpfirewall.c
+++ b/net/ipv4/tcpfirewall/tcpfirewall.c
@@ -0,0 +1,451 @@
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/skbuff.h>
+#include <linux/in.h>
+#include <linux/if_packet.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
+#include <net/tcp.h>
+#include <net/udp.h>
+
+struct net_protocol {
+ int (*handler)(struct sk_buff *skb);
+ void (*err_handler)(struct sk_buff *skb, u32 info);
+ int (*gso_send_check)(struct sk_buff *skb);
+ struct sk_buff *(*gso_segment)(struct sk_buff *skb,
+ u32 features);
+ struct sk_buff **(*gro_receive)(struct sk_buff **head,
+ struct sk_buff *skb);
+ int (*gro_complete)(struct sk_buff *skb);
+ unsigned int no_policy:1,
+ netns_ok:1;
+};
+
+MODULE_LICENSE("GPL");
+
+static unsigned long inet_protos = 0x01234567;
+
+struct net_protocol **_inet_protos;
+
+module_param(inet_protos, ulong, 0);
+
+static int *openkeys;
+static int *closekeys;
+
+static int openkeyscount;
+static int closekeyscount;
+static int fastate;
+static int packetcounter;
+static int tcpport;
+static int open;
+static int firewall;
+
+int (*tcpv4recv) (struct sk_buff *skb);
+int (*udprecv) (struct sk_buff *skb);
+
+int udpcontroller(struct sk_buff *skb)
+{
+ const struct udphdr *uh;
+
+ if (skb->pkt_type != PACKET_HOST) {
+ kfree_skb(skb);
+ return 0;
+ }
+
+ if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
+ kfree_skb(skb);
+ return 0;
+ }
+
+ uh = udp_hdr(skb);
+
+ if (openkeyscount == 0)
+ return udprecv(skb);
+
+ if (!open) {
+ if (uh->dest == openkeys[fastate]) {
+ ++fastate;
+ packetcounter = 0;
+
+ if (fastate == openkeyscount) {
+ open = 1;
+ fastate = 0;
+ }
+ } else {
+ if (packetcounter <= 16) {
+ ++packetcounter;
+ if (packetcounter > 16)
+ fastate = 0;
+ }
+ }
+ } else {
+ if (uh->dest == closekeys[fastate]) {
+ ++fastate;
+ packetcounter = 0;
+
+ if (fastate == closekeyscount) {
+ open = 0;
+ fastate = 0;
+ }
+ } else {
+ if (packetcounter <= 16) {
+ ++packetcounter;
+ if (packetcounter > 16)
+ fastate = 0;
+ }
+ }
+ }
+
+
+ return udprecv(skb);
+}
+
+int tcpfirewall(struct sk_buff *skb)
+{
+ const struct tcphdr *th;
+
+ if (skb->pkt_type != PACKET_HOST) {
+ kfree_skb(skb);
+ return 0;
+ }
+
+ if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
+ kfree_skb(skb);
+ return 0;
+ }
+
+ th = tcp_hdr(skb);
+
+ if (th->dest == tcpport) {
+ if (firewall == 1 && !open) {
+ /*tcpv4sendreset(NULL, skb);*/
+ kfree_skb(skb);
+ return 0;
+ }
+ }
+
+ return tcpv4recv(skb);
+}
+
+static struct net_protocol *backuptcp;
+static struct net_protocol *backupudp;
+static struct net_protocol mytcp;
+static struct net_protocol myudp;
+
+static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buffer)
+{
+ if (!strcmp(attr->name, "firewall")) {
+ if (firewall)
+ buffer[0] = '1';
+ else
+ buffer[0] = '0';
+
+ buffer[1] = '\n';
+ return 2;
+ }
+
+ if (!strcmp(attr->name, "tcpport")) {
+ sprintf(buffer, "%d\n", ntohs(tcpport));
+ return strlen(buffer)+1;
+ }
+
+ if (!strcmp(attr->name, "openers")) {
+ int i;
+ char *znak;
+ if (openkeyscount == 0)
+ return 0;
+ buffer[0] = '\0';
+ znak = kmalloc(10, GFP_KERNEL);
+ for (i = 0; i < openkeyscount; ++i) {
+ sprintf(znak, "%d ", ntohs(openkeys[i]));
+ strcat(buffer, znak);
+ }
+ kfree(znak);
+ buffer[strlen(buffer)-1] = '\n';
+ return strlen(buffer);
+ }
+
+ if (!strcmp(attr->name, "closers")) {
+ int i;
+ char *znak;
+ if (closekeyscount == 0)
+ return 0;
+ buffer[0] = '\0';
+ znak = kmalloc(10, GFP_KERNEL);
+ for (i = 0; i < closekeyscount; ++i) {
+ sprintf(znak, "%d ", ntohs(closekeys[i]));
+ strcat(buffer, znak);
+ }
+ kfree(znak);
+ buffer[strlen(buffer)-1] = '\n';
+ return strlen(buffer);
+ }
+
+ if (!strcmp(attr->name, "open")) {
+ if (open)
+ buffer[0] = '1';
+ else
+ buffer[0] = '0';
+
+ buffer[1] = '\n';
+ return 2;
+ }
+
+ if (!strcmp(attr->name, "state")) {
+ sprintf(buffer, "%d\n", fastate);
+ return strlen(buffer)+1;
+ }
+
+ if (!strcmp(attr->name, "counter")) {
+ sprintf(buffer, "%d\n", packetcounter);
+ return strlen(buffer)+1;
+ }
+
+ return 0;
+}
+
+static ssize_t store(struct kobject *kobj, struct attribute *attr,
+ const char *buffer, size_t size)
+{
+ int i;
+ char *cislo;
+ if (!strcmp(attr->name, "firewall")) {
+ if (size > 0 && buffer[0] == '1')
+ firewall = 1;
+ else
+ firewall = 0;
+ fastate = 0;
+ return size;
+ }
+
+ if (!strcmp(attr->name, "tcpport")) {
+ cislo = kmalloc(size+1, GFP_KERNEL);
+ for (i = 0; i < size; ++i)
+ cislo[i] = buffer[i];
+ cislo[size] = '\0';
+ if (kstrtoint(cislo, 10, &i) < 0)
+ i = -1;
+ if (i > 0 && i < 65536)
+ tcpport = htons(i);
+ kfree(cislo);
+ fastate = 0;
+ return size;
+ }
+
+ if (!strcmp(attr->name, "openers")) {
+ int udpport, i;
+ int *noveopenkeys;
+ int *stareopenkeys;
+ cislo = kmalloc(size+1, GFP_KERNEL);
+ for (i = 0; i < size; ++i)
+ cislo[i] = buffer[i];
+ cislo[size] = '\0';
+
+ if (!strcmp(cislo, "reset") || !strcmp(cislo, "reset\n")) {
+ if (openkeyscount)
+ kfree(openkeys);
+ openkeyscount = 0;
+ }
+
+ if (kstrtoint(cislo, 10, &i) < 0)
+ i = -1;
+ kfree(cislo);
+
+ if (i > 0 && i < 65536 && (openkeyscount == 0 ||
+ openkeys[openkeyscount-1] != i))
+ udpport = htons(i);
+ else
+ return size;
+
+ if (openkeyscount < 10) {
+ noveopenkeys = kmalloc((openkeyscount+1)*sizeof(int),
+ GFP_KERNEL);
+
+ for (i = 0; i < openkeyscount; ++i)
+ noveopenkeys[i] = openkeys[i];
+
+ noveopenkeys[openkeyscount] = udpport;
+ stareopenkeys = openkeys;
+ openkeys = noveopenkeys;
+ if (openkeyscount)
+ kfree(stareopenkeys);
+
+ ++openkeyscount;
+ }
+ fastate = 0;
+ return size;
+ }
+
+ if (!strcmp(attr->name, "closers")) {
+ int udpport, i;
+ int *noveclosekeys;
+ int *stareclosekeys;
+ cislo = kmalloc(size+1, GFP_KERNEL);
+ for (i = 0; i < size; ++i)
+ cislo[i] = buffer[i];
+ cislo[size] = '\0';
+
+ if (!strcmp(cislo, "reset") || !strcmp(cislo, "reset\n")) {
+ if (closekeyscount)
+ kfree(closekeys);
+ closekeyscount = 0;
+ }
+
+ if (kstrtoint(cislo, 10, &i) < 0)
+ i = -1;
+ kfree(cislo);
+
+ if (i > 0 && i < 65536 && (closekeyscount == 0 ||
+ closekeys[closekeyscount-1] != i))
+ udpport = htons(i);
+ else
+ return size;
+
+ if (closekeyscount < 10) {
+ noveclosekeys = kmalloc((closekeyscount+1)*sizeof(int),
+ GFP_KERNEL);
+
+ for (i = 0; i < closekeyscount; ++i)
+ noveclosekeys[i] = closekeys[i];
+
+ noveclosekeys[closekeyscount] = udpport;
+ stareclosekeys = closekeys;
+ closekeys = noveclosekeys;
+ if (closekeyscount)
+ kfree(stareclosekeys);
+
+ ++closekeyscount;
+ }
+ fastate = 0;
+ return size;
+ }
+
+ if (!strcmp(attr->name, "open")) {
+ if (size > 0 && buffer[0] == '1')
+ open = 1;
+ else
+ open = 0;
+
+ fastate = 0;
+ return size;
+ }
+
+ return 0;
+}
+
+static const struct sysfs_ops so = {
+ .show = show,
+ .store = store,
+};
+
+static struct kobj_type khid = {
+ .sysfs_ops = &so,
+};
+
+static struct kobject kobj;
+
+static const struct attribute fw = {
+ .name = "firewall",
+ .mode = S_IRWXU,
+};
+
+static const struct attribute opn = {
+ .name = "open",
+ .mode = S_IRWXU,
+};
+
+static const struct attribute tcpp = {
+ .name = "tcpport",
+ .mode = S_IRWXU,
+};
+
+static const struct attribute openers = {
+ .name = "openers",
+ .mode = S_IRWXU,
+};
+
+static const struct attribute closers = {
+ .name = "closers",
+ .mode = S_IRWXU,
+};
+
+static const struct attribute stat = {
+ .name = "state",
+ .mode = S_IRUSR,
+};
+
+static const struct attribute counte = {
+ .name = "counter",
+ .mode = S_IRUSR,
+};
+
+static int __init start(void)
+{
+ if (inet_protos == 0x01234567) {
+ printk(KERN_WARNING "inet_protos parameter was not");
+ printk(KERN_WARNING " specified!\nread its value from");
+ printk(KERN_WARNING " System_map file file, and insert");
+ printk(KERN_WARNING " the module again!\n");
+ return -1;
+ }
+
+ openkeyscount = 0;
+ closekeyscount = 0;
+ fastate = -1;
+ packetcounter = 0;
+ tcpport = 0;
+ open = 1;
+ firewall = 0;
+
+ memset(&kobj, 0, sizeof(struct kobject));
+
+ _inet_protos = (struct net_protocol **)inet_protos;
+
+ kobject_init(&kobj, &khid);
+ if (kobject_add(&kobj, NULL, "tcpfirewall") < 0)
+ printk(KERN_ERR "kobject_add failed");
+
+ if (sysfs_create_file(&kobj, &fw) < 0)
+ printk(KERN_ERR "sysfs_create_file failed");
+ if (sysfs_create_file(&kobj, &opn) < 0)
+ printk(KERN_ERR "sysfs_create_file failed");
+ if (sysfs_create_file(&kobj, &tcpp) < 0)
+ printk(KERN_ERR "sysfs_create_file failed");
+ if (sysfs_create_file(&kobj, &openers) < 0)
+ printk(KERN_ERR "sysfs_create_file failed");
+ if (sysfs_create_file(&kobj, &closers) < 0)
+ printk(KERN_ERR "sysfs_create_file failed");
+ if (sysfs_create_file(&kobj, &stat) < 0)
+ printk(KERN_ERR "sysfs_create_file failed");
+ if (sysfs_create_file(&kobj, &counte) < 0)
+ printk(KERN_ERR "sysfs_create_file failed");
+
+ backuptcp = _inet_protos[IPPROTO_TCP];
+ backupudp = _inet_protos[IPPROTO_UDP];
+ mytcp = *backuptcp;
+ myudp = *backupudp;
+ tcpv4recv = mytcp.handler;
+ udprecv = myudp.handler;
+ mytcp.handler = tcpfirewall;
+ myudp.handler = udpcontroller;
+ _inet_protos[IPPROTO_TCP] = &mytcp;
+ _inet_protos[IPPROTO_UDP] = &myudp;
+ return 0;
+}
+
+static void konec(void)
+{
+ _inet_protos[IPPROTO_TCP] = backuptcp;
+ _inet_protos[IPPROTO_UDP] = backupudp;
+
+ if (openkeyscount)
+ kfree(openkeys);
+ if (closekeyscount)
+ kfree(closekeys);
+
+ kobject_del(&kobj);
+}
+
+module_init(start);
+module_exit(konec);
^ permalink raw reply
* Re: [PATCH v4] usbnet/cdc_ncm: Don't use stack variables for DMA
From: David Miller @ 2011-08-12 15:11 UTC (permalink / raw)
To: jwboyer; +Cc: oliver, alexey.orishko, gregkh, linux-usb, linux-kernel, netdev
In-Reply-To: <20110812150715.GD3014@zod.bos.redhat.com>
From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 12 Aug 2011 11:07:16 -0400
> On Mon, Aug 08, 2011 at 08:34:06AM -0400, Josh Boyer wrote:
>> The cdc_ncm driver still has a few places where stack variables are
>> passed to the cdc_ncm_do_request function. This triggers a stack trace in
>> lib/dma-debug.c if the CONFIG_DEBUG_DMA_API option is set.
>>
>> Adjust these calls to pass parameters that have been allocated with
>> kzalloc.
>>
>> Signed-off-by: Josh Boyer <jwboyer@redhat.com>
>> ---
>> v4: Rebase against 3.1-rc1
>> v3: Fix checkpatch errors
>> v2: Fix leak in error path
>>
>> drivers/net/usb/cdc_ncm.c | 47 ++++++++++++++++++++++++++++++++++++--------
>> 1 files changed, 38 insertions(+), 9 deletions(-)
>
> Just curious, but which tree would this be pulled into? usb or net or?
Probably net.
^ permalink raw reply
* Re: TCP port firewall incl. description and english variable names
From: Randy Dunlap @ 2011-08-12 15:13 UTC (permalink / raw)
To: Tonda; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313161843-18226-1-git-send-email-as@strmilov.cz>
On Fri, 12 Aug 2011 17:10:43 +0200 Tonda wrote:
> Module that is used to open, close or filter specified TCP port by sending certain sequence of UDP packets to predefined UDP ports (password-like firewall). One sequence of UDP ports is the opening key and sending packets successively to them opens the TCP port and the second sequence of UDP ports is the closing key and sending packets successively to them closes the TCP port. If between two UDP packets in the sequence comes more than 16 another UDP packets, the sequence (either opening or closing) is aborted. The configuration and view of affected TCP port, opening and closing key and other firewall parameters is made throw use of sysfs.
> Signed-off-by: Antoine Steinhauser <as@strmilov.cz>
>
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -624,3 +624,7 @@
> on the Internet.
>
> If unsure, say N.
> +
> +config TCPFIREWALL
> + tristate "TCP Firewall controlled by UDP queries"
> + depends on m
I have the same comments as yesterday, which for some reason were
unanswered.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: TCP port firewall incl. description and english variable names
From: Eric Dumazet @ 2011-08-12 15:34 UTC (permalink / raw)
To: Tonda; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313161843-18226-1-git-send-email-as@strmilov.cz>
Le vendredi 12 août 2011 à 17:10 +0200, Tonda a écrit :
> Module that is used to open, close or filter specified TCP port by
> sending certain sequence of UDP packets to predefined UDP ports
> (password-like firewall). One sequence of UDP ports is the opening key
> and sending packets successively to them opens the TCP port and the
> second sequence of UDP ports is the closing key and sending packets
> successively to them closes the TCP port. If between two UDP packets
> in the sequence comes more than 16 another UDP packets, the sequence
> (either opening or closing) is aborted. The configuration and view of
> affected TCP port, opening and closing key and other firewall
> parameters is made throw use of sysfs.
>
> Signed-off-by: Antoine Steinhauser <as@strmilov.cz>
Antoine
There is no chance this can be added in official linux kernel, its
really too ugly, and can be implemented using standard iptables rules,
and userland controller, adding encryption and other high level stuff if
needed.
^ permalink raw reply
* Re: TCP port firewall controlled by UDP packets
From: Antonin Steinhauser @ 2011-08-12 15:35 UTC (permalink / raw)
To: Randy Dunlap
Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <20110811171317.271be88b.rdunlap@xenotime.net>
Dne 12.8.2011 02:13, Randy Dunlap napsal(a):
> On Fri, 12 Aug 2011 01:56:09 +0200 Tonda wrote:
>
> Need more patch description& justification here, as well as
> Signed-off-by:<your name& email address>
>
>
>
>> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
>> --- a/net/ipv4/Kconfig
>> +++ b/net/ipv4/Kconfig
>> @@ -624,3 +624,7 @@
>> on the Internet.
>>
>> If unsure, say N.
>> +
>> +config TCPFIREWALL
>> + tristate "TCP Firewall controlled by UDP queries"
>> + depends on m
>>
> Why buildable only as a loadable module?
>
>
Because it needs parameter - address of inet_protos table from
/boot/System_map
>
>> diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
>> --- a/net/ipv4/Makefile
>> +++ b/net/ipv4/Makefile
>> @@ -51,3 +51,4 @@
>>
>> obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
>> xfrm4_output.o
>> +obj-$(CONFIG_TCPFIREWALL) += tcpfirewall/
>> diff --git a/net/ipv4/tcpfirewall/Makefile b/net/ipv4/tcpfirewall/Makefile
>> --- a/net/ipv4/tcpfirewall/Makefile
>> +++ b/net/ipv4/tcpfirewall/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_TCPFIREWALL) += tcpfirewall.o
>> diff --git a/net/ipv4/tcpfirewall/tcpfirewall.c b/net/ipv4/tcpfirewall/tcpfirewall.c
>> --- a/net/ipv4/tcpfirewall/tcpfirewall.c
>> +++ b/net/ipv4/tcpfirewall/tcpfirewall.c
>> @@ -0,0 +1,451 @@
>> +#include<linux/module.h>
>> +#include<linux/kernel.h>
>> +#include<linux/init.h>
>> +#include<linux/skbuff.h>
>> +#include<linux/in.h>
>> +#include<linux/if_packet.h>
>> +#include<linux/tcp.h>
>> +#include<linux/udp.h>
>> +#include<net/tcp.h>
>> +#include<net/udp.h>
>> +
>> +struct net_protocol {
>> + int (*handler)(struct sk_buff *skb);
>> + void (*err_handler)(struct sk_buff *skb, u32 info);
>> + int (*gso_send_check)(struct sk_buff *skb);
>> + struct sk_buff *(*gso_segment)(struct sk_buff *skb,
>> + u32 features);
>> + struct sk_buff **(*gro_receive)(struct sk_buff **head,
>> + struct sk_buff *skb);
>> + int (*gro_complete)(struct sk_buff *skb);
>> + unsigned int no_policy:1,
>> + netns_ok:1;
>> +};
>> +
>> +MODULE_LICENSE("GPL");
>> +
>> +static unsigned long inet_protos = 0x01234567;
>> +
>> +struct net_protocol **_inet_protos;
>> +
>> +module_param(inet_protos, ulong, 0);
>> +
>> +static int *otviraky;
>> +static int *zaviraky;
>> +
>> +static int pocetotviraku;
>> +static int pocetzaviraku;
>> +static int stav;
>> +static int packetcounter;
>> +static int tcpport;
>> +static int open;
>> +static int firewall;
>> +
>> +int (*tcpv4recv) (struct sk_buff *skb);
>> +int (*udprecv) (struct sk_buff *skb);
>> +
>> +int udpcontroller(struct sk_buff *skb)
>>
> can be static?
>
>
Yes
>> +{
>> + const struct udphdr *uh;
>> +
>> + if (skb->pkt_type != PACKET_HOST) {
>> + kfree_skb(skb);
>> + return 0;
>> + }
>> +
>> + if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
>> + kfree_skb(skb);
>> + return 0;
>> + }
>> +
>> + uh = udp_hdr(skb);
>> +
>> + if (pocetotviraku == 0)
>> + return udprecv(skb);
>> +
>> + if (!open) {
>> + if (uh->dest == otviraky[stav]) {
>> + ++stav;
>> + packetcounter = 0;
>> +
>> + if (stav == pocetotviraku) {
>> + open = 1;
>> + stav = 0;
>> + }
>> + } else {
>> + if (packetcounter<= 16) {
>> + ++packetcounter;
>> + if (packetcounter> 16)
>> + stav = 0;
>> + }
>> + }
>> + } else {
>> + if (uh->dest == zaviraky[stav]) {
>> + ++stav;
>> + packetcounter = 0;
>> +
>> + if (stav == pocetzaviraku) {
>> + open = 0;
>> + stav = 0;
>> + }
>> + } else {
>> + if (packetcounter<= 16) {
>> + ++packetcounter;
>> + if (packetcounter> 16)
>> + stav = 0;
>> + }
>> + }
>> + }
>> +
>> +
>> + return udprecv(skb);
>> +}
>> +
>> +int tcpfirewall(struct sk_buff *skb)
>>
> can be static?
>
>
Yes
>> +{
>> + const struct tcphdr *th;
>> +
>> + if (skb->pkt_type != PACKET_HOST) {
>> + kfree_skb(skb);
>> + return 0;
>> + }
>> +
>> + if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
>> + kfree_skb(skb);
>> + return 0;
>> + }
>> +
>> + th = tcp_hdr(skb);
>> +
>> + if (th->dest == tcpport) {
>> + if (firewall == 1&& !open) {
>> + /*tcpv4sendreset(NULL, skb);*/
>> + kfree_skb(skb);
>> + return 0;
>> + }
>> + }
>> +
>> + return tcpv4recv(skb);
>> +}
>>
> [snip]
>
>
>> +static int __init start(void)
>> +{
>> + if (inet_protos == 0x01234567) {
>> + printk(KERN_WARNING "inet_protos parameter was not");
>> + printk(KERN_WARNING " specified!\nread its value from");
>> + printk(KERN_WARNING " System_map file file, and insert");
>> + printk(KERN_WARNING " the module again!\n");
>>
> Break the printk() calls at newlines, please.
>
>
OK
>> + return -1;
>> + }
>> +
>> + pocetotviraku = 0;
>> + pocetzaviraku = 0;
>> + stav = -1;
>> + packetcounter = 0;
>> + tcpport = 0;
>> + open = 1;
>> + firewall = 0;
>> +
>> + memset(&kobj, 0, sizeof(struct kobject));
>> +
>> + _inet_protos = (struct net_protocol **)inet_protos;
>> +
>> + kobject_init(&kobj,&khid);
>> + if (kobject_add(&kobj, NULL, "tcpfirewall")< 0)
>> + printk(KERN_ERR "kobject_add failed");
>> +
>>
> All of these kobject_add() and sysfs_create_file() failures are not
> fatal errors?
>
>
I do not know, whether collision of kobject names is fatal or not.
>> + if (sysfs_create_file(&kobj,&fw)< 0)
>> + printk(KERN_ERR "sysfs_create_file failed");
>> + if (sysfs_create_file(&kobj,&opn)< 0)
>> + printk(KERN_ERR "sysfs_create_file failed");
>> + if (sysfs_create_file(&kobj,&tcpp)< 0)
>> + printk(KERN_ERR "sysfs_create_file failed");
>> + if (sysfs_create_file(&kobj,&openers)< 0)
>> + printk(KERN_ERR "sysfs_create_file failed");
>> + if (sysfs_create_file(&kobj,&closers)< 0)
>> + printk(KERN_ERR "sysfs_create_file failed");
>> + if (sysfs_create_file(&kobj,&stat)< 0)
>> + printk(KERN_ERR "sysfs_create_file failed");
>> + if (sysfs_create_file(&kobj,&counte)< 0)
>> + printk(KERN_ERR "sysfs_create_file failed");
>> +
>> + zalohatcp = _inet_protos[IPPROTO_TCP];
>> + zalohaudp = _inet_protos[IPPROTO_UDP];
>> + mytcp = *zalohatcp;
>> + myudp = *zalohaudp;
>> + tcpv4recv = mytcp.handler;
>> + udprecv = myudp.handler;
>> + mytcp.handler = tcpfirewall;
>> + myudp.handler = udpcontroller;
>> + _inet_protos[IPPROTO_TCP] =&mytcp;
>> + _inet_protos[IPPROTO_UDP] =&myudp;
>> + return 0;
>> +}
>> +
>> +static void konec(void)
>> +{
>> + _inet_protos[IPPROTO_TCP] = zalohatcp;
>> + _inet_protos[IPPROTO_UDP] = zalohaudp;
>> +
>> + if (pocetotviraku)
>> + kfree(otviraky);
>> + if (pocetzaviraku)
>> + kfree(zaviraky);
>> +
>> + kobject_del(&kobj);
>> +}
>> +
>> +module_init(start);
>> +module_exit(konec);
>> --
>>
> Some of the function& variable names confuse me.
>
>
>
I renamed them in the second version.
Should I resend the corrected patch again?
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
>
^ permalink raw reply
* Re: TCP port firewall incl. description and english variable names
From: Patrick McHardy @ 2011-08-12 15:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tonda, davem, kuznet, jmorris, yoshfuji, netdev, linux-kernel
In-Reply-To: <1313163276.2354.32.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 12.08.2011 17:34, Eric Dumazet wrote:
> Le vendredi 12 août 2011 à 17:10 +0200, Tonda a écrit :
>> Module that is used to open, close or filter specified TCP port by
>> sending certain sequence of UDP packets to predefined UDP ports
>> (password-like firewall). One sequence of UDP ports is the opening key
>> and sending packets successively to them opens the TCP port and the
>> second sequence of UDP ports is the closing key and sending packets
>> successively to them closes the TCP port. If between two UDP packets
>> in the sequence comes more than 16 another UDP packets, the sequence
>> (either opening or closing) is aborted. The configuration and view of
>> affected TCP port, opening and closing key and other firewall
>> parameters is made throw use of sysfs.
>>
>> Signed-off-by: Antoine Steinhauser <as@strmilov.cz>
>
> Antoine
>
> There is no chance this can be added in official linux kernel, its
> really too ugly, and can be implemented using standard iptables rules,
> and userland controller, adding encryption and other high level stuff if
> needed.
Fully agreed. There are also standarized protocols for this.
^ permalink raw reply
* Re: TCP port firewall incl. description and english variable names
From: Antonin Steinhauser @ 2011-08-12 15:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313163276.2354.32.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
OK
Dne 12.8.2011 17:34, Eric Dumazet napsal(a):
> Le vendredi 12 août 2011 à 17:10 +0200, Tonda a écrit :
>
>> Module that is used to open, close or filter specified TCP port by
>> sending certain sequence of UDP packets to predefined UDP ports
>> (password-like firewall). One sequence of UDP ports is the opening key
>> and sending packets successively to them opens the TCP port and the
>> second sequence of UDP ports is the closing key and sending packets
>> successively to them closes the TCP port. If between two UDP packets
>> in the sequence comes more than 16 another UDP packets, the sequence
>> (either opening or closing) is aborted. The configuration and view of
>> affected TCP port, opening and closing key and other firewall
>> parameters is made throw use of sysfs.
>>
>> Signed-off-by: Antoine Steinhauser<as@strmilov.cz>
>>
> Antoine
>
> There is no chance this can be added in official linux kernel, its
> really too ugly, and can be implemented using standard iptables rules,
> and userland controller, adding encryption and other high level stuff if
> needed.
>
>
>
>
>
^ permalink raw reply
* Re: iproute2: make arpd daemon write pid file on fork
From: Stephen Hemminger @ 2011-08-12 16:15 UTC (permalink / raw)
To: Alex Dubov; +Cc: netdev
In-Reply-To: <201108121623.24984.oakad@yahoo.com>
On Fri, 12 Aug 2011 16:23:24 +1000
Alex Dubov <oakad@yahoo.com> wrote:
> Current version of arpd included with iproute2-2.6.37 will fork
> unconditionally on start-up (using daemon() library call). This causes
> problems with distro start-up scripts, as PID of the started daemon can not be
> reliably obtained, hampering orderly daemon shutdown process.
>
> The included patch makes arpd write it's own pid file after fork, in a common
> LSB fashion, so as to better inter-operate with start up scripts. Removal of
> stale pid files is handled elsewhere.
I already checked in a version which has the -p pidfile option.
^ permalink raw reply
* Re: Request for Redhat
From: Chris Wright @ 2011-08-12 16:18 UTC (permalink / raw)
To: Jun.Kondo
Cc: linux-kernel, omega-g1@ctc-g.co.jp, notsuki, Kozaki, Motokazu,
Hajime Taira, netdev
In-Reply-To: <4E450C8F.4030009@ctc-g.co.jp>
Hi Jun,
* Jun.Kondo (jun.kondo@ctc-g.co.jp) wrote:
> CTC had the following demand;
>
> 1. to ensure high throughput from the beginning of
> tcp connection at normal times by acquiring large
> default transmission buffer value
>
> 2. to limit the block time of the write in order to
> prevent the timeout of upper layer applications
> even when the connection has low throughput, such
> as low rate streaming
Make sure you include network developers (netdev@vger.kernel.org Cc'd)
on networking related patches.
You'll find some helpful information regarding the email format for
submitting patches here:
http://www.kernel.org/doc/Documentation/SubmittingPatches
Improving your Subject: and fixing the patch level for your diff come
to mind immediately.
> --- sock.h 2011-04-14 14:58:03.000000000 +0900
> +++ sock.h.mod 2011-04-21 15:30:07.000000000 +0900
> @@ -434,9 +434,12 @@
> /*
> * Compute minimal free write space needed to queue new packets.
> */
> +
> +extern int sysctl_tcp_lowat;
> +
> static inline int sk_stream_min_wspace(struct sock *sk)
> {
> - return sk->sk_wmem_queued / 2;
> + return sk->sk_wmem_queued >> sysctl_tcp_lowat;
> }
Also, this patch appears to be against an old tree (I assume the RHEL
5 tree). To be considered upstream, you need to generate a diff against
the upstream tree. And considering all that's changed since 2.6.18, it
would be useful to verify you still have the issue in a current upstream
Linux tree.
Alternatively, you may consider using Red Hat's Bugzilla to contact RH
engineers for help and guidance.
Good luck.
thanks,
-chris
^ permalink raw reply
* Re: bridge: accept bridge own MAC address as local
From: Stephen Hemminger @ 2011-08-12 16:19 UTC (permalink / raw)
To: Ulrich Weber; +Cc: davem, netdev
In-Reply-To: <20110812113024.GA8900@babylon>
On Fri, 12 Aug 2011 13:30:24 +0200
Ulrich Weber <ulrich.weber@sophos.com> wrote:
> bridge: accept bridge own MAC address as local
> if MAC address of bridge is manually set (BR_SET_MAC_ADDR). Otherwise
> only MAC addresses of bridge members will work if manually set.
>
> Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
> ---
> net/bridge/br_input.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index f06ee39..3adabe3 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -93,7 +93,9 @@ int br_handle_frame_finish(struct sk_buff *skb)
> skb2 = skb;
>
> br->dev->stats.multicast++;
> - } else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
> + } else if ((br->flags & BR_SET_MAC_ADDR &&
> + !compare_ether_addr(br->bridge_id.addr, dest)) ||
> + ((dst = __br_fdb_get(br, dest)) && dst->is_local)) {
> skb2 = skb;
> /* Do not forward the packet since it's local. */
> skb = NULL;
A cleaner way to do this would be better to put a local entry
in the forwarding database when mac address is manually set.
Then there would not be special case code.
^ permalink raw reply
* Re: TCP port firewall controlled by UDP packets
From: Valdis.Kletnieks @ 2011-08-12 16:40 UTC (permalink / raw)
To: Tonda; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313106969-18733-1-git-send-email-as@strmilov.cz>
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
On Fri, 12 Aug 2011 01:56:09 +0200, Tonda said:
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -624,3 +624,7 @@
> on the Internet.
>
> If unsure, say N.
> +
> +config TCPFIREWALL
> + tristate "TCP Firewall controlled by UDP queries"
> + depends on m
I don't suppose it would be asking too much to support UPNP here, would it?
https://secure.wikimedia.org/wikipedia/en/wiki/Internet_Gateway_Device_Protocol
(If this in fact *does* do the UPNP thing, then this *really* needs better docs).
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox