Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Nov 2003 09:13:59 -0800
From:      Sam Leffler <sam@errno.com>
To:        Hartmut Brandt <harti@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/hatm if_hatm.c if_hatmvar.h [MPSAFE network]
Message-ID:  <200311050913.59097.sam@errno.com>
In-Reply-To: <200311051147.hA5BlWiV057262@repoman.freebsd.org>
References:  <200311051147.hA5BlWiV057262@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 05 November 2003 03:47 am, Hartmut Brandt wrote:
> harti       2003/11/05 03:47:32 PST
>
>   FreeBSD src repository
>
>   Modified files:
>     sys/dev/hatm         if_hatm.c if_hatmvar.h
>   Log:
>   Make the driver conditionally MPSAFE. MPSAFEty defaults to not-mpsafe
>   but can be enabled by setting hw.atm.hatmN.mpsafe in the kernel
>   environment to a non-zero value before loading the driver. When
>   the problems with network MPSAFEty have been sorted out this will
>   be removed and the driver will default to MPSAFE.

I'm about to commit mods to make debug_mpsafenet globally visible so other 
parts of the system (to be committed) can use it too.  Perhaps your stuff 
should reference it also?

FWIW the problems with the MPSAFE changes I committed were two-fold.  Most 
importantly I'd forgotten that the direct dispatch in the netisr code was 
left on (I thought Robert had reverted his change).  This meant that drivers 
marked MPSAFE were potentially dispatching directly into the protocol stacks 
w/o Giant.  This obviously caused major problems as there was no interlocking 
against the top half of the kernel.  The second problem is that it turns out 
that significant bits of IPv4 are not properly locked (contrary to existing 
claims).  The effects of this were less obvious because of the first problem, 
but both contributed to major instability so rather than try to bandaid the 
problem I just backed everytihng out to let other major changes (e.g. 
interrupt routing) settle before trying again.

Going forward what I plan to do is commit a set of changes to bring in all the 
work I've done to "push Giant up" one level (previously I tried to bring 
things in in stages so each set of changes could get individual exposure).  
The new code grabs Giant depending on whether each netisr is MPSAFE or not.  
Then at the next level up Giant is acquired as needed, with this conditional 
on debug_mpsafenet (sysctl debug.mpsafenet).  In the initial commit all the 
code will go in but with debug_mpsafenet 0.  Then I'll need folks that were 
having problems test with debug_mpsafenet set to 1.  Once things look ok I'll 
change the default to 1.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311050913.59097.sam>