Revert revision 254095

In revision 254095, gpt_entries is not set to match the on-disk
hdr_entries, but rather is computed based on available space.
There are 2 problems with this:

1.  The GPT backend respects hdr_entries and only reads and writes
    that number of partition entries.  On top of that, CRC32 is
    computed over the table that has hdr_entries elements.  When
    the common code works on what is possibly a larger number, the
    behaviour becomes inconsistent and problematic.  In particular,
    it would be possible to add a new partition that on a reboot
    isn't there anymore.
2.  The calculation of gpt_entries is based on flawed assumptions.
    The GPT specification does not dictate that sectors are layed
    out in a particular way that the available space can be
    determined by looking at LBAs.  In practice, implementations
    do the same thing, because there's no reason to do it any
    other way.  Still, GPT allows certain freedoms that can be
    exploited in some form or shape if the need arises.

PR:		229977
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D19438
This commit is contained in:
marcel 2019-03-05 04:15:34 +00:00
parent e846d2bb4f
commit 6ea9978207

View File

@ -990,10 +990,9 @@ g_part_gpt_read(struct g_part_table *basetable, struct g_consumer *cp)
basetable->gpt_first = table->hdr->hdr_lba_start;
basetable->gpt_last = table->hdr->hdr_lba_end;
basetable->gpt_entries = (table->hdr->hdr_lba_start - 2) *
pp->sectorsize / table->hdr->hdr_entsz;
basetable->gpt_entries = table->hdr->hdr_entries;
for (index = table->hdr->hdr_entries - 1; index >= 0; index--) {
for (index = basetable->gpt_entries - 1; index >= 0; index--) {
if (EQUUID(&tbl[index].ent_type, &gpt_uuid_unused))
continue;
entry = (struct g_part_gpt_entry *)g_part_new_entry(