Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH/RFC] [v2] TCP: use non-delayed ACK for congestion control RTT
From: Gavin McCullagh @ 2007-12-18 20:40 UTC (permalink / raw)
  To: netdev
In-Reply-To: <20071217134425.GD7409@nuim.ie>


The last attempt didn't take account of the situation where a timestamp
wasn't available and tcp_clean_rtx_queue() has to feed both the RTO and the
congestion avoidance.  This updated patch stores both RTTs, making the
delayed one available for the RTO and the other (ca_seq_rtt) available for
congestion control.


Signed-off-by: Gavin McCullagh <gavin.mccullagh@nuim.ie> 


diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 889c893..6fb7989 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2651,6 +2651,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
 	u32 cnt = 0;
 	u32 reord = tp->packets_out;
 	s32 seq_rtt = -1;
+	s32 ca_seq_rtt = -1;
 	ktime_t last_ackt = net_invalid_timestamp();
 
 	while ((skb = tcp_write_queue_head(sk)) && skb != tcp_send_head(sk)) {
@@ -2686,13 +2687,15 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
 				if (sacked & TCPCB_SACKED_RETRANS)
 					tp->retrans_out -= packets_acked;
 				flag |= FLAG_RETRANS_DATA_ACKED;
+				ca_seq_rtt = -1;
 				seq_rtt = -1;
 				if ((flag & FLAG_DATA_ACKED) ||
 				    (packets_acked > 1))
 					flag |= FLAG_NONHEAD_RETRANS_ACKED;
 			} else {
+				ca_seq_rtt = now - scb->when;
 				if (seq_rtt < 0) {
-					seq_rtt = now - scb->when;
+					seq_rtt = ca_seq_rtt;
 					if (fully_acked)
 						last_ackt = skb->tstamp;
 				}
@@ -2709,8 +2712,9 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
 			    !before(end_seq, tp->snd_up))
 				tp->urg_mode = 0;
 		} else {
+			ca_seq_rtt = now - scb->when;
 			if (seq_rtt < 0) {
-				seq_rtt = now - scb->when;
+				seq_rtt = ca_seq_rtt;
 				if (fully_acked)
 					last_ackt = skb->tstamp;
 			}
@@ -2772,8 +2776,8 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
 						 net_invalid_timestamp()))
 					rtt_us = ktime_us_delta(ktime_get_real(),
 								last_ackt);
-				else if (seq_rtt > 0)
-					rtt_us = jiffies_to_usecs(seq_rtt);
+				else if (ca_seq_rtt > 0)
+					rtt_us = jiffies_to_usecs(ca_seq_rtt);
 			}
 
 			ca_ops->pkts_acked(sk, pkts_acked, rtt_us);



^ permalink raw reply related

* [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: Brian Haley @ 2007-12-18 20:57 UTC (permalink / raw)
  To: David Miller, YOSHIFUJI Hideaki, David Stevens; +Cc: netdev@vger.kernel.org

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

Trying to connect() to an IPv6 link-local multicast address by
specifying the outgoing multicast interface doesn't work, you have to
bind to a device first with an SO_BINDTODEVICE setsockopt() call.  This
patch allows the IPV6_MULTICAST_IF setting to also control which
interface should be used for the connection, as specified in RFC 3493.

Signed-off-by: Brian Haley <brian.haley@hp.com>
---


[-- Attachment #2: mcast_oif.patch --]
[-- Type: text/x-patch, Size: 644 bytes --]

diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 2ed689a..0b1e7eb 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -123,9 +123,15 @@ ipv4_connected:
 				goto out;
 			}
 			sk->sk_bound_dev_if = usin->sin6_scope_id;
-			if (!sk->sk_bound_dev_if &&
-			    (addr_type & IPV6_ADDR_MULTICAST))
-				fl.oif = np->mcast_oif;
+		}
+
+		if ((addr_type & IPV6_ADDR_MULTICAST) && np->mcast_oif) {
+			if (sk->sk_bound_dev_if &&
+			    sk->sk_bound_dev_if != np->mcast_oif) {
+				err = -EINVAL;
+				goto out;
+			}
+			sk->sk_bound_dev_if = np->mcast_oif;
 		}
 
 		/* Connect to link-local address requires an interface */


^ permalink raw reply related

* Re: After many hours all outbound connections get stuck in SYN_SENT
From: Jan Engelhardt @ 2007-12-18 21:20 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: James Nichols, linux-kernel, Linux Netdev List
In-Reply-To: <47682F8C.20205@cosmosbay.com>


On Dec 18 2007 21:37, Eric Dumazet wrote:
>
> If turning off tcp_sack makes the problem go away, why dont you
> turn it off all the time ?
>
That would just be workaround. I welcome the efforts to track this;
not all users have the time to do so.
Disabling tcp_sack also disabled it kernel-wide, which, well... for
2.6.25 there is a TCPOPTSTRIP netfilter target slated with which
SACK could be stripped only for a given host list or processes from
a UID.

^ permalink raw reply

* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: David Stevens @ 2007-12-18 21:52 UTC (permalink / raw)
  To: Brian Haley; +Cc: David Miller, netdev@vger.kernel.org, YOSHIFUJI Hideaki
In-Reply-To: <47683452.8080102@hp.com>

Brian Haley <brian.haley@hp.com> wrote on 12/18/2007 12:57:54 PM:

> Trying to connect() to an IPv6 link-local multicast address by
> specifying the outgoing multicast interface doesn't work, you have to
> bind to a device first with an SO_BINDTODEVICE setsockopt() call.

        No, you simply have to specify sin6_scope_id for link-scope
addresses, like you do in unicast cases. Your patch requires them
to match (if specified), but I don't think IPV6_MULTICAST_IF should
override or require a match for a valid sin6_scope_id (or be an error).
        If I read it correctly, the existing code uses IPV6_MULTICAST_IF
if the sin6_scope_id is not set, otherwise honors the interface specified
in the connect. That seems like correct behaviour to me, and RFC 3493
doesn't address the relative precedence of the two that I see. This is
in the "linklocal" branch, and all unicast linklocal's require specifying
sin6_scope_id. Multicast doesn't if require a scope_id in the case where
you've done an IPV6_MULTICAST_IF, but it should still allow a different
scope_id when you have used IPV6_MULTICAST_IF.

        Do you have application code that you believe is correct that
doesn't work?

                                                                +-DLS


^ permalink raw reply

* Re: [ROSE] [AX25] possible circular locking
From: Jarek Poplawski @ 2007-12-18 22:04 UTC (permalink / raw)
  To: Pidoux; +Cc: Alexey Dobriyan, Ralf Baechle DL5RB, Linux Netdev List
In-Reply-To: <476837BF.3070207@free.fr>

On Tue, Dec 18, 2007 at 10:12:31PM +0100, Pidoux wrote:
> Hi,
>
> Thank you Jarek for the analysis of the circular locking dependency report.
> I applied the patch you proposed and it works well as soon as I am able to 
> reboot now without
> lock warning message and I can also killall kissattach.
>
> I tried also the patch without the loop, that is only spin_unlock_bh() 
> before calling
> ax25_disconnect() and spin_lock_bh() just after.
> It worked also well.
> However I must say that I only have one ax25 device running (ax0).
>
> Is the loop really necessary here ? in case there are more than one ax25 
> device ?
>
> Also, I will let my AX25 - ROSE application running in order to test the 
> system stability with the full patch.
> I will let you know the results in a while.

Thank you Bernard for the bravery!

The loop is only for debugging: I don't know exactly what is done
during this ax25_disconnect(), and how the list can change in the
meantime because of some other activities. So, it's e.g. against
possible list_del of this node - then some sockets would stay not
disconnected.

I think, it's up to Ralf or some other ax25 expert to judge if this
could be done like this. Since it's not used very often, I think
this should better stay during testing: if there are no warnings
- the loop isn't repeated; otherwise it could simply take a little
more time, but all sockets should be serviced, plus we know about
problems.

Thanks,
Jarek P.

^ permalink raw reply

* Re: RFC: igb: Intel 82575 gigabit ethernet driver (take #2)
From: Jeff Garzik @ 2007-12-18 22:33 UTC (permalink / raw)
  To: Kok, Auke
  Cc: NetDev, Arjan van de Ven, Jesse Brandeburg, Ronciak, John,
	Mitch Williams
In-Reply-To: <475F107A.8080201@intel.com>

Looks pretty decent.  Main comments (style mostly, driver operation path 
seems sound):

* kill the bitfields and unions [in descriptor structs].  they are not 
endian-safe as presented, generate poor code, and are otherwise undesirable.

* the basic operations are too verbose:  E1000_READ_REG(hw, REGISTER) is 
far more readable as ER32(REGISTER), following the style of other 
drivers.  Furthermore, the "E1000_" prefix, in addition to being overly 
redundant (used in each register read/write), it is also incorrect, 
because this is not E1000...

* in general, rename everything with "e1000_" prefix.  this will 
eliminate plenty of human confusion in the long run.

* API:   unless you have chips in the lab that will require an API hook, 
don't create one.  For example, a direct call to 
e1000_acquire_nvm_82575() should replace all ->acquire_nvm() hooks.... 
if there are no chips in pipeline GUARANTEED to have a different 
->acquire_nvm() feature.

In general, I try to communicate that I am not opposed to these hooks, 
you merely need to make sure they are needed in _each_ case.  Otherwise 
engineers WILL fall into the habit of writing bloated code simply 
because that's what their chosen driver framework has always done.

	Jeff









^ permalink raw reply

* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: Brian Haley @ 2007-12-18 22:34 UTC (permalink / raw)
  To: David Stevens; +Cc: David Miller, netdev@vger.kernel.org, YOSHIFUJI Hideaki
In-Reply-To: <OF87295D1E.4B69B8F8-ON882573B5.00755AB2-882573B5.0078619A@us.ibm.com>

David Stevens wrote:
> Brian Haley <brian.haley@hp.com> wrote on 12/18/2007 12:57:54 PM:
> 
>> Trying to connect() to an IPv6 link-local multicast address by
>> specifying the outgoing multicast interface doesn't work, you have to
>> bind to a device first with an SO_BINDTODEVICE setsockopt() call.

Other OSes allow this operation, like FreeBSD, Tru64 UNIX and Solaris.

>         No, you simply have to specify sin6_scope_id for link-scope
> addresses, like you do in unicast cases.

But isn't this why IPV6_MULTICAST_IF exists?  So you don't have to bind 
to an interface or use the scope id?  RFC 3493 does not mention having 
to set a scope id in order to send multicast packets:

    IPv6 applications may send multicast packets by simply specifying an
    IPv6 multicast address as the destination address, for example in the
    destination address argument of the sendto() function.

> Your patch requires them
> to match (if specified), but I don't think IPV6_MULTICAST_IF should
> override or require a match for a valid sin6_scope_id (or be an error).

The patch won't override sk_bound_dev_if, or sin6_scope_id, it's a last 
resort for link-local multicast.  As far as matching, I think they 
should if you set both SO_BINDTODEVICE/sin6_scope_id and 
IPV6_MULTICAST_IF.  I can relax that check if you like.

The one thing my patch does do is set sk_bound_dev_if, which it never 
did - that seemed like the right thing to do since that's what the scope 
id path does, and makes sure we always continue to use this interface.

>         If I read it correctly, the existing code uses IPV6_MULTICAST_IF
> if the sin6_scope_id is not set, otherwise honors the interface specified
> in the connect. That seems like correct behaviour to me, and RFC 3493
> doesn't address the relative precedence of the two that I see. This is
> in the "linklocal" branch, and all unicast linklocal's require specifying
> sin6_scope_id. Multicast doesn't if require a scope_id in the case where
> you've done an IPV6_MULTICAST_IF, but it should still allow a different
> scope_id when you have used IPV6_MULTICAST_IF.

The IPV6_ADDR_MULTICAST check is inside the sin6_scope_id if() 
statement, so will never get checked if the scope hasn't been specified, 
that's the bug.  Since that isn't required for multicast we always get 
an EINVAL here.

>         Do you have application code that you believe is correct that
> doesn't work?

Yes, a customer does.

-Brian

^ permalink raw reply

* Nested VLAN causes recursive locking error
From: Chuck Ebbert @ 2007-12-18 23:03 UTC (permalink / raw)
  To: Netdev

From:
https://bugzilla.redhat.com/show_bug.cgi?id=426164


kernel version is 2.6.24-0.107.rc5.git3.fc9

>From boot log on serial console:
(full log attached)

Added VLAN with VID == 2 to IF -:eth0.1568:-

=============================================
[ INFO: possible recursive locking detected ]
2.6.24-0.107.rc5.git3.fc9 #1
---------------------------------------------
ifconfig/15011 is trying to acquire lock:
 (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d9450>] dev_mc_sync+0x1c/0x102

but task is already holding lock:
 (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d51bd>] dev_set_rx_mode+0x14/0x3c

other info that might help us debug this:
2 locks held by ifconfig/15011:
 #0:  (rtnl_mutex){--..}, at: [<c05de4f7>] rtnl_lock+0xf/0x11
 #1:  (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d51bd>] dev_set_rx_mode+0x14/0x3c

stack backtrace:
Pid: 15011, comm: ifconfig Not tainted 2.6.24-0.107.rc5.git3.fc9 #1
 [<c040649a>] show_trace_log_lvl+0x1a/0x2f
 [<c0406d41>] show_trace+0x12/0x14
 [<c0407061>] dump_stack+0x6c/0x72
 [<c044cfb3>] __lock_acquire+0x815/0xb5f
 [<c044d6f5>] lock_acquire+0x7b/0x9e
 [<c063dcf5>] _spin_lock_bh+0x33/0x5d
 [<c05d9450>] dev_mc_sync+0x1c/0x102
 [<f8b24c96>] vlan_dev_set_multicast_list+0x15/0x17 [8021q]
 [<c05d5107>] __dev_set_rx_mode+0x7e/0x81
 [<c05d51d0>] dev_set_rx_mode+0x27/0x3c
 [<c05d749e>] dev_open+0x61/0x7b
 [<c05d60b0>] dev_change_flags+0xa4/0x152
 [<c0616b8d>] devinet_ioctl+0x211/0x518
 [<c061723b>] inet_ioctl+0x86/0xa4
 [<c05caf0b>] sock_ioctl+0x1ca/0x1eb
 [<c049cdf2>] do_ioctl+0x22/0x67
 [<c049d080>] vfs_ioctl+0x249/0x25c
 [<c049d0d5>] sys_ioctl+0x42/0x5d
 [<c0405252>] syscall_call+0x7/0xb
 =======================

^ permalink raw reply

* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: David Stevens @ 2007-12-18 23:56 UTC (permalink / raw)
  To: Brian Haley
  Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
	YOSHIFUJI Hideaki
In-Reply-To: <47684AE3.7080007@hp.com>

Brian,

OK, I see what you're trying to fix now.

I think the scope_id checks are not quite right-- they
should be something like this:

if (addr_type&IPV6_ADDR_LINKLOCAL) {
        if (addr_len >= sizeof(struct sockaddr_in6)) {
                if (sk->sk_bound_dev_if && usin->sin6_scope_id &&
                    sk->sk_bound_dev_if != usin->sin6_scope_id) {
                        err = -EINVAL;
                        goto out;
                }
                if (usin->sin6_scope_id)
                        sk->sk_bound_dev_if = usin->sin6_scope_id;
                if (!sk->sk_bound_dev_if &&
                     (addr_type & IPV6_ADDR_MULTICAST))
                        fl.oif = np->mcast_oif;
        }

        /* connect to the link-local addres requires an interface */
        if (!sk->sk_bound_dev_if) {
                err = -EINVAL;
                goto out;
        }
}

        That is (in English):

        If I did an SO_BINDTODEVICE and specified sin6_scope_id,
then they better agree.
        If I specified sin6_scope_id without SO_BINDTODEVICE, set
the device to that.
        If I get this far without a device and it's multicast, use 
mcast_oif
        If I get all through that and don't have a device, EINVAL.

        Does that work for you?

                                        +-DLS


^ permalink raw reply

* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Jeff Garzik @ 2007-12-19  0:38 UTC (permalink / raw)
  To: Thomas Bogendoerfer; +Cc: netdev, linux-mips, ralf
In-Reply-To: <20071218103006.GA18598@alpha.franken.de>

Thomas Bogendoerfer wrote:
> On Mon, Dec 17, 2007 at 08:18:38PM -0500, Jeff Garzik wrote:
>>> Changes to last version:
>>> - Use inline functions for dma_sync_* instead of macros (suggested by Ralf)
>>> - added Kconfig change to make selection for similair SGI boxes easier
>> hrm, could you rediff?  it doesn't seem to apply
> 
> sure, against which tree ? I tried netdev-2.6 and it applies without fuzz...

It needs to be the 'upstream' branch of netdev-2.6.

The default netdev-2.6.git branch, master, is a 100% vanilla duplicate 
of Linus's git repository.

(this permits a common practice of presenting logs and diffs using git's 
branch..branch notation)

	Jeff




^ permalink raw reply

* [PATCH] sch_generic.c: Make dev_watchdog use deferrable timer
From: Parag Warudkar @ 2007-12-19  1:04 UTC (permalink / raw)
  To: netdev; +Cc: davem, linux-kernel, akpm


Reduces the number of wakeups from idle per second, makes powertop happy.

Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>

--- linux-2.6/net/sched/sch_generic.c	2007-12-07 10:04:43.000000000 -0500
+++ linux-2.6-work/net/sched/sch_generic.c	2007-12-16 17:57:05.000000000 -0500
@@ -213,7 +213,7 @@

  static void dev_watchdog_init(struct net_device *dev)
  {
-	init_timer(&dev->watchdog_timer);
+	init_timer_deferrable(&dev->watchdog_timer);
  	dev->watchdog_timer.data = (unsigned long)dev;
  	dev->watchdog_timer.function = dev_watchdog;
  }

^ permalink raw reply

* [PATCH] sky2: Use deferrable timer for watchdog
From: Parag Warudkar @ 2007-12-19  1:13 UTC (permalink / raw)
  To: netdev; +Cc: shemminger, akpm, linux-kernel


sky2 can use deferrable timer for watchdog - reduces wakeups from idle per 
second.

Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>

--- linux-2.6/drivers/net/sky2.c	2007-12-07 10:04:39.000000000 -0500
+++ linux-2.6-work/drivers/net/sky2.c	2007-12-18 20:07:58.000000000 -0500
@@ -4230,7 +4230,10 @@
  			sky2_show_addr(dev1);
  	}

-	setup_timer(&hw->watchdog_timer, sky2_watchdog, (unsigned long) hw);
+	hw->watchdog_timer.function = sky2_watchdog;
+	hw->watchdog_timer.data = (unsigned long) hw;
+	init_timer_deferrable(&hw->watchdog_timer);
+
  	INIT_WORK(&hw->restart_work, sky2_restart);

  	pci_set_drvdata(pdev, hw);

^ permalink raw reply

* Re: "ip neigh show" not showing arp cache entries?
From: Herbert Xu @ 2007-12-19  1:14 UTC (permalink / raw)
  To: Chris Friesen; +Cc: yoshfuji, dada1, netdev, linux-kernel
In-Reply-To: <4767DE91.9060803@nortel.com>

On Tue, Dec 18, 2007 at 08:52:01AM -0600, Chris Friesen wrote:
>
> Looks like that did it.  Why does specifying the family make a difference?

Because this is the only parameter that changes kernel behaviour.

Next step is to strace both commands with -s 16384 to see exactly
what the kernel reply looks like to determine the problem.

BTW my emails to you are bouncing so you might want to fix that.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [PATCH] e1000: Use deferrable timer for watchdog
From: Parag Warudkar @ 2007-12-19  1:46 UTC (permalink / raw)
  To: linux.nics, netdev; +Cc: linux-kernel, akpm


Use deferrable timer for watchdog. Reduces wakeups from idle per second.

Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>

--- linux-2.6/drivers/net/e1000/e1000_main.c	2007-12-07 10:04:39.000000000 -0500
+++ linux-2.6-work/drivers/net/e1000/e1000_main.c	2007-12-18 20:38:38.000000000 -0500
@@ -1030,7 +1030,7 @@
  	adapter->tx_fifo_stall_timer.function = &e1000_82547_tx_fifo_stall;
  	adapter->tx_fifo_stall_timer.data = (unsigned long) adapter;

-	init_timer(&adapter->watchdog_timer);
+	init_timer_deferrable(&adapter->watchdog_timer);
  	adapter->watchdog_timer.function = &e1000_watchdog;
  	adapter->watchdog_timer.data = (unsigned long) adapter;


^ permalink raw reply

* [PATCH] e1000e: Use deferrable timer for watchdog
From: Parag Warudkar @ 2007-12-19  1:49 UTC (permalink / raw)
  To: netdev, linux.nics; +Cc: linux-kernel, akpm


Reduce wakeups from idle per second.

Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>

--- linux-2.6/drivers/net/e1000e/netdev.c	2007-12-07 10:04:39.000000000 -0500
+++ linux-2.6-work/drivers/net/e1000e/netdev.c	2007-12-18 20:45:59.000000000 -0500
@@ -3899,7 +3899,7 @@
  		goto err_eeprom;
  	}

-	init_timer(&adapter->watchdog_timer);
+	init_timer_deferrable(&adapter->watchdog_timer);
  	adapter->watchdog_timer.function = &e1000_watchdog;
  	adapter->watchdog_timer.data = (unsigned long) adapter;


^ permalink raw reply

* [PATCH 1/2] net: flow hash timer power saving
From: Stephen Hemminger @ 2007-12-19  2:18 UTC (permalink / raw)
  To: parag.warudkar, David Miller; +Cc: netdev, akpm
In-Reply-To: <Pine.LNX.4.64.0712181956180.3616@mini.warudkars.net>

The net flow hash randomization timer runs every 10 minutes.
This time is low priority and doesn't need to wakeup the CPU.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

--- a/net/core/flow.c	2007-12-18 07:43:31.000000000 -0800
+++ b/net/core/flow.c	2007-12-18 07:44:32.000000000 -0800
@@ -81,8 +81,8 @@ static void flow_cache_new_hashrnd(unsig
 	for_each_possible_cpu(i)
 		flow_hash_rnd_recalc(i) = 1;
 
-	flow_hash_rnd_timer.expires = jiffies + FLOW_HASH_RND_PERIOD;
-	add_timer(&flow_hash_rnd_timer);
+	mod_timer(&flow_hash_rnd_timer,
+		  round_jiffies(jiffies + FLOW_HASH_RND_PERIOD));
 }
 
 static void flow_entry_kill(int cpu, struct flow_cache_entry *fle)
@@ -352,7 +352,7 @@ static int __init flow_cache_init(void)
 	flow_lwm = 2 * flow_hash_size;
 	flow_hwm = 4 * flow_hash_size;
 
-	init_timer(&flow_hash_rnd_timer);
+	init_timer_deferrable(&flow_hash_rnd_timer);
 	flow_hash_rnd_timer.function = flow_cache_new_hashrnd;
 	flow_hash_rnd_timer.expires = jiffies + FLOW_HASH_RND_PERIOD;
 	add_timer(&flow_hash_rnd_timer);

^ permalink raw reply

* [PATCH 2/2] net: neighbor timer power saving
From: Stephen Hemminger @ 2007-12-19  2:18 UTC (permalink / raw)
  To: parag.warudkar; +Cc: David Miller, netdev, akpm
In-Reply-To: <20071218174120.4b0ef6dd@shemminger-laptop>

The neighbor GC timer runs once a second, but it doesn't need to wake
up the machine.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

--- a/net/core/neighbour.c	2007-12-18 07:46:07.000000000 -0800
+++ b/net/core/neighbour.c	2007-12-18 07:47:36.000000000 -0800
@@ -270,7 +270,7 @@ static struct neighbour *neigh_alloc(str
 	n->nud_state	  = NUD_NONE;
 	n->output	  = neigh_blackhole;
 	n->parms	  = neigh_parms_clone(&tbl->parms);
-	init_timer(&n->timer);
+	init_timer_deferrable(&n->timer);
 	n->timer.function = neigh_timer_handler;
 	n->timer.data	  = (unsigned long)n;
 
@@ -740,7 +740,7 @@ static void neigh_timer_handler(unsigned
 
 	state = neigh->nud_state;
 	now = jiffies;
-	next = now + HZ;
+	next = round_jiffies(now + HZ);
 
 	if (!(state & NUD_IN_TIMER)) {
 #ifndef CONFIG_SMP
@@ -1372,7 +1372,7 @@ void neigh_table_init_no_netlink(struct 
 	get_random_bytes(&tbl->hash_rnd, sizeof(tbl->hash_rnd));
 
 	rwlock_init(&tbl->lock);
-	init_timer(&tbl->gc_timer);
+	init_timer_deferrable(&tbl->gc_timer);
 	tbl->gc_timer.data     = (unsigned long)tbl;
 	tbl->gc_timer.function = neigh_periodic_timer;
 	tbl->gc_timer.expires  = now + 1;

^ permalink raw reply

* Re: [ipw3945-devel] 2.6.24-rc5-mm1 -- INFO: possible circular locking dependency detected -- pm-suspend/5800 is trying to acquire lock
From: Zhu Yi @ 2007-12-19  2:58 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Miles Lane, Len Brown, netdev, LKML, ipw3945-devel,
	Rafael J. Wysocki, Pavel Machek, Andrew Morton
In-Reply-To: <1197989826.4885.169.camel@johannes.berg>

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]


On Tue, 2007-12-18 at 15:57 +0100, Johannes Berg wrote:
> Thanks. This is a bug in iwlwifi.
> 
> The problem is actually another case where my workqueue debugging with
> lockdep is triggering a warning :))
> 
> Here's the thing:
> 
> iwl3945_cancel_deferred_work does 
> 
> cancel_delayed_work_sync(&priv->init_alive_start);
> 
> (which is the "(&(&priv->init_alive_start)->work)" lock)
> 
> but it is called from within a locked section of
> mutex_lock(&priv->mutex); (locked from iwl3945_pci_suspend)
> 
> On the other hand, the task that runs from the init_alive_start
> workqueue is iwl3945_bg_init_alive_start() which will lock the same
> mutex.
> 
> So the deadlock condition is that you can be in
> cancel_delayed_work_sync() above while the mutex is locked, and be
> waiting for iwl_3945_bg_init_alive_start() which tries to lock the
> mutex.

Thanks for the analysis.

Miles, please try the attached patch. I'll send a patch for both 3945
and 4965 to linux-wireless later.

Thanks,
-yi

[-- Attachment #2: fix-3945-deadlock-susp.patch --]
[-- Type: text/x-patch, Size: 2206 bytes --]

diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 88cf035..f0303e8 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -6355,8 +6355,6 @@ static void __iwl3945_down(struct iwl3945_priv *priv)
 	/* Unblock any waiting calls */
 	wake_up_interruptible_all(&priv->wait_command_queue);
 
-	iwl3945_cancel_deferred_work(priv);
-
 	/* Wipe out the EXIT_PENDING status bit if we are not actually
 	 * exiting the module */
 	if (!exit_pending)
@@ -6431,6 +6429,8 @@ static void iwl3945_down(struct iwl3945_priv *priv)
 	mutex_lock(&priv->mutex);
 	__iwl3945_down(priv);
 	mutex_unlock(&priv->mutex);
+
+	iwl3945_cancel_deferred_work(priv);
 }
 
 #define MAX_HW_RESTARTS 5
@@ -8739,10 +8739,9 @@ static void iwl3945_pci_remove(struct pci_dev *pdev)
 
 	IWL_DEBUG_INFO("*** UNLOAD DRIVER ***\n");
 
-	mutex_lock(&priv->mutex);
 	set_bit(STATUS_EXIT_PENDING, &priv->status);
-	__iwl3945_down(priv);
-	mutex_unlock(&priv->mutex);
+
+	iwl3945_down(priv);
 
 	/* Free MAC hash list for ADHOC */
 	for (i = 0; i < IWL_IBSS_MAC_HASH_SIZE; i++) {
@@ -8801,12 +8800,10 @@ static int iwl3945_pci_suspend(struct pci_dev *pdev, pm_message_t state)
 {
 	struct iwl3945_priv *priv = pci_get_drvdata(pdev);
 
-	mutex_lock(&priv->mutex);
-
 	set_bit(STATUS_IN_SUSPEND, &priv->status);
 
 	/* Take down the device; powers it off, etc. */
-	__iwl3945_down(priv);
+	iwl3945_down(priv);
 
 	if (priv->mac80211_registered)
 		ieee80211_stop_queues(priv->hw);
@@ -8815,8 +8812,6 @@ static int iwl3945_pci_suspend(struct pci_dev *pdev, pm_message_t state)
 	pci_disable_device(pdev);
 	pci_set_power_state(pdev, PCI_D3hot);
 
-	mutex_unlock(&priv->mutex);
-
 	return 0;
 }
 
@@ -8874,8 +8869,6 @@ static int iwl3945_pci_resume(struct pci_dev *pdev)
 
 	printk(KERN_INFO "Coming out of suspend...\n");
 
-	mutex_lock(&priv->mutex);
-
 	pci_set_power_state(pdev, PCI_D0);
 	err = pci_enable_device(pdev);
 	pci_restore_state(pdev);
@@ -8889,7 +8882,6 @@ static int iwl3945_pci_resume(struct pci_dev *pdev)
 	pci_write_config_byte(pdev, 0x41, 0x00);
 
 	iwl3945_resume(priv);
-	mutex_unlock(&priv->mutex);
 
 	return 0;
 }

^ permalink raw reply related

* Re: [PATCH 2/4] [CORE]: datagram: basic memory accounting functions
From: Hideo AOKI @ 2007-12-19  3:21 UTC (permalink / raw)
  To: David Miller, Herbert Xu, netdev
  Cc: Takahiro Yasui, Masami Hiramatsu, Satoshi Oshima, Bill Fink,
	Andi Kleen, Evgeniy Polyakov, Stephen Hemminger, yoshfuji,
	Yumiko Sugita, haoki
In-Reply-To: <47673299.3010301@redhat.com>

Hello,

I would like to update this patch since there were redundant extern declarations.

Regards,
Hideo

---

This patch includes changes in network core sub system for memory
accounting.

Memory scheduling, charging, uncharging and reclaiming functions are
added. These functions use sk_forward_alloc to store socket local
accounting. They currently support only datagram protocols.

sk_datagram_rfree() is a receive buffer detractor for datagram
protocols which are capable of protocol specific memory accounting.

Cc: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Takahiro Yasui <tyasui@redhat.com>
signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
---

 include/net/sock.h  |   78 +++++++++++++++++++++++++++++++++++++++++++++++
 net/core/datagram.c |   85 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 163 insertions(+)

diff -pruN net-2.6-udp-take11a1-p1/include/net/sock.h net-2.6-udp-take11a1-p2/include/net/sock.h
--- net-2.6-udp-take11a1-p1/include/net/sock.h	2007-12-11 10:54:53.000000000 -0500
+++ net-2.6-udp-take11a1-p2/include/net/sock.h	2007-12-18 18:57:35.000000000 -0500
@@ -750,6 +750,9 @@ static inline struct inode *SOCK_INODE(s
 	return &container_of(socket, struct socket_alloc, socket)->vfs_inode;
 }

+/*
+ * Functions for memory accounting
+ */
 extern void __sk_stream_mem_reclaim(struct sock *sk);
 extern int sk_stream_mem_schedule(struct sock *sk, int size, int kind);

@@ -778,6 +781,79 @@ static inline int sk_stream_wmem_schedul
 	       sk_stream_mem_schedule(sk, size, 0);
 }

+extern int __sk_datagram_account_charge(struct sock *sk, int size, int kind);
+extern void __sk_datagram_mem_reclaim(struct sock *sk);
+extern int sk_datagram_mem_schedule(struct sock *sk, int size, int kind);
+
+#define SK_DATAGRAM_MEM_QUANTUM ((unsigned int)PAGE_SIZE)
+
+static inline int sk_datagram_pages(int amt)
+{
+	/* Cast to unsigned as an optimization, since amt is always positive. */
+	return DIV_ROUND_UP((unsigned int)amt, SK_DATAGRAM_MEM_QUANTUM);
+}
+
+static inline void sk_datagram_mem_reclaim(struct sock *sk)
+{
+	if (!sk->sk_prot->memory_allocated)
+		return;
+
+	__sk_datagram_mem_reclaim(sk);
+}
+
+static inline int sk_datagram_rmem_schedule(struct sock *sk, int size)
+{
+	return size <= sk->sk_forward_alloc ||
+		sk_datagram_mem_schedule(sk, size, 1);
+}
+
+static inline int sk_datagram_wmem_schedule(struct sock *sk, int size)
+{
+	return size <= sk->sk_forward_alloc ||
+		sk_datagram_mem_schedule(sk, size, 0);
+}
+
+static inline void sk_mem_reclaim(struct sock *sk)
+{
+	if (sk->sk_type == SOCK_DGRAM)
+		sk_datagram_mem_reclaim(sk);
+}
+
+static inline int sk_wmem_schedule(struct sock *sk, int size)
+{
+	if (sk->sk_type == SOCK_DGRAM)
+		return sk_datagram_wmem_schedule(sk, size);
+	else
+		return 1;
+}
+
+static inline int sk_account_rmem_charge(struct sock *sk, int size)
+{
+	/* account if protocol supports memory accounting. */
+	if (!sk->sk_prot->memory_allocated || sk->sk_type != SOCK_DGRAM)
+		return 1;
+
+	return __sk_datagram_account_charge(sk, size, 1);
+}
+
+static inline int sk_account_wmem_charge(struct sock *sk, int size)
+{
+	/* account if protocol supports memory accounting. */
+	if (!sk->sk_prot->memory_allocated || sk->sk_type != SOCK_DGRAM)
+		return 1;
+
+	return __sk_datagram_account_charge(sk, size, 0);
+}
+
+static inline void sk_account_uncharge(struct sock *sk, int size)
+{
+	/* account if protocol supports memory accounting. */
+	if (!sk->sk_prot->memory_allocated || sk->sk_type != SOCK_DGRAM)
+		return;
+
+	sk->sk_forward_alloc += size;
+}
+
 /* Used by processes to "lock" a socket state, so that
  * interrupts and bottom half handlers won't change it
  * from under us. It essentially blocks any incoming
@@ -1166,6 +1242,8 @@ static inline void skb_set_owner_r(struc
 	atomic_add(skb->truesize, &sk->sk_rmem_alloc);
 }

+extern void sk_datagram_rfree(struct sk_buff *skb);
+
 extern void sk_reset_timer(struct sock *sk, struct timer_list* timer,
 			   unsigned long expires);

diff -pruN net-2.6-udp-take11a1-p1/net/core/datagram.c net-2.6-udp-take11a1-p2/net/core/datagram.c
--- net-2.6-udp-take11a1-p1/net/core/datagram.c	2007-12-11 10:54:55.000000000 -0500
+++ net-2.6-udp-take11a1-p2/net/core/datagram.c	2007-12-18 18:49:39.000000000 -0500
@@ -484,6 +484,91 @@ fault:
 }

 /**
+ *	sk_datagram_rfree - receive buffer detractor for datagram protocls
+ *	@skb: skbuff
+ */
+void sk_datagram_rfree(struct sk_buff *skb)
+{
+	struct sock *sk = skb->sk;
+
+	skb_truesize_check(skb);
+	atomic_sub(skb->truesize, &sk->sk_rmem_alloc);
+	sk_account_uncharge(sk, skb->truesize);
+	sk_datagram_mem_reclaim(sk);
+}
+EXPORT_SYMBOL(sk_datagram_rfree);
+
+
+/**
+ * 	__sk_datagram_account_charge - send buffer for datagram protocls
+ *	@sk: socket
+ *	@size: memory size to charge
+ *	@kind: charge type
+ *
+ *	If kind is 0, it means wmem allocation. Otherwise it means rmem
+ *	allocation.
+ */
+int __sk_datagram_account_charge(struct sock *sk, int size, int kind)
+{
+	if ((kind && sk_datagram_rmem_schedule(sk, size)) ||
+	    (!kind && sk_datagram_wmem_schedule(sk, size))) {
+		sk->sk_forward_alloc -= size;
+		return 1;
+	}
+	return 0;
+}
+EXPORT_SYMBOL(__sk_datagram_account_charge);
+
+/**
+ * 	__sk_datagram_mem_reclaim - send buffer for datagram protocls
+ *	@sk: socket
+ */
+void __sk_datagram_mem_reclaim(struct sock *sk)
+{
+	if (sk->sk_forward_alloc < SK_DATAGRAM_MEM_QUANTUM)
+		return;
+
+	atomic_sub(sk->sk_forward_alloc / SK_DATAGRAM_MEM_QUANTUM,
+		   sk->sk_prot->memory_allocated);
+	sk->sk_forward_alloc &= SK_DATAGRAM_MEM_QUANTUM - 1;
+}
+EXPORT_SYMBOL(__sk_datagram_mem_reclaim);
+
+/**
+ * 	sk_datagram_mem_schedule - memory accounting for datagram protocls
+ *	@sk: socket
+ *	@size: memory size to allocate
+ *	@kind: allocation type
+ *
+ *	If kind is 0, it means wmem allocation. Otherwise it means rmem
+ *	allocation.
+ */
+int sk_datagram_mem_schedule(struct sock *sk, int size, int kind)
+{
+	int amt;
+	struct proto *prot = sk->sk_prot;
+
+	/* Don't account and limit memory if protocol doesn't support. */
+	if (!prot->memory_allocated)
+		return 1;
+
+	amt = sk_datagram_pages(size);
+	if (atomic_add_return(amt, prot->memory_allocated) >
+	    prot->sysctl_mem[0])
+		if ((kind && atomic_read(&sk->sk_rmem_alloc) + size >=
+		     prot->sysctl_rmem[0]) ||
+		    (!kind && atomic_read(&sk->sk_wmem_alloc) + size >=
+		     prot->sysctl_wmem[0])) {
+			/* Undo changes. */
+			atomic_sub(amt, prot->memory_allocated);
+			return 0;
+		}
+	sk->sk_forward_alloc += amt * SK_DATAGRAM_MEM_QUANTUM;
+	return 1;
+}
+EXPORT_SYMBOL(sk_datagram_mem_schedule);
+
+/**
  * 	datagram_poll - generic datagram poll
  *	@file: file struct
  *	@sock: socket
-- 
Hitachi Computer Products (America) Inc.

^ permalink raw reply

* Inline local_bh_disable when TRACE_IRQFLAGS
From: Herbert Xu @ 2007-12-19  3:40 UTC (permalink / raw)
  To: Ingo Molnar, Linux Kernel Mailing List; +Cc: David S. Miller, netdev

Hi Ingo:

I noticed that local_bh_disable is now always out-of-line.  The
change was made when TRACE_IRQFLAGS was added.  However, with
TRACE_IRQFLAGS off, local_bh_disable does exactly the same work
as before.  In particular, it does pretty much the same as what
preempt_disable does and the latter is always inline.

So I'm wondering if it would be reasonable to make it out-of-line
when TRACE_IRQFLAGS is off.  This may make a difference because
the networking stack is a frequent user of local_bh_disable and
local_bh_enable.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [IPSEC]: Do xfrm_state_check_space before encapsulation
From: Herbert Xu @ 2007-12-19  6:12 UTC (permalink / raw)
  To: Kazunori MIYAZAWA; +Cc: David Miller, usagi-core, netdev
In-Reply-To: <4768A7CA.4090503@taca.jp>

On Wed, Dec 19, 2007 at 02:10:34PM +0900, Kazunori MIYAZAWA wrote:
>
> Dec 19 11:31:44 hawaii kernel: ip6_rcv_finish: head=f7505000(**)
> Dec 19 11:31:44 hawaii kernel: ip6_rcv_finish: data=f7505020(**)
> Dec 19 11:31:44 hawaii kernel: xfrm6_tunnel_output: head=f7505000
> Dec 19 11:31:44 hawaii kernel: xfrm6_tunnel_output: data=f7505020

Sorry I introduced this bug when I moved the encapsulation output
function to the top of the loop.  Here's the fix.

[IPSEC]: Do xfrm_state_check_space before encapsulation

While merging the IPsec output path I moved the encapsulation output
operation to the top of the loop so that it sits outside of the locked
section.  Unfortunately in doing so it now sits in front of the space
check as well which could be a fatal error.

This patch rearranges the calls so that the space check happens as
the thing on the output path.

This patch also fixes an incorrect goto should the encapsulation output
fail.

Thanks to Kazunori MIYAZAWA for finding this bug.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 3c277a4..26fa0cb 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -33,16 +33,6 @@ static int xfrm_state_check_space(struct xfrm_state *x, struct sk_buff *skb)
 	return 0;
 }
 
-static int xfrm_state_check(struct xfrm_state *x, struct sk_buff *skb)
-{
-	int err = xfrm_state_check_expire(x);
-	if (err < 0)
-		goto err;
-	err = xfrm_state_check_space(x, skb);
-err:
-	return err;
-}
-
 static int xfrm_output_one(struct sk_buff *skb, int err)
 {
 	struct dst_entry *dst = skb->dst;
@@ -52,12 +42,16 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
 		goto resume;
 
 	do {
+		err = xfrm_state_check_space(x, skb);
+		if (err)
+			goto error_nolock;
+
 		err = x->outer_mode->output(x, skb);
 		if (err)
-			goto error;
+			goto error_nolock;
 
 		spin_lock_bh(&x->lock);
-		err = xfrm_state_check(x, skb);
+		err = xfrm_state_check_expire(x);
 		if (err)
 			goto error;
 
Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply related

* Re: [IPSEC]: Do xfrm_state_check_space before encapsulation
From: David Miller @ 2007-12-19  6:14 UTC (permalink / raw)
  To: herbert; +Cc: miyazawa, usagi-core, netdev
In-Reply-To: <20071219061210.GA6731@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 19 Dec 2007 14:12:10 +0800

> [IPSEC]: Do xfrm_state_check_space before encapsulation
> 
> While merging the IPsec output path I moved the encapsulation output
> operation to the top of the loop so that it sits outside of the locked
> section.  Unfortunately in doing so it now sits in front of the space
> check as well which could be a fatal error.
> 
> This patch rearranges the calls so that the space check happens as
> the thing on the output path.
> 
> This patch also fixes an incorrect goto should the encapsulation output
> fail.
> 
> Thanks to Kazunori MIYAZAWA for finding this bug.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied, thanks Herbert.

^ permalink raw reply

* Re: IPsec replay sequence number overflow behavior? (RFC4303 section 3.3.3)
From: Joy Latten @ 2007-12-19  6:36 UTC (permalink / raw)
  To: paul.moore; +Cc: herbert, kaber, latten, netdev

>Rereading the thread it's unclear to me which solution was deemed "correct".  
>I'm not a big fan of fiddling/forcing SA lifetimes unless we have no other 
>option; if someone is foolish enough to use manual keying with replay 
>protection and no mechanism to catch rollover then they most likely have 
>larger problems.  It's the whole "we'll provide you with the gun, but you 
>have to shoot yourself" argument as applied to SA lifetimes.

Also, the ipsec rfc require auotmated SA management when 
using anti-replay service and that the option be disabled 
when SAs are manually setup.

It may not stop anyone, but we can always point to rfc. :-)

Joy


^ permalink raw reply

* [IPSEC]: Rename tunnel-mode functions to avoid collisions with tunnels
From: Herbert Xu @ 2007-12-19  6:38 UTC (permalink / raw)
  To: David S. Miller, netdev

Hi Dave:

[IPSEC]: Rename tunnel-mode functions to avoid collisions with tunnels

It appears that I've managed to create two different functions both
called xfrm6_tunnel_output.  This is because we have the plain tunnel
encapsulation named xfrmX_tunnel as well as the tunnel-mode encapsulation
which lives in the files xfrmX_mode_tunnel.c.

This patch renames functions from the latter to use the xfrmX_mode_tunnel
prefix to avoid name-space conflicts.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
index aa335db..8dee617 100644
--- a/net/ipv4/xfrm4_mode_tunnel.c
+++ b/net/ipv4/xfrm4_mode_tunnel.c
@@ -26,7 +26,7 @@ static inline void ipip_ecn_decapsulate(struct sk_buff *skb)
  *
  * The top IP header will be constructed per RFC 2401.
  */
-static int xfrm4_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
+static int xfrm4_mode_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
 {
 	struct dst_entry *dst = skb->dst;
 	struct iphdr *top_iph;
@@ -63,7 +63,7 @@ static int xfrm4_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
 	return 0;
 }
 
-static int xfrm4_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
+static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
 {
 	const unsigned char *old_mac;
 	int err = -EINVAL;
@@ -94,21 +94,21 @@ out:
 }
 
 static struct xfrm_mode xfrm4_tunnel_mode = {
-	.input2 = xfrm4_tunnel_input,
+	.input2 = xfrm4_mode_tunnel_input,
 	.input = xfrm_prepare_input,
-	.output2 = xfrm4_tunnel_output,
+	.output2 = xfrm4_mode_tunnel_output,
 	.output = xfrm4_prepare_output,
 	.owner = THIS_MODULE,
 	.encap = XFRM_MODE_TUNNEL,
 	.flags = XFRM_MODE_FLAG_TUNNEL,
 };
 
-static int __init xfrm4_tunnel_init(void)
+static int __init xfrm4_mode_tunnel_init(void)
 {
 	return xfrm_register_mode(&xfrm4_tunnel_mode, AF_INET);
 }
 
-static void __exit xfrm4_tunnel_exit(void)
+static void __exit xfrm4_mode_tunnel_exit(void)
 {
 	int err;
 
@@ -116,7 +116,7 @@ static void __exit xfrm4_tunnel_exit(void)
 	BUG_ON(err);
 }
 
-module_init(xfrm4_tunnel_init);
-module_exit(xfrm4_tunnel_exit);
+module_init(xfrm4_mode_tunnel_init);
+module_exit(xfrm4_mode_tunnel_exit);
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_XFRM_MODE(AF_INET, XFRM_MODE_TUNNEL);
diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c
index f7d0d66..0c742fa 100644
--- a/net/ipv6/xfrm6_mode_tunnel.c
+++ b/net/ipv6/xfrm6_mode_tunnel.c
@@ -29,7 +29,7 @@ static inline void ipip6_ecn_decapsulate(struct sk_buff *skb)
  *
  * The top IP header will be constructed per RFC 2401.
  */
-static int xfrm6_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
+static int xfrm6_mode_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
 {
 	struct dst_entry *dst = skb->dst;
 	struct ipv6hdr *top_iph;
@@ -58,7 +58,7 @@ static int xfrm6_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
 	return 0;
 }
 
-static int xfrm6_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
+static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
 {
 	int err = -EINVAL;
 	const unsigned char *old_mac;
@@ -89,21 +89,21 @@ out:
 }
 
 static struct xfrm_mode xfrm6_tunnel_mode = {
-	.input2 = xfrm6_tunnel_input,
+	.input2 = xfrm6_mode_tunnel_input,
 	.input = xfrm_prepare_input,
-	.output2 = xfrm6_tunnel_output,
+	.output2 = xfrm6_mode_tunnel_output,
 	.output = xfrm6_prepare_output,
 	.owner = THIS_MODULE,
 	.encap = XFRM_MODE_TUNNEL,
 	.flags = XFRM_MODE_FLAG_TUNNEL,
 };
 
-static int __init xfrm6_tunnel_init(void)
+static int __init xfrm6_mode_tunnel_init(void)
 {
 	return xfrm_register_mode(&xfrm6_tunnel_mode, AF_INET6);
 }
 
-static void __exit xfrm6_tunnel_exit(void)
+static void __exit xfrm6_mode_tunnel_exit(void)
 {
 	int err;
 
@@ -111,7 +111,7 @@ static void __exit xfrm6_tunnel_exit(void)
 	BUG_ON(err);
 }
 
-module_init(xfrm6_tunnel_init);
-module_exit(xfrm6_tunnel_exit);
+module_init(xfrm6_mode_tunnel_init);
+module_exit(xfrm6_mode_tunnel_exit);
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_XFRM_MODE(AF_INET6, XFRM_MODE_TUNNEL);

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply related

* Re: missing dir in and dir fwd policy on 2.6.23
From: Herbert Xu @ 2007-12-19  7:03 UTC (permalink / raw)
  To: Marco Berizzi; +Cc: netdev
In-Reply-To: <BAY103-DAV1125DF8000481F6A3CB962B2630@phx.gbl>

Marco Berizzi <pupilla@hotmail.com> wrote:
> Hello everybody.
> I'm experimenting a pretty strange ipsec problem with 2.6.23.x
> and openswan 2.4.11
> Here is the output from 'ip -s x p':

It's a bug in openswan but I haven't had the time to track it
down yet.  Anyway, the kernel is not involved since the management
of policies is entirely up to the user-space Key Manager.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox