From owner-svn-src-head@freebsd.org Sun Nov 5 19:19:07 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5288E4E995; Sun, 5 Nov 2017 19:19:07 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (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 2F1A6662FB; Sun, 5 Nov 2017 19:19:06 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f45.google.com with SMTP id 75so8287911lfx.1; Sun, 05 Nov 2017 11:19:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KdCse6TcN8mfCnTPtQj8zVl3IUhX9U4Hk9a85qZGyu8=; b=s+IQeB085dIyrY2FVjP/GwkZc/os+ZteTQ26SgjjeH23njdv/indmO7ZI9oqMzdG4N q9Mvfe7tbIWqfHkMTz9AvUi+HAiyKNojmaQTmV+5n1LwFCx8B1xolF+YM0ArLHiuG9yR 0DoIm+QbAv6f4G/FbkdG+BaYhC1L7LJKlL7AC8pvNL01qt3YHMYUK3jmDBYMq59vnWKB iZ5OGVXfbKUSD4E5jSukq6iOzSkf6ABMTmPuSbPniI+S9jkwzy33HJ80N74nJUzd7X0F A4IAzlPaK7gznTmTgvqieXHDnJASISE9J1Ff32lUM00j8mWGFvn53iDzGB0CpUsawzbz m+lA== X-Gm-Message-State: AMCzsaWmpxI5JjIcE0rcUy7AEuffvsjK8optGj7SZ9m1ZO4fBHCsHBwS ixHEMb/4gMBr//YQdcCrJh5JR4AOgpY= X-Google-Smtp-Source: ABhQp+QdX6HyiHSnCsQniA57N+1Kju4Hi5HKcbHYQJ/RFtKVE1XNNAwiRt+CpzVK+GwreAWeB4mDtA== X-Received: by 10.46.34.133 with SMTP id i127mr5243323lji.34.1509909203697; Sun, 05 Nov 2017 11:13:23 -0800 (PST) Received: from [192.168.0.197] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id s125sm2309518lja.46.2017.11.05.11.13.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 11:13:22 -0800 (PST) Subject: Re: svn commit: r325386 - head/sys/kern To: Konstantin Belousov , Warner Losh Cc: "Conrad E. Meyer" , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" References: <201711041049.vA4AnZUE096709@repo.freebsd.org> <20171105130607.GA2566@kib.kiev.ua> <20171105173032.GE2566@kib.kiev.ua> <20171105190214.GG2566@kib.kiev.ua> From: Andriy Gapon Message-ID: <20f694b3-c60c-1b6d-76a1-2ef14cbdd698@FreeBSD.org> Date: Sun, 5 Nov 2017 21:13:21 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171105190214.GG2566@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 19:19:07 -0000 On 05/11/2017 21:02, Konstantin Belousov wrote: > On Sun, Nov 05, 2017 at 11:42:51AM -0700, Warner Losh wrote: >> On Sun, Nov 5, 2017 at 11:32 AM, Conrad Meyer wrote: >> >>> E.g., >>> >>> --- a/sys/ufs/ffs/ffs_alloc.c >>> +++ b/sys/ufs/ffs/ffs_alloc.c >>> @@ -304,8 +304,7 @@ retry: >>> } >>> >>> if (bp->b_blkno == bp->b_lblkno) { >>> - if (lbprev >= UFS_NDADDR) >>> - panic("ffs_realloccg: lbprev out of range"); >>> + ASSERT(lbprev < UFS_NDADDR, "ffs_realloccg: lbprev out >>> of range"); >>> bp->b_blkno = fsbtodb(fs, bprev); >>> } >>> >> >> Just a side point: All these should be programming errors. The bogus data >> that comes or could come from the FS itself should remain always-on panics. >> Well, actually, they should transition from always-on panics to some sort >> of degraded mount that would be more resilient in the face of such >> corruption. But failing that, they should remain always-on panics :) > > This is what I said in my reply before the last. > > I still have no idea what is the point cem tries to express. > > Nor I know what should the ASSERT() macro do in the kernel. If the > patch above really about replacing panic() with _K_ASSERT, then I most > likely agree with it, since the error catched is not due to the on-disk > metadata corruption. > I guess (only guess) that Conrad is saying that it would be useful to have a macro like KASSERT but which would be always active regardless of INVARIANTS. E.g. in illumos they have ASSERT and VERIFY. -- Andriy Gapon