Как получить доступ ко всем каналам в системе из пространства ядра Linux - PullRequest
Новая
       29

Как получить доступ ко всем каналам в системе из пространства ядра Linux

3 голосов
/ 13 мая 2011

Я хочу добавить новый системный вызов в ядро ​​Linux, который покажет информацию обо всех каналах, которые созданы в системе.

Как я могу получить индекс (или любую другую связанную структуручто позволит мне получить доступ к pipe_inode_info) каждой трубы в pipefs?

Я смотрел на struct vfsmount , struct dentry и struct super_block , но я не нашел правильный путь. Можно ли как-нибудь получить структуру файла каждого файла в pipefs?

1 Ответ

1 голос
/ 14 мая 2011

Сначала я захожу в каталог / proc и выдаю: 

ls -al */fd |grep pipe

(попробуйте убрать "трубу" выше, и вы узнаете больше.) И результаты (просто снимок): 

l-wx------ 1 root     root     64 2011-05-14 23:12 17 -> pipe:[39208]
l-wx------ 1 root     root     64 2011-05-14 23:12 2 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 4 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 8 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 17 -> pipe:[39532]
l-wx------ 1 root     root     64 2011-05-14 23:12 2 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 4 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 8 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 1 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 16 -> pipe:[40032]
l-wx------ 1 root     root     64 2011-05-14 23:12 17 -> pipe:[40032]
l-wx------ 1 root     root     64 2011-05-14 23:12 2 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 4 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 8 -> pipe:[23406]
l-wx------ 1 tteikhua tteikhua 64 2011-05-14 23:13 1 -> pipe:[16245]
l-wx------ 1 tteikhua tteikhua 64 2011-05-14 23:13 12 -> pipe:[66674]
lr-x------ 1 tteikhua tteikhua 64 2011-05-14 23:13 13 -> pipe:[66674]
l-wx------ 1 root root 64 2011-05-14 23:30 1 -> pipe:[101794]

И если вы хотите увидеть процесс, который создал канал, просто удалите «grep», например:

Здесь показано, что pid = 1 имеет канал fdв 6759: 

1/fd:
total 0
dr-x------ 2 root root  0 2011-05-14 23:29 .
dr-xr-xr-x 7 root root  0 2011-05-14 22:59 ..
lrwx------ 1 root root 64 2011-05-14 23:29 0 -> /dev/console (deleted)
lrwx------ 1 root root 64 2011-05-14 23:29 1 -> /dev/console (deleted)
lrwx------ 1 root root 64 2011-05-14 23:29 2 -> /dev/console (deleted)
lr-x------ 1 root root 64 2011-05-14 23:29 3 -> pipe:[6759]

И прослеживая вышеупомянутое назад к fs / pipe.c (исходный код ядра Linux, который печатает их): 

/*
 * pipefs_dname() is called from d_path().
 */
static char *pipefs_dname(struct dentry *dentry, char *buffer, int buflen)
{
        return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]",
                                dentry->d_inode->i_ino);
}

static const struct dentry_operations pipefs_dentry_operations = {
        .d_dname        = pipefs_dname,
};

И чтение fs / dcache.c: 

char *d_path(const struct path *path, char *buf, int buflen)
{
        if (path->dentry->d_op && path->dentry->d_op->d_dname)
                return path->dentry->d_op->d_dname(path->dentry, buf, buflen);

and since d_path() is an exported symbol,

EXPORT_SYMBOL(d_path);

вы должны иметь возможность вызывать его из любого места и получать информацию о пути - если это канал, то будет вызван соответствующий pipefs_dname () - он зависит от файловой системы: 

./fs/pipe.c:
    .d_dname    = pipefs_dname,

Прочитайте inode.c: init_inode_always (), и вы увидите, что для i_pipe установлено значение NULL.Это не нуль, только когда индексом является ТРУБА.

Таким образом, вы всегда можете перебрать весь процесс и получить его дескриптор открытого файла, и если для i_pipe inode установлено значение, отличное от NULL, вы будете знать, что это значение является номером инода канала.

Я не думаю, что такие коды будут существовать в исходном коде ядра (поэтому нет необходимости охотиться за ним - я уже пробовал), так как это намного эффективнее и безопаснее делать это в пользовательском пространстве (например, "ls -al "команда, которую я объяснил ранее) затем внутри ядра - как правило, чем меньше ядро, тем меньше ошибок безопасности и, следовательно, лучшая стабильность и т. д.

...