Bug 5247

Summary: При запуске etercifs иногда не выгружается ванильный cifs
Product: CIFS@Etersoft Reporter: Александр Морозов <amorozov>
Component: прочееAssignee: Pavel Shilovsky <piastry>
Status: CLOSED FIXED QA Contact: Денис Баранов <baraka>
Severity: minor    
Priority: P3 CC: lav, piastry, sin
Version: не указана   
Target Milestone: ---   
Hardware: PC   
OS: Debian GNU/Linux   
Whiteboard:
Заявки RT: 13212 Связано с:
Дата напоминания:
Bug Depends on:    
Bug Blocks: 3043, 4284    

Description Александр Морозов 2010-03-12 14:27:50 MSK
Иногда возникает ошибка при выгрузке ванильного модуля cifs. В логах при этом:

Thu Mar 11 11:35:47 2010: //192.168.1.8/1cbase on /mnt/winS18 type cifs
(rw,mand)
Thu Mar 11 11:35:47 2010: //192.168.1.3/1CBASE on /mnt/winSA type cifs
(rw,mand)
Thu Mar 11 11:35:47 2010: //192.168.7.5/ZK on /mnt/winSTZ type cifs
(rw,mand)
Thu Mar 11 11:35:47 2010: Unmounting CIFS resources... ^[[73G[
^[[1m^[[32mDONE^[[39;49m^[[0;10m ]
Thu Mar 11 11:35:47 2010: Removing vanilla kernel module cifs... ERROR:
Module cifs is in use
Thu Mar 11 11:35:47 2010: ^[[73G[^[[1m^[[31mFAILED^[[39;49m^[[0;10m]
Thu Mar 11 11:35:47 2010: Running etersafed... ^[[73G[
^[[1m^[[32mDONE^[[39;49m^[[0;10m ]

После загрузки в выводе lsmod:
cifs 219978 0
В /etc/fstab прописано монтирование 3-х разделов с Windows-машин:
//192.168.1.8/1cbase /mnt/winS18 cifs
credentials=/etc/alesh,rw,iocharset=utf8,noperm,forcemand,direct,nounix 0 0
//192.168.1.3/1CBASE /mnt/winSA cifs
credentials=/etc/alesh,rw,iocharset=utf8,noperm,forcemand,direct,nounix 0 0
//192.168.7.5/ZK /mnt/winSTZ cifs
credentials=/etc/admin,rw,iocharset=utf8,noperm,forcemand,direct,nounix 0 0

Debian Squeeze, ядро 2.6.32, etercifs_4.4.5-eter2debian_all.deb

Надо воспроизвести у нас.
Comment 1 Pavel Shilovsky 2010-03-13 11:30:06 MSK
Проблема в том, что на старых ядрах ванильного cifs вообще нельзя делать rmmod сразу после umount, так как там не успевает очиститься информация, связанная с шарой и при попытке удалить модуль возникает ошибка ядра. В etercifs у нас сделаны хаки для того, чтобы после отмонтирования шары на старых ядрах, вся информация была уже удалена.

Начиная с 29 ядра, в ядре пофиксили эту багу следующим образом: каждая новая сессия увеличивает ссылку на модуль на один - то есть модуль будет занят, пока вся информация не выгрузится и количество ссылок не станет равным нулю.

Потому можно всегда использовать rmmod --wait (он будет ждать, пока модуль не освободиться) - это будет хорошо работать на ядрах, начиная с 29, и с нашим etercifs, и с ванильным cifs. Для более старых версий можно сделать что-то вроде sleep() на какое-нибудь небольшое время - обычно там это занимает не более чем секунду (потому вопроизводится только, если сделать umount и rmmod сразу быстро друг за другом - и то не всегда).
Comment 2 Vitaly Lipatov 2010-03-15 12:31:39 MSK
(In reply to comment #1)
...
> Потому можно всегда использовать rmmod --wait
> (он будет ждать, пока модуль не
> освободиться) - это будет хорошо работать
Давайте использовать. Но не будет ли это зависать навсегда, если шара смонтирована и занята?

> на ядрах, начиная с 29, и с нашим etercifs, и с
> ванильным cifs. Для более старых версий можно
> сделать что-то вроде sleep() на какое-нибудь
> небольшое время - обычно там это занимает
> не более чем секунду (потому
> вопроизводится только, если сделать umount и
> rmmod сразу быстро друг за другом - и то не
> всегда).
Давайте сделаем задержку на пару секунд для старых ядер.
В принципе, можно на полгода-год вставить жёсткий sleep,
а потом и ядер таких не будет ;)

Comment 3 Pavel Shilovsky 2010-03-15 22:31:58 MSK
Выпустил 4.5.0-alt2. Доступен с ftp.

Делается rmmod --wait после umount_cifs (которая отмонтирует все ресурсы), если она завершена успешно, иначе выводится сообщение об ошибке.

Для старых ядер делается sleep на 2 секунды.

Comment 4 Pavel Shilovsky 2010-03-19 08:23:40 MSK
Fixed.
Comment 5 Денис Баранов 2010-12-02 22:03:49 MSK
Принято.