19313 2009-03-24 18:03:01 +0300 Не срабатывает правило для udev 2009-06-03 18:54:57 +0400 1 1 4 Development Sisyphus ifrename unstable all Linux CLOSED FIXED P2 critical --- 1 rider placeholder aen boyarsh cas glebfm inger ldv mike placeholder rider shrek silicium vitty vsu vt vvk qa-sisyphus oldest_to_newest 87837 0 rider 2009-03-24 18:03:01 +0300 $ cat /etc/iftab eth0 mac 00:07:e9:0a:46:72 eth1 mac 00:0e:a6:5c:01:a0 После загрузки имеем eth1 и eth2 87839 1 rider 2009-03-24 18:17:03 +0300 Обновление версии ifrename не помогает. Смену ядра - не пробовал (сейчас alt14 из branch/5.0). Валера, а udev тут может как-то зафиксить этот вопрос ? запускать ifrename только тогда, когда поток сетевых интерфейсов иссякнет ? 87840 2 legion 2009-03-24 18:21:55 +0300 Кажется такое невозможно. 87856 3 shrek 2009-03-24 21:32:09 +0300 переименовывай во что нибудь отличное от ethX. других бесграбельных вариантов нет 87881 4 rider 2009-03-25 09:37:49 +0300 Это к Стасу в alterator-network. Впрочем, /etc/net/iftab сейчас тоже сломан, но там уже есть работающий патч: https://bugzilla.altlinux.org/show_bug.cgi?id=11786 87884 5 rider 2009-03-25 10:28:23 +0300 Получил лог (ifrename --verbose) в момент некорректного переименовывания. Вот что происходит: --------запуск для eth1, идет перед eth0 в логе!!! ----------- Parsing : Added Mapping `eth0' from line 1. Parsing : Added exact MAC address `00:07:e9:0a:46:72' from line 1. Parsing : Added Mapping `eth1' from line 2. Parsing : Added exact MAC address `00:0e:a6:5c:01:a0' from line 2. Querying eth0 : Got MAC address `00:0E:A6:5C:01:A0' and ARP/Link Type `1'. Takeover : moving interface `eth1' to `eth%d'. ------------------- Запуск номер 2 в логе: ------------------- Parsing : Added Mapping `eth0' from line 1. Parsing : Added exact MAC address `00:07:e9:0a:46:72' from line 1. Parsing : Added Mapping `eth1' from line 2. Parsing : Added exact MAC address `00:0e:a6:5c:01:a0' from line 2. Querying eth1 : Got MAC address `00:0E:A6:5C:01:A0' and ARP/Link Type `1'. Setting : Interface `eth1' already matches `eth1'. Error: cannot change name of eth0 to eth1: No such device -------------------- Последний Error, по ощущением - от первого запуска ifrename. Собственно вопрос: - почему пришло уведомление сначала об eth1, потом об eth0 ? Ну и что произошло, на русском: - пришло уведомление о том, что появился интерфейс eth1, udev вызвает ifrename, который, пытаясь поменять eth1 на eth0 обнаруживает наличие eth0, меняет eth1 на eth2 (%d - это просто следующий свободный номер в ядре), и пытается eth0 переименовать в eth1. В это время, параллельно, другой процесс ifrename пытается так же eth0 перереименовать в eth1. Тут где-то засада и порылась. Видимо, кто-то из них успевает первее... и обламывается тот, который делал takeover в первом процессе, оставляя бывший eth1 как eth2. При этом eth0 у нас успешно переименован в eth1, и на выходе мы можем наблюдать наличие двух интерфейсов - eth1 и eth2. Вопрос - как чинить ? Идеи есть ? Сделать блокировку ? если запускается процесс takeover, то другой процесс ifrename ни в коем случае не должен трогать интерфейсы, для которых выполняется переименование... впрочем, видимо, это будет полезно и в других случаях. 87885 6 legion 2009-03-25 10:41:47 +0300 (В ответ на комментарий №5) > Ну и что произошло, на русском: > - пришло уведомление о том, что появился интерфейс eth1, udev вызвает ifrename, > который, пытаясь поменять eth1 на eth0 обнаруживает наличие eth0, меняет eth1 > на eth2 (%d - это просто следующий свободный номер в ядре), и пытается eth0 > переименовать в eth1. Насколько я понимаю ifrename -u не меняет интерфейсы, он лишь говорит udev какое имя присвоить устройству... Правда, большой разницы это не делает в данном случае. > Сделать блокировку ? если запускается процесс takeover, то другой процесс > ifrename ни в коем случае не должен трогать интерфейсы, для которых выполняется > переименование... впрочем, видимо, это будет полезно и в других случаях. Нужно не вызывать ifrename напрямую из правила, а сделать скрипт-обёртку с блокировкой. Благо место для файловой блокировки есть. Из того что ты нашёл следует, что эта проблема не зависит от #14837. Это рейс ifrename. 87886 7 legion 2009-03-25 10:51:56 +0300 Внезапно выяснил, что мантейнер пакета не legion, а george. Тогда ему и решать эти проблемы. Assign => george@ 87887 8 rider 2009-03-25 10:52:08 +0300 Судя по коду в ядре - в качестве блокировки интерфейса от смены имени - можно говорить ему IFF_UP (т.е. - выставлять флаг в UP). По поводу флага -u у ifrename - он влияет только на вывод, не более того. Вообще, я не знаю, зачем udev'у нужна эта информация от ifrename - реально имя интерфейсу меняет ifrename, а не udev. И да, эта проблема - race в связке udev/ядра/ifrename. Про это было сразу понятно. 87888 9 rider 2009-03-25 10:54:10 +0300 Добавлю, что проблема воспроизводится на 5.0, а наши средства настройки активно используют /etc/iftab для привязки интерфейсов к мак-адресам. Соответственно, со всеми вытекающими последствиями в дистрибутивах. 87890 10 legion 2009-03-25 11:02:26 +0300 Антон, не меняй пожалуйста атрибуты бага без комментариев. Я больше не мантейнер этого пакета. $ ssh git.alt acl sisyphus wireless-tools show wireless-tools ldv george $ rpmquery -p --lastchange --qf='%{packager}\n' ifrename-29-alt3.i586.rpm |sed -n 's/.*<\([^@]\+@\).*/\1/p' |uniq george@ 87891 11 rider 2009-03-25 11:05:57 +0300 гм. я ничего специально не менял. 87903 12 legion 2009-03-25 13:57:54 +0300 (В ответ на комментарий №11) > гм. я ничего специально не менял. Я знаю. 87904 13 3394 legion 2009-03-25 14:00:54 +0300 Created attachment 3394 ifrename-alt-lockfile.patch На месте мантейнера, я не стал бы делать никаких скриптов, а добавил блокировку на конфигурационный файл. Как, например, в этом патче. 87993 14 ldv 2009-03-26 15:39:52 +0300 (In reply to comment #13) > Created an attachment (id=3394) [details] > ifrename-alt-lockfile.patch > > На месте мантейнера, я не стал бы делать никаких скриптов, а добавил блокировку > на конфигурационный файл. Как, например, в этом патче. Спасибо, собрал 29-alt4 с этим патчем. 88071 15 rider 2009-03-27 09:33:56 +0300 Спасибо, всё работает отлично! 88122 16 vsu 2009-03-27 15:28:35 +0300 На самом деле то, что сейчас сделано в пакете ifrename, работать не должно, и по-прежнему работает только при наличии достаточного везения. Во-первых, в /etc/udev/rules.d/19-udev-ifrename.rules сейчас содержится SUBSYSTEM=="net", ACTION=="add", PROGRAM="/sbin/ifrename -u -t -i %k", NAME="%k" Это правило неверное - предполагалось, что ifrename -u будет вызываться не через PROGRAM, а через IMPORT. Для программ, вызываемых через PROGRAM, udevd сохраняет вывод для использования в последующих подстановках "%c"; поскольку "%c" в данном правиле нет, вывод ifrename -u просто теряется. Формат вывода ifrename -u разработан именно для использования в IMPORT: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/HOTPLUG-UDEV.txt Потеря вывода приводит к тому, что udevd не получает информации о новом имени интерфейса, в результате старое (уже неверное) имя интерфейса сохраняется в базе udev и передаётся в hald. Во-вторых, даже замена PROGRAM на IMPORT и добавление блокировок в ifrename не устраняет race при переименовании нескольких интерфейсов - блокировка просто уменьшает вероятность проявления проблемы. Надёжная работа правила с IMPORT="/sbin/ifrename -u -i %k" возможна только при отсутствии в этом правиле опции -t. При наличии опции -t ifrename переименовывает не только интерфейс, указанный в командной строке, но и интерфейс, занимающий имя, которое должно быть назначено обрабатываемому; если событие для этого мешающего интерфейса в этот момент обрабатывается udevd (или находится в очереди), оно будет обработано неверно (скорее всего, вообще не будет обработано, поскольку при обработке старого имени второго интерфейса ifrename обнаружит под этим именем уже переименованный первый интерфейс, для которого больше ничего делать не нужно). Корректное с точки зрения udev правило должно выглядеть так: SUBSYSTEM=="net", ACTION=="add", PROGRAM="/sbin/ifrename -D -i %k", NAME="%c" (или NAME:="%c", если результат этого переименования нужно объявить окончательным, чтобы последующие правила на него не влияли). В этом случае ifrename только определяет имя, которое должно быть назначено интерфейсу, и сообщает его процессу udevd, а само переименование выполняется udevd, причём без промежуточного изменения имён для других интерфейсов (благодаря чему оно не может помешать параллельной обработке переименования других интерфейсов, если только им не назначены имена вида *_rename - такие имена использовать нельзя). Правда, появляется другое ограничение - правила udevd для переименования интерфейсов (не обязательно только это правило - могут быть другие правила, переустанавливающие NAME) должны обязательно устанавливать несовпадающие имена для всех интерфейсов; если для какого-то интерфейса нет правила, и назначенное ему по умолчанию имя мешает какому-то другому интерфейсу, оба интерфейса не будут переименованы. На этот случай можно добавить дополнительную проверку: если при вызове ifrename -D -i %k в iftab не найдено подходящее имя для интерфейса, и при этом текущее имя интерфейса присутствует в iftab в качестве назначенного для одного из интерфейсов, переименовать интерфейс, сохранив базовое имя и выбрав любой не занятый в данный момент номер (причём номер не должен быть занят как в ядре, так и в iftab, так что просто переименование в eth%d не годится). Также нельзя использовать в iftab имена с '*' в конце (разве что вынести их обработку на второй шаг). 88127 17 rider 2009-03-27 15:47:56 +0300 Сергей, т.е. - коротко говоря: идея привязывать eth0 и eth1 к мак-адресам посредством вызова ifrename из udev - неверна в корне, и проблемы будут вылезать в любом случае. Возможен только один вид использования ifrename - это смена имени интерфейса на уникальное, никому не принадлежащее. Т.е. - возвращаемся к тому, что немешало-бы научить alterator-network менять имена для интерфейсов. 88129 18 legion 2009-03-27 15:57:48 +0300 (В ответ на комментарий №16) > Это правило неверное - предполагалось, что ifrename -u будет вызываться не > через PROGRAM, а через IMPORT. Кстати, родное правило в wireless-tools выглядит так: SUBSYSTEM=="net", ACTION=="add", IMPORT="/sbin/ifrename -u -i %k", NAME:="%k" 88215 19 ldv 2009-03-29 04:17:58 +0400 Нет, race недостаточно выиграть, race надо исправить. 88255 20 legion 2009-03-29 17:52:47 +0400 (В ответ на комментарий №19) > Нет, race недостаточно выиграть, race надо исправить. Зачем ты выложил этот пакет с этим неправильным патчем ? 88273 21 ldv 2009-03-29 19:56:49 +0400 (In reply to comment #20) > (В ответ на комментарий №19) > > Нет, race недостаточно выиграть, race надо исправить. > > Зачем ты выложил этот пакет с этим неправильным патчем ? Я не считаю выложенный патч неправильным, я считаю его недостаточным. 88274 22 rider 2009-03-29 19:58:36 +0400 ну, если уж исходить с точки зрения пользователя - то по крайней мере у меня этот пакет с недостаточным патчем заработал. Чудом, да.. кто-нить сможет написать testcase для ifrename ? ;) 88275 23 mike 2009-03-29 20:11:57 +0400 (In reply to comment #3) > переименовывай во что нибудь отличное от ethX. > других бесграбельных вариантов нет Этот тоже грабельный -- в обсуждениях проблемы упоминали разный софт (открытый и закрытый), закладывающийся именно на ethX. 88276 24 rider 2009-03-29 20:15:00 +0400 Софт, закладывающийся на eth* умрёт в любом случае - есть же ещё br0, wlan0, tap0 и т.д. 88357 25 george 2009-03-31 00:59:35 +0400 (В ответ на комментарий №7) > Внезапно выяснил, что мантейнер пакета не legion, а george. Тогда ему и решать > эти проблемы. > > Assign => george@ Без меня меня женили. Каким образом я угодил в майнтейнеры этого пакета. Я один раз исправлял trivial (как казалось) баг в 4.1, добавил takeover. Без takeover наши дистрибутивы прямо из коробки работали с вероятностью 50% неправильно. Фиксить надо было, как обычно, "вчера". А исправление в 4.1 невозможно без исправления в Сизифе. Вот и помогай после этого людям. 88532 26 mike 2009-04-01 23:07:47 +0400 (In reply to comment #25) > > Внезапно выяснил, что мантейнер пакета не legion, а george. > Без меня меня женили. [...] Вот и помогай после этого людям. Мужики, не кипятитесь. Если бы это была единственная проблема с обязательными ACL и автоназначением кого попало, всё было бы ещё хорошо. Насколько мне не нравится вседозволенность в виде @nobody by default -- всё-таки за неимением _адекватного_ механизма это меньшая плата за хорошие отношения. 88943 27 rider 2009-04-08 10:05:52 +0400 Протестировал по просьбе Legion'а wireless-tools отсуда: http://git.altlinux.org/people/legion/packages/wireless-tools.git?p=wireless-tools.git;a=tree;h=refs/heads/19313-try-1;hb=19313-try-1 У меня работают. Патча с блокировками там нет, интерфейсы переименовываются и так и эдак (20 перезагрузок). 89038 28 boyarsh 2009-04-09 18:01:56 +0400 > У меня работают. Патча с блокировками там нет, интерфейсы переименовываются и > так и эдак (20 перезагрузок). А если так, то что нам мешает получить его в Сизифе? 91912 29 boyarsh 2009-05-27 13:43:20 +0400 Так или иначе, проблема продолжает наблюдаться. Например, сегодня, после установки office-server на ham1, после установки на нём наблюдались интерфейсы eth0, breth0 (сконфигурированный и работающий) и eth2 (несконфигурированный и неработающий). При наличии конфигурации для eth1/breth1. Средств исправить это через web интерфейс я не знаю. 92011 30 repository-robot 2009-05-28 15:04:24 +0400 wireless-tools-29-alt5 -> sisyphus: * Thu May 28 2009 Dmitry V. Levin <ldv@altlinux> 29-alt5 - Added udev-ifrename helper, updated udev rule (by Alexey Gladkov; closes: #19313). - ifrename: Removed no longer needed configuration file locking introduced in previous build. 92012 31 legion 2009-05-28 15:11:32 +0400 (В ответ на комментарий №30) > - Added udev-ifrename helper, updated udev rule > (by Alexey Gladkov; closes: #19313). Вот только это не полное решение проблемы. 92026 32 ldv 2009-05-28 17:05:48 +0400 (In reply to comment #31) > (В ответ на комментарий №30) > > - Added udev-ifrename helper, updated udev rule > > (by Alexey Gladkov; closes: #19313). > > Вот только это не полное решение проблемы. Зато оно ближе к полному решению. 92029 33 legion 2009-05-28 17:15:48 +0400 > Зато оно ближе к полному решению. Я рад, что новых мантейнеров устраивает это временное решение. Настоящее же решение может быть совсем не в ifrename, а в udev. Как вариант: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/rule_generator/write_net_rules;h=cb346757cc40050e034dada01224f4fc0790629b;hb=a29b30b4115db16035998c551117685d8152a496 92062 34 boyarsh 2009-05-29 12:15:35 +0400 Теперь breth1 превратился в неработающий breth1_rename 92096 35 ldv 2009-05-30 02:15:31 +0400 (In reply to comment #34) > Теперь breth1 превратился в неработающий breth1_rename Зачем в /etc/iftab указан breth1? Нечего ему там делать! 92213 36 boyarsh 2009-06-01 14:28:26 +0400 > > Теперь breth1 превратился в неработающий breth1_rename > Зачем в /etc/iftab указан breth1? Нечего ему там делать! А его там нет. Только eth0 и eth1 Ну и по прежнему не работает.. 92219 37 ldv 2009-06-01 14:41:07 +0400 (In reply to comment #36) > > > Теперь breth1 превратился в неработающий breth1_rename > > Зачем в /etc/iftab указан breth1? Нечего ему там делать! > А его там нет. Только eth0 и eth1 > > Ну и по прежнему не работает.. Оно, очевидно, пытается переименовать breth1 в eth1, поскольку у них одинаковый mac, а eth1 внесён в /etc/iftab. Есть ли в iftab(5) какая-нибудь характеристика, по которой можно было бы наверняка отличить eth1 и от eth0, и от breth1? 92222 38 shrek 2009-06-01 14:49:44 +0400 SYSFS{type} у физических интерфейсов он равен 1 92224 39 ldv 2009-06-01 15:03:08 +0400 (In reply to comment #37) > Есть ли в iftab(5) какая-нибудь характеристика, по которой можно было бы > наверняка отличить eth1 и от eth0, и от breth1? В качестве быстрого хака могу заменить в installer-feature-eth-by-mac-stage2 mac на bus. 92225 40 shrek 2009-06-01 15:10:33 +0400 не надо хаков. запись для физического интерфейса должна выглядеть следующим образом: ethX SYSFS{address} 00:1d:e0:b2:f0:5d SYSFS{type} 1 92226 41 ldv 2009-06-01 15:30:05 +0400 (In reply to comment #40) > не надо хаков. запись для физического интерфейса должна выглядеть следующим > образом: > ethX SYSFS{address} 00:1d:e0:b2:f0:5d SYSFS{type} 1 Так тоже не работает: [root@host ~]# cat /etc/iftab eth0 SYSFS{address} 00:1a:64:a3:93:9c SYSFS{type} 1 eth1 SYSFS{address} 00:08:c7:8a:23:69 SYSFS{type} 1 [root@host ~]# ifrename -D -i breth0 Dry-run : Would rename breth0 to eth0. eth0 92227 42 shrek 2009-06-01 15:42:27 +0400 ах ты блин. у бриджа type тоже 1 можно привязаться еще жестче, допустим по SYSFS{device}. см. man iftab 92230 43 vsu 2009-06-01 16:03:15 +0400 Да, дописывание "SYSFS{device} *" в iftab помогает отличить физические интерфейсы от bridge (причём, похоже, сейчас это работает независимо от CONFIG_SYSFS_DEPRECATED, несмотря на описание в man iftab). Возможно, не будет работать с какими-то особо кривыми драйверами, не выставляющими ссылку на физическое устройство. 92246 44 repository-robot 2009-06-01 18:37:25 +0400 installer-feature-eth-by-mac-stage3-0.4-alt1 -> sisyphus: * Mon Jun 01 2009 Dmitry V. Levin <ldv@altlinux> 0.4-alt1 - Changed iftab format (closes: #19313). - Switched to stage3. 92275 45 mike 2009-06-02 00:55:44 +0400 (In reply to comment #39) > В качестве быстрого хака могу заменить в installer-feature-eth-by-mac-stage2 > mac на bus. Дима, тебе следует более внимательно читать рассылки и багзиллу. :) Это уже обсуждалось (кажется, с asy@/vvk@); решили, что породит больше проблем: MAC более постоянен и меняется скорее со сменой карты, а вот порядок сканирования шин(ы) может плавать с ядром, его параметрами и IIRC версией BIOS. Ну и переставив карточку в соседний слот, получаем отъезд привязки. 92358 46 shrek 2009-06-03 10:57:09 +0400 - Added udev-ifrename helper, updated udev rule (by Alexey Gladkov; closes: #19313). в результате на 3-х машинах остался без сети # /lib/ifrename/udev-ifrename eth0 udev-ifrename: /etc/iftab line 3: : interface name patterns are not supported eth0 $ cat /etc/iftab # 82566MM Gigabit Network Connection ether mac 00:1D:72:82:50:03 # PRO/Wireless 4965 AG or AGN Network Connection wifi SYSFS{address} 00:1d:e0:b2:f0:5d SYSFS{type} 1 92378 47 ldv 2009-06-03 14:40:30 +0400 (In reply to comment #46) > # /lib/ifrename/udev-ifrename eth0 > udev-ifrename: /etc/iftab line 3: : interface name patterns are not supported > eth0 Значит, в скрипте udev-ifrename есть баги. 92381 48 aen 2009-06-03 14:51:14 +0400 (В ответ на комментарий №47) > (In reply to comment #46) > > # /lib/ifrename/udev-ifrename eth0 > > udev-ifrename: /etc/iftab line 3: : interface name patterns are not supported > > eth0 > > Значит, в скрипте udev-ifrename есть баги. Или, как пишет vsu@ : "Возможно, не будет работать с какими-то особо кривыми драйверами, не выставляющими ссылку на физическое устройство." 92422 49 repository-robot 2009-06-03 18:54:57 +0400 wireless-tools-29-alt6 -> sisyphus: * Wed Jun 03 2009 Dmitry V. Levin <ldv@altlinux> 29-alt6 - udev-ifrename: Fixed comments handling (closes: #19313). 3394 2009-03-25 14:00:54 +0300 2009-03-25 14:00:54 +0300 ifrename-alt-lockfile.patch ifrename-alt-lockfile.patch text/plain 1038 legion ZGlmZiAtLWdpdCBhL3dpcmVsZXNzLXRvb2xzL2lmcmVuYW1lLmMgYi93aXJlbGVzcy10b29scy9p ZnJlbmFtZS5jCmluZGV4IDlhMjlkMTcuLjJkNWMxOTAgMTAwNjQ0Ci0tLSBhL3dpcmVsZXNzLXRv b2xzL2lmcmVuYW1lLmMKKysrIGIvd2lyZWxlc3MtdG9vbHMvaWZyZW5hbWUuYwpAQCAtMjA0NSw2 ICsyMDQ1LDcgQEAgbWFwcGluZ19yZWFkZmlsZShjb25zdCBjaGFyICoJZmlsZW5hbWUpCiAgIHNp emVfdAkJbGluZWxlbiA9IDA7IAogICBpbnQJCQlsaW5lbnVtID0gMDsgCiAgIHN0cnVjdCBhZGRf ZXh0cmEJZXh0cmFpbmZvOworICBpbnQJCQljb25maWdfZmQ7CiAKICAgLyogUmVzZXQgdGhlIGxp c3Qgb2YgZmlsdGVycyAqLwogICBiemVybyhzZWxlY3Rvcl9hY3RpdmUsIHNpemVvZihzZWxlY3Rv cl9hY3RpdmUpKTsKQEAgLTIwNjYsNiArMjA2NywyMiBAQCBtYXBwaW5nX3JlYWRmaWxlKGNvbnN0 IGNoYXIgKglmaWxlbmFtZSkKIAkJICBmaWxlbmFtZSwgc3RyZXJyb3IoZXJybm8pKTsgCiAJICBy ZXR1cm4oLTEpOwogCX0KKworICAgICAgLyogT3BlbiB0aGUgY29uZmlnIGZpbGUgZm9yIGxvY2tp bmcgKi8KKyAgICAgIGlmICgoY29uZmlnX2ZkID0gb3BlbihmaWxlbmFtZSwgT19SRE9OTFkpKSA9 PSAtMSkKKyAgICAgICAgeworCSAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogQ2FuJ3Qgb3BlbiBj b25maWd1cmF0aW9uIGZpbGUgYCVzJzogJXNcbiIsCisJCSAgZmlsZW5hbWUsIHN0cmVycm9yKGVy cm5vKSk7CisJICByZXR1cm4oLTEpOworICAgICAgICB9CisKKyAgICAgIC8qIExvY2sgY29uZmln IGZpbGUgKi8KKyAgICAgIGlmIChmbG9jayhjb25maWdfZmQsIExPQ0tfRVgpID09IC0xKQorICAg ICAgICB7CisgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogQ2FuJ3QgbG9jayBjb25m aWd1cmF0aW9uIGZpbGUgYCVzJzogJXNcbiIsCisJCSAgZmlsZW5hbWUsIHN0cmVycm9yKGVycm5v KSk7CisJICByZXR1cm4oLTEpOworICAgICAgICB9CiAgICAgfQogCiAgIC8qIFJlYWQgZWFjaCBs aW5lIG9mIGZpbGUK