linux-kernel - Re: [PATCH] virtio-blk: emit udev event when device is resized

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <16100EF6-6C55-47ED-9BBB-2C3CAC8FA37A@sde.cz>
Date:	Mon, 25 Feb 2013 18:41:03 -0500
From:	Milos Vyletel <milos.vyletel@....cz>
To:	Greg KH <greg@...ah.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>, Kay Sievers <kay@...y.org>,
	linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org,
	virtualization@...ts.linux-foundation.org, mst@...hat.com
Subject: Re: [PATCH] virtio-blk: emit udev event when device is resized


On Feb 25, 2013, at 5:12 PM, Greg KH <greg@...ah.com> wrote:

> On Fri, Feb 22, 2013 at 10:14:49AM +1030, Rusty Russell wrote:
>> Milos Vyletel <milos.vyletel@....cz> writes:
>> 
>>> When virtio-blk device is resized from host (using block_resize from QEMU) emit
>>> KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
>>> custom udev rules which would take whatever action if such event occurs. As a
>>> proof of concept I've created simple udev rule that automatically resize
>>> filesystem on virtio-blk device.
>>> 
>>> ACTION=="change", KERNEL=="vd*", \
>>>        ENV{RESIZE}=="1", \
>>>        ENV{ID_FS_TYPE}=="ext[3-4]", \
>>>        RUN+="/sbin/resize2fs /dev/%k"
>>> ACTION=="change", KERNEL=="vd*", \
>>>        ENV{RESIZE}=="1", \
>>>        ENV{ID_FS_TYPE}=="LVM2_member", \
>>>        RUN+="/sbin/pvresize /dev/%k"
>> 
>> This looks fine to me, but I like to check with Greg before adding udev
>> callouts.... Greg?
> 
> Hm, I thought we were frowning apon running binaries from udev rules
> these days, especially ones that might have big consequences (like
> resizing a disk image) like this.
> 
> Kay, am I right?
> 
> We already emit KOBJECT_CHANGE events when block devices change, from
> within the block core code.  Why is the patch below needed instead of
> using these events that are already generated?  How are virtio block
> devices special?
> 
>> BTW, if this is good, it's good for stable IMHO.
> 
> What bug does it fix?
> 

It is not really a bug but it definitely is useful enhancement to have in stable too. I
can imagine lots of people can benefit from this.

Milos

> thanks,
> 
> greg k-h
> 
>> Cheers,
>> Rusty.
>> 
>>> Signed-off-by: Milos Vyletel <milos.vyletel@....cz>
>>> ---
>>> drivers/block/virtio_blk.c |    3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>>> index 8ad21a2..5990382 100644
>>> --- a/drivers/block/virtio_blk.c
>>> +++ b/drivers/block/virtio_blk.c
>>> @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct work_struct *work)
>>> 	struct virtio_device *vdev = vblk->vdev;
>>> 	struct request_queue *q = vblk->disk->queue;
>>> 	char cap_str_2[10], cap_str_10[10];
>>> +	char event[] = "RESIZE=1";
>>> +	char *envp[] = { event, NULL };
>>> 	u64 capacity, size;
>>> 
>>> 	mutex_lock(&vblk->config_lock);
>>> @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct work_struct *work)
>>> 
>>> 	set_capacity(vblk->disk, capacity);
>>> 	revalidate_disk(vblk->disk);
>>> +	kobject_uevent_env(&disk_to_dev(vblk->disk)->kobj, KOBJ_CHANGE, envp);
>>> done:
>>> 	mutex_unlock(&vblk->config_lock);
>>> }
>>> -- 
>>> 1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/