Bug 7334

Реализовал механизм кэширования блокировок на основе старых разработок (из баги #5442):

http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/etersoft-lock-cache

Далее планируется провести более подробное тестирование данного функционала.

Переосмыслил дизайн. Нашёл ошибки связанные с расширением и data races. Переписал реализацию и провёл первоначальное тестирование. Далее требуется провести более подробное синтетическое тестирование.

Разобрался как хранятся posix блокировки в vfs и использовал данный мезанизм для реализации кэширования блокировок в стиле posix.
http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/etersoft-lock-cache

Провёл тестирование реализованного функционала (mandatory и posix варианты) с потощью RECT  и Connectathon Test suite соответственно с Samba-3.6.0-alt1 с опциями kernel oplocks = no и level2 oplocks = yes.
http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v3.0-lock-cache

В ходе работ обнаружил ошибку в выборе исходников ядра пакетом etercifs, что поправил (войдёт в следующую версию пакета).
http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=shortlog;h=refs/heads/master

Далее можно собирать тестовую версию пакета etercifs и тестировать с WINE.

Просмотрел код и обнаружил некоторые недочёты в сематике и стиле. Провёл рефакторинг кода. Добавил новый функионал по быстрому снятию блокировок при закрытии (запросы отправляются партиями).

Закоммитил изменения в новую ветку lock-cache-to-kernel (http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/lock-cache-to-kernel). Далее займусь портированием патчей в v3.0-lock-cache и более тщательным тестированием.

Портировал патчи из lock-cache-to-kernel. Изучал различие в поведении mandatory и posix блокировок. Обнаружил ошибки и недочёты, поправил стиль кода.

Создал реализацию, которая полностью удовлетворяет mandatory семантике (текущая не является таковой). Так же поднял в рассылке linux-cifs тему о статусе данного кода в апстрим.

Итого сейчас имею две актуальные ветки:
v3.0-lock-cache
v3.0-lock-cache-fullmand

Протетированно с помощью RECT (mandatory блокировки) Connectathon Test suite (posix блокировки).

Сделал некоторые изменения в описании патчей. Исследовал работу вызова unlock  в связке WINE+CIFS - текущая реализация некорректно работает с пересекающимися блокировками. По результатам обсуждения в devel@, создал ещё две ветки etersoft-fullmand и v3.0-fullmand с исправлениями для вызова unlock.

Собрал две сборки 5.1.0 ( v3.0-fullmand ) и 5.1.1 ( v3.0-lock-cache-fullmand ) для тестирования.

Исправил ошибку из http://bugs.etersoft.ru/show_bug.cgi?id=7685#c4, поправил стиль кода, протестировал с помощью RECT обе ветки (c fullmand и без). 

По результатам обсуждения в рассылке отправил туда патчи без fullmand (так как режим fullmand не соответствует изначальной цели, преследуемой в оригинальном cifs.ko).

(В ответ на comment #8)
...
> По результатам обсуждения в рассылке отправил туда патчи без fullmand
Первые два патча в аптрим (http://bugs.etersoft.ru/show_bug.cgi?id=6517#c54).

В третьем патче обнаружена ошибка залипания блокировки. Поправил 3 и 5 патчи, протестировал и отправил рассылку исправленные версии.

Остальные патчи из данной серии приняты в апстрим

Тестирование нового функционала прошло успешно: http://bugs.etersoft.ru/show_bug.cgi?id=7685

Закрываю.

Обнаружил некоторые недостатки в патчах, принятых в апстрим.

Создал и протестировал три патча, исправляющие вышеуказанные недостатки. Отправил в рассылку.

Включил вышеописанные патчи в основной код etercifs. Выпустил 5.1.3 сборку для тестирования.

Обсудил с amorozov@ ситуацию с разблокированием.

Если у нас есть код вида:

fd = open(filename)
pid = fork()
if (pid == 0) {
  lock(fd)
} else {
  sleep(10)
  lock(fd)
}

то блокировка поставленная в дочернем процессе не снимется в текущей реализации.

Таким образом, любое приложение, запущенное вайн-приложением и установившее блокировки на унаследованный файл не сможет их снять, если не укажет снятие явно (вызовом unlock с тем же смещением и длиной блокировки) - то, есть завершение процесса, снятие блокировок со всей области файла(от 0 до бесконечности) работать не будет.

В связи с этим, решили откатить данное изменения для CIFS и WINE и добавить в последний предупреждающие сообщения при наличии пересекающихся блокировок на чтение от одного пида на одном файловом дескрипторе и нескольких файловых дескрипторах одного файла.

Собрал новую сборку 5.1.4 с учётом вышеописанного, исключив из неё патч fullmand (протестировал с помощью RECT и Connectathon test suite).

(В ответ на comment #15)
> Создал и протестировал три патча, исправляющие вышеуказанные недостатки.
> Отправил в рассылку.

Последний из трёх патчей принят в аптрим.

Переосмыслил первый, разбил второй на два и отправил в рассылку три новых патча.

(В ответ на comment #19)
> Переосмыслил первый, разбил второй на два и отправил в рассылку три новых
> патча.

Все три патча приняты в апстрим.

Создал патч с подробными описаними 4-х основных реализованных функий (test и add/set для mandatory и posix вариантов), логика работы которых нуждается в описании.

(В ответ на comment #20)
> Создал патч с подробными описаними 4-х основных реализованных функий (test и
> add/set для mandatory и posix вариантов), логика работы которых нуждается в
> описании.

Патч в апстрим.

(В ответ на comment #18)
> Собрал новую сборку 5.1.4 с учётом вышеописанного, исключив из неё патч
> fullmand (протестировал с помощью RECT и Connectathon test suite).

Тестирование сборки 5.1.4 прошло успешно: http://bugs.etersoft.ru/show_bug.cgi?id=7685#c23. Данный код войдёт в следующий релиз 5.2.0. Задача решена.

> В связи с этим, решили откатить данное изменения для CIFS и WINE и добавить в
> последний предупреждающие сообщения при наличии пересекающихся блокировок на
> чтение от одного пида на одном файловом дескрипторе и нескольких файловых
> дескрипторах одного файла.

Изменение убрал. Предупреждение пока не добавлял. Не очень понятно, относится оно только к CIFS или к остальным ФС тоже. Какая проблема возникает при установке пересекающихся блокировок на чтение?

(В ответ на comment #23)
> Изменение убрал. Предупреждение пока не добавлял. Не очень понятно, относится
> оно только к CIFS или к остальным ФС тоже. Какая проблема возникает при
> установке пересекающихся блокировок на чтение?

При наличии пересекающихся блокировок в связке CIFS+WINE возникают проблемы, связанные с тем, что CIFS не позволяет разбивать существующую блокировку. То есть вариант для POSIX файловых систем, когда у нас стоят блокировки (0,10) и (5,15), и мы, чтобы снять только первую, отправляем запрос снять (0,5), для CIFS не проходит из-за ограничений протокола.

Исправить это, не сломав принципы функционирования VFS, пока непонятно как. Поэтому, предлагаю в случае наличия пересекающихся блокировок от одного процесса (пусть и с нескольких файловых дескрипторов) выводить предупреждающее сообщение в случае CIFS.

Не очень понял, чем закончилось. Мы добавили предупреждение при пересекающихся блокировках?

Да, добавили.

(В ответ на comment #24)
...
> есть вариант для POSIX файловых систем, когда у нас стоят блокировки (0,10) и
> (5,15), и мы, чтобы снять только первую, отправляем запрос снять (0,5), для
> CIFS не проходит из-за ограничений протокола.
> 
> Исправить это, не сломав принципы функционирования VFS, пока непонятно как.
А нельзя снимать блокировку и ставить новую? Или ставить новую и снимать старую?
Возможно это стоит обсудить. Как-то же должна решаться задача совместимости с POSIX.

С другой стороны, если это Wine написан так, что использует подход разбиения блокировки, быть может стоит его код пересмотреть?

(В ответ на comment #27)
> (В ответ на comment #24)
> ...
> > есть вариант для POSIX файловых систем, когда у нас стоят блокировки (0,10) и
> > (5,15), и мы, чтобы снять только первую, отправляем запрос снять (0,5), для
> > CIFS не проходит из-за ограничений протокола.
> > 
> > Исправить это, не сломав принципы функционирования VFS, пока непонятно как.
> А нельзя снимать блокировку и ставить новую? Или ставить новую и снимать
> старую?
> Возможно это стоит обсудить. Как-то же должна решаться задача совместимости с
> POSIX.

Это будет неатомарно, поэтому смысла особого нет.

> 
> С другой стороны, если это Wine написан так, что использует подход разбиения
> блокировки, быть может стоит его код пересмотреть?

Wine написан основываясь на принципах функционирования VFS. Правильнее сделать так, как уже обсуждалось ранее: добавить в VFS специальный под-вызов FCNTL, который будет обрабатывать логику работы блокировок в стиле Windows. Но это отдельная большая задача.