svn commit: r217830 - head/share/man/man9

[mdf at FreeBSD.org]

On Wed, Jan 26, 2011 at 9:55 AM, Robert N. M. Watson
<rwatson at freebsd.org> wrote:
>
> On 26 Jan 2011, at 17:12, mdf at FreeBSD.org wrote:
>
>>> Hmm.  Is this description missing mention of how wiring failures are
>>> handled? (Also, it should probably mention that this call can sleep for
>>> potentially quite long periods of time, even if sbuf_printf (and friends)
>>> can't).
>>
>> I'm not sure how much to write, since some of the wiring failures are
>> dealt with by the sysctl subsystem and are not documented.
>>
>> The current state of the actual code is that a failure in vslock(9) is
>> ignored, unless it's ENOMEM in which case sysctl_wire_old_buffer sets
>> the sysctl_req->validlen to 0, which would behave perhaps slightly
>> unexpectedly for the user since no data will be copied out.
>>
>> Any non-ENOMEM failure from vslock() presumably would also have been a
>> failure from SYSCTL_OUT and this does get squashed, perhaps
>> incorrectly.
>>
>> I'll think about saving the error code so that sbuf_finish can report
>> it if nothing else has gone wrong.
>
> Yeah, no specific opinions on the right answer, except perhaps that sbuf_new_for_sysctl()
> failing due to ENOMEM is something worth making it easy to report to the user.

The ENOMEM is already managed and squashed inside
sysctl_wire_old_buffer(), so there's no way for sbuf_new_for_sysctl()
to report it.  It may end up happening automagically since it sets the
validlen to 0.

> I suppose an important question is now often we see this actually failing

I don't believe we've ever seen a memory failure relating to sysctls
at Isilon and we've been using the equivalent of this code for a few
years.  Our machines aren't low memory but they are under memory
pressure sometimes.

Thanks,
matthew