"Jeff V. Merkey" wrote:
>
> "David S. Miller" wrote:
> >
> >Date:Tue, 10 Oct 2000 00:44:58 +0200
> >From: "Andi Kleen" <[EMAIL PROTECTED]>
> >
> >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> >> I dont actually know a CPU that doesnt have one in SMP mode.
"Jeff V. Merkey" wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > "David S. Miller" wrote:
> > >
> > >Date:Tue, 10 Oct 2000 00:44:58 +0200
> > >From: "Andi Kleen" <[EMAIL PROTECTED]>
> > >
> > >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > >> I dont
"David S. Miller" wrote:
>
>Date:Tue, 10 Oct 2000 00:44:58 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
>> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
>> behind an I/O
"David S. Miller" wrote:
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that
"Jeff V. Merkey" wrote:
"Jeff V. Merkey" wrote:
"David S. Miller" wrote:
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
I dont actually know a CPU that
"Jeff V. Merkey" wrote:
"David S. Miller" wrote:
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
Hello!
> > And what the hell does TCP need current for anyway?
>
> For a very hackish user context TCP implementation that probably should
> be cleaned up (but it is code freeze etc.etc.blabla.)
TCP does not _use_ value of current in softirq, certainly.
But it really refers to current, just
Hello!
And what the hell does TCP need current for anyway?
For a very hackish user context TCP implementation that probably should
be cleaned up (but it is code freeze etc.etc.blabla.)
TCP does not _use_ value of current in softirq, certainly.
But it really refers to current, just
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Linus Torvalds wrote:
>> You can also still do the stack pointer plaything by just using
>> indirection: and when you context switch you switch the pointer around at
>> the base of the per-cpu interrupt stack.
>
"Jeff V. Merkey" wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > "David S. Miller" wrote:
> > >
> > >Date:Tue, 10 Oct 2000 00:44:58 +0200
> > >From: "Andi Kleen" <[EMAIL PROTECTED]>
> > >
> > >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > >> I dont actually
Based of my measurement on i386 smp configuration,
If a system has plenty of runnable tasks, schedule() produces
noticable amount of cache misses at runqueue-head traversing and the
goodness calculations.
David S. Miller writes:
> Some of us actually have instrumented it :-) I added a coloring
Date:Tue, 10 Oct 2000 10:54:11 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
Having the stacks aligned also isnt good for the caches. If you are
bored some time instrument the cache lines that wake_up() touches
on a wake. Its very common to see most of them being on the
> Linus Torvalds wrote:
> > You can also still do the stack pointer plaything by just using
> > indirection: and when you context switch you switch the pointer around =
> at
> > the base of the per-cpu interrupt stack.
>
> Indirection, =E0 la "current =3D *(stack & ~8191)" might not be a bad
Linus Torvalds wrote:
> You can also still do the stack pointer plaything by just using
> indirection: and when you context switch you switch the pointer around at
> the base of the per-cpu interrupt stack.
Indirection, à la "current = *(stack & ~8191)" might not be a bad idea
in general. As
On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
Linus Torvalds wrote:
You can also still do the stack pointer plaything by just using
indirection: and when you context switch you switch the pointer around at
the base of the per-cpu interrupt stack.
Indirection, à la "current = *(stack ~8191)" might not be a bad idea
in general. As Ralf
Linus Torvalds wrote:
You can also still do the stack pointer plaything by just using
indirection: and when you context switch you switch the pointer around =
at
the base of the per-cpu interrupt stack.
Indirection, =E0 la "current =3D *(stack ~8191)" might not be a bad ide=
a
in
Date:Tue, 10 Oct 2000 10:54:11 +0100 (BST)
From: Alan Cox [EMAIL PROTECTED]
Having the stacks aligned also isnt good for the caches. If you are
bored some time instrument the cache lines that wake_up() touches
on a wake. Its very common to see most of them being on the
Based of my measurement on i386 smp configuration,
If a system has plenty of runnable tasks, schedule() produces
noticable amount of cache misses at runqueue-head traversing and the
goodness calculations.
David S. Miller writes:
Some of us actually have instrumented it :-) I added a coloring
"Jeff V. Merkey" wrote:
"Jeff V. Merkey" wrote:
"David S. Miller" wrote:
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
I dont actually know a CPU that doesnt have
In article [EMAIL PROTECTED],
Jamie Lokier [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
You can also still do the stack pointer plaything by just using
indirection: and when you context switch you switch the pointer around at
the base of the per-cpu interrupt stack.
Indirection, à la
On Tue, Oct 10, 2000 at 12:55:33AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
> > Simple. Each interrupt stack is, say, 8 pages. You have an array
> > of N interrupt stacks. Then you calculate
> >
> >cpu_id = (sp & ~(INT_STACK_SIZE-1)) >>
On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
> Simple. Each interrupt stack is, say, 8 pages. You have an array
> of N interrupt stacks. Then you calculate
>
>cpu_id = (sp & ~(INT_STACK_SIZE-1)) >> (PAGE_SHIFT + 3);
>
> Actually, I'd put the interrupt stack and any other
> > I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> > behind an I/O interface that is slower than ideal
>
> Where would you put it for IA32 ? I don't know any free MSR that could
> be abused for that, and acessing MSRs is insanely slow anyways. Any
> other ideas ?
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> behind an I/O interface that is slower than ideal
Where
On Tue, Oct 10, 2000 at 12:36:35AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > > I think I'll go for the 'current is in a well-known register'
> > > approach and see how this goes...
> >
> > Failing that the 2.0 approach will work, current is a global
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > The problem is where to get the cpuid from (see how smp_processor_id
> > is currently defined ;) When you don't have a hidden register in the
> > CPU you're screwed.
> > [x86-64 has one btw]
>
> I dont actually know a CPU that
> The problem is where to get the cpuid from (see how smp_processor_id
> is currently defined ;) When you don't have a hidden register in the
> CPU you're screwed.
> [x86-64 has one btw]
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that
On Mon, 9 Oct 2000, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
You can also still
On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
> I think I'll go for the 'current is in a well-known register'
> approach and see how this goes...
Failing that the 2.0 approach will work, current is a global in uniprocessor
and a #define to an array indexed by cpu id in smp
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, Oct 10, 2000 at 09:04:30AM +1100, Keith Owens wrote:
> On 9 Oct 2000 11:08:36 -0700,
> [EMAIL PROTECTED] (Linus Torvalds) wrote:
> >Note that there are alternative approaches. For example, you could make
> >the interrupt stack be in the same multi-page as the regular stack, and
> >switch
On 9 Oct 2000 11:08:36 -0700,
[EMAIL PROTECTED] (Linus Torvalds) wrote:
>Note that there are alternative approaches. For example, you could make
>the interrupt stack be in the same multi-page as the regular stack, and
>switch them both at task-switch time - just allocate four pages instead
>of
On Sun, Oct 08, 2000 at 09:27:09PM +0100, Kenn Humborg wrote:
> I'm working on the VAX port and the reason I ask is that the
> VAX has separate stack pointers for user, kernel and interrupt
> contexts. Therefore, the current = (SP & ~8192) hack will give
> completely bogus results when handling
On Sun, Oct 08, 2000 at 05:05:45PM -0600, [EMAIL PROTECTED] wrote:
> > > BTW: there is an implicit reference to "current" in smp_processor_id.
> >
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
On Sun, Oct 08, 2000 at 04:19:01PM -0700, Mitchell Blank Jr wrote:
> Some do (look at asm-sparc/smp.h). However, linux does everything possible
> to make dereferencing "current" as fast as possible, so actually just
> looping it up there is pretty damn efficient. We need to keep track of the
>
On Sun, Oct 08, 2000 at 04:36:09PM -0600, [EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
More a design principle than a real problem.
> BTW: there is an implicit reference to "current" in smp_processor_id.
Which is
In article <[EMAIL PROTECTED]>,
Kenn Humborg <[EMAIL PROTECTED]> wrote:
>
>I'd just like to confirm that it's illegal to call current()
>from interrupt-handling code.
It's not categorically forbidden.
It does indeed happen, think about things like cross-CPU interrupts for
TLB invalidations
On Sun, 8 Oct 2000, Mitchell Blank Jr wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the code, I don't see any places where "current" is not valid.
> > Got some examples?
>
> It's not that its invalid, it just doesn't make much sense. It points to
> whatever task happened to be running when
On Sun, 8 Oct 2000, Kenn Humborg wrote:
>
> I'd just like to confirm that it's illegal to call current()
> from interrupt-handling code.
>
> I'm working on the VAX port and the reason I ask is that the
> VAX has separate stack pointers for user, kernel and interrupt
> contexts. Therefore, the
Hi,
> The m68k port which has a interrupt stack solves the problem by
> loading current into a global register variable on all kernel entries.
Not all m68k cpus have an interrupt stack and it can be turned off, so we
don't use it.
bye, Roman
-
To unsubscribe from this list: send the line
On Mon, Oct 09, 2000 at 03:54:21AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote:
> > On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> > > On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > > > 2.4 TCP code relies on current
On Mon, Oct 09, 2000 at 03:54:21AM +0200, Andi Kleen wrote:
On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote:
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
2.4 TCP code relies on current being valid
Hi,
The m68k port which has a interrupt stack solves the problem by
loading current into a global register variable on all kernel entries.
Not all m68k cpus have an interrupt stack and it can be turned off, so we
don't use it.
bye, Roman
-
To unsubscribe from this list: send the line
In article [EMAIL PROTECTED],
Kenn Humborg [EMAIL PROTECTED] wrote:
I'd just like to confirm that it's illegal to call current()
from interrupt-handling code.
It's not categorically forbidden.
It does indeed happen, think about things like cross-CPU interrupts for
TLB invalidations etc.
At
On Sun, Oct 08, 2000 at 04:36:09PM -0600, [EMAIL PROTECTED] wrote:
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
More a design principle than a real problem.
BTW: there is an implicit reference to "current" in smp_processor_id.
Which is
On Sun, Oct 08, 2000 at 04:19:01PM -0700, Mitchell Blank Jr wrote:
Some do (look at asm-sparc/smp.h). However, linux does everything possible
to make dereferencing "current" as fast as possible, so actually just
looping it up there is pretty damn efficient. We need to keep track of the
On Sun, Oct 08, 2000 at 05:05:45PM -0600, [EMAIL PROTECTED] wrote:
BTW: there is an implicit reference to "current" in smp_processor_id.
Yes, on architectures that use current-processor that is an exception
to the rule. After all, you know for sure that you're still on the
same
On Sun, Oct 08, 2000 at 09:27:09PM +0100, Kenn Humborg wrote:
I'm working on the VAX port and the reason I ask is that the
VAX has separate stack pointers for user, kernel and interrupt
contexts. Therefore, the current = (SP ~8192) hack will give
completely bogus results when handling an
On 9 Oct 2000 11:08:36 -0700,
[EMAIL PROTECTED] (Linus Torvalds) wrote:
Note that there are alternative approaches. For example, you could make
the interrupt stack be in the same multi-page as the regular stack, and
switch them both at task-switch time - just allocate four pages instead
of two,
On Tue, Oct 10, 2000 at 09:04:30AM +1100, Keith Owens wrote:
On 9 Oct 2000 11:08:36 -0700,
[EMAIL PROTECTED] (Linus Torvalds) wrote:
Note that there are alternative approaches. For example, you could make
the interrupt stack be in the same multi-page as the regular stack, and
switch them
I think I'll go for the 'current is in a well-known register'
approach and see how this goes...
Failing that the 2.0 approach will work, current is a global in uniprocessor
and a #define to an array indexed by cpu id in smp
-
To unsubscribe from this list: send the line "unsubscribe
On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
I think I'll go for the 'current is in a well-known register'
approach and see how this goes...
Failing that the 2.0 approach will work, current is a global in uniprocessor
and a #define to an array indexed by cpu id in smp
The
On Mon, 9 Oct 2000, Alan Cox wrote:
I think I'll go for the 'current is in a well-known register'
approach and see how this goes...
Failing that the 2.0 approach will work, current is a global in uniprocessor
and a #define to an array indexed by cpu id in smp
You can also still do the
The problem is where to get the cpuid from (see how smp_processor_id
is currently defined ;) When you don't have a hidden register in the
CPU you're screwed.
[x86-64 has one btw]
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that is
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
The problem is where to get the cpuid from (see how smp_processor_id
is currently defined ;) When you don't have a hidden register in the
CPU you're screwed.
[x86-64 has one btw]
I dont actually know a CPU that doesnt have
On Tue, Oct 10, 2000 at 12:36:35AM +0200, Andi Kleen wrote:
On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
I think I'll go for the 'current is in a well-known register'
approach and see how this goes...
Failing that the 2.0 approach will work, current is a global in
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that is slower than ideal
Where
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that is slower than ideal
Where would you put it for IA32 ? I don't know any free MSR that could
be abused for that, and acessing MSRs is insanely slow anyways. Any
other ideas ?
The
On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
Simple. Each interrupt stack is, say, 8 pages. You have an array
of N interrupt stacks. Then you calculate
cpu_id = (sp ~(INT_STACK_SIZE-1)) (PAGE_SHIFT + 3);
Actually, I'd put the interrupt stack and any other per-cpu
On Tue, Oct 10, 2000 at 12:55:33AM +0200, Andi Kleen wrote:
On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
Simple. Each interrupt stack is, say, 8 pages. You have an array
of N interrupt stacks. Then you calculate
cpu_id = (sp ~(INT_STACK_SIZE-1)) (PAGE_SHIFT +
On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> > On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > > 2.4 TCP code relies on current being valid in a softirq.
> >
> > And what the hell does TCP need
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
>
> And what the hell does TCP need current for anyway?
I think the only reference is in tcp_input.c,
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
>
> Well, then as long as Linux guarantees that there is always a
> valid 'current task' on a CPU, then I can
On Mon, Oct 09, 2000 at 02:09:49AM +0100, Kenn Humborg wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
> >
> > The m68k port which has a interrupt stack solves the problem by
> > loading current into a global register variable on all kernel entries.
> > x86-64 will likely do
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> 2.4 TCP code relies on current being valid in a softirq.
Well, then as long as Linux guarantees that there is always a
valid 'current task' on a CPU, then I can special-case the
called-from-interrupt case. The previous kernel stack
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > BTW: there is an implicit reference to "current" in smp_processor_id.
>
> Yes I forgot about that. (Self-flagellate). However that is
> architecture specific. If it's not an SMP Vax port, no big
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> > Kenn Humborg wrote:
> > > My feeling is that interrupt code has no business calling current(),
> > > but I don't know the kernel well enough to be sure. Is there any
>
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> Kenn Humborg wrote:
> > My feeling is that interrupt code has no business calling current(),
> > but I don't know the kernel well enough to be sure. Is there any
> > interrupt-level code that calls current() or is it a design
> >
[EMAIL PROTECTED] wrote:
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
> > same CPU as the task currently running.
>
> This makes sense. And I wish cpu architects would put a cpu-id
> register
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the [network] code, I don't see any places where "current"
> > is not valid.
> > Got some examples?
>
> Damn I'm being dense tonight. No, that bug was due to calling "current"
> from the
On Sun, Oct 08, 2000 at 03:58:55PM -0700, Mitchell Blank Jr wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the code, I don't see any places where "current" is not valid.
> > Got some examples?
>
> It's not that its invalid, it just doesn't make much sense. It points to
> whatever task
[EMAIL PROTECTED] wrote:
> Looking at the [network] code, I don't see any places where "current"
> is not valid.
> Got some examples?
Damn I'm being dense tonight. No, that bug was due to calling "current"
from the wrong process context, not from an invalid context.
(Self-flagellate,
[EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be running when the interrupt happened. So
any attempt to access it is
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
BTW: there is an implicit reference to "current" in smp_processor_id.
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> Kenn Humborg wrote:
> > My feeling is that interrupt code has
Kenn Humborg wrote:
> My feeling is that interrupt code has no business calling current(),
> but I don't know the kernel well enough to be sure. Is there any
> interrupt-level code that calls current() or is it a design
> principle that it cannot be called?
It's a design principle that you must
I'd just like to confirm that it's illegal to call current()
from interrupt-handling code.
I'm working on the VAX port and the reason I ask is that the
VAX has separate stack pointers for user, kernel and interrupt
contexts. Therefore, the current = (SP & ~8192) hack will give
completely bogus
I'd just like to confirm that it's illegal to call current()
from interrupt-handling code.
I'm working on the VAX port and the reason I ask is that the
VAX has separate stack pointers for user, kernel and interrupt
contexts. Therefore, the current = (SP ~8192) hack will give
completely bogus
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
BTW: there is an implicit reference to "current" in smp_processor_id.
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
Kenn Humborg wrote:
My feeling is that interrupt code has no
[EMAIL PROTECTED] wrote:
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be running when the interrupt happened. So
any attempt to access it is 99%
[EMAIL PROTECTED] wrote:
Looking at the [network] code, I don't see any places where "current"
is not valid.
Got some examples?
Damn I'm being dense tonight. No, that bug was due to calling "current"
from the wrong process context, not from an invalid context.
(Self-flagellate,
On Sun, Oct 08, 2000 at 03:58:55PM -0700, Mitchell Blank Jr wrote:
[EMAIL PROTECTED] wrote:
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
[EMAIL PROTECTED] wrote:
Looking at the [network] code, I don't see any places where "current"
is not valid.
Got some examples?
Damn I'm being dense tonight. No, that bug was due to calling "current"
from the wrong process
[EMAIL PROTECTED] wrote:
Yes, on architectures that use current-processor that is an exception
to the rule. After all, you know for sure that you're still on the
same CPU as the task currently running.
This makes sense. And I wish cpu architects would put a cpu-id
register somewhere
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
Kenn Humborg wrote:
My feeling is that interrupt code has no business calling current(),
but I don't know the kernel well enough to be sure. Is there any
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
[EMAIL PROTECTED] wrote:
BTW: there is an implicit reference to "current" in smp_processor_id.
Yes I forgot about that. (Self-flagellate). However that is
architecture specific. If it's not an SMP Vax port, no big deal. If
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
2.4 TCP code relies on current being valid in a softirq.
Well, then as long as Linux guarantees that there is always a
valid 'current task' on a CPU, then I can special-case the
called-from-interrupt case. The previous kernel stack
On Mon, Oct 09, 2000 at 02:09:49AM +0100, Kenn Humborg wrote:
2.4 TCP code relies on current being valid in a softirq.
The m68k port which has a interrupt stack solves the problem by
loading current into a global register variable on all kernel entries.
x86-64 will likely do the same.
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
2.4 TCP code relies on current being valid in a softirq.
Well, then as long as Linux guarantees that there is always a
valid 'current task' on a CPU, then I can
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
2.4 TCP code relies on current being valid in a softirq.
And what the hell does TCP need current for anyway?
I think the only reference is in tcp_input.c,
On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote:
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
2.4 TCP code relies on current being valid in a softirq.
And what the hell does TCP need current for
91 matches
Mail list logo
