Date: Wed, 26 Jan 2011 10:29:09 -0800 From: mdf@FreeBSD.org To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217830 - head/share/man/man9 Message-ID: <AANLkTimn0te0NKR%2BusYC6CzxUVVaP%2BnpZKstsw1mWC7o@mail.gmail.com> In-Reply-To: <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org> References: <201101251739.p0PHdqKX044842@svn.freebsd.org> <alpine.BSF.2.00.1101260929430.44308@fledge.watson.org> <AANLkTimqyPYah5=yWHVxf3Us4=cBYKGkb0oyAE%2B7R-%2Bt@mail.gmail.com> <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 26, 2011 at 9:55 AM, Robert N. M. Watson <rwatson@freebsd.org> wrote: > > On 26 Jan 2011, at 17:12, mdf@FreeBSD.org wrote: > >>> Hmm. =A0Is 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 friend= s) >>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimn0te0NKR%2BusYC6CzxUVVaP%2BnpZKstsw1mWC7o>