Returning ENOMEM in sysctl handler
Returning ENOMEM in sysctl handler
- Subject: Returning ENOMEM in sysctl handler
- From: Alexander Dimitrov <email@hidden>
- Date: Mon, 22 Oct 2012 19:27:39 +0300
Hello to all,
I have tried sending/getting some data to/from a bsd kernel extension
using a sysctl, but when I return ENOMEM from the handler the user
space got success from the sysctl(3) call. I couldn't find explanation
for this case in the man page, so I made a very simple kext which
registers a systl using sysctl_register_oid under _debug, which
handler always returns ENOMEM. When calling this sysctl from user
space I observed the following things:
[1] If I call sysctlbyname with oldp set to NULL then I get an error
code -1 and errno is set to ENOMEM, but
[2] if I call sysctlbyname with valid oldp, in my case pointing to a
stack buffer, the call to sysctlbyname returns 0.
According to sysctl(3) I expect in case [2] to get ENOMEM again - "If
the amount of data available is greater than the size of the buffer
supplied, the call supplies as much data as fits in the buffer
provided and returns with the error code ENOMEM."
The system I'm testing on is 10.7.4 with Xcode 4.4.1 installed.
I could also provide the source of the kext and the user space program
calling the sysctl if anyone wants to test this.
I tried to look through the xnu source but didn't found any place
where ENOMEM is handled explicitly and changed to 0.
I also debugged the command line after calling sysctl(3) and saw that
till the call to syscall the execution path is the same, but if the
sysctl handler returns ENOMEM the syscall returns with CF cleared and
the the whole call returns success, but if the handler returns
ENOATTR, then syscall returns with CF and we go on the fail path
(errno is set to ENOATTR, etc).
Can somebody point me whether this is well-known behavior of sysctl,
is it undocumented or I'm misreading the man page?
Thank you,
Alex.
_______________________________________________
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