On Sun, Nov 05, 2017 at 11:42:51AM -0700, Warner Losh wrote: > On Sun, Nov 5, 2017 at 11:32 AM, Conrad Meyer <[email protected]> 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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "[email protected]"
