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

Robert N. M. Watson rwatson at freebsd.org
Wed Jan 26 17:55:11 UTC 2011


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. I suppose an important question is now often we see this actually failing, and in what circumstances: if there's a moderate chance of it failing on low-memory machines under memory pressure, it suggests we've gone wrong somewhere... One nice thing about the non-wiring model is that it's pretty cheap in the common case, whereas the new code is pretty expensive in the common case. Maybe this doesn't matter too much.

Robert


More information about the svn-src-head mailing list