Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*System\s+crash\s+in\s+tcp_fragment\(\)\s*$/: 50 ]

Total 50 documents matching your query.

1. System crash in tcp_fragment() (score: 1)
Author: -Szabo <kisza@xxxxxxxxxxxxxxxx>
Date: Mon, 20 May 2002 12:42:08 -0700
I wonder if you could help me squash a bug in the tcp code. Here is what we know thus far: An SMP (x386 dual) 2.4.17 kernel crashes with an attempt to deference NULL at the end of tcp_fragment() (in
/archives/netdev/2002-05/msg00041.html (11,923 bytes)

2. Re: System crash in tcp_fragment() (score: 1)
Author: ge anzinger <george@xxxxxxxxxx>
Date: Mon, 20 May 2002 22:29:37 +0200
2.4 TCP should in theory already have enough locking to prevent this (the socket lock that is aquired by timers and user context socket users) -Andi
/archives/netdev/2002-05/msg00042.html (9,024 bytes)

3. Re: System crash in tcp_fragment() (score: 1)
Author: vedita Singhvi <niv@xxxxxxxxxx>
Date: Mon, 20 May 2002 14:18:34 -0700
Here is another oops, not quite the same, AND with an assert failure ahead of it. I append the whole report and some and some observations: We had two more panics over the weekend. Here is the analys
/archives/netdev/2002-05/msg00045.html (15,416 bytes)

4. Re: System crash in tcp_fragment() (score: 1)
Author: ge anzinger <george@xxxxxxxxxx>
Date: Tue, 21 May 2002 01:25:53 +0400 (MSD)
No. They are already applied. Looking at the last lines of the bugzilla thread, I see the answer: Well, add BUG() to BIG_TRAP() to oops it earlier. Maybe this will move you closer to real problem. A
/archives/netdev/2002-05/msg00046.html (9,346 bytes)

5. Re: System crash in tcp_fragment() (score: 1)
Author: xxxxxxxxx>
Date: Mon, 20 May 2002 15:08:33 -0700 (PDT)
I wonder if you could help me squash a bug in the tcp code. Here is what we know thus far: An SMP (x386 dual) 2.4.17 kernel crashes with an attempt to deference NULL at the end of tcp_fragment() (in
/archives/netdev/2002-05/msg00047.html (9,022 bytes)

6. Re: System crash in tcp_fragment() (score: 1)
Author: d S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 20 May 2002 16:01:00 -0700
Right. Will do. That (ahem) hack was tried and rejected by the powers that be. I admit that is it more work to find the resulting problems, but the fixes seem to be easy and do not to add to overhead
/archives/netdev/2002-05/msg00048.html (10,498 bytes)

7. Re: System crash in tcp_fragment() (score: 1)
Author: ge anzinger <george@xxxxxxxxxx>
Date: Tue, 21 May 2002 01:54:07 +0200
It's unfortunately the truth. Even in_interrupt() is buggy current on SMP preemptive. -Andi
/archives/netdev/2002-05/msg00049.html (9,372 bytes)

8. Re: System crash in tcp_fragment() (score: 1)
Author: xxxxxx>
Date: Tue, 21 May 2002 04:11:00 +0400 (MSD)
And why folks working on preemtive kernel do not repair this? To all that I remember it is well known issue. Alexey
/archives/netdev/2002-05/msg00050.html (9,032 bytes)

9. Re: System crash in tcp_fragment() (score: 1)
Author: k@xxxxxxx>
Date: Tue, 21 May 2002 02:20:07 +0200
It is fixed on x86-64 @) if [ "$CONFIG_SMP" = "n" ]; then bool 'Preemptible Kernel' CONFIG_PREEMPT fi -Andi
/archives/netdev/2002-05/msg00051.html (9,832 bytes)

10. Re: System crash in tcp_fragment() (score: 1)
Author: xxxxxxx
Date: Mon, 20 May 2002 17:26:29 -0700
Ah, but we have. in_interrupt() was fixed about a month ago. I think Robert got it into all the patches. Whats more, it is a bit faster too :) -- George Anzinger george@xxxxxxxxxx High-res-timers: ht
/archives/netdev/2002-05/msg00052.html (9,560 bytes)

11. Re: System crash in tcp_fragment() (score: 1)
Author: ge anzinger <george@xxxxxxxxxx>
Date: Mon, 20 May 2002 17:18:19 -0700 (PDT)
Ah, but we have. in_interrupt() was fixed about a month ago. I think Robert got it into all the patches. Whats more, it is a bit faster too :) Well, back to the main point, this code is pretty stable
/archives/netdev/2002-05/msg00053.html (9,147 bytes)

12. Re: System crash in tcp_fragment() (score: 1)
Author: d S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 20 May 2002 17:34:21 -0700
That is not a fix! It is dodging the issue. ;) -- George Anzinger george@xxxxxxxxxx High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/
/archives/netdev/2002-05/msg00054.html (10,487 bytes)

13. Re: System crash in tcp_fragment() (score: 1)
Author: ge anzinger <george@xxxxxxxxxx>
Date: Tue, 21 May 2002 04:41:39 +0400 (MSD)
It is the only real fix, if you are going to follow this instruction: +RULE #1: Per-CPU data structures need explicit protection + + +Two similar problems arise. An example code snippet: + + struct
/archives/netdev/2002-05/msg00055.html (10,202 bytes)

14. Re: System crash in tcp_fragment() (score: 1)
Author:
Date: Mon, 20 May 2002 17:34:16 -0700 (PDT)
+Two similar problems arise. An example code snippet: + + struct this_needs_locking tux[NR_CPUS]; + tux[smp_processor_id()] = some_value; + /* task is preempted here... */ + something = tux[smp_proce
/archives/netdev/2002-05/msg00057.html (10,643 bytes)

15. Re: System crash in tcp_fragment() (score: 1)
Author: d S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 21 May 2002 02:39:19 +0200
It's not fixed in 2.5.15/16. I don't know about your patches. -Andi
/archives/netdev/2002-05/msg00058.html (9,458 bytes)

16. Re: System crash in tcp_fragment() (score: 1)
Author: xxxxxxx>
Date: Tue, 21 May 2002 05:00:11 +0400 (MSD)
Yup. And this has nothing to do with SMP... Well, we can make this. It is too serious. Anyway, this means that preemptive patch for 2.4 is "tainting" :-) Alexey
/archives/netdev/2002-05/msg00059.html (10,118 bytes)

17. Re: System crash in tcp_fragment() (score: 1)
Author: ak@xxxxxx>
Date: Mon, 20 May 2002 18:49:27 -0700 (PDT)
A lot of the synchronization between process context and interrupt context is based on per-cpu data structures or simple locks (without disabling irq's globally) eg: softnet_data queue (we only disab
/archives/netdev/2002-05/msg00060.html (10,888 bytes)

18. Re: System crash in tcp_fragment() (score: 1)
Author: Laudney Ren" <laudney@xxxxxxxx>
Date: Mon, 20 May 2002 23:08:38 -0700
May be someone could tell me if these matter. If you are bumping a counter and you switch cpus in the middle, a.) does it matter? and b.) if so which cpu should get the count? I sort of thought that,
/archives/netdev/2002-05/msg00063.html (12,097 bytes)

19. Re: System crash in tcp_fragment() (score: 1)
Author: ge anzinger <george@xxxxxxxxxx>
Date: Mon, 20 May 2002 23:00:21 -0700 (PDT)
May be someone could tell me if these matter. If you are bumping a counter and you switch cpus in the middle, a.) does it matter? and b.) if so which cpu should get the count? I sort of thought that
/archives/netdev/2002-05/msg00064.html (11,855 bytes)

20. Re: System crash in tcp_fragment() (score: 1)
Author: d S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 21 May 2002 00:25:46 -0700
I understand the issue. The question is what is the result. Bogus numbers do.. what? Does the kernel crash or does the user think strange things while every thing just keeps on working? As for the fi
/archives/netdev/2002-05/msg00065.html (13,389 bytes)


This search system is powered by Namazu