i attached it in a previous mail... try again...
--
cinap
--- Begin Message ---
> process1:
> still in kernel:
> memmove(buf, ...)
> *fault*
> trap()
> fault386()
> fault() => -1
>
you can get similar effects by remapping things.
i meant that it isn't likely to happen by accident, so am i bovvered?
fault386 needs to be fixed mainly by or for people running a shared cpu
server with hostile users (ie, students).
for the rest of us it might be more useful to have the panic
to pr
> it ensures mmuflushes in all other processes (sharing that segment) as well.
> in fact, the crash you describe just emphasises that point:
> the page reference no longer exists, hence the fault.
>
> the problem (which frankly doesn't bother me) is that fault386
> is being overly cautious in assu
>but my testcase crashes a uniprocessor system, so here is no
>waiting for mmuflushes on other processors going on.
it ensures mmuflushes in all other processes (sharing that segment) as well.
in fact, the crash you describe just emphasises that point:
the page reference no longer exists, hence th
2009/7/31 erik quanstrom :
>> > could you be more specific. what is your test program,
>> > where is it crashing (if you know), and what is the panic
>> > message, if any? i must be dense, but i'm confused by
>> > your process diagram.
>>
>> He posted it earlier in this thread
>>
>> --dho
>
> ple
> > could you be more specific. what is your test program,
> > where is it crashing (if you know), and what is the panic
> > message, if any? i must be dense, but i'm confused by
> > your process diagram.
>
> He posted it earlier in this thread
>
> --dho
please post a reference. i do not see
2009/7/31 erik quanstrom :
>> process1:
>> still in kernel:
>> memmove(buf, ...)
>> *fault*
>> trap()
>> fault386()
>> fault() => -1
>> if(!user){
>>
> process1:
> still in kernel:
> memmove(buf, ...)
> *fault*
> trap()
> fault386()
> fault() => -1
> if(!user){
> panic()
>
very interesting. thanks for the sum up.
but my testcase crashes a uniprocessor system, so here is no
waiting for mmuflushes on other processors going on.
any other process that shares the segment and was suspended
in the kernel may potentialy hold a pointer to that freed memory
area of the segme
> ... procflushseg finds all processes that share s, sets them all up
> to flush their mmu states, and also sets any processor running such a process
> to flush its state (that's picked up by a clock interrupt).
>
> procflushseg will not proceed until all processes and processors that
> might need
this resulted in a little side discussion.
to save someone else from having to break a strong oath about 9fans,
i'll sum it up. the existing code handles this situation.
when several processes share a segment, and any one of them
decides to shrink the segment, all the processes must see
the change
just stop processes with s->ref > 1 from freeing parts of s with ibrk.
it's not as if anything ever does in practice.
> I think you may be right, Elly. Multithreaded programs indeed have their
> stack running outside the stack segment, so this could happen there.
> splhi won't even do on a multiprocessor. One should probably lock down
> the segment.
> We've never seen this happen, of course — or rather, we haven
... but you can still shrink segments for other processes :-)
(this crashes the kernel)
--
cinap
--- Begin Message ---
hm... what about the other stuff port/sysfile.c?
they also just checks pointers with validaddr and then call
into the device handler without locking anything / holding
anything.
ok, forget it... the segments are actualy reference counted.
so a process would not be able to unmap a segment in
another process.
--
cinap
--- Begin Message ---
> On Thu, 30 Jul 2009, erik quanstrom wrote:
>
>> On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
>>> My familiarity with
hm... what about the other stuff port/sysfile.c?
they also just checks pointers with validaddr and then call
into the device handler without locking anything / holding
anything.
--
cinap
--- Begin Message ---
> On Thu, 30 Jul 2009, erik quanstrom wrote:
>
>> On Thu Jul 30 00:05:45 EDT 2009, el.
> > plan 9 threads are cooperatively scheduled. so
> > the correct term is proc. but you are correct,
> > another proc sharing memory with this one
> > could be running. however, that proc would
> > not have access to this proc's stack. (rfork
> > doesn't allow shared stack.) and even if it
>
> On Thu, 30 Jul 2009, erik quanstrom wrote:
>
>> On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
>>> My familiarity with the kernel source code is superficial to say the
>>> least, but it seems to me that this code (from /sys/src/9/pc/trap.c)
>>> contains a race condition:
>>>
>>>
On Thu, 30 Jul 2009, erik quanstrom wrote:
On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
My familiarity with the kernel source code is superficial to say the
least, but it seems to me that this code (from /sys/src/9/pc/trap.c)
contains a race condition:
702 if(sp<(USTK
On Thu Jul 30 00:05:45 EDT 2009, el...@andrew.cmu.edu wrote:
> My familiarity with the kernel source code is superficial to say the
> least, but it seems to me that this code (from /sys/src/9/pc/trap.c)
> contains a race condition:
>
> 702 if(sp<(USTKTOP-BY2PG) || sp>(USTKTOP-sizeof(Sa
My familiarity with the kernel source code is superficial to say the
least, but it seems to me that this code (from /sys/src/9/pc/trap.c)
contains a race condition:
702 if(sp<(USTKTOP-BY2PG) || sp>(USTKTOP-sizeof(Sargs)-BY2WD))
703 validaddr(sp, sizeof(Sargs)+BY2WD, 0);
7
21 matches
Mail list logo
