Date: Fri, 23 May 2008 11:09:50 +0000 (UTC) From: Konstantin Belousov <kib@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern sys_pipe.c Message-ID: <200805231109.m4NB9osT069861@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
kib 2008-05-23 11:09:50 UTC
FreeBSD src repository
Modified files:
sys/kern sys_pipe.c
Log:
Destruction of the pipe calls knlist_cleardel() to remove the knotes
monitoring the pipe. The code sets pipe_present = 0 and enters
knlist_cleardel(), where the PIPE_MTX might be dropped when knl->kl_list
cannot be cleared due to influx knotes.
If the following often encountered code fragment
if (!(kn->kn_status & KN_DETACHED))
kn->kn_fop->f_detach(kn);
knote_drop(kn, td); [1]
is executed while the knlist lock is dropped, then the knote memory is freed
by the knote_drop() without knote being removed from the knlist, since
the filt_pipedetach() contains the following:
if (kn->kn_filter == EVFILT_WRITE) {
if (!cpipe->pipe_peer->pipe_present) {
PIPE_UNLOCK(cpipe);
return;
Now, the memory may be reused in the zone, causing the access to the
freed memory. I got the panics caused by the marker knote appearing on
the knlist, that, I believe, manifestation of the issue. In the Peter
Holm test scenarious, we got unkillable processes too.
The pipe_peer that has the knote for write shall be present. Ignore the
pipe_present value for EVFILT_WRITE in filt_pipedetach().
Debugging help and tested by: pho
Discussed with: jmg
MFC after: 2 weeks
Revision Changes Path
1.197 +1 -6 src/sys/kern/sys_pipe.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805231109.m4NB9osT069861>