Bug 2157

http://wiki.etersoft.ru/RECT/

почему-то ресурс в конце не размонтируется. 
mount -t cifs
//testing/public      998M   24K  998M   1% /tmp/rect/testing/public
//testing/public      998M   24K  998M   1% /tmp/rect/testing/public
//testing/public      998M   24K  998M   1% /tmp/rect/testing/public
//testing/public      998M   24K  998M   1% /tmp/rect/testing/public
//testing/public      998M   24K  998M   1% /tmp/rect/testing/public
причем:
umount /tmp/rect/testing/public
This utility only unmounts cifs filesystems.
This utility only unmounts cifs filesystems.
This utility only unmounts cifs filesystems.
This utility only unmounts cifs filesystems.
This utility only unmounts cifs filesystems.
This utility only unmounts cifs filesystems.

не считая этого, вот что получилось у меня:
ERROR: testLocal (CrossRW_Test.TheTest)
ERROR: testLocal (DualRW_Test.TheTest)
ERROR: testLocal (SimpleRWLockW_Test.TheTest)
ERROR: testMounts (SimpleRWLockW_Test.TheTest)
ERROR: testLocal (CrossRWLockR_Test.TheTest)
ERROR: testLocal (CrossLockWRErr_Test.TheTest)

Ran 16 tests in 3.963s
FAILED (errors=6)

(In reply to comment #2)

> почему-то ресурс в конце не размонтируется. 
> mount -t cifs
[...]

Известная проблема с командой cifsumount -- она
не чистит за собой mtab...

Проверьте при помощи cat /proc/mounts: скорее
всего там ничего такого нет. И верьте
только ядру ;) Уже довольно давно не доходят
руки повесить что-нибудь в ALT на samba-client по
этому поводу. Если кто-нибудь это сделает,
буду благодарен.

Как временное решение можно дать на машине,
где запускается slave, пользователю, от имени
которого он запускается, беспарольное sudo, и
запускать его как

$ rect "--Mount.Umount=sudo umount"

>не считая этого, вот что получилось у меня:
[...]

"Локальные" тесты скорее всего пишут в
текущий каталог -- скорее всего у rect нет
прав на запись туда. Думаю, подобное
поведение по умолчанию должно быть
изменено. Думаю, это претензия к
составителям тестов. Возможно, локальные
вообще не нужны.

А вот это:

> ERROR: testMounts (SimpleRWLockW_Test.TheTest)

уже интересно. Тут надо разбираться. Думаю,
стоит запустить этот тест отдельно и
посмотреть на подробный вывод и вывод slave в
этот момент.

(In reply to comment #3)
> Проверьте при помощи cat /proc/mounts: скорее
> всего там ничего такого нет.
Да, действительно.
> > ERROR: testMounts (SimpleRWLockW_Test.TheTest)
> 
> уже интересно. Тут надо разбираться. Думаю,
> стоит запустить этот тест отдельно и
> посмотреть на подробный вывод и вывод slave в
> этот момент.
>
rect
Starting RECT with endpoints tcp -p 13666
Description: Linux
***** MARK: Test#SimpleRWLockW, Slave1, testLocal
Opening file: test.dat
***** MARK: Test#SimpleRWLockW, Slave1, testMounts
creating mountpoint: mkdir -p '/tmp/rect//testing/public'
mounting share: cifsmount //testing/public /tmp/rect//testing/public -o noperm,setuids,guest
Opening file: /tmp/rect//testing/public/test.dat
        fd = 11
Closing file in cleanup, fd = 11
unmounting share: cifsumount '/tmp/rect//testing/public'
 
rect
Starting RECT with endpoints tcp -p 13666
Description: Linux
***** MARK: Test#SimpleRWLockW, Slave1, testLocal
Opening file: test.dat
***** MARK: Test#SimpleRWLockW, Slave1, testMounts
creating mountpoint: mkdir -p '/tmp/rect//testing/public'
mounting share: cifsmount //testing/public /tmp/rect//testing/public -o noperm,setuids,guest
Opening file: /tmp/rect//testing/public/test.dat
        fd = 11
Closing file in cleanup, fd = 11
unmounting share: cifsumount '/tmp/rect//testing/public'

ERROR: testMounts (__main__.TheTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./SimpleRWLockW_Test.py", line 43, in testMounts
    self._testContent(os.path.join(self.share[0], self.file))
  File "./SimpleRWLockW_Test.py", line 30, in _testContent
    res = file2.read(len(self.data) + 500)
  File "/usr/share/rect/slice/linux.ice", line 227, in read
Error: exception ::RECT::Linux::Error
{
    reason = Permission denied
    code = 13
}

rect
Starting RECT with endpoints tcp -p 13666
Description: Linux
***** MARK: Test#SimpleRWLockW, Slave0, testLocal
Opening file: test.dat
        fd = 11
Closing file in cleanup, fd = 11
***** MARK: Test#SimpleRWLockW, Slave0, testMounts
creating mountpoint: mkdir -p '/tmp/rect//testing/public'
mounting share: cifsmount //testing/public /tmp/rect//testing/public -o noperm,setuids,guest
Opening file: /tmp/rect//testing/public/test.dat
        fd = 11
Closing file in cleanup, fd = 11
unmounting share: cifsumount '/tmp/rect//testing/public'

в пред. дважды один и тот же слейв

кстати если использовать просто umount вместо cifsumount, то запись не остается

> "Локальные" тесты скорее всего пишут в
> текущий каталог -- скорее всего у rect нет
> прав на запись туда. Думаю, подобное
> поведение по умолчанию должно быть
> изменено. Думаю, это претензия к
> составителям тестов. Возможно, локальные
> вообще не нужны.

Если тесты запускаются на одной машине, то локальные тесты работают, если rect запущен в соответствии с описанием http://wiki.etersoft.ru/RECT/LinuxSlave#h295-9 (ссылка в меню " Настройка при запуске более, чем одного слэйва в рамках одной ОС" на всякий случай), если на разных слейвах, то локальные тесты (при кол-ве слейвов > 1) не сработают, так как локально файл пишется, к примеру, первым слейвом в свою директорию, а читается вторым. А в его директории файла нету. Предложение по убиранию локальных тестов посему выглядит обоснованным.

В данном случае, судя по всему (вернее по логам в выводе, а точнее по совпадающей строке

> Starting RECT with endpoints tcp -p 13666

) rect  был запущены на разных компах, так как слушается один и тот же порт 13666. И не сработали локальные тесты ТОЛЬКО в случае количества 2 слейвов в них. Стало быть с локальными тестами все понятно.

да. с локальными все понятно.
но я cifs тестировал и локальные меня не интересуют, так?

Да, конечно.

Вот мой вывод запуска теста:

master:

[kipruss@localhost tests]$ ./SimpleRWLockW_Test.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.847s

OK

Slave0:

***** MARK: Test#SimpleRWLockW, Slave0, testLocal
Opening file: test.dat
        fd = 10
Closing file fd = 10


***** MARK: Test#SimpleRWLockW, Slave0, testMounts
creating mountpoint: mkdir -p '/tmp/rect//server/upload'
mounting share: cifsmount //server/upload /tmp/rect//server/upload -o
noperm,setuids,guest
Opening file: /tmp/rect//server/upload/test.dat
        fd = 10
Closing file fd = 10
unmounting share: cifsumount '/tmp/rect//server/upload'

Slave1:

***** MARK: Test#SimpleRWLockW, Slave1, testLocal
Opening file: test.dat
        fd = 10
Closing file fd = 10


***** MARK: Test#SimpleRWLockW, Slave1, testMounts
creating mountpoint: mkdir -p '/tmp/rect//server/upload'
mounting share: cifsmount //server/upload /tmp/rect//server/upload -o
noperm,setuids,guest
Opening file: /tmp/rect//server/upload/test.dat
        fd = 10
Closing file fd = 10
unmounting share: cifsumount '/tmp/rect//server/upload'

но у меня как раз случай 2 слейвов на 1
машине. Будем проверять далее.

я использовал
linux-cifs 1.53
ALTLinux Sisyphus
testing.office.etersoft.ru 2.6.25-std-def-alt5
lin-test.office.etersoft.ru 2.6.25-std-def-alt7
samba-3.0.30-alt3.1

rect из http://git.etersoft.ru/people/imelnikov/packages/rect.git/
тесты из http://git.etersoft.ru/people/kipruss/packages/rect-tests.git/

(In reply to comment #10)
> я использовал
> linux-cifs 1.53
> ALTLinux Sisyphus
> testing.office.etersoft.ru 2.6.25-std-def-alt5
> lin-test.office.etersoft.ru 2.6.25-std-def-alt7
> samba-3.0.30-alt3.1
> 
> rect из http://git.etersoft.ru/people/imelnikov/packages/rect.git/
> тесты из http://git.etersoft.ru/people/kipruss/packages/rect-tests.git/
> 

Пытались воспроизвести - не получилось

шара, она же один из слейвов: дистр - смесь, но ближе к сизифу

evilistiq.saratov.etersoft.ru 2.6.24-std-def-alt6
samba-3.0.30-alt3.1
samba-client-3.0.30-alt3.1
linux-cifs не установлен (может он и не нужен)

другой слейв, он же мастер: дистр - тоже смесь, но ближе к бранчу 4.1

heaven.saratov.etersoft.ru 2.6.24-std-def-alt8
linux-cifs-1.50c-alt2
samba-3.0.30-alt3
samba-client-3.0.30-alt3

в качестве шары также был использован и третий комп с характеристиками бранча 4.1 - результат тот же.

Итак: до этого момента я просто упустил момент, что надо подгрузить модуль ядра etercifs.

Теперь история (подробная):

-2. Чуть изменился конфиг в моем git-репозитории (http://git.etersoft.ru/people/kipruss/packages/rect-tests.git/) и на wiki добавилось описание. Из существенного только запуск тестов теперь лучше $ ./all_old.py так как all.py с новыми фичами пока не допилили. Тесты не менялись, но выкинул локальные. Так что лучше обновить.

-1. Обновил ядро (из-за отсутствия нужных для сборки модуля etercifs kernel-headers).

[kipruss@heaven ~]$ uname -a
Linux heaven.saratov.etersoft.ru 2.6.24-std-def-alt9 #1 SMP Mon May 5 18:59:15 MSD 2008 i686 GNU/Linux

0. Взял пакет linux-cifs-1.53-alt1.bld1.i586.rpm

1. Выдрал оттуда исходники, запустил скрипт buildmodule.sh в результате появился модуль /lib/modules/2.6.24-std-def-alt9/kernel/fs/cifs/etercifs.ko

2. modprobe etercifs - подгрузил модуль

3. запускаю тесты:

[kipruss@heaven tests]$ ./all_old.py
--------------- Test Time:  2008-07-29 19:10:27.326198 ---------------
....E...
======================================================================
ERROR: testMounts (CrossRWLockR_Test.TheTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kipruss/GIT/rect-tests/tests/CrossRWLockR_Test.py", line 41, in testMounts
    BasicTest.mountSlaves(self, N, 'umount')
  File "/home/kipruss/GIT/rect-tests/tests/rectc.py", line 45, in mountSlaves
    self.slave[s].umount(self.share[h])
  File "/usr/share/rect/slice/linux.ice", line 299, in umount
Error: exception ::RECT::Linux::Error
{
    reason = Failed: unmounting share
    code = 35584
}

----------------------------------------------------------------------
Ran 8 tests in 5.516s

FAILED (errors=1)

4. Мало того, по окончании тестов не отмонтировалась директория на шаре

при вызове mount наблюдаем многократно:
//evilistiq/public on /tmp/rect/evilistiq/public type cifs (rw,mand,nosuid,nodev,user=kipruss)

5. Отмонтировать не выходит никак. Ни cifsumount ни umount

[kipruss@heaven tests]$ cifsumount /tmp/rect/evilistiq/public/
Ошибка сегментирования

[root@heaven kipruss]# cifsumount /tmp/rect/evilistiq/public/
Segmentation fault

[root@heaven kipruss]# umount /tmp/rect/evilistiq/public/ ; echo $?
2

[root@heaven kipruss]# strace cifsumount /tmp/rect/evilistiq/public/
execve("/usr/bin/cifsumount", ["cifsumount", "/tmp/rect/evilistiq/public/"], [/* 37 vars */]) = 0
brk(0)                                  = 0x80003000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=117375, ...}) = 0
mmap2(NULL, 117375, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ed7000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000b\1\0004\0\0\0\310"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1208640, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ed6000
mmap2(NULL, 1214724, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dad000
mmap2(0xb7ed0000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123) = 0xb7ed0000
mmap2(0xb7ed3000, 10500, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ed3000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dac000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dac6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7ed0000, 4096, PROT_READ)   = 0
munmap(0xb7ed7000, 117375)              = 0
geteuid32()                             = 0
statfs64("/tmp/rect/evilistiq/public", 84, {f_type=0xff534d42, f_bsize=4096, f_blocks=2063568, f_bfree=420897, f_bavail=316073, f_files=1048576, f_ffree=838567, f_fsid={0, 0}, f_namelen=4096, f_frsize=4096}) = 0
getuid32()                              = 0
umount("/tmp/rect/evilistiq/public", 0 <unfinished ...>
+++ killed by SIGSEGV +++
Process 7582 detached
[root@heaven kipruss]#   

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

7а. Решили собрать модуль из чистых сырцов.

8. Теперь залез в linux-cifs-1.53-alt1.bld1.src.rpm

9. разархивировал сырцы cifs-1.53.tar.bz2

10. Из linux-cifs-shared-1.53.patch взял изменения, касающиеся названия модуля (в Makefile), а также изменения в файле inode.c, чтобы на моем ядре собиралось:
#include <linux/version.h>
и строчки сразу после строки
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)

11. скопировал buildmodule.sh и собрал модуль тоже под названием etercifs.ko. Подгрузил его.

12. Смонтировал и отмонтировал ресурс руками (cifsmount) - успешно

13. Запуск тестов:

[kipruss@heaven tests]$ ./all_old.py
--------------- Test Time:  2008-07-29 19:59:09.211730 ---------------
.....E.E
======================================================================
ERROR: testMounts (SimpleRWLockW_Test.TheTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kipruss/GIT/rect-tests/tests/SimpleRWLockW_Test.py", line 40, in testMounts
    BasicTest.mountSlaves(self, N, 'umount')
  File "/home/kipruss/GIT/rect-tests/tests/rectc.py", line 45, in mountSlaves
    self.slave[s].umount(self.share[h])
  File "/usr/share/rect/slice/linux.ice", line 299, in umount
Error: exception ::RECT::Linux::Error
{
    reason = Failed: unmounting share
    code = 35584
}

======================================================================
ERROR: testMounts (CrossLockWRErr_Test.TheTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kipruss/GIT/rect-tests/tests/CrossLockWRErr_Test.py", line 41, in testMounts
    BasicTest.mountSlaves(self, N, 'umount')
  File "/home/kipruss/GIT/rect-tests/tests/rectc.py", line 45, in mountSlaves
    self.slave[s].umount(self.share[h])
  File "/usr/share/rect/slice/linux.ice", line 299, in umount
Error: exception ::RECT::Linux::Error
{
    reason = Failed: unmounting share
    code = 65280
}

----------------------------------------------------------------------
Ran 8 tests in 4.913s

FAILED (errors=2)

14. Также после этого невозможно ничего отмонтировать (те же симптомы, что и выше)

15. Перезагрузился (довольно быстро уже почему-то)

16. Не стал делать modprobe, запустил тесты. Все работает нормально (со стандартным модулем cifs.ko то бишь)

Насчет того, как должно работать или не работать в тестах я не совсем хорошо представляю, но с неотмонтированием - это беда именно модуля.

(In reply to comment #12)
...
> 0. Взял пакет linux-cifs-1.53-alt1.bld1.i586.rpm
> 
> 1. Выдрал оттуда исходники, запустил скрипт
> buildmodule.sh в результате появился модуль
А зачем выдирать исходники, когда компиляция производится командой
service linux-cifs build
?
Это я в попытке упрощать воспроизведение ситуации.

> /lib/modules/2.6.24-std-def-alt9/kernel/fs/cifs/etercifs.ko
> 
> 2. modprobe etercifs - подгрузил модуль
Запускается через
service linux-cifs start

....
> Насчет того, как должно работать или не
> работать в тестах я не совсем хорошо
> представляю, но с неотмонтированием - это
> беда именно модуля.
Да, и через dmesg должно быть видно, что всё вообще падает.

(In reply to comment #13)

> service linux-cifs build

Про это не знал.

> > 2. modprobe etercifs - подгрузил модуль
> Запускается через
> service linux-cifs start

Поскольку модуль при загрузке не загружается (внес, но закомментировал)

[root@heaven ~]# cat /etc/modules | grep etercifs
# etercifs

, то хотя и

[root@heaven ~]# chkconfig --list | grep cifs
linux-cifs      0:off   1:off   2:off   3:on    4:on    5:on    6:off

получается

[root@heaven ~]# service linux-cifs status
CIFS module status:
    kernel module cifs is not loaded ()

отсюда и нужда в modprobe

(In reply to comment #14)
> [root@heaven ~]# service linux-cifs status
> CIFS module status:
>     kernel module cifs is not loaded ()
> 
> отсюда и нужда в modprobe

Наверное нужно ещё проверить

service linux-cifs start
он загрузит модуль наверное только в случае если был выполнен 
service linux-cifs build

в любом случае, если сервис не грузит модуль при старте системы, это бага, которую надо рассматривать отдельно. 

> Наверное нужно ещё проверить
> 
> service linux-cifs start
> он загрузит модуль наверное только в
> случае если был выполнен 
> service linux-cifs build
> 
> в любом случае, если сервис не грузит
> модуль при старте системы, это бага,
> которую надо рассматривать отдельно. 
> 

Это работает. Сделал все, как было указано еще 2 раза проверил.

Первый тест - оба слейва - моя машина (heaven), шара - server. тестирование встало после 5 тестов на этапе отмонтирования. Консоль пришлось закрывать. Шару впоследствии руками отмонтировать получилось, после завершения работы сервиса rect.

Второй тест - оба слейва - моя машина, шара - evilistiq. После выполнения 2 тестов комп завис и работала только мышь. Пришлось его насильно выключать. Возможно это следствие уже накопившихся проблем.

Проверил на всякий случай на совпадение исходников, из которых я руками модуль собирал и тех, которые в бинарнике лежат. Одинаковые. И собирал запуском того же файла buildmodule.sh

В-общем покамест у меня $ sudo chkconfig linux-cifs off 

Продолжение:

1. Обновил ядро до 26 от Лакостиса.

[kipruss@heaven ~]$ uname -a
Linux heaven.saratov.etersoft.ru 2.6.26-wks-smp-alt1 #1 SMP PREEMPT Mon Jul 14 14:36:23 MSD 2008 i686 GNU/Linux

2. При попытке пересобрать etercifs нашел ошибку, которая показалась мне похожей на уже существующий баг, о чем я и отписал в багзиллу - см. http://bugs.etersoft.ru/show_bug.cgi?id=1783#c10
В итоге модуль собрал

3. При запуске тестов (etercifs) обнаружились ошибки, описанные выше.

4. При использовании стандартного cifs тесты проходят.

================

Резюме. 

Думается, что у linux-cifs проблемы нетривиальные и давайте пока проверим нашу тестовую среду под стандартным cifs. Предлагается это сделать для ряда популярных дистрибутивов (наверное на виртуальных машинах). Для этого нам не хватает пакета rect для этих дистрибутивов. Надеемся на вашу помощь.

> Надеемся на вашу помощь.
для федоры я понимаю все собралось. еще для чего-нить надо? если да, отпишите в 2190

Процитирую сам себя (из Devel):

Хотелось бы добавить (на всякий случай), что последнюю версию (0.0.7) rect можно обнаружить в репозитории Ивана:
http://git.etersoft.ru/people/imelnikov/packages/rect.git/
а последнюю версию тестов (0.0.3), соответствующую последней версии rect, можно взять в моем репозитории
http://git.etersoft.ru/people/kipruss/packages/rect-tests.git/

Что сейчас там есть я попытался отразить в http://wiki.etersoft.ru/RECT/Tests/Description и вообще в http://wiki.etersoft.ru/RECT и далее по ссылкам. Вкратце теперь там не каша из разных тестов, а вполне себе тестовое покрытие для тестирования блокировок на драйверах cifs и etercifs (разные тесты ибо поведение отличается), на 1 либо 2 слейвах, на шаре Linux или Windows (это в конфиге указывается и тоже влияет на поведение). Также есть crashtest, который монтирует/размонтирует шару пока драйвер не упадет или не будет нажато Ctrl+C. Кстати, появилась сборка etercifs для ядра 2.6.25, основанная на cifs-1.52, которая не падает на Альте с ядром 2.6.25. Впрочем, это уже другая история. См. http://git.etersoft.ru/people/kipruss/packages/linux-cifs-2.6.25.git но скоро будет немного все по-другому сделано.

(In reply to comment #19)
> Впрочем, это уже другая история. См.
> http://git.etersoft.ru/people/kipruss/packages/linux-cifs-2.6.25.git но
> скоро будет немного все по-другому сделано.
> 

Уже по-другому. См. http://wiki.etersoft.ru/Etercifs

По просьбе sin выкладываю выводы dmesg и messages после неудачного прохождения crashtest драйвером версии 1.54

кусок из dmesg

BUG: unable to handle kernel NULL pointer dereference at 00000260
IP: [<f9d5d022>] :etercifs:init_module+0x1526022/0x15270f0
*pde = 00000000
Oops: 0000 [#2] SMP
Modules linked in: etercifs isofs udf nls_utf8 nls_base vboxdrv ac cpufreq_powersave cpufreq_conservative cpufreq_ondemand freq_table cpufreq_userspace nvidia(P) agpgart af_packet dm_mod joydev usbhid hid ff_memless ppdev snd_hda_intel snd_pcm_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device thermal ohci_hcd snd_mixer_oss ssb snd_pcm processor pcmcia forcedeth button ehci_hcd pcmcia_core psmouse parport_pc sr_mod snd_timer parport rtc firmware_class usbcore cdrom i2c_nforce2 i2c_core serio_raw snd_page_alloc pcspkr snd_hwdep evdev snd soundcore sg ext3 jbd mbcache ata_generic sata_nv pata_amd pata_acpi libata dock sd_mod scsi_mod [last unloaded: cifs]

Pid: 17680, comm: cifsumount Tainted: P      D  (2.6.25-std-def-alt7 #1)
EIP: 0060:[<f9d5d022>] EFLAGS: 00010206 CPU: 0
EIP is at init_module+0x1526022/0x15270f0 [etercifs]
EAX: 00000260 EBX: f7634000 ECX: f9d5d010 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: eb04a000 ESP: eb04bf24
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process cifsumount (pid: 17680, ti=eb04a000 task=f5728070 task.ti=eb04a000)
Stack: c0232c18 f7634000 c02a7667 00000000 00000000 00000012 00000000 f55aff40
       f55aff40 ceb777c8 eb026580 00000c34 f57d4b7c 00000001 00000001 00000000
       eb0265b4 f6c1b800 00000000 00000002 c0262feb bfbb0819 00000034 40000003
Call Trace:
 [<c0232c18>] __capable+0x8/0x20
 [<c02a7667>] sys_umount+0x137/0x380
 [<c0262feb>] audit_syscall_entry+0xfb/0x130
 [<c020be05>] do_syscall_trace+0x1d5/0x1f0
 [<c0204e52>] syscall_call+0x7/0xb
 =======================
Code: <8b> 18 85 db 0f 84 b4 00 00 00 f0 ff 4b 10 79 08 8d 43 10 e8 f6 d1
EIP: [<f9d5d022>] init_module+0x1526022/0x15270f0 [etercifs] SS:ESP 0068:eb04bf24
---[ end trace 7b420984e540bdad ]---


кусок из messages

[root@valhalla ~]# cat /var/log/messages | grep 20:38
Aug 11 20:38:32 valhalla -- MARK --
Aug 13 20:38:13 valhalla kernel: Status code returned 0xc0000054 NT_STATUS_FILE_LOCK_CONFLICT
Aug 13 20:38:13 valhalla kernel:  CIFS VFS: Send error in read = -13
Aug 13 20:38:13 valhalla kernel: Status code returned 0xc0000054 NT_STATUS_FILE_LOCK_CONFLICT
Aug 13 20:38:13 valhalla kernel:  CIFS VFS: Send error in read = -13

базовая среда для тестирования есть. тестируем.
закрываю.

базовая среда для тестирования есть. тестируем.
закрываю.