2002-04-12 06:19:12 +00:00
|
|
|
.\"
|
|
|
|
|
.\" Copyright (C) 2002 Chad David <davidc@acns.ab.ca>. All rights reserved.
|
|
|
|
|
.\"
|
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
|
.\" are met:
|
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
.\" notice(s), this list of conditions and the following disclaimer as
|
|
|
|
|
.\" the first lines of this file unmodified other than the possible
|
|
|
|
|
.\" addition of one or more copyright notices.
|
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
.\" notice(s), this list of conditions and the following disclaimer in the
|
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
|
.\"
|
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND ANY
|
|
|
|
|
.\" EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
|
|
|
|
.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
|
|
|
.\" DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY
|
|
|
|
|
.\" DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
|
|
|
|
.\" (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
|
|
|
.\" SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
|
|
|
|
.\" CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
|
|
|
|
|
.\" DAMAGE.
|
|
|
|
|
.\"
|
|
|
|
|
.\" $FreeBSD$
|
|
|
|
|
.\"
|
Fix a deficiency in the selinfo interface:
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
2011-08-25 15:51:54 +00:00
|
|
|
.Dd August 25, 2011
|
2002-04-12 06:19:12 +00:00
|
|
|
.Dt SELRECORD 9
|
|
|
|
|
.Os
|
|
|
|
|
.Sh NAME
|
Fix a deficiency in the selinfo interface:
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
2011-08-25 15:51:54 +00:00
|
|
|
.Nm seldrain ,
|
2002-04-12 06:19:12 +00:00
|
|
|
.Nm selrecord ,
|
2002-05-30 13:33:59 +00:00
|
|
|
.Nm selwakeup
|
2002-04-12 06:19:12 +00:00
|
|
|
.Nd "record and wakeup select requests"
|
|
|
|
|
.Sh SYNOPSIS
|
|
|
|
|
.In sys/param.h
|
|
|
|
|
.In sys/selinfo.h
|
|
|
|
|
.Ft void
|
Fix a deficiency in the selinfo interface:
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
2011-08-25 15:51:54 +00:00
|
|
|
.Fn seldrain "struct selinfo *sip"
|
|
|
|
|
.Ft void
|
2002-04-12 06:19:12 +00:00
|
|
|
.Fn selrecord "struct thread *td" "struct selinfo *sip"
|
|
|
|
|
.Ft void
|
|
|
|
|
.Fn selwakeup "struct selinfo *sip"
|
|
|
|
|
.Sh DESCRIPTION
|
Fix a deficiency in the selinfo interface:
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
2011-08-25 15:51:54 +00:00
|
|
|
.Fn seldrain ,
|
2002-04-12 06:19:12 +00:00
|
|
|
.Fn selrecord
|
|
|
|
|
and
|
|
|
|
|
.Fn selwakeup
|
Fix a deficiency in the selinfo interface:
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
2011-08-25 15:51:54 +00:00
|
|
|
are the three central functions used by
|
2002-04-12 06:19:12 +00:00
|
|
|
.Xr select 2 ,
|
|
|
|
|
.Xr poll 2
|
|
|
|
|
and the objects that are being selected on.
|
|
|
|
|
They handle the task of recording which threads are waiting on which objects
|
|
|
|
|
and the waking of the proper threads when an event of interest occurs on an
|
|
|
|
|
object.
|
|
|
|
|
.Pp
|
|
|
|
|
.Fn selrecord
|
|
|
|
|
records that the calling thread is interested in events related to a given
|
|
|
|
|
object.
|
|
|
|
|
If another thread is already waiting on the object a collision will be flagged
|
|
|
|
|
in
|
|
|
|
|
.Fa sip
|
|
|
|
|
which will be later dealt with by
|
|
|
|
|
.Fn selwakeup .
|
|
|
|
|
.Pp
|
|
|
|
|
.Fn selrecord
|
|
|
|
|
acquires and releases
|
|
|
|
|
.Va sellock .
|
|
|
|
|
.Pp
|
|
|
|
|
.Fn selwakeup
|
|
|
|
|
is called by the underlying object handling code in order to notify any waiting
|
|
|
|
|
threads that an event of interest has occurred.
|
2002-05-30 13:33:59 +00:00
|
|
|
If a collision has occurred,
|
2002-04-12 06:19:12 +00:00
|
|
|
.Fn selwakeup
|
|
|
|
|
will increment
|
|
|
|
|
.Va nselcoll ,
|
|
|
|
|
and broadcast on the global cv in order to wake all waiting threads so that
|
|
|
|
|
they can handle it.
|
|
|
|
|
If the thread waiting on the object is not currently sleeping or the wait
|
|
|
|
|
channel is not
|
|
|
|
|
.Va selwait ,
|
|
|
|
|
.Fn selwakeup
|
|
|
|
|
will clear the
|
|
|
|
|
.Dv TDF_SELECT
|
|
|
|
|
flag which should be noted by
|
|
|
|
|
.Xr select 2
|
|
|
|
|
and
|
|
|
|
|
.Xr poll 2
|
2002-05-30 13:33:59 +00:00
|
|
|
when they wake up.
|
2002-04-12 06:19:12 +00:00
|
|
|
.Pp
|
Fix a deficiency in the selinfo interface:
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
2011-08-25 15:51:54 +00:00
|
|
|
.Fn seldrain
|
|
|
|
|
will flush the waiters queue on a specified object before its
|
|
|
|
|
destruction.
|
|
|
|
|
The object handling code must ensure that
|
|
|
|
|
.Fa *sip
|
|
|
|
|
cannot be used once
|
|
|
|
|
.Fn seldrain
|
|
|
|
|
has been called.
|
|
|
|
|
.Pp
|
2007-06-14 22:38:50 +00:00
|
|
|
The contents of
|
|
|
|
|
.Fa *sip
|
|
|
|
|
must be zeroed, such as by softc initialization, before any call to
|
|
|
|
|
.Fn selrecord
|
|
|
|
|
or
|
|
|
|
|
.Fn selwakeup ,
|
|
|
|
|
otherwise a panic may occur.
|
2002-04-12 06:19:12 +00:00
|
|
|
.Fn selwakeup
|
|
|
|
|
acquires and releases
|
|
|
|
|
.Va sellock
|
|
|
|
|
and may acquire and release
|
|
|
|
|
.Va sched_lock .
|
Fix a deficiency in the selinfo interface:
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
2011-08-25 15:51:54 +00:00
|
|
|
.Fn seldrain
|
|
|
|
|
could usually be just a wrapper for
|
|
|
|
|
.Fn selwakeup ,
|
|
|
|
|
but consumers should not generally rely on this feature.
|
2002-04-12 06:19:12 +00:00
|
|
|
.Sh SEE ALSO
|
2002-05-30 13:33:59 +00:00
|
|
|
.Xr poll 2 ,
|
2002-04-12 06:19:12 +00:00
|
|
|
.Xr select 2
|
|
|
|
|
.Sh AUTHORS
|
2002-05-30 13:33:59 +00:00
|
|
|
.An -nosplit
|
2005-06-28 20:15:19 +00:00
|
|
|
This manual page was written by
|
2002-05-30 13:33:59 +00:00
|
|
|
.An Chad David Aq davidc@FreeBSD.org
|
2002-04-12 06:19:12 +00:00
|
|
|
and
|
2002-05-30 13:33:59 +00:00
|
|
|
.An Alfred Perlstein Aq alfred@FreeBSD.org .
|
