* [patch 2.6.13-rc6] net/802/tr: use interrupt-safe locking
From: John W. Linville @ 2005-08-17 20:49 UTC (permalink / raw)
To: netdev, linux-tr, mikep; +Cc: jgarzik, davem, fubar, linux-kernel
Change operations on rif_lock from spin_{un}lock_bh to
spin_{un}lock_irq{save,restore} equivalents. Some of the
rif_lock critical sections are called from interrupt context via
tr_type_trans->tr_add_rif_info. The TR NIC drivers call tr_type_trans
from their packet receive handlers.
Signed-off-by: Jay Vosburg <foobar@us.ibm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
It is my understanding that this same patch has been submitted multiple
times in the past. Some of those submissions were around a year ago,
but it does not seem to have been committed.
FWIW, this patch is currently being carried in the Fedora and RHEL
kernels. It certainly looks like it is necessary to me. Can we get
some movement on this?
net/802/tr.c | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/net/802/tr.c b/net/802/tr.c
--- a/net/802/tr.c
+++ b/net/802/tr.c
@@ -251,10 +251,11 @@ void tr_source_route(struct sk_buff *skb
unsigned int hash;
struct rif_cache *entry;
unsigned char *olddata;
+ unsigned long flags;
static const unsigned char mcast_func_addr[]
= {0xC0,0x00,0x00,0x04,0x00,0x00};
- spin_lock_bh(&rif_lock);
+ spin_lock_irqsave(&rif_lock, flags);
/*
* Broadcasts are single route as stated in RFC 1042
@@ -323,7 +324,7 @@ printk("source routing for %02X:%02X:%02
else
slack = 18 - ((ntohs(trh->rcf) & TR_RCF_LEN_MASK)>>8);
olddata = skb->data;
- spin_unlock_bh(&rif_lock);
+ spin_unlock_irqrestore(&rif_lock, flags);
skb_pull(skb, slack);
memmove(skb->data, olddata, sizeof(struct trh_hdr) - slack);
@@ -337,10 +338,11 @@ printk("source routing for %02X:%02X:%02
static void tr_add_rif_info(struct trh_hdr *trh, struct net_device *dev)
{
unsigned int hash, rii_p = 0;
+ unsigned long flags;
struct rif_cache *entry;
- spin_lock_bh(&rif_lock);
+ spin_lock_irqsave(&rif_lock, flags);
/*
* Firstly see if the entry exists
@@ -378,7 +380,7 @@ printk("adding rif_entry: addr:%02X:%02X
if(!entry)
{
printk(KERN_DEBUG "tr.c: Couldn't malloc rif cache entry !\n");
- spin_unlock_bh(&rif_lock);
+ spin_unlock_irqrestore(&rif_lock, flags);
return;
}
@@ -420,7 +422,7 @@ printk("updating rif_entry: addr:%02X:%0
}
entry->last_used=jiffies;
}
- spin_unlock_bh(&rif_lock);
+ spin_unlock_irqrestore(&rif_lock, flags);
}
/*
@@ -430,9 +432,9 @@ printk("updating rif_entry: addr:%02X:%0
static void rif_check_expire(unsigned long dummy)
{
int i;
- unsigned long next_interval = jiffies + sysctl_tr_rif_timeout/2;
+ unsigned long flags, next_interval = jiffies + sysctl_tr_rif_timeout/2;
- spin_lock_bh(&rif_lock);
+ spin_lock_irqsave(&rif_lock, flags);
for(i =0; i < RIF_TABLE_SIZE; i++) {
struct rif_cache *entry, **pentry;
@@ -454,7 +456,7 @@ static void rif_check_expire(unsigned lo
}
}
- spin_unlock_bh(&rif_lock);
+ spin_unlock_irqrestore(&rif_lock, flags);
mod_timer(&rif_timer, next_interval);
@@ -485,7 +487,7 @@ static struct rif_cache *rif_get_idx(lof
static void *rif_seq_start(struct seq_file *seq, loff_t *pos)
{
- spin_lock_bh(&rif_lock);
+ spin_lock_irq(&rif_lock);
return *pos ? rif_get_idx(*pos - 1) : SEQ_START_TOKEN;
}
@@ -516,7 +518,7 @@ static void *rif_seq_next(struct seq_fil
static void rif_seq_stop(struct seq_file *seq, void *v)
{
- spin_unlock_bh(&rif_lock);
+ spin_unlock_irq(&rif_lock);
}
static int rif_seq_show(struct seq_file *seq, void *v)
^ permalink raw reply
* Re: NAPI poll routine happens in interrupt context?
From: Ralf Baechle @ 2005-08-17 18:18 UTC (permalink / raw)
To: Joshua Wise
Cc: Stephen Hemminger, netdev, linux-kernel, linux-mips, Aaron Brooks
In-Reply-To: <200508171321.20094.Joshua.Wise@sicortex.com>
On Wed, Aug 17, 2005 at 01:21:18PM -0400, Joshua Wise wrote:
> > The bug is that ipv6 is doing an operation to handle MIB statistics and
> > the MIPS architecture math routines seem to need to sleep.
Except nothing in the network stack is using fp - the use of FP inside the
MIPS kernel is not supported in any way. What happend is probably the
fetching of the opcode of the instruction in the branch delay slot of
the unaligned instruction emulator blew up because it uses a get_user which
again calls might_sleep and that won't exactly work if not called from
process context.
Ralf
^ permalink raw reply
* Re: NAPI poll routine happens in interrupt context?
From: Joshua Wise @ 2005-08-17 17:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel, linux-mips, Aaron Brooks
In-Reply-To: <20050817094317.3437607e@dxpl.pdx.osdl.net>
On Wednesday 17 August 2005 12:43, Stephen Hemminger wrote:
> You will get more response to network issues on netdev@vger.kernel.org
Okay. Thanks.
> NAPI poll is usually called from softirq context. This means that
> hardware interrupts are enabled, but it is not in a thread context that
> can sleep.
Okay. I wasn't aware of quite how it was "supposed" to be.
> You shouldn't be calling things that could sleep! If you are it
> is a bug.
I guess I'd better track down this bug, then :)
> Harald Welte is working on a generic virtual Ethernet device, perhaps
> you could collaborate with him.
I assume he is on this mailing list?
> The bug is that ipv6 is doing an operation to handle MIB statistics and
> the MIPS architecture math routines seem to need to sleep.
> Previous versions of SNMP code may have done atomic operations, but
> current 2.6 code uses per-cpu variables.
> Also, there is no might sleep in the current 2.6 MIPS code either
> so the problem is probably fixed if you use current 2.6.12 or later
> kernel.
Hm -- I am using 2.6.13-rc2.
Here is a new trace, showing the same issue with IPv4:
Debug: sleeping function called from invalid context at
arch/mips/math-emu/dsemul.c:137
in_atomic():1, irqs_disabled():0
Call Trace:
[<ffffffff801406e0>] __might_sleep+0x180/0x198 (kernel/sched.c:5223)
[<ffffffff80101930>] mipsIRQ+0x130/0x1e0 (arch/mips/sc1000/mipsIRQ.S:95)
[<ffffffff802860fc>] ip_rcv+0x9c/0x7b0 (net/ipv4/ip_input.c:381)
[<ffffffff80140428>] do_dsemulret+0x68/0x1a0
(arch/mips/math-emu/dsemul.c:137)
[<ffffffff8010b3a4>] do_ade+0x24/0x550 (arch/mips/kernel/unaligned.c:506)
[<ffffffff80102964>] handle_adel_int+0x3c/0x58 (arch/mips/kernel/genex.S:281)
[<ffffffff80268260>] netif_receive_skb+0x1b0/0x2e0 (net/core/dev.c:1646)
[<ffffffff80286100>] ip_rcv+0xa0/0x7b0 (net/ipv4/ip_input.c:394)
[<ffffffff8014da5c>] printk+0x2c/0x38 (kernel/printk.c:515)
[<ffffffff80268260>] netif_receive_skb+0x1b0/0x2e0 (net/core/dev.c:1646)
[<ffffffff802573c8>] lanlan_poll+0x3e0/0x440 (drivers/net/lanlan.c:246)
etc, etc.
CC:'ing to linux-mips for obvious reasons. This seems to stem from an
unaligned access. If this is no longer appropriate for linux-kernel, feel
free to stop CCing to there, and I will follow.
Thanks,
joshua
^ permalink raw reply
* Re: NAPI poll routine happens in interrupt context?
From: Stephen Hemminger @ 2005-08-17 16:43 UTC (permalink / raw)
To: Joshua Wise; +Cc: netdev, linux-kernel
In-Reply-To: <200508170932.10441.Joshua.Wise@sicortex.com>
On Wed, 17 Aug 2005 09:32:10 -0400
Joshua Wise <Joshua.Wise@sicortex.com> wrote:
> Hello LKML,
You will get more response to network issues on netdev@vger.kernel.org
> I have recently been working on a network driver for an emulated ultra-simple
> network card, and I've run into a few snags with the NAPI. My current issue
> is that it seems to me that my poll routine is being called from an atomic
> context, so when poll calls rx, and rx calls netif_receive_skb, I end up with
> lots of __might_sleep warnings in the various network layers.
NAPI poll is usually called from softirq context. This means that
hardware interrupts are enabled, but it is not in a thread context that
can sleep.
> This is not so good. I need every cycle I can get, as this emulator is
> incredibly slow, so burning cycles by printing out the reported badness is
> not really acceptible. Conceivably the badness itself is also an issue.
You shouldn't be calling things that could sleep! If you are it
is a bug.
> Before posting here, I did search Google for "lkml napi poll interrupt",
> although I did not find anything relevant to my issue.
>
> If interested, the code is available at http://joshuawise.com/lanlan.c . Some
> notes:
>
> The virtual lan-lan is a very very simple device. It consists of an ioreg that
> maintains state of the device, as described by the ioreg bit defines. It also
> has an ioctlreg that can pass through ioctls to the Linux kernel tap device
> that it's sitting on top of. (This goes with the ifreq seen in the struct.)
> One must always write and read in word-aligned chunks to and from it, for
> simplicity's sake.
Harald Welte is working on a generic virtual Ethernet device, perhaps
you could collaborate with him.
> Feel free to suggest any modifications that this device might need to make it
> more fully functional. Hopefully we can bring this driver to such a state
> where it will be usable as a replacement skeleton driver for the NAPI.
> Here is a trace:
> Debug: sleeping function called from invalid context at
> arch/mips/math-emu/dsemul.c:137
> in_atomic():1, irqs_disabled():0
> Call Trace:
> [<ffffffff801406e0>] __might_sleep+0x180/0x198
> [<ffffffff802cec00>] ipv6_rcv+0xc0/0x440
> [<ffffffff80140428>] do_dsemulret+0x68/0x1a0
> [<ffffffff8010b3a4>] do_ade+0x24/0x550
> [<ffffffff80102964>] handle_adel_int+0x3c/0x58
> [<ffffffff80268160>] netif_receive_skb+0x1b0/0x2e0
> [<ffffffff802cec04>] ipv6_rcv+0xc4/0x440
> [<ffffffff80268160>] netif_receive_skb+0x1b0/0x2e0
> [<ffffffff802572c8>] lanlan_poll+0x3e0/0x440
> [<ffffffff8026868c>] net_rx_action+0x16c/0x370
> [<ffffffff802686a8>] net_rx_action+0x188/0x370
> [<ffffffff80154f28>] __do_softirq+0x118/0x250
> [<ffffffff80154f28>] __do_softirq+0x118/0x250
> [<ffffffff80155110>] do_softirq+0xb0/0xe0
> [<ffffffff80101930>] mipsIRQ+0x130/0x1e0
> [<ffffffff80101c90>] r4k_wait+0x0/0x10
> [<ffffffff80103e6c>] cpu_idle+0x4c/0x68
> [<ffffffff80103e64>] cpu_idle+0x44/0x68
> [<ffffffff8037fcfc>] start_kernel+0x454/0x4e8
> [<ffffffff8037fcf4>] start_kernel+0x44c/0x4e8
The bug is that ipv6 is doing an operation to handle MIB statistics and
the MIPS architecture math routines seem to need to sleep.
Previous versions of SNMP code may have done atomic operations, but
current 2.6 code uses per-cpu variables.
Also, there is no might sleep in the current 2.6 MIPS code either
so the problem is probably fixed if you use current 2.6.12 or later
kernel.
Thanks
Steve
^ permalink raw reply
* Re: [PATCH] add new iptables ipt_connbytes match
From: Patrick McHardy @ 2005-08-17 10:29 UTC (permalink / raw)
To: Amin Azez; +Cc: Linux Netdev List, Netfilter Development Mailinglist
In-Reply-To: <4301CB6D.80901@ufomechanic.net>
Amin Azez wrote:
> Work well done, so oughtn't div64_64 to go in
> include/asm-generic/div64.h one day, to be available kernel wide, as
> do_div64_64
>
> I see that net/core/pktgen.c is full of 64 bit division and maybe could
> benefit from this, and perhaps a version that does remainders too.
So far nothing besides ipt_connbytes and pktgen seems to need
it, and they use different versions. I'd rather leave it where
it is to not encourage more use of it.
^ permalink raw reply
* [ANNOUNCE] iproute2 util update
From: Stephen Hemminger @ 2005-08-16 21:34 UTC (permalink / raw)
To: netdev, lartc; +Cc: linux-kernel
http://developer.osdl.org/dev/iproute2/download/iproute2-050816.tar.gz
Update to iproute2 to include:
* Limit ip neigh flush to 10 rounds
* tc ematch support (thomas)
* build cleanups (thomas, et al)
* Fix for options process with ipt (jamal)
* Fix array overflow in paretonormal distribution build
* Update include files to 2.6.13
* Decnet doc update (Steven Whithouse)
Note: the ematch support won't build on really old versions of bison (1.28),
but the kernel on those systems wouldn't support it anyway.
^ permalink raw reply
* ÀÌÁ¦ µÉ¶§±îÁöÀüÈ¿µ¾î ¹«·áüÇèÇϼ¼¿ä!!
From: ¼Õ¼±¿µ @ 2005-08-16 13:20 UTC (permalink / raw)
To: cvs
[-- Attachment #1: Type: text/html, Size: 1927 bytes --]
^ permalink raw reply
* Re: [PATCH] add new iptables ipt_connbytes match
From: Amin Azez @ 2005-08-16 11:18 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List, Netfilter Development Mailinglist
In-Reply-To: <42FD4AC6.2020506@trash.net>
Work well done, so oughtn't div64_64 to go in
include/asm-generic/div64.h one day, to be available kernel wide, as
do_div64_64
I see that net/core/pktgen.c is full of 64 bit division and maybe could
benefit from this, and perhaps a version that does remainders too.
Amin
Patrick McHardy wrote:
> Harald Welte wrote:
>
>> Just send two incremental patches to Dave.
>
>
> Here they are. The first patch fixes the div64_64 function, the second
> one renames some constants.
>
>
> ------------------------------------------------------------------------
>
> [NETFILTER]: Fix div64_64 in ipt_connbytes
>
> Signded-off-by: Patrick McHardy <kaber@trash.net>
>
> ---
> commit 62084bc1a04e2fbc492566fa30997bd0a7aa2d0a
> tree 083c8042609e0da81f0be9e15583d5d31b54e685
> parent 68e734a5864ba568058c3b8ea63fac3d7d567542
> author Patrick McHardy <kaber@trash.net> Sat, 13 Aug 2005 03:16:32 +0200
> committer Patrick McHardy <kaber@trash.net> Sat, 13 Aug 2005 03:16:32 +0200
>
> net/ipv4/netfilter/ipt_connbytes.c | 22 +++++++++-------------
> 1 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/net/ipv4/netfilter/ipt_connbytes.c b/net/ipv4/netfilter/ipt_connbytes.c
> --- a/net/ipv4/netfilter/ipt_connbytes.c
> +++ b/net/ipv4/netfilter/ipt_connbytes.c
> @@ -22,23 +22,19 @@ MODULE_AUTHOR("Harald Welte <laforge@net
> MODULE_DESCRIPTION("iptables match for matching number of pkts/bytes per connection");
>
> /* 64bit divisor, dividend and result. dynamic precision */
> -static u_int64_t div64_64(u_int64_t divisor, u_int64_t dividend)
> +static u_int64_t div64_64(u_int64_t dividend, u_int64_t divisor)
...
^ permalink raw reply
* 10ºÐ¾¿¸¸ ÅõÀÚÇÏ¿©¹«·á·Î ¿µ¾îȸÈüÇèÇغ¸¼¼¿ä~~**
From: ¼Õ¼±¿µ @ 2005-08-16 6:07 UTC (permalink / raw)
To: cvs
[-- Attachment #1: Type: text/html, Size: 1927 bytes --]
^ permalink raw reply
* Re: Route cache performance
From: Eric Dumazet @ 2005-08-16 2:23 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, netdev
In-Reply-To: <20050815213855.GA17832@netnation.com>
Simon Kirby a écrit :
> Hi!
>
> Well, after a few years of other work :), I have finally got around to
> setting up some more permanent forwarding / route cache performance
> test boxes. I noticed the route trie option in the newer 2.6 kernels
> and figured it would be a good time to revisit things.
>
> Test setup:
>
> [Xeon w/e1000]---[Opteron w/dual e1000]---[Xeon w/e1000]
>
> The Xeons are 2.4 GHz boxes and the Opteron is a 140. At some point
> I intend to compare the performance of a 32 bit versus 64 bit kernel.
>
> I'm only able to get pktgen to spit out about 660 kpps from the test 2.4
> Xeon box with onboard e1000 (pause disabled), but already I notice some
> disappointing results. The old 2.4.27 kernel I last did tests with seems
> to do a much better job of forwarding small packets (static src/dst) than
> 2.4.31 and 2.6.12.
>
> On the (leftmost) sending box, 2.4.27, 2.4.31, and 2.6.12 all seem to do
> fairly well at transmission with pktgen. The 2.6 pktgen seems a little
> better (no transmission errors and a few more Mbps), so I've been using
> 2.6.12. With fixed dst packets and pause disabled via ethtool, about
> 660 kpps is sent continuously. juno (spoofed source, userspace) seems to
> do about 360 kpps. The routes and packets are set up to route through
> the Opteron box to the receiving (rightmost) box.
>
> I've noticed that e1000 changes integrated in 2.6.11-bk2 are resulting in
> the forwarding test box slowing down enough that it seems to be exposing
> "dst cache overflow", even though under slightly less load the gc seems
> to be able to keep up. Robert, if I read correctly it seems that the
> e1000 NAPI changes were some fixes you submitted?
>
> Something appears to be different in the rtcache GC or perhaps NAPI or
> some other interaction, because firing juno at 2.4 does not show any
> problems while I can't seem to get 2.6.12 to _not_ print "dst cache
> overflow". 2.6.11 (pre-bk2) seems a little better at start, but any kind
> of burst seems to make the route cache entries exceed gc and then the
> slower hash lookups seem to make it get stuck at max_size (and printing
> "dst cache overflow") until the attack stops, even with gc_min_interval
> set to 0 (really 0).
>
> Anyway, I'm still in early testing stages here but it seems it's still as
> easy as ever to destroy routers (and hosts?) with a fairly small stream
> of small packets which create new rtcache entries. These days, 184 Mbps
> is starting to fall under the "small" DoS attack category, too.
>
> I notice the hash table size is still only 4096 buckets for 512 MB, which
> isn't that wonderful when it hits a max_size of 65536 (w/512 MB)...
>
> Simon-
>
>
Hi Simon
I think one of the reason linux 2.6 has worst results is because HZ=1000 (instead of HZ=100 for linux 2.4)
So if rt_garbage_collect() has heavy work to do, it usually break out of the loop because of :
} while (!in_softirq() && time_before_eq(jiffies, now));
Could you please test latest 2.6.13-rc6 kernel on the Opteron machine, compiled with HZ=100, with the appended kernel argument :
rhash_entries=8191 ( or rhash_entries=16383 )
and
echo 1 >/proc/sys/net/ipv4/route/gc_interval
echo 2 >/proc/sys/net/ipv4/route/gc_elasticity
Could you also post some data from your router (like : rtstat -c 20 -i 1)
Eric
^ permalink raw reply
* Thanks for being a good friend!
From: Kieth Metcalf @ 2005-08-15 23:18 UTC (permalink / raw)
To: ftp
[-- Attachment #1: Type: text/html, Size: 5427 bytes --]
^ permalink raw reply
* Route cache performance
From: Simon Kirby @ 2005-08-15 21:38 UTC (permalink / raw)
To: Robert Olsson, netdev
Hi!
Well, after a few years of other work :), I have finally got around to
setting up some more permanent forwarding / route cache performance
test boxes. I noticed the route trie option in the newer 2.6 kernels
and figured it would be a good time to revisit things.
Test setup:
[Xeon w/e1000]---[Opteron w/dual e1000]---[Xeon w/e1000]
The Xeons are 2.4 GHz boxes and the Opteron is a 140. At some point
I intend to compare the performance of a 32 bit versus 64 bit kernel.
I'm only able to get pktgen to spit out about 660 kpps from the test 2.4
Xeon box with onboard e1000 (pause disabled), but already I notice some
disappointing results. The old 2.4.27 kernel I last did tests with seems
to do a much better job of forwarding small packets (static src/dst) than
2.4.31 and 2.6.12.
On the (leftmost) sending box, 2.4.27, 2.4.31, and 2.6.12 all seem to do
fairly well at transmission with pktgen. The 2.6 pktgen seems a little
better (no transmission errors and a few more Mbps), so I've been using
2.6.12. With fixed dst packets and pause disabled via ethtool, about
660 kpps is sent continuously. juno (spoofed source, userspace) seems to
do about 360 kpps. The routes and packets are set up to route through
the Opteron box to the receiving (rightmost) box.
I've noticed that e1000 changes integrated in 2.6.11-bk2 are resulting in
the forwarding test box slowing down enough that it seems to be exposing
"dst cache overflow", even though under slightly less load the gc seems
to be able to keep up. Robert, if I read correctly it seems that the
e1000 NAPI changes were some fixes you submitted?
Something appears to be different in the rtcache GC or perhaps NAPI or
some other interaction, because firing juno at 2.4 does not show any
problems while I can't seem to get 2.6.12 to _not_ print "dst cache
overflow". 2.6.11 (pre-bk2) seems a little better at start, but any kind
of burst seems to make the route cache entries exceed gc and then the
slower hash lookups seem to make it get stuck at max_size (and printing
"dst cache overflow") until the attack stops, even with gc_min_interval
set to 0 (really 0).
Anyway, I'm still in early testing stages here but it seems it's still as
easy as ever to destroy routers (and hosts?) with a fairly small stream
of small packets which create new rtcache entries. These days, 184 Mbps
is starting to fall under the "small" DoS attack category, too.
I notice the hash table size is still only 4096 buckets for 512 MB, which
isn't that wonderful when it hits a max_size of 65536 (w/512 MB)...
Simon-
^ permalink raw reply
* [-mm PATCH 05/32] net: fix-up schedule_timeout() usage
From: Nishanth Aravamudan @ 2005-08-15 18:10 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, kuznet-v/Mj1YrvjDBInbfyfbPRSQ,
pekkas-UjJjq++bwZ7HOG6cAo2yLw, jmorris-H+wXaHxf7aLQT0dZR+AlfA,
yoshfuji-VfPWfsRibaP+Ru+s062T9g, kaber-9zj18yfci/wOIzVOb1FTxg,
jt-sDzT885Ts8HQT0dZR+AlfA, okir-pn4DOG8n3UYbFoVRYvo4fw
Cc: akpm-3NddpPZAyC0, netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20050815180514.GC2854-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Description: Use schedule_timeout_{,un}interruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size. Also use
human-time conversion functions instead of hard-coded division to avoid
rounding issues.
Signed-off-by: Nishanth Aravamudan <nacc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
net/core/pktgen.c | 13 +++++--------
net/dccp/proto.c | 2 +-
net/ipv4/ipconfig.c | 5 ++---
net/irda/ircomm/ircomm_tty.c | 9 +++------
net/sunrpc/svcsock.c | 3 +--
5 files changed, 12 insertions(+), 20 deletions(-)
--- 2.6.13-rc5-mm1/net/core/pktgen.c 2005-08-07 10:05:22.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/net/core/pktgen.c 2005-08-14 13:32:59.000000000 -0700
@@ -1452,8 +1452,7 @@ static int proc_thread_write(struct file
thread_lock();
t->control |= T_REMDEV;
thread_unlock();
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(HZ/8); /* Propagate thread->control */
+ schedule_timeout_interruptible(msecs_to_jiffies(125)); /* Propagate thread->control */
ret = count;
sprintf(pg_result, "OK: rem_device_all");
goto out;
@@ -1716,10 +1715,9 @@ static void spin(struct pktgen_dev *pkt_
printk(KERN_INFO "sleeping for %d\n", (int)(spin_until_us - now));
while (now < spin_until_us) {
/* TODO: optimise sleeping behavior */
- if (spin_until_us - now > (1000000/HZ)+1) {
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(1);
- } else if (spin_until_us - now > 100) {
+ if (spin_until_us - now > jiffies_to_usecs(1)+1)
+ schedule_timeout_interruptible(1);
+ else if (spin_until_us - now > 100) {
do_softirq();
if (!pkt_dev->running)
return;
@@ -2449,8 +2447,7 @@ static void pktgen_run_all_threads(void)
}
thread_unlock();
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(HZ/8); /* Propagate thread->control */
+ schedule_timeout_interruptible(msecs_to_jiffies(125)); /* Propagate thread->control */
pktgen_wait_all_threads_run();
}
diff -urpN 2.6.13-rc5-mm1/net/dccp/proto.c 2.6.13-rc5-mm1-dev/net/dccp/proto.c
--- 2.6.13-rc5-mm1/net/dccp/proto.c 2005-08-07 10:05:22.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/net/dccp/proto.c 2005-08-10 16:10:55.000000000 -0700
@@ -225,7 +225,7 @@ int dccp_sendmsg(struct kiocb *iocb, str
if (delay > timeo)
goto out_discard;
release_sock(sk);
- delay = schedule_timeout(delay);
+ delay = schedule_timeout_interruptible(delay);
lock_sock(sk);
timeo -= delay;
if (signal_pending(current))
diff -urpN 2.6.13-rc5-mm1/net/ipv4/ipconfig.c 2.6.13-rc5-mm1-dev/net/ipv4/ipconfig.c
--- 2.6.13-rc5-mm1/net/ipv4/ipconfig.c 2005-08-07 10:05:22.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/net/ipv4/ipconfig.c 2005-08-10 15:26:57.000000000 -0700
@@ -1102,10 +1102,9 @@ static int __init ic_dynamic(void)
#endif
jiff = jiffies + (d->next ? CONF_INTER_TIMEOUT : timeout);
- while (time_before(jiffies, jiff) && !ic_got_reply) {
+ while (time_before(jiffies, jiff) && !ic_got_reply)
set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(1);
- }
+ schedule_timeout_uninterruptible(1);
#ifdef IPCONFIG_DHCP
/* DHCP isn't done until we get a DHCPACK. */
if ((ic_got_reply & IC_BOOTP)
diff -urpN 2.6.13-rc5-mm1/net/irda/ircomm/ircomm_tty.c 2.6.13-rc5-mm1-dev/net/irda/ircomm/ircomm_tty.c
--- 2.6.13-rc5-mm1/net/irda/ircomm/ircomm_tty.c 2005-08-07 09:57:38.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/net/irda/ircomm/ircomm_tty.c 2005-08-10 15:27:13.000000000 -0700
@@ -567,10 +567,8 @@ static void ircomm_tty_close(struct tty_
self->tty = NULL;
if (self->blocked_open) {
- if (self->close_delay) {
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(self->close_delay);
- }
+ if (self->close_delay)
+ schedule_timeout_interruptible(self->close_delay);
wake_up_interruptible(&self->open_wait);
}
@@ -863,8 +861,7 @@ static void ircomm_tty_wait_until_sent(s
spin_lock_irqsave(&self->spinlock, flags);
while (self->tx_skb && self->tx_skb->len) {
spin_unlock_irqrestore(&self->spinlock, flags);
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(poll_time);
+ schedule_timeout_interruptible(poll_time);
spin_lock_irqsave(&self->spinlock, flags);
if (signal_pending(current))
break;
diff -urpN 2.6.13-rc5-mm1/net/sunrpc/svcsock.c 2.6.13-rc5-mm1-dev/net/sunrpc/svcsock.c
--- 2.6.13-rc5-mm1/net/sunrpc/svcsock.c 2005-08-07 10:05:22.000000000 -0700
+++ 2.6.13-rc5-mm1-dev/net/sunrpc/svcsock.c 2005-08-12 13:51:40.000000000 -0700
@@ -1167,8 +1167,7 @@ svc_recv(struct svc_serv *serv, struct s
while (rqstp->rq_arghi < pages) {
struct page *p = alloc_page(GFP_KERNEL);
if (!p) {
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(HZ/2);
+ schedule_timeout_uninterruptible(msecs_to_jiffies(500);
continue;
}
rqstp->rq_argpages[rqstp->rq_arghi++] = p;
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* **Lloyds TSB Urgent**
From: Lloyds TSB @ 2005-08-15 16:55 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 1204 bytes --]
^ permalink raw reply
* È¿°ú °ËÁõÈĽÃÇàÇÏ´Â ¸¶ÄÉÆÃ...
From: Wendell Kearney @ 2005-08-15 16:54 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 3805 bytes --]
^ permalink raw reply
* [°¢Á¾Ã¤¹«·Î°í¹ÎÁß?] °³ÀÎȸ»ýÁ¦µµ°¡ ÀÖ½À´Ï´Ù.
From: "½Å¿ë6" <"Bank" @ 2005-08-15 16:41 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 797 bytes --]
^ permalink raw reply
* ÀÌÁ¨ Ãò¸®´× °ÆÁ¤³¡!
From: Alfred Meza @ 2005-08-15 16:36 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 707 bytes --]
^ permalink raw reply
* ¿îÀüÁß´«ÀÌÇÇ·ÎÇϽźÐ.¼ö¸éÀ»¿äÇϽôºÐ.ÄÄÇ»Å͸¦´Ã »ç¿ëÇϽôºв²°ÃßÇÕ´Ï´Ù~~
From: Àå¼öºñ°á @ 2005-08-15 16:35 UTC (permalink / raw)
To: linux-xfs
[-- Attachment #1: Type: text/html, Size: 1394 bytes --]
^ permalink raw reply
* Áý¾ÈÀÇħ´ë.À̺Ò.º£°Ô¿¡²Ëä¿öÁø¸ÕÁöÁøµå±â°¡ 300¸¸¸¶¸®°¡ ¼½ÄÇÏ°íÀÖ½À´Ï´Ù!!!!
From: ¹ÚÁö¿¬ @ 2005-08-15 16:22 UTC (permalink / raw)
To: linux-xfs
[-- Attachment #1: Type: text/html, Size: 1410 bytes --]
^ permalink raw reply
* °á°ú·Î ¸»À»Çϴ¸¶ÄÉÆÃ~
From: Kelli Walker @ 2005-08-15 16:11 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 3683 bytes --]
^ permalink raw reply
* WINNING NOTIFICATION
From: ROYAL SPANISH SWEEPSTAKE LOTTERY @ 2005-08-15 16:06 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]
ROYAL SPANISH SWEEPSTAKE LOTTERY
INTERNATIONAL PROMOTION/PRIZE AWARD DEPT.
CALLE GRANVIA 32N 1C MADRID SPAIN
REF: RSSL/61-ILGI0509/45
BATCH:RSSL/15/096/WRCS
RE: WINNING FINAL NOTIFICATION
Dear Winner,
WINNING NOTIFICATION
We happily announce to you the draw of the Royal spanish Sweepstake Lottery International programs held on the 14th january 2005 in Madrid Spain.Your e-mail address attached to ticket number: 212005600545 188 with Serial number 4888/02 drew the lucky numbers: 41-6-76-13-45-8, which subsequently won you the lottery in the 2nd category.You have therefore been approved to claim a total sum of 1,000,000.00 Euro(One million Euro) in cash credited to file KPC/9080333308/03.This is from a total cash prize of Ten Million Euro(10 million Euro), shared amongst the first Tenth (10th) lucky winners in this category.Please note that your lucky winning number falls within our Madrid booklet representative office in Spain as indicated in your play coupon.In view of this, your 1,000,000.00 Euro(One million Euro) would be released to you by our security firm in Madrid,Spain.Our agent will immediately commence the process to facilitate the release of your funds as soon as you contact him.All participants were selected randomly from World Wide Web site through computer draw system and extracted from over 100,000 companies. This promotion takes place annually. For security reasons, you are advised to keep your winning information confidential till your claims is processed and your money remitted to you in whatever manner you deem fit to claim your prize. This is part of our precautionary measure to avoid double claiming and unwarranted abuse of this program by some unscrupulous elements. Please be warned.
To file for your claim, please contact our fiduciary agent:
Mr Jeff Carlos
World Royal Consultancy And Security Madrid Spain.
Email: worldroconsultx@netscape.net
For due processing and remittance of your prize money to a designated account of your choice.
Remember,You are to contact our agents by email and within a week of receiving this notice.After this date, all funds will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed.
To avoid unnecessary delays and complications,please quote your reference/batch numbers in any correspondences with us or our designated agent.Congratulations once more from all members and staffs of this program.
Yours Sincerely,
Wilfred Alberto
Lottery Director.
^ permalink raw reply
* ±Í»çÀÇ ¸¶ÄÉÆøðÜÁÖ¼¼¿ä
From: Graham Stokes @ 2005-08-15 15:56 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 3751 bytes --]
^ permalink raw reply
* COMPLETE YOUR $5,000,000 WINNING NOTIFICATION.
From: LOCKYSURF LOTTO INTERNATIONAL. @ 2005-08-15 15:49 UTC (permalink / raw)
To: netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="DEFAULT", Size: 2535 bytes --]
WELCOME TO LOTTERIAS Y APUESTAS DEL ESTADO,ESPANA
C/PLAZA DE ESPANA,28020 MADRID - ESPAÑA
TEL:0034-678-188-705
FROM: THE DESK OF THE PROMOTIONS/BONAZA MANAGER,
INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT,
REF: LP/26510460037/02 BATCH: 24/00319/IPD.
ATTN:
( CONGRATULATION)
DEAR SIR,
"AWARD NOTIFICATION FINAL NOTICE."
We are pleased to inform you of the announcement, of winners of the LuckySurf Lotto International held on 6th August ,2005.
Your name is attached to ticket number 004-05117963-198, with serial number 12A drew no 03/61,the winning ticket numbers 61622 and consequently won the lottery in the 1st category. You have therefore been approved for a lump sum pay out of $5,000,000.00 million MeGa Prize in cash credited to file No:LP/26510460037/02.This is from total prize money of $30,000,000.00 shared among the six international winners n this category. All participants were selected through a computer ballot system drawn form 25,000 names from Australia, New Zealand,America, Europe, North America and Asia as part of International
Promotions Program, which is conducted annually.
CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this
program. We hope with a part of you prize, you will participate in our end of year high stakes Euros1.1 billion International Lottery. To begin your claim, please contact your claim agent at the below information.
Contact Person:Dr Benard Thomson.
Tel:(+34-678-188-705 )
Email: lottosurf@walla.com
For due processing and remittance of your prize money to a designated account with our bankers. Remember, all prize money must be claimed not later than 27TH August, 2005. After this date, all funds will be returned as unclaimed.
NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondences with your agent.
Furthermore,. should there be any change of your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programm.
( CONGRATULATION)
BEST REGARDS,DR. CLIFFORD F. LOPEZ.
(DIRECTOR EXTERNAL AFFAIRS
^ permalink raw reply
* Ä«µå´ëÃâ ÇÏ·çÀÌÀÚ330¿ø¿¡ Ä«µå ¿¬Ã¼À²¸·À¸¼¼¿©Àå±âÇҺηÎ!@ ggltb a
From: 87gboejp @ 2005-08-15 15:46 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 920 bytes --]
^ permalink raw reply
* ±ÍÇÏÀÇ ¸¶ÄÉÆà åÀÓÁö°Ú½À´Ï´Ù
From: Lucinda Culver @ 2005-08-15 15:39 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 3746 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox