[devel] хм... umount и hal

[devel] хм... umount и hal

[Alexey I.Froloff]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

Наблюл сегодня такую картину:

1. Монтируем флэшку без -o sync
2. Копируем туда файл большого размера
3. Сразу отмонтируем

В п.3 umount/pumount ждут, пока все буфера сбросятся на
устройство, но HAL рассылает сообщения про property modified
(volume.is_mounted и volume.mount_point) не дожидаясь пока буфера
собсно запишутся...  Таким образом вся индикация записалось/не
записалось вместе с гипотетической командой "извлечь усттройство"
идёт лесом...

Бага?

-- 
Regards, Sir Raorn.
-------------------
Как доставить удовольствие обслуживающим Сизиф? Переложить пакет
в orphaned ;)
		-- inger in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: хм... umount и hal

[Anton Farygin]

On Tue, 30 Aug 2005 15:15:22 +0400, Alexey I. Froloff wrote:

> Наблюл сегодня такую картину:
> 
> 1. Монтируем флэшку без -o sync 2. Копируем
> туда файл большого размера 3. Сразу
> отмонтируем
> 
> В п.3 umount/pumount ждут, пока все буфера
> сбросятся на устройство, но HAL рассылает
> сообщения про property modified (volume.is_mounted и
> volume.mount_point) не дожидаясь пока буфера
> собсно запишутся...  Таким образом вся
> индикация записалось/не записалось
> вместе с гипотетической командой
> "извлечь усттройство" идёт лесом...
> 
> Бага?

Только вот где ?

Собственно hal получает сигнал от ядра.


Rgds,
Rider

Re: [devel] Re: хм... umount и hal

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

On Tue, Aug 30, 2005 at 04:30:30PM +0400, Anton Farygin wrote:
> On Tue, 30 Aug 2005 15:15:22 +0400, Alexey I. Froloff wrote:
> 
> > Наблюл сегодня такую картину:
> > 
> > 1. Монтируем флэшку без -o sync 2. Копируем
> > туда файл большого размера 3. Сразу
> > отмонтируем
> > 
> > В п.3 umount/pumount ждут, пока все буфера
> > сбросятся на устройство, но HAL рассылает
> > сообщения про property modified (volume.is_mounted и
> > volume.mount_point) не дожидаясь пока буфера
> > собсно запишутся...  Таким образом вся
> > индикация записалось/не записалось
> > вместе с гипотетической командой
> > "извлечь усттройство" идёт лесом...
> > 
> > Бага?
> 
> Только вот где ?
> 
> Собственно hal получает сигнал от ядра.

Как именно - через netlink?

void kill_block_super(struct super_block *sb)
{
	struct block_device *bdev = sb->s_bdev;

	bdev_uevent(bdev, KOBJ_UMOUNT);
	generic_shutdown_super(sb);
	sync_blockdev(bdev);
	close_bdev_excl(bdev);
}

При этом generic_shutdown_super() вызывает функции ФС, обрабатывающие
umount, затем sync_blockdev() дописывает блоки, о которых эти функции явно
не позаботились.

С одной стороны, это вроде бы правильно, поскольку файловая система уже
недоступна, да и в /proc/mounts её не видно.  (Кстати, отсутствие записи в
/proc/mounts ни о чём не говорит, поскольку этих /proc/mounts потенциально
столько же, сколько и процессов в системе - у каждого процесса может быть
отдельный namespace, и смонтированные в таком namespace файловые системы
за его пределами не видны.)  С другой стороны, событие KOBJ_UMOUNT
относится не к файловой системе, а к самому устройству - тогда логичнее
было бы выдавать его, когда устройство уже свободно.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: хм... umount и hal

[Alexey I.Froloff]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

* Sergey Vlasov <vsu@> [050830 17:20]:
> > Собственно hal получает сигнал от ядра.
> Как именно - через netlink?
Угу.  А в обработчике сообщения mount/umount смотрит в
/proc/mounts.

> С одной стороны, это вроде бы правильно, поскольку файловая система уже
> недоступна, да и в /proc/mounts её не видно.  (Кстати, отсутствие записи в
> /proc/mounts ни о чём не говорит, поскольку этих /proc/mounts потенциально
> столько же, сколько и процессов в системе - у каждого процесса может быть
> отдельный namespace, и смонтированные в таком namespace файловые системы
> за его пределами не видны.)  С другой стороны, событие KOBJ_UMOUNT
> относится не к файловой системе, а к самому устройству - тогда логичнее
> было бы выдавать его, когда устройство уже свободно.
Делать-то что будем? ;-)

-- 
Regards, Sir Raorn.
-------------------
В mysql chroot'изация всегда была сделана из рук вон плохо, и реакция от
upstream на мои патчи была невразумительной.  Как следствие, у меня есть
основание полагать, что в этой области там не все сделано правильно, вне
зависимости от того, что написано в документации.
		-- ldv in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: хм... umount и hal

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Tue, Aug 30, 2005 at 05:34:22PM +0400, Alexey I. Froloff wrote:
> * Sergey Vlasov <vsu@> [050830 17:20]:
> > > Собственно hal получает сигнал от ядра.
> > Как именно - через netlink?
> Угу.  А в обработчике сообщения mount/umount смотрит в
> /proc/mounts.
> 
> > С одной стороны, это вроде бы правильно, поскольку файловая система уже
> > недоступна, да и в /proc/mounts её не видно.  (Кстати, отсутствие записи в
> > /proc/mounts ни о чём не говорит, поскольку этих /proc/mounts потенциально
> > столько же, сколько и процессов в системе - у каждого процесса может быть
> > отдельный namespace, и смонтированные в таком namespace файловые системы
> > за его пределами не видны.)  С другой стороны, событие KOBJ_UMOUNT
> > относится не к файловой системе, а к самому устройству - тогда логичнее
> > было бы выдавать его, когда устройство уже свободно.
> Делать-то что будем? ;-)

Можно запатчить ядро и посмотреть, как поведёт себя hal, а потом пойти с
этим патчем куда-нибудь и посмотреть, куда пошлют оттуда.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: хм... umount и hal

[Alexey I.Froloff]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

* Sergey Vlasov <vsu@> [050830 18:49]:
> > > > Собственно hal получает сигнал от ядра.
> > > Как именно - через netlink?
> > Угу.  А в обработчике сообщения mount/umount смотрит в
> > /proc/mounts.
> Можно запатчить ядро и посмотреть, как поведёт себя hal, а потом пойти с
> этим патчем куда-нибудь и посмотреть, куда пошлют оттуда.
Ну, у volume'а есть два пропертя - is_mounted и mount_point, при
чём обновляются они оба сразу.  Вот первую проперть надо
обновлять уже после освобождения устройства, впихнув в ядро ещё
одно сообщение и в hal ещё один обработчик...

-- 
Regards, Sir Raorn.
-------------------
incoming работает нормально - проверил с четырех разных российских точек.
		-- rider in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: хм... umount и hal

[Alexey I.Froloff]

[-- Attachment #1.1: Type: text/plain, Size: 616 bytes --]

* Alexey I.Froloff <raorn@> [050830 19:06]:
> Ну, у volume'а есть два пропертя - is_mounted и mount_point, при
> чём обновляются они оба сразу.  Вот первую проперть надо
> обновлять уже после освобождения устройства, впихнув в ядро ещё
> одно сообщение и в hal ещё один обработчик...
А вот и патчик для 2.6.12-почтиstd26-alt3.  Untested, лучшего
названия кроме FREE не нашёл ;-)

-- 
Regards, Sir Raorn.
-------------------
Текстовый инсталлятор не исправлялся и исправляться не будет по причине
невозможности определения ошибки в этом нагромождении жуткого перлового
кода.
		-- darkstar in sisyphus@

[-- Attachment #1.2: linux-2.6.12-alt-umount-free-event.patch --]
[-- Type: text/plain, Size: 1582 bytes --]

diff -Naurp kernel-source-2.6.12-orig/fs/super.c kernel-source-2.6.12/fs/super.c
--- kernel-source-2.6.12-orig/fs/super.c	2005-06-17 23:48:29 +0400
+++ kernel-source-2.6.12/fs/super.c	2005-08-31 19:17:54 +0400
@@ -734,6 +734,7 @@ void kill_block_super(struct super_block
 	generic_shutdown_super(sb);
 	sync_blockdev(bdev);
 	close_bdev_excl(bdev);
+	bdev_uevent(bdev, KOBJ_FREE);
 }
 
 EXPORT_SYMBOL(kill_block_super);
diff -Naurp kernel-source-2.6.12-orig/include/linux/kobject_uevent.h kernel-source-2.6.12/include/linux/kobject_uevent.h
--- kernel-source-2.6.12-orig/include/linux/kobject_uevent.h	2005-06-17 23:48:29 +0400
+++ kernel-source-2.6.12/include/linux/kobject_uevent.h	2005-08-31 19:16:50 +0400
@@ -29,6 +29,7 @@ enum kobject_action {
 	KOBJ_UMOUNT	= (__force kobject_action_t) 0x05,	/* umount event for block devices */
 	KOBJ_OFFLINE	= (__force kobject_action_t) 0x06,	/* offline event for hotplug devices */
 	KOBJ_ONLINE	= (__force kobject_action_t) 0x07,	/* online event for hotplug devices */
+	KOBJ_FREE	= (__force kobject_action_t) 0x08,	/* free device event for block devices */
 };
 
 
diff -Naurp kernel-source-2.6.12-orig/lib/kobject_uevent.c kernel-source-2.6.12/lib/kobject_uevent.c
--- kernel-source-2.6.12-orig/lib/kobject_uevent.c	2005-06-17 23:48:29 +0400
+++ kernel-source-2.6.12/lib/kobject_uevent.c	2005-08-31 19:18:13 +0400
@@ -44,6 +44,8 @@ static char *action_to_string(enum kobje
 		return "offline";
 	case KOBJ_ONLINE:
 		return "online";
+	case KOBJ_FREE:
+		return "free";
 	default:
 		return NULL;
 	}

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: хм... umount и hal

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

On Wed, Aug 31, 2005 at 07:32:59PM +0400, Alexey I. Froloff wrote:
> * Alexey I.Froloff <raorn@> [050830 19:06]:
> > Ну, у volume'а есть два пропертя - is_mounted и mount_point, при
> > чём обновляются они оба сразу.  Вот первую проперть надо
> > обновлять уже после освобождения устройства, впихнув в ядро ещё
> > одно сообщение и в hal ещё один обработчик...
> А вот и патчик для 2.6.12-почтиstd26-alt3.  Untested, лучшего
> названия кроме FREE не нашёл ;-)

> diff -Naurp kernel-source-2.6.12-orig/fs/super.c kernel-source-2.6.12/fs/super.c
> --- kernel-source-2.6.12-orig/fs/super.c	2005-06-17 23:48:29 +0400
> +++ kernel-source-2.6.12/fs/super.c	2005-08-31 19:17:54 +0400
> @@ -734,6 +734,7 @@ void kill_block_super(struct super_block
>  	generic_shutdown_super(sb);
>  	sync_blockdev(bdev);
>  	close_bdev_excl(bdev);
> +	bdev_uevent(bdev, KOBJ_FREE);

Так делать нельзя - close_bdev_excl() вызывает blkdev_put(), и после
этого bdev может быть уже уничтожено (если этот umount выполняется
после отсоединения устройства).  Нужно либо ставить bdev_uevent()
перед close_bdev_excl() (но тогда получается race - до выполнения
bd_release(), вызываемого в close_bdev_excl(), устройство невозможно
открыть с O_EXCL или смонтировать, так что объявлять о его
освобождении ещё рано), либо вместо close_bdev_excl() вызывать
отдельно bd_release() и blkdev_put(), вставив между ними вызов
bdev_uevent() (что тоже не совсем красиво, поскольку исчезает явный
вызов функции, соответствующей open_bdev_excl()).

С другой стороны, если сначала вызвать bd_release(), получается race
другого вида - кто-то может выполнить bd_claim() и объявить о занятии
устройства до того, как будет сгенерировано сообщение об освобождении
устройства.  Возможно, первый вариант race лучше, поскольку в этом
случае хотя бы гарантируется правильный порядок событий, а нарваться
на занятость устройства новым монтированием обработчик KOBJ_FREE может
в любом случае.

>  }
>  
>  EXPORT_SYMBOL(kill_block_super);
> diff -Naurp kernel-source-2.6.12-orig/include/linux/kobject_uevent.h kernel-source-2.6.12/include/linux/kobject_uevent.h
> --- kernel-source-2.6.12-orig/include/linux/kobject_uevent.h	2005-06-17 23:48:29 +0400
> +++ kernel-source-2.6.12/include/linux/kobject_uevent.h	2005-08-31 19:16:50 +0400
> @@ -29,6 +29,7 @@ enum kobject_action {
>  	KOBJ_UMOUNT	= (__force kobject_action_t) 0x05,	/* umount event for block devices */
>  	KOBJ_OFFLINE	= (__force kobject_action_t) 0x06,	/* offline event for hotplug devices */
>  	KOBJ_ONLINE	= (__force kobject_action_t) 0x07,	/* online event for hotplug devices */
> +	KOBJ_FREE	= (__force kobject_action_t) 0x08,	/* free device event for block devices */

Имя слишком общее, и не совсем отражает суть события.  Если это именно
освобождение, тогда получается, что это событие должно выдаваться и
при закрытии устройства, открытого с O_EXCL (т.е., где-то в
bd_release()).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] emacs NMU

[Igor Vlasenko]

õ×ÁÖÁÅÍÙÅ ËÏÌÌÅÇÉ, 
ÐÏËÁ emacs team  ÅÝÅ ÎÅ ÓÏÚÄÁÎÁ,
ÈÏÞÕ × ËÁÞÅÓÔ×Å NMU ×ÙÌÏÖÉÔØ × óÉÚÉÆ ÓÂÏÒËÕ emacs21-21.3-alt11.M24.vla2
ËÁË emacs21-21.3-alt12. 
ïÎÁ ÚÁËÒÙ×ÁÅÔ ÒÑÄ ÍÅÌËÉÈ, ÎÏ ÎÅÐÒÉÑÔÎÙÈ ÄÌÑ ËÏÍÆÏÒÔÎÏÊ ÖÉÚÎÉ ÂÁÇÏ× × 
emacs21-21.3-alt11.
óÂÏÒËÕ ÍÏÖÎÏ ÐÏÓÍÏÔÒÅÔØ × Backpots & Daedalus.

îÅÔ ×ÏÚÒÁÖÅÎÉÊ?

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

Re: [devel] emacs NMU

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Igor Vlasenko пишет:
> Уважаемые коллеги, 
> пока emacs team  еще не создана,
Уже...
> хочу в качестве NMU выложить в Сизиф сборку emacs21-21.3-alt11.M24.vla2
> как emacs21-21.3-alt12. 
> Она закрывает ряд мелких, но неприятных для комфортной жизни багов в 
> emacs21-21.3-alt11.
> Сборку можно посмотреть в Backpots & Daedalus.
> 
> Нет возражений?

Я думаю, стоит обновить его до 21.4 и заливать от имени

Emacs Maintainers Team <emacs@p.a.o>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] emacs NMU

[Igor Vlasenko]

> Igor Vlasenko ÐÉÛÅÔ:
> > õ×ÁÖÁÅÍÙÅ ËÏÌÌÅÇÉ, 
> > ÐÏËÁ emacs team  ÅÝÅ ÎÅ ÓÏÚÄÁÎÁ,
> õÖÅ...

óÐÁÓÉÂÏ! 

> > ÈÏÞÕ × ËÁÞÅÓÔ×Å NMU ×ÙÌÏÖÉÔØ × óÉÚÉÆ ÓÂÏÒËÕ emacs21-21.3-alt11.M24.vla2
> > ËÁË emacs21-21.3-alt12. 
> > ïÎÁ ÚÁËÒÙ×ÁÅÔ ÒÑÄ ÍÅÌËÉÈ, ÎÏ ÎÅÐÒÉÑÔÎÙÈ ÄÌÑ ËÏÍÆÏÒÔÎÏÊ ÖÉÚÎÉ ÂÁÇÏ× × 
> > emacs21-21.3-alt11.
> > óÂÏÒËÕ ÍÏÖÎÏ ÐÏÓÍÏÔÒÅÔØ × Backpots & Daedalus.
> > îÅÔ ×ÏÚÒÁÖÅÎÉÊ?
> 
> ñ ÄÕÍÁÀ, ÓÔÏÉÔ ÏÂÎÏ×ÉÔØ ÅÇÏ ÄÏ 21.4 É ÚÁÌÉ×ÁÔØ ÏÔ ÉÍÅÎÉ
> Emacs Maintainers Team <emacs@p.a.o>

ÍÅÎÑ ÎÁ ÓÌÅÄÕÀÝÅÊ ÎÅÄÅÌÅ ÎÅ ÂÕÄÅÔ, 
×ÅÒÎÕÓØ, ÎÁÞÎÕ ÓÍÏÔÒÅÔØ.
ÐÏËÁ ÚÁÌÉÌ 21.3-alt12 × incoming. 

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

Re: [devel] Re: хм... umount и hal

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On Tue, Aug 30, 2005 at 07:05:25PM +0400, Alexey I. Froloff wrote:
> * Sergey Vlasov <vsu@> [050830 18:49]:
> > > > > Собственно hal получает сигнал от ядра.
> > > > Как именно - через netlink?
> > > Угу.  А в обработчике сообщения mount/umount смотрит в
> > > /proc/mounts.
> > Можно запатчить ядро и посмотреть, как поведёт себя hal, а потом пойти с
> > этим патчем куда-нибудь и посмотреть, куда пошлют оттуда.
> Ну, у volume'а есть два пропертя - is_mounted и mount_point, при
> чём обновляются они оба сразу.  Вот первую проперть надо
> обновлять уже после освобождения устройства, впихнув в ядро ещё
> одно сообщение и в hal ещё один обработчик...

Кстати, событие mount, похоже, тоже сломано (просто это менее
заметно):

http://article.gmane.org/gmane.linux.hotplug.devel/8775

Как обычно - сначала что-то сделали, потом начали думать, как же
сделать правильно.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: хм... umount и hal

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

* Sergey Vlasov <vsu@> [051026 23:55]:
> Кстати, событие mount, похоже, тоже сломано (просто это менее
> заметно):
> http://article.gmane.org/gmane.linux.hotplug.devel/8775
> Как обычно - сначала что-то сделали, потом начали думать, как же
> сделать правильно.
Есть надежда, что когда-ньдь в ближайшем обозримом будущем в этом
месте приведут что-ньдь в порядок?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Re: хм... umount и hal

[Anton Farygin]

On Tue, 30 Aug 2005 17:19:33 +0400, Sergey Vlasov wrote:

> On Tue, Aug 30, 2005 at 04:30:30PM +0400, Anton Farygin wrote:
>> On Tue, 30 Aug 2005 15:15:22 +0400, Alexey I. Froloff wrote:
>> 
>> > Наблюл сегодня такую картину:
>> > 
>> > 1. Монтируем флэшку без -o sync 2. Копируем
>> > туда файл большого размера 3. Сразу
>> > отмонтируем
>> > 
>> > В п.3 umount/pumount ждут, пока все буфера
>> > сбросятся на устройство, но HAL
>> > рассылает сообщения про property modified
>> > (volume.is_mounted и volume.mount_point) не дожидаясь
>> > пока буфера собсно запишутся...  Таким
>> > образом вся индикация записалось/не
>> > записалось вместе с гипотетической
>> > командой "извлечь усттройство" идёт
>> > лесом...
>> > 
>> > Бага?
>> 
>> Только вот где ?
>> 
>> Собственно hal получает сигнал от ядра.
> 
> Как именно - через netlink?

Да.

Rgds,
Rider

Re: [devel] Re: хм... umount и hal

[Alexey I.Froloff]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

* Sergey Vlasov <vsu@> [050830 17:20]:
> С одной стороны, это вроде бы правильно, поскольку файловая
> система уже недоступна, да и в /proc/mounts её не видно.
А вот в /etc/mtab она ещё торчит...

-- 
Regards, Sir Raorn.
-------------------
Вы несколько торопитесь. Сизиф с подачи Дмитрия Левина в данный момент
совершает Большой Переход из Темного Прошлого в Светлое Будущее.
В конце обещают "Решенье Всех Проблем" (TM), но в пути кормить не
обещали.
		-- morozov in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]