Bug 3237

Решение видится следующее:
построить дерево из пидов, каждому из которых будет соответствовать список блокировок.
Это обеспечит быстрое удаление всех блокировок, привязанных к данному пиду - удаляется узел из дерева.
При удалении же какой-то одной конкретной блокировки, мы просто пробегаемся по списку пида и удаляем все блокировки, находящиеся внутри неё.

Ветка репозитория, где ведётся работа.

http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=commitdiff;h=d6090073dcf72f3db9e05aa4c7f744f1a20c4c37

Думаю, что из рабочего дерева, с которым можно будет куда-то выходить, стоит исключить эскпериментальные коммиты с архаизмами вида '\r' и комментариев со странным кодом:

+int main() {\r
+    int n, m;\r
+    //freopen("input", "rt", stdin);\r
+    //freopen("output", "wt", stdout);\r
+    pid_tree *head = NULL;\r
+    while(1) {\r
+       string s;\r
+       cin >> s;\r
+       if (s == "insert") {\r
+           __u64 pid, offset, len;\r

Да и реализацию функций в заголовочные файлы кидать тоже не стоит... А кроме прочего с локальными функциями не стоит забывать про спецификатор static...

Я бы не хотел видеть код из текущего коммита в своих ветках. Его стоит исправить...

Исправлено.
http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=shortlog;h=refs/heads/lock_on_close

(In reply to comment #4)
> Исправлено.
> http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=shortlog;h=refs/heads/lock_on_close
> 

Странные коммиты, я думаю, стоит вообще исключить из истории.
Как быть с кодом в заголовочном файле? Его там быть не должно - это же не C#.

Разбросал код. Набросал реализацию posix поведения при закрытии файлов. Теперь надо буду тестировать и отлавливать ошибки, если таковые найдутся.
По поводу странных коммитов не вижу ничего страшного если они и будут. Это тестовый репо, не больше, не меньше.

Переехал в новый бранч.
http://git.etersoft.ru/people/piastry/packages/?p=cifsLockOnClose.git;a=summary

На локальных своих тестах заработала след функциональность:
Два процесса - 1 и 2
1 открывает файл - дескриптор file1
1 открывает файл - дескриптор file2
2 открывает файл - дескриптор file3
1 устанавливает блокировку через file1
2 пытается установить блокировку через file3, зависая в ожидании
1 закрывает дескриптор file2, 2 - сразу же получает доступ к файлу, устанавливая блокировку на file3

Вышеописанное соответствует поведению posix.

(In reply to comment #8)
> На локальных своих тестах заработала след
> функциональность:
[...]
> Вышеописанное соответствует поведению posix.
> 

Нужно сделать соответствующую ветку ядра в нашем git для cifs, а также собрать тестовую сборку etercifs и протестировать с помощью rect.

Нашел в коде типа bool (например bool USE_TREE = true; ). С этим на ядрах < 2.6.23 собираться не будет. Надо изменить на unsigned USE_TREE = 1; и проверить собираемость на всех ядрах.

... И код отформатирован не так, как он в исходниках ядра форматируется. Вместо табов - пробелы.

Репозиторий разработки:

http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=summary
все ветки *-locks

Решены проблемы с типами данных и оформлением исходного кода.
Проверена собираемость всех веток.

Пакет для тестирования тут

ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.1-alt1.testing1.noarch.rpm

Git тут (ветка testing): http://git.etersoft.ru/people/kipruss/packages/?p=etercifs.git;a=shortlog;h=refs/heads/testing

etercifs-4.1.1-alt1.testing1
rect-slice-0.0.11-alt1
rect-slave-0.0.11-alt1
python-module-RECT-0.0.11-alt1

Клиенты:
start: LS:tcp -h 192.168.33.9 -p 13666
start: LS:tcp -h localhost -p 13555
start: LS:tcp -h valhalla -p 13666

Сервера:
start: //192.168.33.1/upload
start: //192.168.33.9/share

С опцией forcemand тест на снятие блокировки после закрытия файла (DualSetLockOnLock.testReadAfterCloseAfterLock) падает везде.
Без опции forcemand тест падает только при работе с windows сервером.
Падает на операции saferead после закрытия файла. (Для linux - permission denied) 

Я правильно понимаю, что первым слейвом использовался слейв на windows? Если это так, то всё правильно, ибо мой патч исправляет posix поведение linux драйвера, а следственно, его и нужно использовать первым слейвом. Тестировать на linux сервере следует только с опцией forcemand, иначе код моего пачта просто не будет выполняться. Но там и так всё работало - и без моего патча.

Тестируйте в след конфигурациях:
L-L on Windows server
L-W on Windows server
(цель патча)

L-L on Linux server
L-W on Linux server
(для проверки на наличие багов)

Нет. Первым слейвом везде использовался linux.
Получилось как-то все наоборот.
В случае linux-сервера с опцией forcemand тест падал, без нее проходил.
В случае windows-сервера с опцией forcemand тест падал, без нее тоже падал.

http://wiki.etersoft.ru/RECT/Testtest?v=mk1 - тестовая(временная) страница на вики. Туда сохранила результаты этого теста

После обновления ядра все заработало: тест прошел
(2.6.27-std-def-alt11)

Новая версия со свежими Пашиными изменениями:

У нас:

//server/pub/Boxes/etercifs-testing/noarch/RPMS.defaultet/ercifs-4.1.2-alt1.testing1.noarch.rpm

И в Питере:

ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.1-alt1.testing1.noarch.rpm

(In reply to comment #19)

не

> //server/pub/Boxes/etercifs-testing/noarch/RPMS.defaultet/ercifs-4.1.2-alt1.testing1.noarch.rpm

а

//server/pub/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.2-alt1.testing1.noarch.rpm

Тот же тест на новом etercifs успешно пройден.

(In reply to comment #21)
> Тот же тест на новом etercifs успешно пройден.
> 

Ждем заключения экспертов по вопросу перехода патчей в основную ветку. :)

Ссылка на страничку данной проблемы:
http://wiki.office.etersoft.ru/testing/cifs/ProblemRemoveLockWin?v=x17

Проведена проверка кода, обнаружены ошибки.

Проблемы решены. Последняя версия исходников на git.etersoft.ru

(In reply to comment #25)
> Проблемы решены. Последняя версия
> исходников на git.etersoft.ru
> 

Собран пакет ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.2-alt1.testing2.noarch.rpm который ожидает тестирования. Наше тестирование RECTом проблем не выявило и подтвердило ожидаемый эффект от изменений.

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

Ссылка на гит: http://git.etersoft.ru/people/kipruss/packages/?p=etercifs.git;a=shortlog;h=refs/heads/testing

Хотелось бы знать что с этими изменениями делать. Релиз 4.2 он не попал, в отличие от остальных изменений и перед следующим релизом я опять ставлю вопрос про данный патч. Что с ним делать? Было бы здорово получить ответ до понедельника, 30 марта. 

А можно получить какие-либо замечания о том, почему фигурирует именно Windows-сервер? Проблема, как я знаю, характерна для любого CIFS-сервера.

Нет. Samba server с включенными linux ext сам снимает блокировки. Если же мы монтируем его шару с опцией forcemand или используем windows сервер, то появляется проблема, описанная в баге.

(In reply to comment #27)
> Хотелось бы знать что с этими изменениями
> делать. Релиз 4.2 он не попал, в отличие от
> остальных изменений и перед следующим
> релизом я опять ставлю вопрос про данный
> патч. Что с ним делать? 
Включаем в следующую сборку.

Выставляю статус решена.

см. http://bugs.etersoft.ru/show_bug.cgi?id=3755#c1
выпущен 4.3.0, содержащий патчи, решающие данную проблему.