Ну вот я и привел конкретный пример (хоть и не про ядро, но про ту же рассылку), где это не сработало... От слова совсем.
О чем собственно и речь... Хотя возможно это просто из области того исключения подтверждающего правило, однако... судя по слухам всё же нет. И (пользуясь настоящими issue-tracker уже лет дцать с гаком) я действительно не очень представляю как это вообще может работать хорошо. Нельзя просто взять (здесь картинка) и сделать из почтового клиента полноценный современный трекер с полным его функционалом, я уж умолчу про github, gitlab и подобные. Так то можно и код писать и ревьювить в блокноте, а вместо git (или др. какой distributed version control system) те же архивы юзать и patch-ами обмениваться, и т.д. Можно много чего, но зачем?.. И главный вопрос (хоть история и не терпит сослагательного наклонения), насколько лучше и быстрее и качественнее возможно оно было бы по другому.
Once you know the subsystem that is causing the issue, you should send a bug report. Some maintainers prefer bugs to be reported via the kernel.org Bugzilla, while others prefer that bugs be reported via the subsystem mailing list.
Я вообще про баг "трекеры" на основе е-майл и то просто конкретный пример как оно реально работает.
Кроме того, если внимательно посмотреть, место "где мне не понравилось" и есть как раз "трекер" куда человек своё issue из статьи бы и отправил (...@vger.kernel.org), оно что для git, что для всего остального там одинаково работает. И что-то мне говорит, что в случае с kernel (о чем собственно эта статья) количество тех issues всяко поболее будет чем у того же git, т. е. заблудиться там есть где. О чем кстати много где и не раз говорилось, и того же LBT на всяких разных конференциях только ленивый не спрашивал.
Не исчезает, говорите? Есть номера, статус и это всё, говорите? Ну-ну...
Вот засегфаултил как-то мой git, отписал я как положено в тот "мыльный" баг-трекер, и в результате выяснилось внезапно, что очень всё знакомо вдруг и даже ветка где-то с фиксом лежит, про который попросту все позабыли. Что в последствии вылилось в дискуссию с моим описанием почему такой "мыльный" трекер вовсе не трекер, и чем реальный issue-tracker лучше. С ожидаемым результатом - здесь поговорка про инициативу и того незадачливого инициатора, которого она... ну того, значит.
@posthedgehog:касательно поиска контактного лица или ответа на конкретный вопрос люди пользуют IRC (libera.chat). Для того же ядра можно спросить бота /msg alis LIST *kernel* для списка каналов куда можно постучатся (на вскидку #linux-kernel, #kernel или ##kernel).
Коротко, это из-за блокировок под-сетей "из-за значительного роста количества попыток вторжения"...
Подозреваю что у них просто некоторые IP-ranges фильтруются чересчур широко или по IP2Location и подобным базам, а то и вовсе по whois.
Меня последнее время тоже почему-то спрашивают про возросший "злонамеренный" трафик из RU (хотя я наблюдаю совершенно другую картину - довольно сильно возросший malicious traffic из US и CN).
Собрал небольшую статистику у себя и по знакомым. Если кому интересно...
10 стран «победителей» для марта месяца
... со средними показателями в день, абсолютным темпом роста и относительной динамикой в сравнении с предыдущим месяцем:
Поправит (хотя фикс действительно так себе, но всё же фиксит как и написано "just bail out")... Ибо (ударение на сейчас) оно только неправильно работает в случае argc = 0, т.к. он начинает обрабатывать параметры (argv[n]) начиная с n = 1, т.е. "перепрыгивает" NULL и попадает на первую строчку из envp.
Схематично как это должно быть:
n = 1
|---------+---------+-----+------------|---------+---------+-----+------------|
| argv[0] | argv[1] | ... | argv[argc] | envp[0] | envp[1] | ... | envp[envc] |
|----|----+----|----+-----+-----|------|----|----+----|----+-----+-----|------|
V V V V V V
"program" "-option" NULL "value" "PATH=name" NULL
Как оно в случае argc = 0:
n = 1
|---------|---------+---------+-----+------------|
| argv[0] | envp[0] | envp[1] | ... | envp[envc] |
|----|----|----|----+----|----+-----+-----|------|
V V V V
NULL "value" "PATH=name" NULL
В результате вот это вот - path = g_strdup (argv[n]); - очень нехорошая штука (была до фикса)...
Ну а дальше думаю и так всё понятно.
А "так себе" собственно, поскольку оно сейчас действительно работает, а завтра кто-нибудь поправит что-нибудь и сломает его для argc = 1, что бы чуть позже кто-то сделал новую CVE.
Может, согласен... и что для cvtsi2sd, что для fild+fstp... И возможно даже более вероятно чем при делении, потому как меня смущает, что для python 2.7 оно там совсем не воспроизводимо. А если я правильно вспоминаю исходники, то вот эта штука с "многоступенчатым" преобразованием вида timespec --> int64_t --> double как раз где-то в 3-й версии в этом виде появилась (3.6 до 3.8 если не ошибаюсь), т.е. каст из doubleword integer в scalar double может раньше и не был там, поэтому оно там и работает в python 2.7 худо бедно.
Другое дело что есть ли принципиальная разница? - ведь что там, что там FPU сломан (ну или что там еще барахлит), а конкретика в котором месте точно барахлит должна по хорошему лишь хостера интересовать, ну или AMD или возможно KVM, если то вдруг софтовые проблемы виртуализации.
Всё было бы проще если бы машинка была под рукой, а так... муторно оно.
Хотя всё равно странно - как такое не вылазит повсеместно, ибо что cvtsi2sd+divsd, что fild+fstp+fdiv настолько часто должны присутствовать, что оно бы всё равно где-нибудь да проявилось. Аннет, токма тут вылазит.
Дело в том что 1642516506243048649 не влазит в double и получиться 1642516506243048704.
Оно и понятно, только на нормально работаюшей системе это поменеят несколько десятков наносекунд (55 если быдь точным), но никак не секунды т.е. при делении на лярд как бы не очень важно в контексте статьи - время, округленное до миллисекунд, как было 1642516506.243 так и останется 1642516506.243.
А просто при делении 1642516506243048649 / 1e9 получается воспроизвести неправильный результат?
Думаю что временами да, но... спросить чего и ждать потом 2-3 дня (а он как говорилось уже, нукуда не торопится), то такое.
там два действия int64->double и потом деление. Можете оба действия залогировать.
Можно, то оно можно, токма с хайзенбагами осторожно нужно - они чем больше их дебажишь или обвешиваешь логами, тем хуже воспроизводятся, плавали - знаем (приходилось по роду деятельности бороться).
Но глюк точно не связан с памятью, т.к. значения еще не покидало кэш первого уровня
Вот про кеш я бы не был так уверен, ибо 1) вымывается он всякой паразитной дрянью, да на виртуалке то, и 2) та же внезапная запись рядом в том же неудачно выравненном блоке памяти другим каким потоком может вызвать invalidate для всего куска что в L2, а затем и в L1 (я про согласованность кеша и когерентность памяти). Он у Ryzen9 3900X хоть и большой (если не ошибаюсь 64MB), но под виртуалку ему отдали всего 512K судя по инфо о системе: Info: Single Core model: AMD Ryzen 9 3900X bits: 64 type: UP L2 cache: 512 KiB опять же на single core model там контекст-свич контекст-свичем погоняет.
Вот только слишком уж "консистетные" результаты для битой памяти, при том если то память, то здесь действительно стэк (это не объекты питона из кучи). А битый стек должен бы худо бедно сегфолтить где-то еще, а этого нет и в помине судя по всему.
А он не сломан (мы это выяснили еще в первой части, ну и здесь видно): трейсинг показывает что clock_gettime(CLOCK_REALTIME) возвращает корректные значения
Проапдейтил статью, внизу прикрепил "пробник" для bash, выводящий строчку с актуальными значениями каждые полсекунды, который останавливается если отклонение превышает 1 час от начального (или соответственно ровно через 1 час).
Переустановка Debian 11 а затем Fedora 34 на той же VM с последующим тестом на чистых системах ничего не поменяли - тем самым подозрение на hypervisor/hardware проблемы усилилось.
Nix-time 1705M естественно находится в 2024 году (о чем и сказано в посте). Речь про то, что time.time возвращает это значение сейчас (временами, на конкретной машине)... Что этот комментарий должен сказать я не понимаю вовсе... Может поясните?
Я всё понимаю, и ECC не панацея и работать питон может худо бедно на тех же адресах (хотя ASLR)… Но как объяснить битой памятью преобразование вида:
1640M -> 1705M -> 1674M
При том что левое и правое относительно стабильны (что касается такта изменений), а то что посредине плавает, при чем 1674M в теории должно зависеть (алгоритмически) от 1705M.
Тут 2 варианта, либо запаздывающее логирование из сервиса (типичный случай nginx log для долгого запроса, когда запись в лог происходит по response сильно отстающий от request time, а nginx запишет именно время начала запроса). Либо баг - https://github.com/fail2ban/fail2ban/issues/2882 (поправлен для новых версий).
С проблемой из статьи конечно ничего общего (там типа "системное" время прыгает).
Ну вот я и привел конкретный пример (хоть и не про ядро, но про ту же рассылку), где это не сработало... От слова совсем.
О чем собственно и речь... Хотя возможно это просто из области того исключения подтверждающего правило, однако... судя по слухам всё же нет.
И (пользуясь настоящими issue-tracker уже лет дцать с гаком) я действительно не очень представляю как это вообще может работать хорошо. Нельзя просто взять (здесь картинка) и сделать из почтового клиента полноценный современный трекер с полным его функционалом, я уж умолчу про github, gitlab и подобные.
Так то можно и код писать и ревьювить в блокноте, а вместо git (или др. какой distributed version control system) те же архивы юзать и patch-ами обмениваться, и т.д. Можно много чего, но зачем?.. И главный вопрос (хоть история и не терпит сослагательного наклонения), насколько лучше и быстрее и качественнее возможно оно было бы по другому.
Есть то она есть, только...
Once you know the subsystem that is causing the issue, you should send a bug report. Some maintainers prefer bugs to be reported via the kernel.org Bugzilla, while others prefer that bugs be reported via the subsystem mailing list.
Я вообще про баг "трекеры" на основе е-майл и то просто конкретный пример как оно реально работает.
Кроме того, если внимательно посмотреть, место "где мне не понравилось" и есть как раз "трекер" куда человек своё issue из статьи бы и отправил (...@vger.kernel.org), оно что для git, что для всего остального там одинаково работает. И что-то мне говорит, что в случае с kernel (о чем собственно эта статья) количество тех issues всяко поболее будет чем у того же git, т. е. заблудиться там есть где. О чем кстати много где и не раз говорилось, и того же LBT на всяких разных конференциях только ленивый не спрашивал.
Не исчезает, говорите? Есть номера, статус и это всё, говорите? Ну-ну...
Вот засегфаултил как-то мой git, отписал я как положено в тот "мыльный" баг-трекер, и в результате выяснилось внезапно, что очень всё знакомо вдруг и даже ветка где-то с фиксом лежит, про который попросту все позабыли. Что в последствии вылилось в дискуссию с моим описанием почему такой "мыльный" трекер вовсе не трекер, и чем реальный issue-tracker лучше. С ожидаемым результатом - здесь поговорка про инициативу и того незадачливого инициатора, которого она... ну того, значит.
@posthedgehog:касательно поиска контактного лица или ответа на конкретный вопрос люди пользуют IRC (libera.chat).
Для того же ядра можно спросить бота
/msg alis LIST *kernel*для списка каналов куда можно постучатся (на вскидку #linux-kernel, #kernel или ##kernel).https://issues.guix.gnu.org/54370
Коротко, это из-за блокировок под-сетей "из-за значительного роста количества попыток вторжения"...
Подозреваю что у них просто некоторые IP-ranges фильтруются чересчур широко или по IP2Location и подобным базам, а то и вовсе по whois.
Меня последнее время тоже почему-то спрашивают про возросший "злонамеренный" трафик из RU (хотя я наблюдаю совершенно другую картину - довольно сильно возросший malicious traffic из US и CN).
Собрал небольшую статистику у себя и по знакомым. Если кому интересно...
10 стран «победителей» для марта месяца
... со средними показателями в день, абсолютным темпом роста и относительной динамикой в сравнении с предыдущим месяцем:
Поправит (хотя фикс действительно так себе, но всё же фиксит как и написано "just bail out")...
Ибо (ударение на сейчас) оно только неправильно работает в случае
argc = 0, т.к. он начинает обрабатывать параметры (argv[n]) начиная сn = 1, т.е. "перепрыгивает" NULL и попадает на первую строчку из envp.Схематично как это должно быть:
Как оно в случае
argc = 0:В результате вот это вот -
path = g_strdup (argv[n]);- очень нехорошая штука (была до фикса)...Ну а дальше думаю и так всё понятно.
А "так себе" собственно, поскольку оно сейчас действительно работает, а завтра кто-нибудь поправит что-нибудь и сломает его для
argc = 1, что бы чуть позже кто-то сделал новую CVE.Всё - тема закрыта: хост вылечился заменой CPU,
суслик неувиновен.Может, согласен... и что для
cvtsi2sd, что дляfild+fstp...И возможно даже более вероятно чем при делении, потому как меня смущает, что для python 2.7 оно там совсем не воспроизводимо. А если я правильно вспоминаю исходники, то вот эта штука с "многоступенчатым" преобразованием вида
timespec --> int64_t --> doubleкак раз где-то в 3-й версии в этом виде появилась (3.6 до 3.8 если не ошибаюсь), т.е. каст из doubleword integer в scalar double может раньше и не был там, поэтому оно там и работает в python 2.7 худо бедно.Другое дело что есть ли принципиальная разница? - ведь что там, что там FPU сломан (ну или что там еще барахлит), а конкретика в котором месте точно барахлит должна по хорошему лишь хостера интересовать, ну или AMD или возможно KVM, если то вдруг софтовые проблемы виртуализации.
Всё было бы проще если бы машинка была под рукой, а так... муторно оно.
Хотя всё равно странно - как такое не вылазит повсеместно, ибо что
cvtsi2sd+divsd, чтоfild+fstp+fdivнастолько часто должны присутствовать, что оно бы всё равно где-нибудь да проявилось. Аннет, токма тут вылазит.Оно и понятно, только на нормально работаюшей системе это поменеят несколько десятков наносекунд (55 если быдь точным), но никак не секунды т.е. при делении на лярд как бы не очень важно в контексте статьи - время, округленное до миллисекунд, как было 1642516506.243 так и останется 1642516506.243.
Думаю что временами да, но... спросить чего и ждать потом 2-3 дня (а он как говорилось уже, нукуда не торопится), то такое.
Можно, то оно можно, токма с хайзенбагами осторожно нужно - они чем больше их дебажишь или обвешиваешь логами, тем хуже воспроизводятся, плавали - знаем (приходилось по роду деятельности бороться).
Вот про кеш я бы не был так уверен, ибо 1) вымывается он всякой паразитной дрянью, да на виртуалке то, и 2) та же внезапная запись рядом в том же неудачно выравненном блоке памяти другим каким потоком может вызвать invalidate для всего куска что в L2, а затем и в L1 (я про согласованность кеша и когерентность памяти). Он у Ryzen9 3900X хоть и большой (если не ошибаюсь 64MB), но под виртуалку ему отдали всего 512K судя по инфо о системе:
Info: Single Core model: AMD Ryzen 9 3900X bits: 64 type: UP L2 cache: 512 KiB
опять же на single core model там контекст-свич контекст-свичем погоняет.
Вот только слишком уж "консистетные" результаты для битой памяти, при том если то память, то здесь действительно стэк (это не объекты питона из кучи). А битый стек должен бы худо бедно сегфолтить где-то еще, а этого нет и в помине судя по всему.
А он не сломан (мы это выяснили еще в первой части, ну и здесь видно):
трейсинг показывает что
clock_gettime(CLOCK_REALTIME)возвращает корректные значенияНо если хотите - добавлю.
Вышла вторая часть "детектива".
Из последнего: он собрал python 3.10.2 из исходников, результат тот же что и для ванильного 3.9!
Проапдейтил статью, внизу прикрепил "пробник" для bash, выводящий строчку с актуальными значениями каждые полсекунды, который останавливается если отклонение превышает 1 час от начального (или соответственно ровно через 1 час).
Переустановка Debian 11 а затем Fedora 34 на той же VM с последующим тестом на чистых системах ничего не поменяли - тем самым подозрение на hypervisor/hardware проблемы усилилось.
Хоть кошерней тут было бы не минус а xor юзать... но оно всё равно ни в long, ни в double тут не "работает" (как минимум в прямом виде).
Ну да, ну да... Статью не читал, но мысль после "прочтения" не понял.
Nix-time 1705M естественно находится в 2024 году (о чем и сказано в посте). Речь про то, что time.time возвращает это значение сейчас (временами, на конкретной машине)... Что этот комментарий должен сказать я не понимаю вовсе... Может поясните?
Я всё понимаю, и ECC не панацея и работать питон может худо бедно на тех же адресах (хотя ASLR)… Но как объяснить битой памятью преобразование вида:
При том что левое и правое относительно стабильны (что касается такта изменений), а то что посредине плавает, при чем 1674M в теории должно зависеть (алгоритмически) от 1705M.
Тут 2 варианта, либо запаздывающее логирование из сервиса (типичный случай nginx log для долгого запроса, когда запись в лог происходит по response сильно отстающий от request time, а nginx запишет именно время начала запроса). Либо баг - https://github.com/fail2ban/fail2ban/issues/2882 (поправлен для новых версий).
С проблемой из статьи конечно ничего общего (там типа "системное" время прыгает).