Re: [9fans] Race condition in /sys/src/9/pc/trap.c?

[Charles Forsyth <forsyth@terzarima.net>]

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

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 prevent real kernel bugs (ie, just bad pointers in device driver implementations)
from postnoting a process instead of stopping the system.
having said that, it could be argued that even in that case
a postnote to the invoking process would allow the rest of the system
to run and `might not' mean that the broken driver has wrecked other
data structures outside it in kernel memory.

[-- Attachment #2: Type: message/rfc822, Size: 2512 bytes --]

From: erik quanstrom <quanstro@coraid.com>
To: 9fans@9fans.net
Subject: Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
Date: Fri, 31 Jul 2009 15:40:41 -0400
Message-ID: <3aa6d689be5c81fc7ac72211cfee8b13@coraid.com>

> 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 assuming that a page fault that occurs
> in system mode but can't map a page successfully is necessarily a kernel bug:
> that's not true. it could just note the process instead.
> (it doesn't bother me because since unix days i've seen less than a handful
> of programs that SHRINK their existing data segments, and i think that's the
> only case that can cause the panic you're seeing.)

if this case is really not important, would it make sense
to disallow shrinking segments? it might be worth it just
to be able to define Eshrinkage.

- erik