Re: race condition in knote deletion?

看板DFBSD_kernel作者時間15年前 (2011/02/02 12:01), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串3/7 (看更多)
On Tue, Feb 1, 2011 at 6:26 PM, Matthew Dillon <dillon@apollo.backplane.com> wrote: > : ꀠꀠꀠ溆n->kn_status |= KN_DELETING | KN_REPROCESS; > : > :So 烀ouldn't another cpu running knote_release() while the 1st one > :sleeps call knote_detach_and_drop() too > :causing a crash when the 1st cpu resumes? > > ꀠ嘢nly the thread which set KN_PROCESSING can release the knote, > ꀠ澵o it shouldn't be possible. 嘢ther threads will see that KN_PROCESSING > ꀠ湶s already set and not try to do anything drastic to the knote. > > ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀭMatt > ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠ嗰atthew Dillon > ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀼdillon@backplane.com> > I think the mouse detach bug is probably something more fundamental, like teardown ordering. It's very easy to tickle, start up X with a usb mouse configured (/dev/ums*), unplug the mouse. It may take a bit of time before it occurs, but switching from X to a console seems to make it happen immediately. Sam
文章代碼(AID): #1DIDS1WP (DFBSD_kernel)
討論串 (同標題文章)
文章代碼(AID): #1DIDS1WP (DFBSD_kernel)