[C++] Безопасно ли разбирать файл / proc / file?


Answers

Хотя файлы в /proc отображаются как обычные файлы в пользовательском пространстве, они не являются файлами, а объектами, которые поддерживают стандартные операции с файлами из пользовательского пространства ( open , read , close ). Обратите внимание, что это совсем не так, как обычный файл на диске, который изменяется ядром.

Все ядро ​​выполняет печать своего внутреннего состояния в собственную память с помощью функции sprintf like, и эта память копируется в пользовательское пространство всякий раз, когда вы выдаете системный вызов read(2) .

Ядро обрабатывает эти вызовы совершенно по-другому, чем обычные файлы, что может означать, что весь моментальный снимок данных, которые вы будете читать, может быть готов в то время, когда вы open(2) , а ядро ​​удостоверяется, что одновременные вызовы последовательный и атомный. Я не читал этого нигде, но на самом деле не имеет смысла быть иначе.

Мой совет - взглянуть на реализацию файла proc в вашем конкретном вкусе Unix. Это действительно проблема реализации (как и формат и содержание вывода), которые не регулируются стандартом.

Простейшим примером может быть реализация файла proc uptime в Linux. Обратите внимание на то, как весь буфер создается в функции обратного вызова, single_open в single_open .

Question

Я хочу разбирать /proc/net/tcp/ , но безопасно ли это?

Как мне открывать и читать файлы из /proc/ и не бояться, что какой-то другой процесс (или сама ОС) будет менять его в одно и то же время?




API-интерфейс procfs в ядре Linux обеспечивает интерфейс, обеспечивающий считывание возвращаемых согласованных данных. Прочитайте комментарии в __proc_file_read . Пункт 1) в блоке больших комментариев объясняет этот интерфейс.

При этом, конечно, для реализации конкретного файла proc необходимо правильно использовать этот интерфейс, чтобы убедиться, что его возвращаемые данные согласованы. Итак, чтобы ответить на ваш вопрос: нет, ядро ​​не гарантирует согласованности файлов proc во время чтения, но предоставляет средства для реализации этих файлов для обеспечения согласованности.




За исключением неизвестных ошибок, в /proc нет условий гонки, которые приведут к чтению поврежденных данных или сочетанию старых и новых данных. В этом смысле это безопасно. Однако по-прежнему существует условие гонки, что большая часть данных, которые вы читаете из /proc , потенциально устарела, как только она сгенерирована, и даже более того, к тому времени, когда вы ее прочитаете / обработаете. Например, процессы могут умереть в любое время, и новому процессу может быть назначен один и тот же pid; единственные идентификаторы процесса, которые вы можете использовать без условий гонки, - это ваши собственные дочерние процессы ». То же самое касается сетевой информации (открытые порты и т. Д.) И действительно большая часть информации в /proc . Я считаю, что плохая и опасная практика полагается на то, что любые данные в /proc точны, за исключением данных о вашем собственном процессе и, возможно, его дочерних процессах. Конечно, может быть полезно представить другую информацию из /proc пользователю / администратору для информативного / ведения журнала / etc. цели.