Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50

From: John-Mark Gurney <gurney_j_at_efn.org>
Date: Wed, 17 Sep 2003 12:52:03 -0700
Bernd Walter wrote this message on Wed, Sep 17, 2003 at 10:27 +0200:
> On Wed, Sep 17, 2003 at 09:07:24AM +0200, Poul-Henning Kamp wrote:
> > In message <20030916102534.J2924_at_gamplex.bde.org>, Bruce Evans writes:
> > 
> > >This is either disk corruption or an ffs bug.  ffs passes the garbage
> > >block number 0xffffe5441ae9720 to bread.  GEOM then handles this austerely
> > >by panicing.  Garbage block numbers, including negative ones, can possibly
> > >be created by applications seeking to preposterous offsets, so they should
> > >not be handled with panics.
> > 
> > They most certainly should!  If the range checking in any filesystem
> > is not able to catch these cases I insist that GEOM do so with a panic.
> 
> What is wrong with returning an IO error?
> 
> I always hated panics because of filesystem corruptions.
> An alternative would be to just bring that filesystem down.
> Its easy to panic a whole system with a bogus filesystem on a removeable
> media.

If you're file system is so hosed that it does this, then panicing
is the only safe thing to do.  You don't know what continued operation
will do to the filesytem, and you might end up losing more data.

It is not unresonable to put parameter restrictions on function calls.
It is not much different from enforcing that a pointer is not NULL when
being passed as an argument.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
Received on Wed Sep 17 2003 - 10:52:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:22 UTC