Date: Thu, 03 Mar 2005 16:42:14 -0700 From: Scott Long <scottl@samsco.org> To: David Xu <davidxu@freebsd.org> Cc: David Schultz <das@freebsd.org> Subject: Re: cvs commit: src/sys/kern kern_sig.c Message-ID: <4227A0D6.8040404@samsco.org> In-Reply-To: <4227A094.5030600@freebsd.org> References: <200503021343.j22DhpQ3075008@repoman.freebsd.org> <200503020915.28512.jhb@FreeBSD.org> <4226446B.7020406@freebsd.org> <20050303033115.GA13174@VARK.MIT.EDU> <42269DB0.6070107@freebsd.org> <20050303052902.GA14011@VARK.MIT.EDU> <422771E9.6070405@elischer.org> <42279C72.2000208@freebsd.org> <42279EE9.3020905@samsco.org> <4227A094.5030600@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > Scott Long wrote: > >> David Xu wrote: >> >>> Julian Elischer wrote: >>> >>>>> >>>>> >>>>>>> The alternative, of course, is to just fix the code that assumes >>>>>>> that swapping doesn't exist. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> First find all code written in such way, but it is not that easy. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> True. If we changed msleep() to disable swapping by default, then >>>>> we wouldn't have to worry about correctness problems related to >>>>> missing some. >>>>> >>>>> >>>> >>>> adding the flag to ENABLE swapping would be ABI compatible. >>>> >>>> >>> how about adding a PNOSWAP to msleep ? but I won't trust the kernel >>> under swapping, because they can not give me 100% guarantee, my >>> machine crashes several times per-month, even when fscking at boot time, >>> mostly it is a page fault. >>> >>> David Xu >>> >>> >>> >>> >>> >> >> An msleep/tsleep option doesn't solve the problem because the the msleep >> might happen several layers down from where the stack abuse is taking >> place, and thus the caller would have no idea that it's needed. > > > But it at least can help a piece of code managed by a single guy. > It's still of limited value. I'd rather the effort be put into diagnostics development. Also, regarding your objections to PHOLD, I thought that the proc lock was a leaf mutex. Where are you seeing LORs with it? >> The fix >> for sigwait() is easy and can be applied without hacking in new options >> that have limited value. I don't argue that similar problems might >> exist elsewhere, but swappable kstacks have been part of BSD since >> before most of us knew where the power switch was on our Ataris, so it's >> likely not to be a wide-spread and fundamental problem in the code. I'd >> be in favor of adding diagnostics that help catch these problems and >> report them, but just throwing away kstack swapping in leiu of taking >> the 2 minutes to fix sigwait() is pretty silly. >> > Yes, sigwait is simple, but my umtx code is also broken by this silly > swapping > code, now I have to fill malloc/free/retry/lock_order_reversal_work_around > all over the code. Can you provide a reference? It turns out the fixing sigwait() can be done without any mallocs at all, maybe the same can be done for umtx. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4227A0D6.8040404>