[parted-devel] Bug: Removal of BLKPG causes regression of ability to manipulate disks with other partitions in use

Jim Meyering jim at meyering.net
Tue Mar 30 15:08:13 UTC 2010


Phillip Susi wrote:

> On 3/30/2010 3:58 AM, Jim Meyering wrote:
>> I'll make the request once again:
>> Please give details of precisely how you test this (I assume you do).
>> Best is to give a script like one of those in tests/, but a
>> sequence of parted commands would be fine, too.
>> This will require root permissions and the use of the scsi_debug module,
>> so you may find it easiest to base a test script on one of the
>> existing 5 that do that:
>>   tests/t3000-resize-fs.sh
>>   tests/t3200-type-change.sh
>>   tests/t9010-big-sector.sh
>>   tests/t9020-alignment.sh
>>   tests/t9030-align-check.sh
>
> I have not looked at the automated testing at all.  I tested parted
> interactively on a real disk by adding and removing partitions while
> sometimes forcing one or more to be in use by spawning a dd process with
> a command like:
>
> dd of=fifo < /dev/sdd
>
> Which caused the shell to open the drive then dd blocks trying to open a
> named pipe I created with mkfifo.  I made sure to test removing the
> first and last partition both unused and while the partition next to it
> was in use.  I tested both msdos and gpt partition tables, and in the
> case of msdos, made sure to test the case where removing an extended
> partition would renumber the next one which was in use.  This last case
> resulted in the warning and the open partition remained with the higher
> number for the time being.  Subsequently closing the partition and
> either having fdisk force a BLKRRPART or using parted to make further
> changes with BLKPG successfully refreshed the kernel partition table.
>
> Oh that reminds me, is there a way to force the partition number used
> with mkpart instead of choosing the first number not in use already?  I
> ended up accidentally doing some testing with higher numbered partitions
> without the lower ones since I had already removed them and thought it
> might be a good test case to be able to artificially create say,
> partition 27 on a gpt disk by itself.
>
>>> +                                /* get start and length of existing partition */
>>> +                                dev_name = _device_get_part_path (disk->dev, i);
>>
>> Don't segfault when dev_name is NULL.
>
> How can it be NULL,

Just look at the definition of _device_get_part_path:

    static char*
    _device_get_part_path (PedDevice* dev, int num)
    {
            int             path_len = strlen (dev->path);
            int             result_len = path_len + 16;
            char*           result;

            result = (char*) ped_malloc (result_len);
            if (!result)
                    return NULL;


> and what would be the proper recovery?  Throw a bug
> exception and return?

I haven't looked closely yet, but that sounds right.
Though if you're returning early, be sure to free anything
that needs freeing.

>>> +                                fd = open (dev_name, O_RDONLY);
>>
>> You must free dev_name here, to avoid a leak.
>
> Oh, I didn't realize _device_get_part_path() duplicated the string, I
> thought it just returned the existing copy which would be freed when the
> device object was.

I guess this means you did look at the above function definition.



More information about the parted-devel mailing list