Re: [RFC PATCH] db: Stop core dumping on attr3 if block header is not recognized

[Carlos Maiolino <cmaiolino@redhat.com>]

On Thu, Apr 19, 2018 at 03:18:12PM -0500, Eric Sandeen wrote:
> On 4/19/18 3:01 PM, Darrick J. Wong wrote:
> 
>  
> > I like it better, though on further thought I think I like better the
> > idea of printing the contents of all potential magic numbers:
> > 
> > For a block starting with:
> > 
> > 0xDE 0xAD 0xBE 0xEF 0xCA 0xFE 0xF0 0x0D 0xBA 0xAD...
> > 
> > xfs_db> p
> > Unrecognized attr3 block, attempting to print magic numbers and/or blkinfo:
> > unknown.blockhdr.magic = 0xDEADBEEF
> > unknown.da_blkinfo.magic = 0xBAAD
> > unknown.inode.magic = 0xDEAD
> 
> If we asked for an attr3 type, I don't see the value in printing out structures
> that are unrelated to an attr3, like an inode....?
> 

Well, if we fall into this case, the block is supposed to have no attr3 relevant
fields at all, so, I don't see how we would benefit from printing 'relevant'
attr3 data from a non attr3 block.

Although I also didn't like the idea of being 'specific' on the magic number
type, because we don't know what we would be printing, unless we do some checks
and see if we could match the block with a known type, which well, although I
think it's doable, I don't see it being too useful at all.

Best case scenario, we try to print a non-attr3 type using attr3, and a
'generic' attempt to print a magic number using both blkinfo style offset, and
remote style offset, would be enough. As the main reason here is to tell the
user "hey, you are using attr3 on the wrong place", and let the user correct it.
After all, xfs_db users are supposed to know what they are doing.

Worst case scenario is trying to print a corrupted block, which well, no matter
what we print, it's not gonna make sense anyway.

/me starts to think if just printing an "unrecognized format" message isn't the
best approach after all :P


> The whole problem here is that "attr3" is non-specific, and could be several
> formats.  (bad design decision, IMHO, but bridge, water under, etc).  So I'd
> prefer that we only print structures which might be relevant to the thing(s)
> the user asked for.
> 
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos