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>
index | next in thread | previous in thread | raw e-mail
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. Scotthome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4227A0D6.8040404>