Re: /proc/partitions broken in 2.5.23

On Wed, Jun 19, 2002 at 10:02:48AM +0100, Dave Jones wrote:

    > I got a bug report about an issue with LVM in 2.5.22-dj1, which turns
    > out to be caused by broken /proc/partitions in mainline.
    > 
    > (davej@mesh:davej)$ cat /proc/partitions 
    > major minor  #blocks  name
    > 
    >    8     0          0 sda
    >   22     0 1515870810 hdc
    > 
    > Note the huge numbers in hex are 0x5a5a5a5a, so something
    > seems to be getting poisoned somewhere.

Is this LVM?

I don't see how LVM could produce such values.
(And in fact LVM does not even compile, so only a patched LVM
could produce anything at all.)

From: Wayne Whitney <[e-mail]>

    I traced the change to the part of mainline ChangeSet 1.496 given
    below (warning: cut and pasted).  It seems to cause every possible
    device that a driver could provide to show up in /proc/partitions.
    For LVM, that's a zillion devices, and /proc/partitions overflows,
    showing some random pages from memory.  Reverting the patch below
    makes /proc/partitions and LVM happy again.

    --- a/drivers/block/genhd.c    Wed May  8 09:53:06 2002
    +++ b/drivers/block/genhd.c    Sun Jun  9 18:58:36 2002
    @@ -177,9 +177,10 @@
         if (sgp == gendisk_head)
             seq_puts(part, "major minor  #blocks  name\n\n");
     
    -    /* show all non-0 size partitions of this disk */
    +    /* show the full disk and all non-0 size partitions of it */
         for (n = 0; n < (sgp->nr_real << sgp->minor_shift); n++) {
    -        if (sgp->part[n].nr_sects == 0)
    +        int minormask = (1<<sgp->minor_shift) - 1;
    +        if ((n & minormask) && sgp->part[n].nr_sects == 0)
                 continue;
             seq_printf(part, "%4d  %4d %10d %s\n",
                 sgp->major, n, sgp->sizes[n],

Yes.
Normally the nr_real field indicates how many devices are
present. But LVM sets that to 256 even when nothing is present.
So, indeed, when all size fields are set to 0 this would probably
yield a list of 256 absent LVM devices.
Maybe LVM has to be fixed, or this patch fragment reverted, or both.

Something else is that if /proc/partitions overflows that must be
fixed independently of zeros or LVM.

Andries