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 <c...@freebsd.org> 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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
