Date: Fri, 21 Sep 2001 17:14:20 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: John Baldwin <jhb@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sys_generic.c Message-ID: <Pine.BSF.4.21.0109211708310.37053-100000@InterJet.elischer.org> In-Reply-To: <20010921180304.I97903@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
no, it's ok Alfred.. I'm watching... John is right in this.. (WHen he does have a question he asks me by private mail) Thanks for the interest however.. (Having spent about 6 weeks of my employers time on KSE I'm busy catching up there for a while, while KSE "settles" in -current before starting on the next part) (Why you haven't seen much followup work from me) julian P.S. If others wish to do some (bored?). There are lots of small tasks that could be done.. e.g. write separate allocator routines (with caches) for threads, KSEs, ksegroups, kernel stacks, etc. At teh moment they are allocated in manners that are dependent on everything being 1:1.. :-) (oh, and destructors too :-) On Fri, 21 Sep 2001, Alfred Perlstein wrote: > * Julian Elischer <julian@elischer.org> [010921 17:52] wrote: > > > > > > On Fri, 21 Sep 2001, John Baldwin wrote: > > > > > jhb 2001/09/21 15:06:22 PDT > > > > > > Modified files: > > > sys/kern sys_generic.c > > > Log: > > > The P_SELECT flag was moved from p->p_flag to td->td_flags, but p_flag > > > was locked by the proc lock and td_flags is locked by the sched_lock. > > > The places that read, set, and cleared TDF_SELECT weren't updated, so they > > > read and modified td_flags w/o holding the sched_lock, meaning that they > > > could corrupt the per-thread flags field. As an immediate band-aid, > > > grab sched_lock while reading and manipulating td_flags in relation to > > > TDF_SELECT. This will probably be cleaned up some later on. > > > > > > reading this again I think the clue is: > > > > "and td_flags is locked by the sched_lock" > > > > I don't know how this can be true unless it's been done recently.. > > Whatever locking was used for p_flag was left alone when I change it to > > td_flags in some places, so if p_flag was locked by the proc lock then > > td_flags should also be locked by it.. (I didn't change any occurances of > > the prock lock to be occurances of the sched lock)! > > I think John should start passing these diffs by Julian so this > doesn't result in the same problem of the vm mutex where so many > people jumped in to "fix" things without consulting me that it had > to be backed out because I was no longer sure what the hell had > been done to it. > > Julian seems quite available and I'd expect more cooperation with > him because of this. Please review your fixes by him, even if his > code is wrong you'll at least give him a better understanding of > what's going on, and if his code has found bugs with splitting > flags you shouldn't be obilitirating the code such that he doesn't > even recognize it any longer. > > I'm seeing someone (not me) stepping up to back out this whole mess > if it snowballs and I think that would be a shame. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109211708310.37053-100000>