Summary: | Зависает при использовании с aufs2-util-ng и новыми ядрами | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Michael Pozhidaev <msp> |
Component: | aufs2-util-ng | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | major | ||
Priority: | P3 | CC: | aen, aspsk, boyarsh, evg, gns, radik, stanv, zerg |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Michael Pozhidaev
2010-11-23 10:52:49 MSK
C 2.6.35-std-def-alt9 осталось старое поведение. То же самое могу сказать и про un-def-2.6.37-alt1 может быть проблема в самих aufs2-util-ng ? Николай, а у Вас aufs работает хоть с каким-то ядром? (In reply to comment #3) > Николай, а у Вас aufs работает хоть с каким-то ядром? До последнего времени было std-ng, сейчас pure-emerald (2.6.38rc5 с втянутым aufs). Отлично работают aufs-util-ng. В aufs2-util-ng надо добавить коммит: commit 89d08d339fe3efcad1e2da2f5e2103824630e13f Author: J. R. Okajima <hooanon05@yahoo.co.jp> Date: Fri Jan 7 10:44:27 2011 +0900 bugfix, O_CLOEXEC for the plink maintenance mode /sbin/mount.aufs (and others) puts aufs into the plink maintenance mode via /proc/fs/aufs/plink_maint which make many other operations to return error or block. During in this mode, /sbin/mount.aufs exec(2) the original mount(8). If mount(8) is not statically linked, it may mmap(2) ld.so (and others). And if ld.so is inside of the target aufs, then aufs mmap(2) blocks, ie. deadlock. To address this problem, specify O_CLOEXEC for /proc/fs/aufs/plink_maint which makes aufs to exit the plink maintenance mode. Reported-by: Marco Clocchiatti <ziapannocchia@gmail.com> Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp> Без него remount_rw виснет по крайней мере на un-def и std-def (В ответ на комментарий №5)
> Без него remount_rw виснет по крайней мере на un-def и std-def
А с ним, соответственно, не виснет.
Ok. Сегодня сделаю. #39142 AWAITING #1 [test-only] sisyphus aufs2.1.git=2.1-alt2.git0f0cf3f (In reply to comment #6) > (В ответ на комментарий №5) > > > Без него remount_rw виснет по крайней мере на un-def и std-def > А с ним, соответственно, не виснет. Проверьте пожалуйста с http://git.altlinux.org/tasks/39142/ (В ответ на комментарий №9) > > > Без него remount_rw виснет по крайней мере на un-def и std-def > > А с ним, соответственно, не виснет. > > Проверьте пожалуйста с http://git.altlinux.org/tasks/39142/ Работает, спасибо! (In reply to comment #10) > (В ответ на комментарий №9) > > > > > Без него remount_rw виснет по крайней мере на un-def и std-def > > > А с ним, соответственно, не виснет. > > > > Проверьте пожалуйста с http://git.altlinux.org/tasks/39142/ > Работает, спасибо! Ok, закоммитил в сизиф. А у нас остались ещё ядра, на которых работает старый aufs2-util? (В ответ на комментарий №11) > (In reply to comment #10) > А у нас остались ещё ядра, на которых работает старый aufs2-util? el-smp. Сейчас aspsk пытается перевести его на новый aufs2-util. Как только, так сразу.
> el-smp. Сейчас aspsk пытается перевести его на новый aufs2-util.
> Как только, так сразу.
В el-smp со вчерашнего дня aufs2.1
Ну, тогда можно текушее содержимое aufs2-util-ng просто собрать под именем aufs2-util без всяких obsolete/provide. Давайте дружно попросим stanv дать NMU. (В ответ на комментарий №14) > Ну, тогда можно текушее содержимое aufs2-util-ng просто собрать под именем > aufs2-util без всяких obsolete/provide. > > Давайте дружно попросим stanv дать NMU. > ssh git.alt acl sisyphus aufs2-util show aufs2-util stanv @everybody (В ответ на комментарий №14) > без всяких obsolete/provide. Почему? (In reply to comment #16) > (В ответ на комментарий №14) > > без всяких obsolete/provide. > Почему? Зачем? (В ответ на комментарий №17)
> > Почему?
> Зачем?
Что зачем? "Почему?"? ;-)
|