[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-bugs
Subject:    Re: port-sparc64/54810: sparc64 pool_redzone_check errors during install
From:       mlelstv () serpens ! de (Michael van Elst)
Date:       2020-10-26 12:10:02
Message-ID: 20201026121002.0B6F01A923A () mollari ! NetBSD ! org
[Download RAW message or body]

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

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-sparc64/54810: sparc64 pool_redzone_check errors during install
Date: Mon, 26 Oct 2020 12:08:25 -0000 (UTC)

 martin@duskware.de (Martin Husemann) writes:
 
 > 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).
 
 But that's not what happened.
 
 If you do regular I/O on a device that is not a multiple of sector size,
 the driver will just fail that request with EINVAL.
 
 cd(4) is magic, as it needs to support 512 byte UFS access on CD-ROMs
 for compatibility with old Sun hardware.
 
 CD-ROM drives that support 512 byte blocks will just be configured to
 handle 512 byte read commands. For CD-ROMs that do not (the majority)
 the driver provides the bounce buffer.
 
 The magic is triggered by the special sun*/sparc* disklabel code that
 returns a default sector size of 512 for CD-ROMs.
 
 When I refactored the code in 2016, I missed the case of a read
 smaller than a single sector. Apparently nobody does this but
 our NTFS code, so nobody noticed the bug until NTFS was recently
 added to the sparc64 kernel.
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."
 
[prev in list] [next in list] [prev in thread] [next in thread]