Summary: | Shared flags to kernel | ||
---|---|---|---|
Product: | CIFS@Etersoft | Reporter: | Pavel Shilovsky <piastry> |
Component: | блокировки файлов и доступ | Assignee: | BUGS@Etersoft <bugs> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | normal | ||
Priority: | P4 | CC: | lav, piastry, sin |
Version: | не указана | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: | |||
Заявки RT: | Связано с: | 9650 | |
Дата напоминания: | |||
Deadline: | 2015-03-31 |
Description
Pavel Shilovsky
2008-10-30 10:36:44 MSK
Ну вот теперь осталось здесь записывать вехи движения к решению баги. На данный момент состояние следующее: было отправлено письмо Стиву Френчу лично и в рассылку linux-cifs-client@lists.samba.org по поводу результатов продвижения флагов. Ответа получено не было. Возобновил работу над багой. Подготовил и протестировал патчи для fcntl и cifs. Ссылки на переписку 2008 года: http://www.archivum.info/linux-fsdevel@vger.kernel.org/2008-11/00251/(PATCH-0-2)-Shared-flags.html http://www.kerneltrap.com/mailarchive/linux-fsdevel/2008/12/2/4289774 Рабочая ветка тут: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags Подготовил и отправил патчи в рассылки. Переотправил патчи включив в получатели linux-nfs и wine-deve рассылки. Переотправил, включив: 1) linux-cifs, 2) LKML, 3) linux-fsdevel, 4) wine-devel, 5) linux-nfs. Работал над письмом - ответом в LKML. Обновил вторую ссылку из http://bugs.etersoft.ru/show_bug.cgi?id=2771#c4, теперь: http://www.archivum.info/linux-fsdevel@vger.kernel.org/2008-12/00009/Support-for-applications-which-need-NFS-or-CIFS-quot-share_deny-quot-flags-on-open.html http://www.archivum.info/linux-fsdevel@vger.kernel.org/2008-11/00251/(PATCH-0-2)-Shared-flags.html Работал над письмом в LKML. Изучал полученные ответы, продумавал реализацию данного режима VFS и CIFS/NFS. (В ответ на comment #12) > Изучал полученные ответы, продумавал реализацию данного режима VFS и CIFS/NFS. В багу стоит дать ссылку на письмо (и тред) в lklm, а также привести (на русском) дайджест (краткий обзор) полученных ответов. Думаю, после обдумывания это возможно. Иначе по баге никогда не будет понятно, куда текла мысль. (В ответ на comment #13) > (В ответ на comment #12) > > Изучал полученные ответы, продумавал реализацию данного режима VFS и CIFS/NFS. > В багу стоит дать ссылку на письмо (и тред) в lklm, а также привести (на > русском) дайджест (краткий обзор) полученных ответов. Думаю, после обдумывания > это возможно. Иначе по баге никогда не будет понятно, куда текла мысль. И правда, забыл ссылку на обсуждение добавить - исправляюсь: https://lkml.org/lkml/2012/12/6/268 (тут как-то не сразу обновляется) http://comments.gmane.org/gmane.linux.kernel.cifs/7566 Краткий смысл ответов следующий: в основном, разработчики ядра хотят сделать эту фичу доступной и влияющей только на те процессы, которые этого хотят: wine, Samba и NFS сервера. Предлагаются различные варанты этого разграничения: дополнительные свойства процесса, LSM, опции монтирования, биты доступа, доработка уже существуюшего механизма LOCK_MAND вызова flock. Последний вариант пока выглядит наиболее предпочтительно. Продолжил работу над задачей. Наложил патч LOCK_MAND из обсуждения (https://lkml.org/lkml/diff/2012/12/11/177/1) на на текущее ядро в Sisyphus (3.6.10-alt1). Собрал ядро. Изучал API ядра относительно вызовов open и flock для внедрения механизма флагов доступа в VFS. Реализовал локальную поддержку флагов в VFS (используя дополнительный O_DENYMAND флаг в качестве индикатора - следует ли проводить проверки на флаги доступа или нет): http://git.altlinux.org/people/piastry/public/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-3.6.10 Работал над патчами. http://git.altlinux.org/people/piastry/public/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-alt Собрал новый RECT - 0.0.14-alt1 (исправил сборку на текущем Sisyphus + изменил параметры флагов доступа при CIFS.version=cifs для тестирования текущих патчей), протестировал патчи. Обсудил текущие патчи. В результате обсуждения сделаны следующие выводы: 1) Нужно оставить неизменным текущую семантику вызова flock. 2) Нужно добавить примеры использования данных флагов серверами NFS и Samba. (В ответ на comment #19) > Обсудил текущие патчи. В результате обсуждения сделаны следующие выводы: > 1) Нужно оставить неизменным текущую семантику вызова flock. В смысле? Не добавлять LOCK_MAND? > 2) Нужно добавить примеры использования данных флагов серверами NFS и Samba. Насчёт NFS понятно, но так ли нужно менять сервер Самбы, чтобы она начала транслировать все блокировки в локальную фС? (В ответ на comment #20) > (В ответ на comment #19) > > Обсудил текущие патчи. В результате обсуждения сделаны следующие выводы: > > 1) Нужно оставить неизменным текущую семантику вызова flock. > В смысле? Не добавлять LOCK_MAND? Он есть, но работает сейчас немного подругому - уже есть на это ориентированные приложения (например та же Samba), поэтому менять работу по умолчанию не стоит. Надо продумать механизм, как нам включать этот режим только для вызова open с O_DENYMAND, а не flock с LOCK_MAND. > > > 2) Нужно добавить примеры использования данных флагов серверами NFS и Samba. > Насчёт NFS понятно, но так ли нужно менять сервер Самбы, чтобы она начала > транслировать все блокировки в локальную фС? Да, причём чем больше мы приведём реальных примеров (именно в виде патчей для приложений), тем большая вероятность принятия этой опции в ядро. Польза для Samba следующая, как минимум: использование Samba + NFS сервера, раздающими одну и ту же директорию для Windows (Samba) и Linux (NFS) клиентов соответственно. Как в таком случае обеспечить корректность работы? Использование O_DENY флагов должно помочь. В результате, мы имеем не какую-то странную фичу, нужную для работы Wine, а достаточно широко используемый популярными Linux приложениями механизм работы ядра. Это совершенно меняет характер предложения. Сделал так, чтобы патчи не затрагивали семантику вызова flock. Протестировал с помощью RECT. http://git.altlinux.org/people/piastry/public/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-alt Работал над реализацией O_DENY* флагов в NFS сервере и клиенте. http://git.altlinux.org/people/piastry/public/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-alt2 Пересмотрел немного реализацию NFSD части. Исправил утечку памяти в предыдущих патчах. http://git.altlinux.org/people/piastry/public/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-alt3 Провёл рефакторинг рабочей ветки, сформировал патчи, собрал и протестировал получавшуюся сборку ядра. http://git.altlinux.org/people/piastry/public/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-alt Работал над патчем для Samba. http://git.altlinux.org/people/piastry/packages/?p=samba.git;a=shortlog;h=refs/heads/share-flags-alt Разбирался, почему на новой Samba4 не проходят все тесты RECT - выяснил, что проблема в порядке блокировок внутри кода сервера. Создал патч, исправляющий работы тестов. Залил в рабочую ветку. Исследовал проблему с Samba4, упомянутую выше, отправил патч в рассылку. Подготовил и отправил в рассылку патчи с флагами доступа: http://marc.info/?l=linux-kernel&m=135844155717622&w=2 (В ответ на comment #28) > Исследовал проблему с Samba4, упомянутую выше, отправил патч в рассылку. Создал багу в багзилла на bugzilla.samba.org с сетевым трэйсом: https://bugzilla.samba.org/show_bug.cgi?id=9571 (В ответ на comment #29) > (В ответ на comment #28) > > Исследовал проблему с Samba4, упомянутую выше, отправил патч в рассылку. > > Создал багу в багзилла на bugzilla.samba.org с сетевым трэйсом: > https://bugzilla.samba.org/show_bug.cgi?id=9571 Патч принят с незначительным изменением: в ветках v3-6-test, v4-0-test и master. Получил комментарии по патчам с флагами доступа. Составил небольшую документацию по использованию данных флагов. Занимался патчами - исправлял, собирал, тестировал. Разбирался проблему гонок за данными в предложенных патчах (VFS часть). Общался в рассылке на эту тему. Продолжил разбираться с проблемой гонок за данными, в результате которых, запрос на открытие файла с O_CREAT может завершиться с ошибкой, но файл будет успешно создан. Создал и протестировал патч, исправляющий эту проблему. Подготовил и отправил патчи в рассылку. Обновил актуальную ветку в репозитории: http://git.altlinux.org/people/piastry/public/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-alt Получил комментарии в рассылке. Предлагается всё же механизм дополнительного флага O_DENYMAND, заменить опцией монтирования на уровне VFS. Обсудил данную проблему с одним из разработчиков + разработал план дальнейших действий по продвижению патчей. Ответил в рассылку. Обсуждал ситуацию с floc LOCK_MAND в случае замены O_DENYMAND на опцию монтирования. Пока пришёл к мнению, что для файловых систем, смонтированных данной опцией, возможность вызовы flock LOCK_MAND надо отключать, так как данный вызов позволяет переписать блокировку общего доступа (DENY флаги), что не соотвествует требуемой семантике флагов. Работал над опцией монтирования для VFS. Делал необходимые изменения в патчах. Продолжил работу над задачей: убрал возможность flock/LOCK_MAND при опции монтирования sharelock, убрал дублирование блокировок локально, если они установлены сетевыми ФС, провёл рефакторинг кода, протестировал. Обнаружил и исправил ошибки в патче для модуля NFS. Модифицировал демонстрационный патч для Samba. Протестировал, подготовил патчи и отправил в рассылку (http://marc.info/?l=linux-kernel&m=136518085830490&w=2). Учёл полученный комментарий по поводу механизма определения поддержки флагов доступа файловой системой. Исправил, протестировал, подготовил патчи и отправил. Исправлял и обсуждал патчи: 1) добавил новый код возврата для вызова open в случае, если текущие флагми доступа других файловых дескрипторов не позволяют открыть файл. 2) обсудил вопрос о O_DENYDELETE в VFS и NFS. Для данного флага возможна реализация в VFS. В случае NFS поддержка может быть только локальной - опять же через VFS; 3) исправил патч для CIFS - теперь не требуется указывать дополнительную опцию монтирования forcemand для включения поддержки флагов доступа при работе с сервером Samba; 4) начал реализацию O_DENYDELETE в VFS. (В ответ на comment #42) > 4) начал реализацию O_DENYDELETE в VFS. Доработал данный патч и протестировал. Начал подготавливать патчи для отправки в рассылку. (В ответ на comment #43) > (В ответ на comment #42) > > 4) начал реализацию O_DENYDELETE в VFS. > > Доработал данный патч и протестировал. Начал подготавливать патчи для отправки > в рассылку. Подготовил патчи, протестировал, отправил в рассылку (версия 6). Основные изменения с версии 5: 1) O_DENYDELETE теперь поддерживается VFS. 2) Добавлен новый код ошибки ESHAREDENIED, обозначающий конфликт флагов доступа. 3) Удалена зависимость от опции forcemand. CIFS модуль теперь определяет использовать ли ему команду открытия файла NTCreateAndX из наличия или отсутствия O_DENY флагов. 4) Термин 'deny lock' заменён 'sharelock' (имена функция, комментарии в коде, описания патчей). (В ответ на comment #44) > Подготовил патчи, протестировал, отправил в рассылку (версия 6). > Основные изменения с версии 5: > 1) O_DENYDELETE теперь поддерживается VFS. > 2) Добавлен новый код ошибки ESHAREDENIED, обозначающий конфликт флагов > доступа. > 3) Удалена зависимость от опции forcemand. CIFS модуль теперь определяет > использовать ли ему команду открытия файла NTCreateAndX из наличия или > отсутствия O_DENY флагов. > 4) Термин 'deny lock' заменён 'sharelock' (имена функция, комментарии в коде, > описания патчей). Ссылка на патчи: https://lkml.org/lkml/2013/4/26/242 Наложил патчи на ядро v3.9.8. Исправил ошибку в патче 2. Собрал и протестировал. Немного переосмыслил патч 1: данный патч модифицирует функцию do_last, которая используется всеми файловыми системами, поэтому нужно изменить патч так, чтобы для ФС смонтированных без sharelock поведение оставалось прежним. Далее займусь данным патчем. Переработал патч 1, протестировал. Подготовил патчи и отправил в рассылку. Ссылка на первый патч (из семи): https://patchwork.kernel.org/patch/2808791/ Подготовил инфраструктуру для работы над патчами на убунту на ноутбуке. Собрал пакеты ядра из асптрим cifs-2.6 (v3.13-rc4). Работал над патчами. Смержил первые два + переделал третий. Далее решено разбить третий патч на части ввиду его большого размера ( 8 files changed, 305 insertions(+), 217 deletions(-)). Рабочая ветка тут: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/share-flags-cur Разобрал третий часть на части, провёл дополнительную подготовку кода к добавлению флагов. Смержил остальные патчи. Собрал и протестировал работу CIFS. В итоге, сейчас получается подготовительных патча (которые можно отправить отдельно) и 6 патчей с флагами. (В ответ на comment #50) > В итоге, сейчас получается подготовительных патча (которые можно отправить > отдельно) и 6 патчей с флагами. 4 подготовительных Протестировал патчи VFS - использовалась XFS. Занимался дальнейшим тестированием патчей. Протестировал патчи NFS клиента - не работают проверки при открытии двух дексрипторов через одну шару (как и ранее). Разбирался с этой проблемой. Разбирался с устройством NFS клиента, его архитектры. Изучал особенности протовола NFS4 в плане работы с флагами доступа при открытии файла. Создал предварительную версию патча для NFS. Пока при закрытии сбрасываются все флаги. Добавил возможность обрабатывать флаги при закрытии файлов. Пересобрал ядро, протестировал. Обнаружил ошибку в патче связанную с возвращением EOPENSTALE в open, что приводило к ошибки размонтирования. Изучал работу NFS4 протокола с оплоками (delegations) и как они влияют на открытие файлов с флагами доступа. Ядерный клиент может кэшировать операции открытия и закрытия файлов, то есть требуется локальная обработка данных операций и проверок на флаги доступа. В результате патч для NFS4 был доработан с учётом данных возможностей и протестирован. Тестировал патчи и обнаружил ошибку при сбросе оплока в NFS патче. В результате исследования выяснилось, что ошибка основана на неправильном толковании спецификации - требуются дополнительные исследования работы протокола при сбросе оплока, разрыве связи и перезагрузке сервера. (В ответ на comment #58) > Тестировал патчи и обнаружил ошибку при сбросе оплока в NFS патче. В > результате исследования выяснилось, что ошибка основана на неправильном > толковании спецификации - требуются дополнительные исследования работы > протокола при сбросе оплока, разрыве связи и перезагрузке сервера. Исследовал NFS протокол в вышеназванных ситуациях. Получается следующее: 1) при сбросе оплока, клиент должен отправить на сервер все изменения в состояние открытого файла (режиме доступа + флаги), обработанные локально. 2) при разрыве связи или перезагрузке сервера, клиенту требуется восстановить все открытые файловые дескрипторы. В связи с этим решено было сохранять количество файловых дексрипторов каждого типа (доступ + флаги) - всего 12 дескрипторов. Текущий код был немного переработан для наиболее удобной обработки данного количества дексрипторов (12 вместо 7 ранее). Текущий вариант в гит содержит различные сообщения и sleep, которые требуется выкинуть после окончательного тестирования. Протестировал NFS патчи, убрал все дебаг сообщения и sleep, провёл рефакторинг кода, смержил патчи в один большой NFS патч. Отправил подготовительные CIFS патчи в рассылку. Подготовил и отправил остальные патчи в рассылку. Разбирался с вопросами, поступившими на патчи. Продолжил обсуждение патчей в рассылке. Изучил вопрос перемонтирования с политик доступа для пользователя root. (В ответ на comment #63) > Продолжил обсуждение патчей в рассылке. Кидай ссылку. (В ответ на comment #64) > (В ответ на comment #63) > > Продолжил обсуждение патчей в рассылке. > Кидай ссылку. http://thread.gmane.org/gmane.linux.nfs/60931 https://lkml.org/lkml/2014/1/17/427 По совещанию с lav@ было отправлено 3 письма: 1) в linux-kernel с копией Al Viro (VFS мэйнтейнер) и Bruce Fields (Red Hat); 2) лично Steve French (IBM), Jeff Laython (Red Hat) and Sachin Prabhu (Red Hat); 3) в devel@ альта с копией Боковому и Левину. Получил ответы в рассылке. Выяснилось, что попутно с добавлением флагов целесообразно решить проблему вызова open: неподдерживаемые флаги игнорируются файловой системой без генерирования ошибки, что ведёт к возможному неадекватному поведению приложений на более старых ядрах. Было предложено добавить новый вызов openat2(), который будет проверять наличие поддержки в ядре для указанного флага и генерировать ошибку, если флаг не известен. В данном вызове можно увеличить поле флагов или сделать расширяемый список параметров, а также добавить новые флаги. Так же было предложено разбить патч №1 на два: а) исправляет работу flock+LOCK_MAND для разделов, смонтированных с 'sharelock'. б) добавляет флаги O_DENYREAD и O_DENYWRITE и их обработку в open. O_DENYDELETE следует перенести в патч №2. Откладываем задачи, к которым не обращались более 100 дней. Добавил страницу на вики с описанием текущего состояния дел http://wiki.etersoft.ru/Etercifs/shareflags. Поправил основную страницу http://wiki.etersoft.ru/Etercifs. |