From owner-svn-src-all@FreeBSD.ORG Wed Jan 26 18:29:10 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9DBE1065674; Wed, 26 Jan 2011 18:29:10 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7604F8FC15; Wed, 26 Jan 2011 18:29:10 +0000 (UTC) Received: by iyb26 with SMTP id 26so659577iyb.13 for ; Wed, 26 Jan 2011 10:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jf6ThKcIT7Q+7AzQkB7N9A2kbCX0isr+WD9n/ZtENCc=; b=tNEHHDLjQWkaioDYoxoXYYO5+oO4NxKNk5rG2V63hgK95gWuiTeWouqmTr8Ed1omPz pFqsK1Kn0S0HX0cgd07KckqfpuCdm+9GJA2Cu9V+brljixyigKI9VlScNYLkuxLQCzQR JDs6nQgIW1P7xNccWPFcxnD6weWoKsliy2dV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MJ4EHcbMtLPlnfc0/aenetRR2Mo7MhDBqHvpn/hPvPbDGFUJk3g0utaWw/OXvJc55s rdjNL03aledjSiYBLsMmqmQE/zS6vI+ajC779IMHqq+wsp0aJEgXXTzs8YDuSAEyZZgO Tqp0F8rBZloXQX3NRkZl3ISx5KziANf4OTWAM= MIME-Version: 1.0 Received: by 10.231.31.131 with SMTP id y3mr8658025ibc.179.1296066549748; Wed, 26 Jan 2011 10:29:09 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Wed, 26 Jan 2011 10:29:09 -0800 (PST) In-Reply-To: <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org> References: <201101251739.p0PHdqKX044842@svn.freebsd.org> <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org> Date: Wed, 26 Jan 2011 10:29:09 -0800 X-Google-Sender-Auth: bSrYxGw5nnbmolwHXILjnoPLyf0 Message-ID: From: mdf@FreeBSD.org To: "Robert N. M. Watson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217830 - head/share/man/man9 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:29:11 -0000 On Wed, Jan 26, 2011 at 9:55 AM, Robert N. M. Watson 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