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

[ Available lists | Index of svn-src-head | Month of Jan 2011 | Week of 26 Jan 2011 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Robert N. M. Watson <rwatson@freebsd.org>
Date
26 Jan 2011 17:55:11
Subject
Re: svn commit: r217830 - head/share/man/man9
Message-ID
12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org


[ Hide this part ]
 
On 26 Jan 2011, at 17:12, mdf@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

Elapsed time: 0.160 seconds