Re: How can the so_pcb field of a "socket_t" instance be accessed with KPI?
Re: How can the so_pcb field of a "socket_t" instance be accessed with KPI?
- Subject: Re: How can the so_pcb field of a "socket_t" instance be accessed with KPI?
- From: Stephane Sudre <email@hidden>
- Date: Sat, 10 Feb 2007 13:28:27 +0100
So basically, I guess the idea is to mark the "retained" socket as
non valid anymore from the sf_detach_func callback of a socketfilter.
On Feb 10, 2007, at 12:45 AM, Terry Lambert wrote:
There are not a lot of places this can happen, which you could have
known from grepping the xnu sources:
find . -type f | xargs fgrep "so_pcb = " | grep "NULL\|0"
These boil down to:
- On the last unlock of a control datagram or stream socket, when
no one is supposed to be left using it
- On the last detach of a kevent (it was set on attach)
- After a unp_detach/abort on a socket close for an AF_UNIX domain
socket
- Same thing, for a network device socket (AF_NDRV)
- Same thing for a raw socket
- A failure to attach a routing socket (or same as above, for a
routing socket)
- Same for AF_APPLETALK
- Same for AF_INET or a NAT dummy socket
- Same for any protocol family that uses an raw socket as an
underlying implementation detail
So most likely you are trying to continue using an already closed
socket by holding a promiscuous reference on it, and not
invalidating that reference when the socket has been closed out
from under you.
Either don't hold the promiscuous reference, block the close as
part of your filter, or take an invalidation event as a result of
your filter seeing the close. Alternately, find some other way of
doing what you need to do.
I personally do NOT recommend blocking the close.
-- Terry
On Feb 9, 2007, at 2:04 AM, Stephane Sudre wrote:
To check that it's not NULL before calling socket_data_inject_in.
Since it's going to cause a kernel panic.
I guess a better way to deal with this would be to wonder why the
so_pcb field is NULL before that.
The issue is that I haven't found any possible good explanation
for so_pcb to be NULL till now (and I have never been able to
reproduce the issue). And unfortunately, almost every socket KPI
API is calling socket_lock (that is going to kernel panic if
so_pcb is NULL).
On 8 févr. 07, at 20:33, Vincent Lubet wrote:
Follow up question: why would you want to perform this check?
Vincent
On Feb 8, 2007, at 11:10 AM, Josh Graessley wrote:
You can not get to this field. It is considered private. The
contents a specific to the protocol of the socket created.
-josh
On Feb 8, 2007, at 3:21 AM, Stephane wrote:
I would like to check that the so_pcb field of a socket_t
instance is non NULL.
Since KPI obfuscates things, I'm looking for a method to access
this field with no success so far.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden