From owner-svn-src-all@freebsd.org Fri Mar 9 16:08:58 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2283F3503F; Fri, 9 Mar 2018 16:08:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 346D27E545; Fri, 9 Mar 2018 16:08:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id m22so4037353iob.12; Fri, 09 Mar 2018 08:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=umXhokMmeKfDlqke/5OKJzh39Kh77z6WEIGwUWY6+AU=; b=VHq7CWT7at7A1BrPEvWnSqYt/UsKdJtT5W/eBtxKZQrtQUE4T4wkLuKNNThA6bx2of grGECIbpb9BwqrpurgOC10JDcjAzmn1EM18UyDcW8b3hQn/6txfRAd+59oLqweY1Cng0 8fkWt3+6Hjb+rqz/y8z3xQmDtqlW8oy94rAkawFJ0aRFcxmy6YWtoh2JJ3/nzP2gdqPQ MjQkMh+ZrLlKaR6MboPGcGSEHxSpH+85h9HnvTnbiQ8r8bLHC8DPcw+g2pOZo3edK1GS TOZfeZZp5+onAbmL+phv4rD+oxyNW2o7mo+rupfFvm3X+A/+hY1qxMOTGS9vJHFkgpgz uppA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=umXhokMmeKfDlqke/5OKJzh39Kh77z6WEIGwUWY6+AU=; b=mLeN+CQRDeR7ujKJCi6ItD1EfA0W3brcUlR9INK2HO1XDDyuJHL9g/8lVIJprpOa0n tiZf4ku3QtU3LP0q8byWn/56ErnQvLXskOnU6EbnAcu97OR1Z44h5GPl6ejwRh2gd6vz psbcPJAjG9zNHN6h/W8+azyYATQuStQtiMmIoQfrRJCMMHktYL/2Hp4Ddzlf0iN9LYks OP3AygUS1Wd/o+7ANKblkEtR72zf7WgmtM/43EFEl+Hp3MGpeu8NqSGUv+VT4fMPthPj 6WCxT1/Za5cQEoPBb1Rn0U6N2uBDxQuOoVavCmN9MrhaNmeoqi5c4Wy8e3CO49tG7NWf AZkg== X-Gm-Message-State: AElRT7E5ikeUWWBVUvPe1yxRf74s3RqUSlUEJQMkx6E2UrzALp6v7lIY YlamHgVyUb1F9+9Q5d9Tbbk= X-Google-Smtp-Source: AG47ELvJ0K1eB1cCpJzfnL8JnL+/dnJjG+SPzmGBGSyOqPwH+nJXK3usSyFGgAU8VBL769dgkfasFQ== X-Received: by 10.107.21.3 with SMTP id 3mr36025625iov.148.1520611737511; Fri, 09 Mar 2018 08:08:57 -0800 (PST) Received: from raichu (toroon0560w-lp130-01-174-88-76-226.dsl.bell.ca. [174.88.76.226]) by smtp.gmail.com with ESMTPSA id b99sm1066544ioj.82.2018.03.09.08.08.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Mar 2018 08:08:56 -0800 (PST) Sender: Mark Johnston Date: Fri, 9 Mar 2018 11:08:54 -0500 From: Mark Johnston To: Bruce Evans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r330663 - head/sys/kern Message-ID: <20180309160854.GC6174@raichu> References: <201803081704.w28H4aQx052056@repo.freebsd.org> <20180309150402.X950@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180309150402.X950@besplex.bde.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 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: Fri, 09 Mar 2018 16:08:58 -0000 On Fri, Mar 09, 2018 at 03:42:05PM +1100, Bruce Evans wrote: > On Thu, 8 Mar 2018, Mark Johnston wrote: > > > Log: > > Return E2BIG if we run out of space writing a compressed kernel dump. > > E2BIG a very wrong errno. It means "Argment list too long". It is broken > as designed, with "too" encrypted as "2" and no indication of what is too > big. EFBIG is not so wrong. It means "File too large". There is explicit handling for E2BIG most of the (mini)dumpsys() implementations, which is why I chose it. In particular, amd64's minidumpsys() retries the dump upon receiving ENOSPC from the MI code, but E2BIG simply causes the dump to fail: 443 else if (error == E2BIG) 444 printf("Dump failed. Partition too small.\n"); > > ENOSPC causes the MD kernel dump code to retry the dump, but this is > > undesirable in the case where we legitimately ran out of space. > > ENOSPC is the correct errno. It means "[really] No space left on device". > The bug was either retrying or possibly abusing ENOSPC instead of EAGAIN > to mean "transiently out of space for something". When writing an uncompressed dump, the starting offset is chosen so that the end of the dump lines up with the end of the dump device. If we attempt to write past the end of the dump, the presumption is that something caused pages to be added to the dump map during the dump, and we should retry with a different starting offset. EAGAIN seems like a reasonable error number for this case, but it's somewhat unsatisfying since these checks were originally meant to stop programming errors from scribbling over a filesystem. I wonder if the retry logic in amd64's minidumpsys() is really useful at all. It was added in r215133 and copied to arm64, but isn't present in any other MD dump code. I've never seen a kernel dump succeed after a retry; for instance, the problem addressed in r329521 simply caused us to retry a number of times before giving up. The description for Differential D8254 also suggests that the retry logic is of questionable value.