Re: kern/38637: pppoe fails to reconnect sometimes

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR kern/38637; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: Andrew Doran <ad%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/38637: pppoe fails to reconnect sometimes
Date: Tue, 5 May 2009 23:26:46 +0200

 On Tue, May 05, 2009 at 08:52:45PM +0000, Andrew Doran wrote:
 > > I think I found the reason for this (or at last a possible reason).
 > > In sys/kern/kern_softint.c, sh_flags should be declared volatile.
 > > Without it, on ports where splhigh() is inline, the compiler will optimise
 > > the second SOFTINT_PENDING test in softint_schedule(). A dissasembly
 > > of softint_schedule() with and without the volatile sh_flags confirm this
 > > on sparc.
 > > Because of this there is a race that could lead to the softhand_t
 > > being enqueued twice on si_q, leading to a corrupted queue and
 > > some handler being SOFTINT_PENDING but never called.
 > 
 > Nice diagnosis! However the softint code is correct.
 > 
 > splhigh/splx on sparc64 should be real functions, or if one believes there
 > is a performance advantage, should be inlines with __insn_barrier in the
 > correct spots. Consider the potential effects elsewhere. I pointed this
 > issue out to Martin or Matthew a couple of years ago and then promptly
 > forgot about it.
 
 Yes, it seems __insn_barrier() would do it too. All ports needs to be audited
 then; I've seen this on sparc not sparc64 (I don't know if they share
 their spl functions) and macallan@ reported this could be an issue on
 macppc too.
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --