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

[Martin Husemann <martin%duskware.de@localhost>]

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

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-sparc64/54810: sparc64 pool_redzone_check errors during
 install
Date: Mon, 26 Oct 2020 11:00:47 +0100

 On Mon, Oct 26, 2020 at 09:15:01AM +0000, Harold Gutch wrote:
 >  >         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().
 
 This is clearly a bug. The medium has 2k sectors, we are not allowed to
 use the buffer cache with blocks smaller than that (or with varying block
 sizes).
 
 We could make ntfs_mountfs() do something like:
 
 	uint64_t psize;
 	unsigned secsize;
 	int error;
 
 	error = getdisksize(devvp, &psize, &secsize);
 
 	if (error || secsize > BBSIZE)
 		return ENODEV;
 
 Or we could go through the code and replace all BBSIZE reads with proper
 code to deal with bigger blocks - or check if FreeBSD did that and update
 from their version.
 
 Martin