Re: port-sparc64/54810: sparc64 pool_redzone_check errors during install

[Harold Gutch <logix%foobar.franken.de@localhost>]

The following reply was made to PR port-sparc64/54810; it has been noted by GNATS.

From: Harold Gutch <logix%foobar.franken.de@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, martin%NetBSD.org@localhost
Subject: Re: port-sparc64/54810: sparc64 pool_redzone_check errors during install
Date: Mon, 26 Oct 2020 10:11:35 +0100

 On Mon, Oct 26, 2020 at 09:25:02AM +0200, Andreas Gustafsson wrote:
 > Harold Gutch wrote:
 > >  The does not appear to be in ntfs_init(), but instead in
 > >  ntfs_mountroot() (or something called by that function).  If I add a
 > >  "return -1" at the top of the function, the installation also succeeds
 > >  for me.
 > >
 > >  FWIW, on an unpatched system ntfs_mountroot() we land in the
 > >  ntfs_mountfs() != 0 case in ntfs_vfsops.c:117, so it is either
 > >  something allocated by vfs_rootmountalloc() or ntfs_mountfs().
 > 
 > Agreed. I also did some debugging by disabling selecting parts of the
 > code and seeing if it fixes the bug, and unless I have made a mistake
 > somewhere, I have narrowed it down to this stretch of code in
 > ntfs_mountfs():
 > 
 >         error = bread(devvp, BBLOCK, BBSIZE, 0, &bp);
 >         if (error)
 >                 goto out;
 
 Ah, that's good, I did the same yesterday and I come to exactly the
 same conclusion, just that I did not "goto out" but instead called
 "brelse(bp,0); return -1;", i.e., I skipped the
 spec_node_setmountedfs() call in the cleanup (so we can rule that out
 too).
 
 
 > or possibly the cleanup code following "out".  Since BBSIZE is 1024, this
 > also seems consistent with the reported corruption in a "[buf1k]" pool.
 > 
 > Maybe some lower layer ends up reading an entire 2048-byte CD-ROM
 > block into a 1024-byte buffer?
 
 That was also my guess, I was planning on following up some more in
 that direction today.  I first wanted to have a look what the other
 file system drivers do there, because in order for this to make sense,
 no other driver should read a 1K block in *_mountroot() or *_init().
 
 
   Harold