Re: kern/53217: -current: dumping to wedges on GPT disks broken

[Frank Kardel <kardel%netbsd.org@localhost>]

The following reply was made to PR kern/53217; it has been noted by GNATS.

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/53217: -current: dumping to wedges on GPT disks broken
Date: Fri, 27 Apr 2018 15:48:20 +0200

 You are right in that regard. The problem is not the dkX types - they 
 are fine an correct, but when the dump function crawls into the rabbit 
 hole accessing the underlying disk it uses the whole disk partion of the 
 underlying disk with the correct offset applied:
 
 dk.c:dkdump()
     1624         bdev = bdevsw_lookup(sc->sc_pdev);
     1625         rv = (*bdev->d_dump)(sc->sc_pdev, blkno + 
 sc->sc_offset, va, size);
 
 Then the dump function of the wd driver is called and defers the work to
 wd.c:wddump()
 
     1420         dksc = &wd->sc_dksc;
     1421
     1422         return dk_dump(dksc, dev, blkno, va, size);
 
 In dksubr.c dkdump (not the wedge code, the general disk support) then 
 examines as I quoted
       796         /* Convert to disk sectors.  Request must be a 
 multiple of size. */
      797         part = DISKPART(dev);
 ...
      806         p = &lp->d_partitions[part];
      807         if (p->p_fstype != FS_SWAP && p->p_fstype != FS_UNUSED) {
      808                 DPRINTF(DKDB_DUMP, ("%s: bad fstype %d\n", 
 __func__,
      809                     p->p_fstype));
      810                 return ENXIO;
      811         }
 
 and finds FS_UNUSED as it is now looking at the full disk "partition" it 
 got from sc->sc_pdev in dkwedge/dk.c. Then
 ENXIO is return and that is the end of the dump.
 
 I am not talking about the dk labels here, but of the label of the 
 underlying disk.
 
 My setup is:
 
 /dev/rwd0: 4 wedges:
 dk0: EFI System, 262144 blocks at 2048, type: msdos
 dk1: bootswap, 33554432 blocks at 264192, type: swap
 dk2: System Root, 419430400 blocks at 33818624, type: ffs
 dk3: User, 1500276111 blocks at 453249024, type: ffs
 
 disklabel wd0 (internal label - automagically created)
 ...
 4 partitions:
 #        size    offset     fstype [fsize bsize cpg/sgs]
   a: 1953525168         0     4.2BSD      0     0     0  # (Cyl. 0 - 
 1938020)
   d: 1953525168         0     unused      0     0        # (Cyl. 0 - 
 1938020)
 
 gpt show wd0
         start        size  index  contents
             0           1         PMBR
             1           1         Pri GPT header
             2          32         Pri GPT table
            34        2014         Unused
          2048      262144      1  GPT part - EFI System
        264192    33554432      2  GPT part - NetBSD swap
      33818624   419430400      3  GPT part - NetBSD FFSv1/FFSv2
     453249024  1500276111      4  GPT part - NetBSD FFSv1/FFSv2
    1953525135          32         Sec GPT table
    1953525167           1         Sec GPT header
 
 Everything is fine until the dksubr.c:dkdump routing hits partition d on 
 the underlying disk.
 
 Frank
 
 On 04/27/18 15:20, Martin Husemann wrote:
 > The following reply was made to PR kern/53217; it has been noted by GNATS.
 >
 > From: Martin Husemann <martin%duskware.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: kern/53217: -current: dumping to wedges on GPT disks broken
 > Date: Fri, 27 Apr 2018 15:15:38 +0200
 >
 >   On Fri, Apr 27, 2018 at 01:05:01PM +0000, Frank Kardel wrote:
 >   >  As long as it works, fine.
 >   
 >   Everything else is pretty dangerous ;-)
 >   
 >   >  It violates, though, a bit the principle of least astonishment.
 >   >  sometimes GPT disks would have a full disk partition with "swap"
 >   >  sometime with "unused"
 >   
 >   I think there is confusion which disk devices "label" we are talking about
 >   here (and what the code checks).
 >   
 >   The full disk "partition" of the fictious (purely internal) label on my
 >   dk1 partition better be of type swap, while my dk0 better be ffs:
 >   
 >   wd0: GPT GUID: d96ce1d6-f47b-464b-b0c8-b8fea0d23f31
 >   dk0 at wd0: Guru-Root
 >   dk0: 5856338797 blocks at 34, type: ffs
 >   dk1 at wd0: d5c3eff7-a35d-41b3-9c58-76679533f5cb
 >   dk1: 4194304 blocks at 5856338831, type: swap
 >   wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
 >   
 >   But wd0's internal label should have a raw partition of type unused.
 >   
 >   The latter is true, the former two I can't check easily as dk* does not
 >   provide access to the label (which is good too).
 >   
 >   
 >   Martin
 >