On Mon., Oct. 19, 2020, 3:29 p.m. Todd C. Miller, <[email protected]> wrote:
> On Mon, 19 Oct 2020 13:26:06 -0600, "Theo de Raadt" wrote: > > > Todd C. Miller <[email protected]> wrote: > > > > > For some reason, cmplabel() in disklabel.c doesn't compare the > > > bounds values when it checks for changes. I'm not sure what the > > > reason for that is, it seems like we should write the new label > > > even if the only change is in the bounds. > > > > I guess it got missed. Let's see a diff :-) > > Well, it seemed intentional; I was unsure why you added those bits. > > - todd > > Index: sbin/disklabel/disklabel.c > =================================================================== > RCS file: /cvs/src/sbin/disklabel/disklabel.c,v > retrieving revision 1.235 > diff -u -p -u -r1.235 disklabel.c > --- sbin/disklabel/disklabel.c 28 Jun 2019 13:32:43 -0000 1.235 > +++ sbin/disklabel/disklabel.c 19 Oct 2020 19:27:19 -0000 > @@ -1198,10 +1198,6 @@ cmplabel(struct disklabel *lp1, struct d > lab1.d_checksum = lab2.d_checksum; > lab1.d_bbsize = lab2.d_bbsize; > lab1.d_sbsize = lab2.d_sbsize; > - lab1.d_bstart = lab2.d_bstart; > - lab1.d_bstarth = lab2.d_bstarth; > - lab1.d_bend = lab2.d_bend; > - lab1.d_bendh = lab2.d_bendh; > > return (memcmp(&lab1, &lab2, sizeof(struct disklabel))); > } > Those four lines were added in r1.159, 11 years ago. As far as I can see it is because getasciilabel() ignores those fields. This is in turn probably because older label files could record obsolete values that contradict what the kernel believes are the absolute limits. So it is probably more involved than simply reverting those lines. .... Ken
