Date: Fri, 21 Sep 2001 18:03:04 -0500 From: Alfred Perlstein <bright@mu.org> To: Julian Elischer <julian@elischer.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: <20010921180304.I97903@elvis.mu.org> In-Reply-To: <Pine.BSF.4.21.0109211635160.37053-100000@InterJet.elischer.org>; from julian@elischer.org on Fri, Sep 21, 2001 at 04:39:40PM -0700 References: <200109212206.f8LM6MF13902@freefall.freebsd.org> <Pine.BSF.4.21.0109211635160.37053-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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?20010921180304.I97903>