* Re: ip address delete bug?
From: Carl-Daniel Hailfinger @ 2005-10-05 15:32 UTC (permalink / raw)
To: hadi; +Cc: lartc, netdev
In-Reply-To: <1128474946.6224.8.camel@localhost.localdomain>
jamal wrote:
> On Tue, 2005-04-10 at 23:08 +0000, Alexey Toptygin wrote:
>
>>On Wed, 5 Oct 2005, Carl-Daniel Hailfinger wrote:
>
> [..]
>
>>>Normally, I would add the new IP to eth0, start another ssh to the new IP,
>>>log out from the session to the old IP, remove the old IP from eth0 and be
>>>done. If I want the server to be reachable under both IPs during a transition
>>>period, I can delay deletion of the old IP until later.
>>
>>Then I guess the question is: does anything in common use depend on the
>>old behavior?
>
> There's a new feature in newer kernels which allows for an alias to be
> upgraded to become primary when you delete the primary. You need to
> configure the sysctl otherwise it defaults to purging all the
> secondaries when you delete the primary.
Thanks for that feature! Just looked at
/proc/sys/net/ipv4/conf/*/promote_secondaries
and it is the feature I was looking for. Merged in 2.6.12, if anyone
reads this in a mail archive and wonders whether he has to upgrade.
This leads to another question: Can I manually promote a secondary
address to become primary without deleting the primary? This would help
me to use the new address by default during the transition period.
> What it sounds like is you need to have ssh run over SCTP instead of TCP
> to allow multi-homing.
Maybe, but I did not find any current openssh version with sctp support.
And with promote_secondaries, my original problem is solved perfectly.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* merganser Gain complimentary benefits & economical medicinal. philadelphia
From: samuel woolard @ 2005-10-05 15:34 UTC (permalink / raw)
To: Lionel Tello, ralf, holt, andrews, dev, netdev
This zonne has more than you request for.
Speak not anymore to anxiety disorder.
We are gear up to our shopper's requirement.
This webpage is for bottom-line budget consumer.
Costless for re-consideration your meddical profiles.
You've got the 'complete' package. Ben A --NY.
http://uk.geocities.com/spacesquelchcoolb/?enpitlcx
"You see," said the old man, stopping and turning round, "they--Hi. Here's
lovely hair. I have got three sacks of ladies' hair below, but none so
beautiful and fine as this. What colour, and what texture."
evans frer family-loving F2 faxe dxdt
It was not until long afterward that Alexander learned that for him this
youth was the most dangerous of companions.
One Sunday evening, at Lady Walford's, Alexander did at last meet Hilda
Burgoyne. Mainhall had told him that she would probably be there. He looked
about for her rather nervously, and finally found her at the farther end of
the large drawing-room, the centre of a circle of men, young and old. She
was apparently telling them a story. They were all laughing and bending
toward her. When she saw Alexander, she rose quickly and put out her hand.
The other men drew back a little to let him approach.
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Andi Kleen @ 2005-10-05 16:53 UTC (permalink / raw)
To: Patrick McHardy
Cc: Harald Welte, netdev, netfilter-devel, linux-kernel,
Henrik Nordstrom
In-Reply-To: <4342B575.9090709@trash.net>
On Tuesday 04 October 2005 19:01, Patrick McHardy wrote:
> Andi Kleen wrote:
> > In a sense it's even getting worse: For example us losing the CONFIG
> > option to disable local conntrack (Patrick has disabled it some time ago
> > without even a comment why he did it) has a really bad impact in some
> > cases.
>
> It was necessary to correctly handle locally generated ICMP errors.
Well you most likely wrecked local performance then when it's enabled.
-Andi
^ permalink raw reply
* Re: [ANNOUNCE] iproute2 version (050929)
From: Stephen Hemminger @ 2005-10-05 18:34 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netdev, lartc
In-Reply-To: <Pine.LNX.4.62.0510012332580.14848@bizon.gios.gov.pl>
On Sat, 1 Oct 2005 23:34:25 +0200 (CEST)
Krzysztof Oledzki <olel@ans.pl> wrote:
>
>
> On Fri, 30 Sep 2005, Stephen Hemminger wrote:
>
> > There is an new minor update to iproute2 utilities available:
> > http://developer.osdl.org/dev/iproute2/download/iproute2-050929.tar.gz
>
>
> It hangs on "ip rule flush". Tested on 2.6.13.2.
>
>
> Best regards,
>
>
> Krzysztof Olędzki
Fixed by this patch (in next release)
==========
When assigning an ip address to an ethernet adapter, the newest
(050929) version of 'ip addr' hangs while older versions worked.
The problem was traced to be a removed initialisation. The patch
below corrects this problem.
Regards,
Jerome Borsboom
--- iproute2-050929/lib/libnetlink.c 2005-09-21 21:33:18.000000000 +0200
+++ iproute2-050929/lib/libnetlink.c 2005-10-04 13:42:30.000000000 +0200
@@ -235,7 +235,10 @@
unsigned seq;
struct nlmsghdr *h;
struct sockaddr_nl nladdr;
- struct iovec iov;
+ struct iovec iov = {
+ .iov_base = (void*)n,
+ .iov_len = n->nlmsg_len
+ };
struct msghdr msg = {
.msg_name = &nladdr,
.msg_namelen = sizeof(nladdr),
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* Re: [PATCH] AX.25: Fix packet socket crash
From: David S. Miller @ 2005-10-05 19:16 UTC (permalink / raw)
To: ralf; +Cc: linux-hams, netdev
In-Reply-To: <20051004194803.GA2724@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Tue, 4 Oct 2005 20:48:03 +0100
> Since changeset 98a82febb6340466824c3a453738d4fbd05db81a AX.25 is passing
> received IP and ARP packets to the stack through netif_rx() but we don't
> set the skb->mac.raw to right value which may result in a crash with
> applications that use a packet socket.
>
> Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Applied, thanks a lot Ralf.
^ permalink raw reply
* 440bx and natsemi
From: Frédéric POTTER @ 2005-10-06 7:01 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: Manfred Spraul
[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]
Hi,
We have designed an embedded board, based on Celeron ULV 400 Mhz and 440bx chipset.
The BIOS has been derivated from Linux Bios of the 440mx (mx and bx have minimal differences).
The ethernet devices are natsemi DP83816 (latest HW revision)
The issue :
----------------
If we set the L1 CPU cache in write back mode then, under heavy ethernet load, we have various memory
corruption on the host memory. It looks like, basically, the natsemi device, when getting bus master, is
accessing former skbuf physicall adresses in the tx_ring structure, and therefore writing at various location
in the memory, generating various kernel panic a few moment later.
If we set the L1 CPU cache in write through, the issue vanishes completely (even after a few days of heavy
load)..
Since we have designed this whole system (hardware, BIOS etc..), it may clearly be that we have introduced
a cache coherency issue in the system, but we have checked it all, and it seems like not
* snooping HW interface is present, correctly wired
* Intel CPU and chipset seems to be properly configured, and anyway no configuration seems to be present
that would have allowed us to 'disable' cache coherency.
* No Intel CPU or chipset errata have been found that refers to cache snooping issues.
Does anyone have a clue on this one ? Does someone have a 440bx with a Natsemi device (that may be a rare
configuration BTW, since 440bx is used in laptop where the natsemi is fairly rare)
Are we just discovering an N+1 Intel issue or did we miss something ?
thanks in advance
fred
[-- Attachment #2: Type: text/html, Size: 4788 bytes --]
^ permalink raw reply
* monkish An E-door to these eye catching deals on generics. rampant
From: pasquale juan @ 2005-10-06 10:15 UTC (permalink / raw)
To: Devon Ryther; +Cc: ralf, holt, andrews, dev, netdev, fox, nguyen, cvs
Buy in bulk & keep $ back much.
Handle your diabetic by consuming our tablet.
We keep up send it as per programmed.
This is the only link to SAVE.
Hit for an order, get complimentary health case review.
Thumbs up to you. You are really something. Jacky G --CA.
http://uk.geocities.com/shinesoddengreatb/?pbighrwktgwk
"I began to keep the little creatures," she said, "with an object that the
wards will readily comprehend. With the intention of restoring them to
liberty. When my judgment should be given. Ye- es. They die in prison,
though. Their lives, poor silly things, are so short in comparison with
Chancery proceedings that, one by one, the whole collection has died over
and over again. I doubt, do you know, whether one of these, though they are
all jake, will live to be jake. Ve-ry mortifying, is it not?"
demax dcmpc budimirovic F2 dumplog eshton
Bartley looked at Hilda across the yellow light of the candles and broke
into a low, happy laugh. "How jolly it was being young, Hilda. Do you
remember that first walk we took together in Paris? We walked down to the
Place Saint-Michel to buy some lilacs. Do you remember how sweet they
smelled?"
"Indeed I do. Come, we'll have our coffee in the other room, and you can
smoke."
^ permalink raw reply
* Re: kernel performance update - 2.6.14-rc3
From: Andi Kleen @ 2005-10-06 10:32 UTC (permalink / raw)
To: Chen, Kenneth W; +Cc: linux-kernel, netdev
In-Reply-To: <200510052115.j95LFgg07836@unix-os.sc.intel.com>
"Chen, Kenneth W" <kenneth.w.chen@intel.com> writes:
> Even though
> softirq is invoked at the end of dev_queue_xmit() via local_bh_enable(),
> not all execution of softirq will result a __wake_up(). With higher
> HZ rate, timer interrupt is more frequent and thus more softirq
> invocation and leads to more __wake_up(), which then takes us to higher
> throughput because cpu spend less time in idle.
This sounds like a serious bug somewhere if true.
-Andi
^ permalink raw reply
* [PATCH] sis900: come alive after temporary memory shortage
From: Daniele Venzano @ 2005-10-06 10:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: NetDev, Jeff Garzik, Stanislav Protassov, Vasily Averin
In-Reply-To: <4337FF9D.70200@sw.ru>
This patch is good and fixes some corner cases. Please consider for
inclusion.
On Mon, Sep 26, 2005 at 06:03:09PM +0400, Konstantin Khorenko wrote:
> Patch solves following problems:
> 1) Forgotten counter incrementation in sis900_rx() in case
> it doesn't get memory for skb, that leads to whole interface failure.
> Problem is accompanied with messages:
> eth0: Memory squeeze,deferring packet.
> eth0: NULL pointer encountered in Rx ring, skipping
> 2) If counter cur_rx overflows and there'll be temporary memory problems
> buffer can't be recreated later, when memory IS avaliable.
> 3) Limit the work in handler to prevent the endless packets processing if
> new packets are generated faster then handled.
>
> Signed-off-by: Konstantin Khorenko <khorenko@sw.ru>
> Signed-off-by: Vasily Averin <vvs@sw.ru>
Signed-off-by: Daniele Venzano <venza@brownhat.org>
--- main-2.6.13.1/drivers/net/sis900.c.sis900 2005-08-29 03:41:01.000000000 +0400
+++ main-2.6.13.1/drivers/net/sis900.c 2005-09-19 14:34:42.000000000 +0400
@@ -1696,6 +1696,8 @@ static int sis900_rx(struct net_device *
long ioaddr = net_dev->base_addr;
unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC;
u32 rx_status = sis_priv->rx_ring[entry].cmdsts;
+ int rx_work_limit =
+ (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;
if (netif_msg_rx_status(sis_priv))
printk(KERN_DEBUG "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d "
@@ -1705,6 +1713,8 @@ static int sis900_rx(struct net_device *
while (rx_status & OWN) {
unsigned int rx_size;
+ if (--rx_work_limit < 0)
+ break;
rx_size = (rx_status & DSIZE) - CRC_SIZE;
if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) {
@@ -1770,6 +1780,7 @@ static int sis900_rx(struct net_device *
sis_priv->rx_ring[entry].cmdsts = 0;
sis_priv->rx_ring[entry].bufptr = 0;
sis_priv->stats.rx_dropped++;
+ sis_priv->cur_rx++;
break;
}
skb->dev = net_dev;
@@ -1787,7 +1798,7 @@ static int sis900_rx(struct net_device *
/* refill the Rx buffer, what if the rate of refilling is slower
* than consuming ?? */
- for (;sis_priv->cur_rx - sis_priv->dirty_rx > 0; sis_priv->dirty_rx++) {
+ for (; sis_priv->cur_rx != sis_priv->dirty_rx; sis_priv->dirty_rx++) {
struct sk_buff *skb;
entry = sis_priv->dirty_rx % NUM_RX_DESC;
--
------------------------------
Daniele Venzano
Web: http://teg.homeunix.org
^ permalink raw reply
* [PATCH] Add Wake on LAN support to sis900
From: Daniele Venzano @ 2005-10-06 11:13 UTC (permalink / raw)
To: Jeff Garzik, NetDev; +Cc: akpm
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
The patch availble below adds support for Wake on LAN to the sis900
driver. Some register addresses were added to sis900.h and two new
functions were implemented in sis900.c. WoL status is controlled by
ethtool.
Patch is against 2.6.13.
Comments are welcome, but also consider for inclusion in the -mm series.
Signed-off-by: Daniele Venzano <venza@brownhat.org>
--
------------------------------
Daniele Venzano
Web: http://teg.homeunix.org
[-- Attachment #2: sis900_c_127.diff --]
[-- Type: text/plain, Size: 5526 bytes --]
--- ../../trunk/sis900.h 2005-07-17 10:43:23.000000000 +0200
+++ sis900.h 2005-10-06 12:49:37.000000000 +0200
@@ -33,6 +33,7 @@
rxcfg=0x34, //Receive Configuration Register
flctrl=0x38, //Flow Control Register
rxlen=0x3c, //Receive Packet Length Register
+ cfgpmcsr=0x44, //Configuration Power Management Control/Status Register
rfcr=0x48, //Receive Filter Control Register
rfdr=0x4C, //Receive Filter Data Register
pmctrl=0xB0, //Power Management Control Register
@@ -140,6 +141,50 @@
EEREQ = 0x00000400, EEDONE = 0x00000200, EEGNT = 0x00000100
};
+/* PCI Registers */
+enum sis900_pci_registers {
+ CFGPMC = 0x40,
+ CFGPMCSR = 0x44
+};
+
+/* Power management capabilities bits */
+enum sis900_cfgpmc_register_bits {
+ PMVER = 0x00070000,
+ DSI = 0x00100000,
+ PMESP = 0xf8000000
+};
+
+enum sis900_pmesp_bits {
+ PME_D0 = 0x1,
+ PME_D1 = 0x2,
+ PME_D2 = 0x4,
+ PME_D3H = 0x8,
+ PME_D3C = 0x10
+};
+
+/* Power management control/status bits */
+enum sis900_cfgpmcsr_register_bits {
+ PMESTS = 0x00004000,
+ PME_EN = 0x00000100, // Power management enable
+ PWR_STA = 0x00000003 // Current power state
+};
+
+/* Wake-on-LAN support. */
+enum sis900_power_management_control_register_bits {
+ LINKLOSS = 0x00000001,
+ LINKON = 0x00000002,
+ MAGICPKT = 0x00000400,
+ ALGORITHM = 0x00000800,
+ FRM1EN = 0x00100000,
+ FRM2EN = 0x00200000,
+ FRM3EN = 0x00400000,
+ FRM1ACS = 0x01000000,
+ FRM2ACS = 0x02000000,
+ FRM3ACS = 0x04000000,
+ WAKEALL = 0x40000000,
+ GATECLK = 0x80000000
+};
+
/* Management Data I/O (mdio) frame */
#define MIIread 0x6000
#define MIIwrite 0x5002
--- ../../trunk/sis900.c 2005-10-06 12:06:06.000000000 +0200
+++ sis900.c 2005-10-06 12:05:45.000000000 +0200
@@ -1,6 +1,6 @@
/* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux.
Copyright 1999 Silicon Integrated System Corporation
- Revision: 1.08.08 Jan. 22 2005
+ Revision: 1.08.09 Sep. 19 2005
Modified from the driver which is originally written by Donald Becker.
@@ -17,6 +17,7 @@
SiS 7014 Single Chip 100BASE-TX/10BASE-T Physical Layer Solution,
preliminary Rev. 1.0 Jan. 18, 1998
+ Rev 1.08.09 Sep. 19 2005 Daniele Venzano add Wake on LAN support
Rev 1.08.08 Jan. 22 2005 Daniele Venzano use netif_msg for debugging messages
Rev 1.08.07 Nov. 2 2003 Daniele Venzano <webvenza@libero.it> add suspend/resume support
Rev 1.08.06 Sep. 24 2002 Mufasa Yang bug fix for Tx timeout & add SiS963 support
@@ -76,7 +77,7 @@
#include "sis900.h"
#define SIS900_MODULE_NAME "sis900"
-#define SIS900_DRV_VERSION "v1.08.08 Jan. 22 2005"
+#define SIS900_DRV_VERSION "v1.08.09 Sep. 19 2005"
static char version[] __devinitdata =
KERN_INFO "sis900.c: " SIS900_DRV_VERSION "\n";
@@ -538,6 +539,11 @@
printk("%2.2x:", (u8)net_dev->dev_addr[i]);
printk("%2.2x.\n", net_dev->dev_addr[i]);
+ /* Detect Wake on Lan support */
+ ret = inl(CFGPMC & PMESP);
+ if (netif_msg_probe(sis_priv) && (ret & PME_D3C) == 0)
+ printk(KERN_INFO "%s: Wake on LAN only available from suspend to RAM.", net_dev->name);
+
return 0;
err_unmap_rx:
@@ -2007,6 +2013,67 @@
return mii_nway_restart(&sis_priv->mii_info);
}
+/**
+ * sis900_set_wol - Set up Wake on Lan registers
+ * @net_dev: the net device to probe
+ * @wol: container for info passed to the driver
+ *
+ * Process ethtool command "wol" to setup wake on lan features.
+ * SiS900 supports sending WoL events if a correct packet is received,
+ * but there is no simple way to filter them to only a subset (broadcast,
+ * multicast, unicast or arp).
+ */
+
+static int sis900_set_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol)
+{
+ struct sis900_private *sis_priv = net_dev->priv;
+ long pmctrl_addr = net_dev->base_addr + pmctrl;
+ u32 cfgpmcsr = 0, pmctrl_bits = 0;
+
+ if (wol->wolopts == 0) {
+ pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr);
+ cfgpmcsr |= ~PME_EN;
+ pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr);
+ outl(pmctrl_bits, pmctrl_addr);
+ if (netif_msg_wol(sis_priv))
+ printk(KERN_DEBUG "%s: Wake on LAN disabled\n", net_dev->name);
+ return 0;
+ }
+
+ if (wol->wolopts & (WAKE_MAGICSECURE | WAKE_UCAST | WAKE_MCAST
+ | WAKE_BCAST | WAKE_ARP))
+ return -EINVAL;
+
+ if (wol->wolopts & WAKE_MAGIC)
+ pmctrl_bits |= MAGICPKT;
+ if (wol->wolopts & WAKE_PHY)
+ pmctrl_bits |= LINKON;
+
+ outl(pmctrl_bits, pmctrl_addr);
+
+ pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr);
+ cfgpmcsr |= PME_EN;
+ pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr);
+ if (netif_msg_wol(sis_priv))
+ printk(KERN_DEBUG "%s: Wake on LAN enabled\n", net_dev->name);
+
+ return 0;
+}
+
+static void sis900_get_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol)
+{
+ long pmctrl_addr = net_dev->base_addr + pmctrl;
+ u32 pmctrl_bits;
+
+ pmctrl_bits = inl(pmctrl_addr);
+ if (pmctrl_bits & MAGICPKT)
+ wol->wolopts |= WAKE_MAGIC;
+ if (pmctrl_bits & LINKON)
+ wol->wolopts |= WAKE_PHY;
+
+ wol->supported = (WAKE_PHY | WAKE_MAGIC);
+}
+
static struct ethtool_ops sis900_ethtool_ops = {
.get_drvinfo = sis900_get_drvinfo,
.get_msglevel = sis900_get_msglevel,
@@ -2015,6 +2082,8 @@
.get_settings = sis900_get_settings,
.set_settings = sis900_set_settings,
.nway_reset = sis900_nway_reset,
+ .get_wol = sis900_get_wol,
+ .set_wol = sis900_set_wol
};
/**
^ permalink raw reply
* RE: [NFS] [RFC: 2.6 patch] net/sunrpc/: possible cleanups
From: Lever, Charles @ 2005-10-06 14:13 UTC (permalink / raw)
To: Adrian Bunk, David Miller
Cc: neilb, trond.myklebust, linux-kernel, nfs, netdev
actually, can we hold off on this change? the RPC transport switch will
eventually need most of those EXPORT_SYMBOLs.
the only harmless change i see below is removing xdr_decode_string().
> -----Original Message-----
> From: Adrian Bunk [mailto:bunk@stusta.de]
> Sent: Saturday, October 01, 2005 10:21 AM
> To: David Miller
> Cc: neilb@cse.unsw.edu.au; trond.myklebust@fys.uio.no;
> linux-kernel@vger.kernel.org; nfs@lists.sourceforge.net;
> netdev@vger.kernel.org
> Subject: [NFS] [RFC: 2.6 patch] net/sunrpc/: possible cleanups
>
> This patch contains the following possible cleanups:
> - make needlessly global code static
> - #if 0 the following unused global function:
> - xdr.c: xdr_decode_string
> - remove the following unneeded EXPORT_SYMBOL's:
> - auth_gss/gss_mech_switch.c: gss_mech_get
> - auth_gss/gss_mech_switch.c: gss_mech_get_by_name
> - auth_gss/gss_mech_switch.c: gss_mech_get_by_pseudoflavor
> - auth_gss/gss_mech_switch.c: gss_pseudoflavor_to_service
> - auth_gss/gss_mech_switch.c: gss_service_to_auth_domain_name
> - auth_gss/gss_mech_switch.c: gss_mech_put
> - sunrpc_syms.c: rpc_wake_up_next
> - sunrpc_syms.c: rpc_new_child
> - sunrpc_syms.c: rpc_run_child
> - sunrpc_syms.c: rpc_new_task
> - sunrpc_syms.c: rpc_release_task
> - sunrpc_syms.c: rpc_release_client
> - sunrpc_syms.c: xprt_udp_slot_table_entries
> - sunrpc_syms.c: xprt_tcp_slot_table_entries
> - sunrpc_syms.c: svc_drop
> - sunrpc_syms.c: svc_authenticate
> - sunrpc_syms.c: xdr_decode_string
>
> Please review which of these patches do make sense and which conflict
> with pending patches.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> This patch was already sent on:
> - 30 May 2005
> - 7 May 2005
>
> include/linux/sunrpc/clnt.h | 1 -
> include/linux/sunrpc/gss_api.h | 3 ---
> include/linux/sunrpc/xdr.h | 2 --
> net/sunrpc/auth_gss/gss_mech_switch.c | 13 +------------
> net/sunrpc/clnt.c | 3 ++-
> net/sunrpc/sunrpc_syms.c | 11 -----------
> net/sunrpc/xdr.c | 4 +++-
> 7 files changed, 6 insertions(+), 31 deletions(-)
>
> ---
> linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/gss_api.h.old
> 2005-05-05 23:05:01.000000000 +0200
> +++ linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/gss_api.h
> 2005-05-05 23:05:10.000000000 +0200
> @@ -110,9 +110,6 @@
> /* Similar, but get by pseudoflavor. */
> struct gss_api_mech *gss_mech_get_by_pseudoflavor(u32);
>
> -/* Just increments the mechanism's reference count and
> returns its input: */
> -struct gss_api_mech * gss_mech_get(struct gss_api_mech *);
> -
> /* For every succesful gss_mech_get or gss_mech_get_by_*
> call there must be a
> * corresponding call to gss_mech_put. */
> void gss_mech_put(struct gss_api_mech *);
> ---
> linux-2.6.12-rc3-mm3-full/net/sunrpc/auth_gss/gss_mech_switc
> h.c.old 2005-05-05 23:05:17.000000000 +0200
> +++
> linux-2.6.12-rc3-mm3-full/net/sunrpc/auth_gss/gss_mech_s
> witch.c 2005-05-05 23:19:33.000000000 +0200
> @@ -133,14 +133,13 @@
>
> EXPORT_SYMBOL(gss_mech_unregister);
>
> -struct gss_api_mech *
> +static struct gss_api_mech *
> gss_mech_get(struct gss_api_mech *gm)
> {
> __module_get(gm->gm_owner);
> return gm;
> }
>
> -EXPORT_SYMBOL(gss_mech_get);
>
> struct gss_api_mech *
> gss_mech_get_by_name(const char *name)
> @@ -160,8 +159,6 @@
>
> }
>
> -EXPORT_SYMBOL(gss_mech_get_by_name);
> -
> static inline int
> mech_supports_pseudoflavor(struct gss_api_mech *gm, u32 pseudoflavor)
> {
> @@ -193,8 +190,6 @@
> return gm;
> }
>
> -EXPORT_SYMBOL(gss_mech_get_by_pseudoflavor);
> -
> u32
> gss_pseudoflavor_to_service(struct gss_api_mech *gm, u32
> pseudoflavor)
> {
> @@ -207,8 +202,6 @@
> return 0;
> }
>
> -EXPORT_SYMBOL(gss_pseudoflavor_to_service);
> -
> char *
> gss_service_to_auth_domain_name(struct gss_api_mech *gm, u32 service)
> {
> @@ -221,16 +214,12 @@
> return NULL;
> }
>
> -EXPORT_SYMBOL(gss_service_to_auth_domain_name);
> -
> void
> gss_mech_put(struct gss_api_mech * gm)
> {
> module_put(gm->gm_owner);
> }
>
> -EXPORT_SYMBOL(gss_mech_put);
> -
> /* The mech could probably be determined from the token
> instead, but it's just
> * as easy for now to pass it in. */
> int
> --- linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/clnt.h.old
> 2005-05-05 23:05:45.000000000 +0200
> +++ linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/clnt.h
> 2005-05-05 23:05:50.000000000 +0200
> @@ -134,7 +134,6 @@
> void rpc_clnt_sigunmask(struct rpc_clnt *clnt,
> sigset_t *oldset);
> void rpc_setbufsize(struct rpc_clnt *, unsigned int,
> unsigned int);
> size_t rpc_max_payload(struct rpc_clnt *);
> -int rpc_ping(struct rpc_clnt *clnt, int flags);
>
> static __inline__
> int rpc_call(struct rpc_clnt *clnt, u32 proc, void *argp,
> void *resp, int flags)
> --- linux-2.6.12-rc3-mm3-full/net/sunrpc/clnt.c.old
> 2005-05-05 23:05:58.000000000 +0200
> +++ linux-2.6.12-rc3-mm3-full/net/sunrpc/clnt.c
> 2005-05-05 23:06:21.000000000 +0200
> @@ -63,6 +63,7 @@
> static u32 * call_header(struct rpc_task *task);
> static u32 * call_verify(struct rpc_task *task);
>
> +static int rpc_ping(struct rpc_clnt *clnt, int flags);
>
> static int
> rpc_setup_pipedir(struct rpc_clnt *clnt, char *dir_name)
> @@ -1178,7 +1179,7 @@
> .p_decode = rpcproc_decode_null,
> };
>
> -int rpc_ping(struct rpc_clnt *clnt, int flags)
> +static int rpc_ping(struct rpc_clnt *clnt, int flags)
> {
> struct rpc_message msg = {
> .rpc_proc = &rpcproc_null,
> --- linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/xdr.h.old
> 2005-05-05 23:06:40.000000000 +0200
> +++ linux-2.6.12-rc3-mm3-full/include/linux/sunrpc/xdr.h
> 2005-05-05 23:07:23.000000000 +0200
> @@ -91,7 +91,6 @@
> u32 * xdr_encode_opaque_fixed(u32 *p, const void
> *ptr, unsigned int len);
> u32 * xdr_encode_opaque(u32 *p, const void *ptr,
> unsigned int len);
> u32 * xdr_encode_string(u32 *p, const char *s);
> -u32 * xdr_decode_string(u32 *p, char **sp, int *lenp,
> int maxlen);
> u32 * xdr_decode_string_inplace(u32 *p, char **sp,
> int *lenp, int maxlen);
> u32 * xdr_encode_netobj(u32 *p, const struct xdr_netobj *);
> u32 * xdr_decode_netobj(u32 *p, struct xdr_netobj *);
> @@ -147,7 +146,6 @@
> extern int xdr_buf_subsegment(struct xdr_buf *, struct
> xdr_buf *, int, int);
> extern int xdr_buf_read_netobj(struct xdr_buf *, struct
> xdr_netobj *, int);
> extern int read_bytes_from_xdr_buf(struct xdr_buf *, int,
> void *, int);
> -extern int write_bytes_to_xdr_buf(struct xdr_buf *, int,
> void *, int);
>
> /*
> * Helper structure for copying from an sk_buff.
> --- linux-2.6.12-rc3-mm3-full/net/sunrpc/xdr.c.old
> 2005-05-05 23:06:52.000000000 +0200
> +++ linux-2.6.12-rc3-mm3-full/net/sunrpc/xdr.c
> 2005-05-05 23:07:56.000000000 +0200
> @@ -95,6 +95,7 @@
> return xdr_encode_array(p, string, strlen(string));
> }
>
> +#if 0
> u32 *
> xdr_decode_string(u32 *p, char **sp, int *lenp, int maxlen)
> {
> @@ -115,6 +116,7 @@
> *sp = string;
> return p + XDR_QUADLEN(len);
> }
> +#endif /* 0 */
>
> u32 *
> xdr_decode_string_inplace(u32 *p, char **sp, int *lenp, int maxlen)
> @@ -882,7 +884,7 @@
> }
>
> /* obj is assumed to point to allocated memory of size at
> least len: */
> -int
> +static int
> write_bytes_to_xdr_buf(struct xdr_buf *buf, int base, void
> *obj, int len)
> {
> struct xdr_buf subbuf;
> --- linux-2.6.12-rc3-mm3-full/net/sunrpc/sunrpc_syms.c.old
> 2005-05-05 23:07:30.000000000 +0200
> +++ linux-2.6.12-rc3-mm3-full/net/sunrpc/sunrpc_syms.c
> 2005-05-05 23:36:43.000000000 +0200
> @@ -29,15 +29,10 @@
> EXPORT_SYMBOL(rpc_execute);
> EXPORT_SYMBOL(rpc_init_task);
> EXPORT_SYMBOL(rpc_sleep_on);
> -EXPORT_SYMBOL(rpc_wake_up_next);
> EXPORT_SYMBOL(rpc_wake_up_task);
> -EXPORT_SYMBOL(rpc_new_child);
> -EXPORT_SYMBOL(rpc_run_child);
> EXPORT_SYMBOL(rpciod_down);
> EXPORT_SYMBOL(rpciod_up);
> -EXPORT_SYMBOL(rpc_new_task);
> EXPORT_SYMBOL(rpc_wake_up_status);
> -EXPORT_SYMBOL(rpc_release_task);
>
> /* RPC client functions */
> EXPORT_SYMBOL(rpc_create_client);
> @@ -45,7 +40,6 @@
> EXPORT_SYMBOL(rpc_bind_new_program);
> EXPORT_SYMBOL(rpc_destroy_client);
> EXPORT_SYMBOL(rpc_shutdown_client);
> -EXPORT_SYMBOL(rpc_release_client);
> EXPORT_SYMBOL(rpc_killall_tasks);
> EXPORT_SYMBOL(rpc_call_sync);
> EXPORT_SYMBOL(rpc_call_async);
> @@ -63,8 +57,6 @@
> /* Client transport */
> EXPORT_SYMBOL(xprt_create_proto);
> EXPORT_SYMBOL(xprt_set_timeout);
> -EXPORT_SYMBOL(xprt_udp_slot_table_entries);
> -EXPORT_SYMBOL(xprt_tcp_slot_table_entries);
>
> /* Client credential cache */
> EXPORT_SYMBOL(rpcauth_register);
> @@ -81,7 +73,6 @@
> EXPORT_SYMBOL(svc_create_thread);
> EXPORT_SYMBOL(svc_exit_thread);
> EXPORT_SYMBOL(svc_destroy);
> -EXPORT_SYMBOL(svc_drop);
> EXPORT_SYMBOL(svc_process);
> EXPORT_SYMBOL(svc_recv);
> EXPORT_SYMBOL(svc_wake_up);
> @@ -89,7 +80,6 @@
> EXPORT_SYMBOL(svc_reserve);
> EXPORT_SYMBOL(svc_auth_register);
> EXPORT_SYMBOL(auth_domain_lookup);
> -EXPORT_SYMBOL(svc_authenticate);
> EXPORT_SYMBOL(svc_set_client);
>
> /* RPC statistics */
> @@ -122,7 +112,6 @@
>
> /* Generic XDR */
> EXPORT_SYMBOL(xdr_encode_string);
> -EXPORT_SYMBOL(xdr_decode_string);
> EXPORT_SYMBOL(xdr_decode_string_inplace);
> EXPORT_SYMBOL(xdr_decode_netobj);
> EXPORT_SYMBOL(xdr_encode_netobj);
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>
^ permalink raw reply
* Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
From: Bill Davidsen @ 2005-10-06 15:09 UTC (permalink / raw)
To: Michael Bellion; +Cc: Emmanuel Fleury, linux-kernel, linux-net, netdev, jamal
In-Reply-To: <200509261638.12731.mbellion@hipac.org>
[-- Attachment #1: Type: text/plain, Size: 5357 bytes --]
Michael Bellion wrote:
>Hi
>
>
>
>>I'm still not convinced by your approach. :-/
>>
>>
>
>You really should have a closer look at nf-HiPAC so that you know what you are
>talking about!
>
>Your Compact Filter takes a completely different approach than nf-HiPAC to
>build the data structure used in the kernel for the packet classification
>lookup.
>
>Your Compact Filter uses a static compiler in user space. That compiler
>transforms the rule set into boolean expressions and than uses operations
>from predicate logic to optimize the rule set.
>This has the big drawback that whenever only a single rule changes you have to
>recompile the complete lookup data structure. So this approach is clearly not
>suitable for scenarios depending on dynamic rule sets.
>
>nf-HiPAC uses a completely different approach to build the lookup data
>structure in the kernel. It is based on geometry.
>This approach allows completely dynamic updates. During an update of the rules
>only the required changes of the lookup data structure are made. The data
>structure is NOT rebuild from scratch. This guarantees that the packet
>processing is only affected to the least possible amount during updates.
>
>Although nf-HiPAC and Compact Filter use completely different approaches and
>algorithms to build the lookup data structure it is important that you
>understand the following:
>nf-HiPAC and Compact filter end up with a very very similar lookup data
>structure in the kernel.
>
>
>
>
>>These experiments have to be updated but can you comment on this:
>>http://www.cs.aau.dk/~mixxel/cf/experiments.html
>>
>>
>
>The current version of the algorithm used in nf-HiPAC does not optimize
>certain aspects of the lookup data structure in order to increase the speed
>of dynamic rule set updates.
>This means that the lookup data structure is larger than it really needs to be
>because it contains some unnecessary redundancy.
>This explains your test results.
>Compact Filter and nf-HiPAC perform the same when they are both able to keep
>their lookup data structure in the CPU caches and when they are both not able
>to do so anymore.
>Compact Filter is currently able to perform better in the area where it is
>able to keep its data structure still in the caches while nf-HiPAC is not
>able to do so anymore.
>
>
It would seem, looking at the provided results and author's comments,
that the following are true:
- for small static rulesets there is little difference, my 200-600
rules run fine in either
- for very large rulesets cf will currently perform better (if this is
due to cache effects, may be less
evident, since the server runs an application rather than being a
dedicated network device).
- cf can't do large dynamic rulesets, compile time > change interval
- the iptables results don't represent server use with persistent
sockets, like mail/usenet, in which
most (~95%) packets match the first rule in INPUT (ESTABLISHED ->
ACCEPT) and the complexity is
in processing TCP/SYN packets and forwarding rules.
Also: none of the results I've seen show the effect of many tracked
sockets, the performance of one stream pushing a lot of packets is not
the same as the same bitrate coming from 500-5k source IPs, at least if
you use the INPUT rule noted above.
>Most aspects of your performance tests are quite nice (e.g. the generating the
>traffic by replaying a packet header trace).
>But your performance tests have a serious flaw:
>You construct your rule set by creating one rule for each entry in your packet
>header trace. This results in an completely artificial rule set that creates
>a lot of redundancy in the nf-HiPAC lookup data structure making it much
>larger than the Compact Filter data structure.
>
>You have to understand that with real world rule sets the size of the computed
>lookup data structure will not be much different for Compact Filter and
>nf-HiPAC. This means that when you use real world rule sets there shouldn't
>be any noticeable difference in lookup performance betweeen Compact Filter
>and nf-HiPAC.
>
>-----------------
>
>I am currently working on a new improved version of the algorithm used in
>nf-HiPAC. The new algorithmic core will reduce memory usage while at the same
>time improving the running time of insert and delete operations. The lookup
>performance will be improved too, especially for bigger rulesets. The
>concepts and the design are already developed, but the implementation is
>still in its early stages.
>
>The new algorithmic core will make sure that the lookup data structure in the
>kernel is always fully optimized while at the same time allowing very fast
>dynamic updates.
>
>At that point Compact Filter will not be able to win in any performance test
>against nf-HiPAC anymore, simply because there is no way to optimize the
>lookup data structure any further.
>
The nf-HiPAC advantage seems to be in applications with moderate to
large dynamic rulesets, in that it allows a lot of changes quickly.
Don't give that up for throughput, the idea of being able to do 5-7
changes/sec on a 500-2k ruleset is exciting, and in some cases vital.
Thanks to everyone working on improvements.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
[-- Attachment #2: Type: text/html, Size: 6222 bytes --]
^ permalink raw reply
* Re: [PATCH SECURITY]: orinoco: Information leakage due to incorrect
From: Jean Tourrilhes @ 2005-10-06 16:33 UTC (permalink / raw)
To: Pavel Roskin, Orinoco Devel, netdev-u79uwXL29TY76Z2rM5mHXA
Pavel Roskin wrote :
>
> orinoco: Information leakage due to incorrect padding
>
> The orinoco driver can send uninitialized data exposing random pieces of
> the system memory. This happens because data is not padded with zeroes
> when its length needs to be increased.
I believe the 802.11 doesn't specify and doesn't require
padding, therefore in theory, none of the 802.11 drivers need to do
padding.
Padding is specific to the way the original Ethernet protocol
detect collisions over the wire, it require a minimum message length
due to the propagation and reflection time of the packet. Propagation
time is way faster over the air and we can't detect collisions anyway,
therefore it doesn't make sense to implement padding. It's just
unnecessary overhead.
Now, I'm not 100% certain that all firmware and TCP/IP stack
would be happy with that, but it's worth a try at some point.
Have fun...
Jean
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Andi Kleen @ 2005-10-06 17:59 UTC (permalink / raw)
To: Harald Welte, Andi Kleen, Patrick McHardy, netdev,
netfilter-devel, linux-kernel, Henrik Nordstrom
In-Reply-To: <20051007023801.GA5953@rama>
On Fri, Oct 07, 2005 at 04:38:02AM +0200, Harald Welte wrote:
> On Wed, Oct 05, 2005 at 06:53:31PM +0200, Andi Kleen wrote:
> > On Tuesday 04 October 2005 19:01, Patrick McHardy wrote:
> > > Andi Kleen wrote:
> > > > In a sense it's even getting worse: For example us losing the CONFIG
> > > > option to disable local conntrack (Patrick has disabled it some time ago
> > > > without even a comment why he did it) has a really bad impact in some
> > > > cases.
> > >
> > > It was necessary to correctly handle locally generated ICMP errors.
> >
> > Well you most likely wrecked local performance then when it's enabled.
>
> so you would favour a system that incorrectly deals with ICMP errors but
> has higher performance?
I would favour a system where development doesn't lose sight of performance.
Perhaps there would be other ways to fix this problem without impacting
performance unduly? Can you describe it in detail?
-Andi
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Jeff V. Merkey @ 2005-10-06 20:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <20051006140007.43262f04@dxpl.pdx.osdl.net>
Stephen Hemminger wrote:
>There is now a wiki for Linux networking related activities and documentation.
> http://linux-net.osdl.org
>This is an experiment to see if it would be more useful to have
>an online and editable documentation source rather than bits and pieces.
>
>Also, it should interact well with Wikipedia, since we can link to have
>the generic descriptions of things like protocols (TCP, bridging, bonding,
>VLAN's,...) and the Linux implementation.
>
>I filled in my stuff, and Acme and Ian have been adding DCCP and
>the TODO list.
>
>
>
Nice site. I'll post the sources for the gcc Wikibuilder when I am done
with it and you can use it as well. Wikimedia extensions are
GPL of course.
Jeff
^ permalink raw reply
* [ANNOUNCE] linux-net wiki
From: Stephen Hemminger @ 2005-10-06 21:00 UTC (permalink / raw)
To: netdev; +Cc: linux-net, linux-kernel
There is now a wiki for Linux networking related activities and documentation.
http://linux-net.osdl.org
This is an experiment to see if it would be more useful to have
an online and editable documentation source rather than bits and pieces.
Also, it should interact well with Wikipedia, since we can link to have
the generic descriptions of things like protocols (TCP, bridging, bonding,
VLAN's,...) and the Linux implementation.
I filled in my stuff, and Acme and Ian have been adding DCCP and
the TODO list.
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* Get rid of everything you owe without paying another dime
From: jamie barnes @ 2005-10-06 21:22 UTC (permalink / raw)
To: Phung Green
Cc: owner-lkcd, bowman, xfs-master, outgoing, ralf, netdev,
bugzilla-daemon
Eliminate all you are indebted for with out paying another cent. End the
calls. Bring a stop to the sending of checks! As it turns out most lending
orgizations are doing something illegal. Incredible but right! Visit our web
site for detailed information on the subject our system at N O expense or
requirement. You have naught to lose and heaps to gain.
http://uk.geocities.com/blossom_regan/?re=bVT.Eradicate all that you owe
without sending an other dime
Exhaustive information or to stop receiving or to comprehend postal address
Before the surprised and baffled scientist could collect himself
sufficiently to reply, the boy was soaring far above his head and searching
for a convenient place to alight, that he might investigate the charms of
this famed city of Paris. It was indeed a beautiful place, with many stately
buildings lining the shady boulevards
So thronged were the streets that Rob well knew he would soon be the center
of a curious crowd should he alight upon them
^ permalink raw reply
* [RFC] ipw2200: check version in eeprom correctly
From: Alexey Dobriyan @ 2005-10-06 21:40 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
I'm not 100% sure the fix is right, but the condition looks bogus:
->eeprom is "u8 eeprom[256]".
drivers/net/wireless/ipw2200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- ./drivers/net/wireless/ipw2200.c
+++ ./drivers/net/wireless/ipw2200.c
@@ -1699,7 +1699,7 @@ static void ipw_eeprom_init_sram(struct
copy. Otherwise let the firmware know to perform the operation
on it's own
*/
- if ((priv->eeprom + EEPROM_VERSION) != 0) {
+ if ((priv->eeprom[EEPROM_VERSION]) != 0) {
IPW_DEBUG_INFO("Writing EEPROM data into SRAM\n");
/* write the eeprom data to sram */
^ permalink raw reply
* [KJ] [PATCH] starfire: free_irq() on error path of netdev_open()
From: Alexey Dobriyan @ 2005-10-06 22:05 UTC (permalink / raw)
To: Ion Badulescu; +Cc: netdev, kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/starfire.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- ./drivers/net/starfire.c
+++ ./drivers/net/starfire.c
@@ -1091,8 +1091,10 @@ static int netdev_open(struct net_device
rx_ring_size = sizeof(struct starfire_rx_desc) * RX_RING_SIZE;
np->queue_mem_size = tx_done_q_size + rx_done_q_size + tx_ring_size + rx_ring_size;
np->queue_mem = pci_alloc_consistent(np->pci_dev, np->queue_mem_size, &np->queue_mem_dma);
- if (np->queue_mem == 0)
+ if (np->queue_mem == 0) {
+ free_irq(dev->irq, dev);
return -ENOMEM;
+ }
np->tx_done_q = np->queue_mem;
np->tx_done_q_dma = np->queue_mem_dma;
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Greg KH @ 2005-10-07 1:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <20051006140007.43262f04@dxpl.pdx.osdl.net>
On Thu, Oct 06, 2005 at 02:00:07PM -0700, Stephen Hemminger wrote:
> There is now a wiki for Linux networking related activities and documentation.
> http://linux-net.osdl.org
> This is an experiment to see if it would be more useful to have
> an online and editable documentation source rather than bits and pieces.
Why not just work with the existing kernelnewbies wiki:
http://wiki.kernelnewbies.org
instead of creating another site?
thanks,
greg k-h
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Ian McDonald @ 2005-10-07 1:34 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Hemminger, netdev, linux-net, linux-kernel
In-Reply-To: <20051007012454.GA9509@kroah.com>
>
> Why not just work with the existing kernelnewbies wiki:
> http://wiki.kernelnewbies.org
> instead of creating another site?
>
Having a quick look around and looking at the name in particular I
think they are different target audiences...
If it was kerneloldies.org it might be different ;-)
Ian
^ permalink raw reply
* Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
From: Harald Welte @ 2005-10-07 2:38 UTC (permalink / raw)
To: Andi Kleen
Cc: Patrick McHardy, netdev, netfilter-devel, linux-kernel,
Henrik Nordstrom
In-Reply-To: <200510051853.32196.ak@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Wed, Oct 05, 2005 at 06:53:31PM +0200, Andi Kleen wrote:
> On Tuesday 04 October 2005 19:01, Patrick McHardy wrote:
> > Andi Kleen wrote:
> > > In a sense it's even getting worse: For example us losing the CONFIG
> > > option to disable local conntrack (Patrick has disabled it some time ago
> > > without even a comment why he did it) has a really bad impact in some
> > > cases.
> >
> > It was necessary to correctly handle locally generated ICMP errors.
>
> Well you most likely wrecked local performance then when it's enabled.
so you would favour a system that incorrectly deals with ICMP errors but
has higher performance?
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH SECURITY]: orinoco: Information leakage due to incorrect padding
From: Jouni Malinen @ 2005-10-07 3:25 UTC (permalink / raw)
To: Pavel Roskin; +Cc: orinoco-devel, NetDev, Meder Kydyraliev
In-Reply-To: <1128475990.11708.21.camel@dv>
On Tue, Oct 04, 2005 at 09:33:10PM -0400, Pavel Roskin wrote:
> orinoco: Information leakage due to incorrect padding
>
> The orinoco driver can send uninitialized data exposing random pieces of
> the system memory. This happens because data is not padded with zeroes
> when its length needs to be increased.
Issue itself looks valid in the current implementation, but a better fix
would be to just remove the padding.
> - /* Length of the packet body */
> - /* FIXME: what if the skb is smaller than this? */
> - len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN - ETH_HLEN);
> + /* Check packet length, pad short packets, round up odd length */
> + len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN);
> + if (skb->len < len) {
> + skb = skb_padto(skb, len);
There is no ETH_ZLEN limit on IEEE 802.11 frames.
--
Jouni Malinen PGP id EFC895FA
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Stephen Hemminger @ 2005-10-07 4:45 UTC (permalink / raw)
To: Greg KH; +Cc: netdev, linux-net, linux-kernel
In-Reply-To: <20051007012454.GA9509@kroah.com>
On Thu, 6 Oct 2005 18:24:54 -0700
Greg KH <greg@kroah.com> wrote:
> On Thu, Oct 06, 2005 at 02:00:07PM -0700, Stephen Hemminger wrote:
> > There is now a wiki for Linux networking related activities and documentation.
> > http://linux-net.osdl.org
> > This is an experiment to see if it would be more useful to have
> > an online and editable documentation source rather than bits and pieces.
>
> Why not just work with the existing kernelnewbies wiki:
> http://wiki.kernelnewbies.org
> instead of creating another site?
Mainly because I started it out for my own linux networking projects,
then generalized it. If you look on kernelnewbies you will see that
there was already an MM wiki.
^ permalink raw reply
* Re: [ANNOUNCE] linux-net wiki
From: Diego Calleja @ 2005-10-07 8:15 UTC (permalink / raw)
To: Ian McDonald; +Cc: greg, shemminger, netdev, linux-net, linux-kernel, riel
In-Reply-To: <cbec11ac0510061834j53678e7cq@mail.gmail.com>
El Fri, 7 Oct 2005 14:34:10 +1300,
Ian McDonald <imcdnzl@gmail.com> escribió:
> >
> > Why not just work with the existing kernelnewbies wiki:
> > http://wiki.kernelnewbies.org
> > instead of creating another site?
> >
> Having a quick look around and looking at the name in particular I
> think they are different target audiences...
The fact that it's called "kernelnewbies" doesn't meant it's targetted only
to non-expert people - everybody, including me, you, Linus and all the "core"
kernel hackers are "newbies" WRT to some parts of the kernel. The one thing
that can keep someone being a newbie forever is considering himself an
"expert". In fact you can find some linux kernel "gurus" there...
Also, kernelnewbies is not linux-specific either so there's a chance that even
gurus could learn something interesting (and teach something to others).
Or at least that has always been the intention of the kernelnewbies project.
(That doesn't mean I'm against the linux-net wiki, I just wanted to point out
that kernelnewbies isn't just for "newbies" ;)
^ 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