Bug 20694 - Некорректно работают POSIX-блокировки
Summary: Некорректно работают POSIX-блокировки
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-std-def (show other bugs)
Version: unstable
Hardware: all Linux
: P3 major
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-06 19:44 MSD by Alexander Morozov
Modified: 2011-01-05 12:19 MSK (History)
6 users (show)

See Also:


Attachments
Программы для воспроизведения проблемы (1.03 KB, application/x-tbz)
2009-07-06 19:44 MSD, Alexander Morozov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Morozov 2009-07-06 19:44:50 MSD
Created attachment 3644 [details]
Программы для воспроизведения проблемы

1-я машина:
Linux lav.office.etersoft.ru 2.6.30-std-def-alt1 #1 SMP Thu Jun 25 07:23:18 UTC 2009 i686 GNU/Linux

2-я машина:
Linux atlant.office.etersoft.ru 2.6.30-std-def-alt3 #1 SMP Sat Jul 4 07:09:22 UTC 2009 i686 GNU/Linux

На 2-й машине монтируется директория по nfs:
# mount -t nfs lav:/net/exports/test /mnt/test

На 1-й машине устанавливаем read-блокировку:
$ ./linlock r test_file
press Ctrl-C...

На 2-й машине пытаемся установить write-блокировку:
$ ./linlock w test_file
fcntl: Resource temporarily unavailable
Всё как и должно быть.
Но при этом F_GETLK говорит, что ничего не должно мешать поставить write-блокировку:
$ ./lockinfo test_file
F_UNLCK SEEK_SET start 0 len 0

Если устанавливать read-блокировку на 2-й машине, то на 1-й она с помощью F_GETLK видна.

linlock и lockinfo в аттаче.
Comment 1 Michail Yakushin 2010-07-08 12:42:14 MSD
буду думать.
А в инете на тему пишут?
Вопрос кстати, там надеюсь lockd запущен везде?
Comment 2 Alexander Morozov 2010-07-09 15:47:28 MSD
> А в инете на тему пишут?
Не видел.

> Вопрос кстати, там надеюсь lockd запущен везде?
Повторил эксперимент. Проверил, что lockd присутствует в списке, выдаваемом ps aux. В этот раз 1-й машина:
Linux altlinux.lin-test 2.6.32-std-def-alt16 #1 SMP Tue Jul 6 22:29:03 UTC 2010 i686 GNU/Linux
2-я машина:
Linux atlant.office.etersoft.ru 2.6.32-std-def-alt15 #1 SMP Wed Jun 23 15:13:44 UTC 2010 i686 GNU/Linux
Всё по-прежнему.
Comment 3 Vitaly Lipatov 2010-07-10 00:46:14 MSD
Возможно, стоит проверить на Ubuntu или CentOS.

2piastry: возьмёшься подтвердить ситуацию, и, быть может, обсудить в lkml, вплоть до исправляющего патча.
Comment 4 Alexander Morozov 2010-11-28 18:03:45 MSK
Выяснил, что проблема появилась между 2.6.21 и 2.6.22-rc1, а также то, что баг зависит только от версии ядра на клиентской стороне.
Создал баг в багзилле ядра:
https://bugzilla.kernel.org/show_bug.cgi?id=23892
Comment 5 Vitaly Lipatov 2010-11-29 21:10:12 MSK
Кстати, лучше всего проверить наличие всего необходимого в выводе
# rpcinfo -p localhost

У меня иногда не хватало nlockmgr при всём запущенном.
Comment 6 Pavel Shilovsky 2010-11-29 22:03:11 MSK
http://lxr.free-electrons.com/source/fs/lockd/clntproc.c?a=m68knommu#L439

Вот тут мы явно выставляем его в ноль. Что довольно странно. Напрашивается:

fl->fl_pid = req->a_res.lock.fl.fl_pid.
Comment 7 Pavel Shilovsky 2010-12-20 22:54:31 MSK
Патч, решающий багу добавлен в 32 и 33 ядра. Так же он уже в upstream разработчика NFS клиента ядра.
Comment 8 Vitaly Lipatov 2010-12-21 16:25:28 MSK
(В ответ на комментарий №7)
> Патч, решающий багу добавлен в 32 и 33 ядра. Так же он уже в upstream
> разработчика NFS клиента ядра.
Идёт ли речь о ядрах в Сизифе? В любом случае, как я понимаю, есть более точная адресация для ядер (вида 2.6.33.X).
Comment 9 Pavel Shilovsky 2010-12-23 09:46:56 MSK
Так. Цифру 33 следует читать как 36 :)
Патч добавлен в очередь, из которой патчится stable релизы.
В долгоподдерживаемое 32 ядро тут:
http://git.kernel.org/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=commitdiff;h=3858761cadee2b9bbb19695a33ec6dcd2f496b87
В текущее стабильное 36 ядро тут:
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=commit;h=0c2956ff492e99e11a95ddcdae84054a85971590
В какой номер релиза этих ядер войдёт патч - неизвестно. Так же следует ожидать его в грядущем 38 ядре.
Comment 10 Pavel Shilovsky 2010-12-23 10:15:58 MSK
Так же судя по:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21ac19d484a8ffb66f64487846c8d53afef04d2b
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=38971ce2fac484249d697fe48a9b0851a0b62572
патч уже в основной ветке. Самый первый таг после этих коммитов - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tag;h=refs/tags/v2.6.37-rc7

То есть, начиная с 2.6.37-rc7, патч уже в ядре.
Comment 11 Pavel Shilovsky 2011-01-05 12:19:24 MSK
(В ответ на комментарий №9)
...
> В какой номер релиза этих ядер войдёт патч - неизвестно. Так же следует ожидать
> его в грядущем 38 ядре.
37 ядре.