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

А почему?

Изучая программирование модулей ядра Linux, познавая (ИМХО, хороший) труд "The Linux Kernel Module Programming Guide" заметил несколько несостыковок при впитывании информации в разделе 7 "Файловая система /proc".

Сразу поясню: так как напрятаться было лень читал книжку в переводе от команды RUVDS (за что им большое спасибо), но перевод, кажется, стар, поэтому параллельно всматривался в оригинал, датируемый "May 2, 2023" - вроде бы как свежак). Условимся, что далее по тексту "RU" будет означать переведенную версию, "EN" - оригинал.

За что зацепился?

Ниже привожу код с примером "procfs3.c", как он есть в RU.

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/sched.h>
#include <linux/uaccess.h>
#include <linux/version.h>

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0)
#define HAVE_PROC_OPS
#endif


#define PROCFS_MAX_SIZE 2048
#define PROCFS_ENTRY_FILENAME "buffer2k"

static struct proc_dir_entry *our_proc_file;
static char procfs_buffer[PROCFS_MAX_SIZE];
static unsigned long procfs_buffer_size = 0;

static ssize_t procfs_read(struct file *filp, char __user *buffer,
                           size_t length, loff_t *offset)
{
  static int finished = 0;
  if (finished) {
      pr_debug("procfs_read: END\n");
      finished = 0;
      return 0;
    }

  finished = 1;

  if (copy_to_user(buffer, procfs_buffer, procfs_buffer_size))
    return -EFAULT;

  pr_debug("procfs_read: read %lu bytes\n", procfs_buffer_size);
  return procfs_buffer_size;
}

static ssize_t procfs_write(struct file *file, const char __user *buffer,
                            size_t len, loff_t *off)
{
  if (len > PROCFS_MAX_SIZE)
    procfs_buffer_size = PROCFS_MAX_SIZE;
  else
    procfs_buffer_size = len;

  if (copy_from_user(procfs_buffer, buffer, procfs_buffer_size))
    return -EFAULT;

  pr_debug("procfs_write: write %lu bytes\n", procfs_buffer_size);
  return procfs_buffer_size;
}

static int procfs_open(struct inode *inode, struct file *file)
{
  try_module_get(THIS_MODULE);
  return 0;
}

static int procfs_close(struct inode *inode, struct file *file)
{
  module_put(THIS_MODULE);
  return 0;
}

#ifdef HAVE_PROC_OPS
static struct proc_ops file_ops_4_our_proc_file = {
  .proc_read = procfs_read,
  .proc_write = procfs_write,
  .proc_open = procfs_open,
  .proc_release = procfs_close,
};  
#else
static const struct file_operations file_ops_4_our_proc_file = {
  .read = procfs_read,
  .write = procfs_write,
  .open = procfs_open,
  .release = procfs_close,
};
#endif

static int __init procfs3_init(void)
{
  our_proc_file = proc_create(PROCFS_ENTRY_FILENAME, 0644, NULL,
                              &file_ops_4_our_proc_file);

  if (our_proc_file == NULL) {
    remove_proc_entry(PROCFS_ENTRY_FILENAME, NULL);
    pr_debug("Error: Could not initialize /proc/%s\n",
             PROCFS_ENTRY_FILENAME);

    return -ENOMEM;
  }

  proc_set_size(our_proc_file, 80);
  proc_set_user(our_proc_file, GLOBAL_ROOT_UID, GLOBAL_ROOT_GID);

  pr_debug("/proc/%s created\n", PROCFS_ENTRY_FILENAME);
  return 0;  
}

static void __exit procfs3_exit(void)
{
  remove_proc_entry(PROCFS_ENTRY_FILENAME, NULL);
  pr_debug("/proc/%s removed\n", PROCFS_ENTRY_FILENAME);  
}

module_init(procfs3_init);
module_exit(procfs3_exit);

MODULE_LICENSE("GPL");

Первое, что ввело смуту - функция "procfs_read". Получается, чтобы прочитать, например, cat-ом нужно этот самый cat вызвать 2 раза для обновления статической переменной (напомню, 0 возвращается в этой функции, когда чтение закончено, а тут 0 вернется на 2-й вызов).

Честно говоря, при вызове "procfs_write" не очень понятно, почему меняется именно внутренняя переменная "procfs_buffer_size", а не пользовательский "len".

И убило меня применение "remove_proc_entry". Убило, потому чтобуквально в предыдущем примере вроде бы как для тех же вещей было использовано "proc_remove".

Решил заглядуть в EN.

А что там в EN?

Заглянув в оригинал я понял, что он действительно посвежее и доработаннее:

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/sched.h>
#include <linux/uaccess.h>
#include <linux/version.h>
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 10, 0)
#include <linux/minmax.h>
#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0)
#define HAVE_PROC_OPS
#endif
#define PROCFS_MAX_SIZE 2048UL
#define PROCFS_ENTRY_FILENAME "buffer2k"
static struct proc_dir_entry *our_proc_file;
static char procfs_buffer[PROCFS_MAX_SIZE];
static unsigned long procfs_buffer_size = 0;
static ssize_t procfs_read(struct file *filp, char __user *buffer,
size_t length, loff_t *offset)
{
  if (*offset || procfs_buffer_size == 0) {
    pr_debug("procfs_read: END\n");
    *offset = 0;
    return 0;
  }
  procfs_buffer_size = min(procfs_buffer_size, length);
  
  if (copy_to_user(buffer, procfs_buffer, procfs_buffer_size))
    return -EFAULT;
  
  *offset += procfs_buffer_size;
  pr_debug("procfs_read: read %lu bytes\n", procfs_buffer_size);
  return procfs_buffer_size;
}

static ssize_t procfs_write(struct file *file, const char __user *buffer,
                            size_t len, loff_t *off)
{
  procfs_buffer_size = min(PROCFS_MAX_SIZE, len);
  if (copy_from_user(procfs_buffer, buffer, procfs_buffer_size))
    return -EFAULT;
  *off += procfs_buffer_size;

  pr_debug("procfs_write: write %lu bytes\n", procfs_buffer_size);
  return procfs_buffer_size;
}

static int procfs_open(struct inode *inode, struct file *file)
{
  try_module_get(THIS_MODULE);
  return 0;
}

static int procfs_close(struct inode *inode, struct file *file)
{
  module_put(THIS_MODULE);
  return 0;
}

#ifdef HAVE_PROC_OPS
static struct proc_ops file_ops_4_our_proc_file = {
  .proc_read = procfs_read,
  .proc_write = procfs_write,
  .proc_open = procfs_open,
  .proc_release = procfs_close,
};
#else
static const struct file_operations file_ops_4_our_proc_file = {
  .read = procfs_read,
  .write = procfs_write,
  .open = procfs_open,
  .release = procfs_close,
};
#endif

static int __init procfs3_init(void)
{
  our_proc_file = proc_create(PROCFS_ENTRY_FILENAME, 0644, NULL,
                              &file_ops_4_our_proc_file);

  if (our_proc_file == NULL) {
    remove_proc_entry(PROCFS_ENTRY_FILENAME, NULL);

    pr_debug("Error: Could not initialize /proc/%s\n",
             PROCFS_ENTRY_FILENAME);
  
    return -ENOMEM;
  }

  proc_set_size(our_proc_file, 80);
  proc_set_user(our_proc_file, GLOBAL_ROOT_UID, GLOBAL_ROOT_GID);

  pr_debug("/proc/%s created\n", PROCFS_ENTRY_FILENAME);
  return 0;
}

static void __exit procfs3_exit(void)
{
  remove_proc_entry(PROCFS_ENTRY_FILENAME, NULL);
  pr_debug("/proc/%s removed\n", PROCFS_ENTRY_FILENAME);
}

module_init(procfs3_init);
module_exit(procfs3_exit);

MODULE_LICENSE("GPL");

Тут видно, что "procfs_read" обрабатывается более правильнее, да и в целом код цивилизованнее - обрабатывает некоторые ситуация, проверки всякие добавлены.

Казалось бы - бинго! На это можно остановиться! Проблема старой версии! Но терзавший меня "remove_proc_entry" все еще уверенно сияет в исходном коде без всяких пояснений от авторов.

proc_remove vs remove_proc_entry

Ничего не понял, полез на википедию... И действительно, каким-то немыслимым футуристичным образом нашел доку, где есть фраза:

Deprecated create_proc_entry.

Note that the above article uses create_proc_entry which was removed in kernel 3.10. Current versions require the following update:

-   entry = create_proc_entry("sequence", 0, NULL);
-   if (entry)
-           entry->proc_fops = &ct_file_ops;
+   entry = proc_create("sequence", 0, NULL, &ct_file_ops);

Больше ничего дельного не увидел (наверное мало искал, надеюсь, кто-то умный подскажет что-то более конкретное).

Так как я глуп и неопытен, то связал "create_proc_entry" & "remove_proc_entry", как 1й, "depricated" интерфейс для создания/удаления точки входа в /proc, а "proc_create" & "proc_remove", как 2-й, более свежий.

Кто такой этот proc_set_size?

Вернее, кто это такой - очень даже понятно, установка размера файла в /proc. Но для чего она нужна?

Итак, пусть в функции "procfs3_init", как в примере EN, будет установлен размер файла, равный 80, тогда в выводе "ls -lah /proc/procfs_3_note" будет явно указан этот заданный размер файла. Но на что он влияет?

Попробуем провести эксперимент. Скомпилируем программу с размером файла = 1 и установим модуль ядра.

user$ ls -lah /proc/procfs_3_note 
-rw-rw-rw- 1 root root 1 июн 22 14:29 /proc/procfs_3_note

Размер файла = 1, но, как и следовало ожидать запись и чтение ограничено только внутренним буфером:

user$ echo 0123456789 > /proc/procfs_3_note
user$ cat /proc/procfs_3_note
0123456789

Т.е. размер файла влияет совсем не на это. Как сказал @jcmvbkbc(мерси):

Для того, чтобы дать возможность обращаться к файлу из /proc с ненулевого смещения...

Окей, попробуем. Рекомпиляем проект под размер 10 байт, загружаем вводим эхом последовательность 0123456789.

static ssize_t procFileRead( struct file *pFile, char __user *buffer,
                             size_t bufLen, loff_t *offset )
{
    enum { END_OF_READING = 0 };
    
    // Обработка случая окончания чтения
    if( *offset >= procfsBufferSize || 0 == procfsBufferSize )
    {
        LOG("procFileRead: end of reading");
        return END_OF_READING;
    }
    
    if( bufLen > procfsBufferSize )
    {
        bufLen = procfsBufferSize;
    }
    
    // Передача данных между пространствами пользователя и ядра
    if( copy_to_user( buffer, procfsBuffer, bufLen ) )
    {
        return -EFAULT;
    }
        
    LOG( "procFileRead: read %lu bytes", bufLen );
    *offset += bufLen;

    return bufLen;    
}

static ssize_t procFileWrite( struct file *pFile, const char __user *buff, 
                              size_t len, loff_t *off) 
{
    if( len > MAX_FILE_SIZE  )
    {
        len = MAX_FILE_SIZE;
        LOG( "procFileWrite: file is truncated to %lu bytes", len );
    }
    else
    {
        LOG( "procFileWrite: writing %lu bytes...", len );
    }
    
    // Передача данных между пространствами пользователя и ядра
    if( copy_from_user( procfsBuffer, buff, len ) )
    {
        return -EFAULT;
    }
    
    *off += len;
    
    // Обновление размера внутреннего буфера
    procfsBufferSize = len;
    
    LOG( "procFileWrite: writing done!" );
    
    return len;
}

Пытаемся считать первые пару байт:

user$ hexdump /proc/procfs_3_note -C -n 2

Все хорошо, теперь считаем из середины.

user$ hexdump /proc/procfs_3_note -C -s 4 -n 2
00000004  30 31                                             |01|
00000006

Упс.. Кажется что-то не то. Адреса (колонка слева) изменены, но данные остались те же. Дело в том, что параметр -s утилиты hexdump позволяет задать смещение относительно начала файла для чтения. Этот параметр в функцию модуля ядра поступает, как offset/off в примере выше, но, если вглядеться, то видно, что в коде изменяются значения сдвигов, но сами значения не влияют на функции передачи данных в/из юзерленд/а. Исправим:

static ssize_t procFileRead( struct file *pFile, char __user *buffer,
                             size_t bufLen, loff_t *offset )
{
    enum { END_OF_READING = 0 };
    
    // Обработка случая окончания чтения
    if( *offset >= procfsBufferSize || 0 == procfsBufferSize )
    {
        LOG("procFileRead: end of reading");
        return END_OF_READING;
    }
    
    // При сдвиге размер "меньше"
    const unsigned truncSize = procfsBufferSize - *offset;
    if( bufLen > truncSize )
    {
        bufLen = truncSize;
    }
    
    // Передача данных между пространствами пользователя и ядра
    if( copy_to_user( buffer, procfsBuffer + *offset, bufLen ) )
    {
        LOG("procFileRead: ERROR copy_to_user ");
        return -EFAULT;
    }
        
    LOG( "procFileRead: read %lu bytes", bufLen );
    *offset += bufLen;

    return bufLen;    
}

static ssize_t procFileWrite( struct file *pFile, const char __user *buff, 
                              size_t len, loff_t *off) 
{    
    // При сдвиге размер "меньше"
    const unsigned truncSize = MAX_FILE_SIZE - *off;

    if( len > truncSize  )
    {
        len = truncSize;
        LOG( "procFileWrite: file is truncated to %lu bytes", len );
    }
    else
    {
        LOG( "procFileWrite: writing %lu bytes...", len );
    }
    
    // Передача данных между пространствами пользователя и ядра
    if( copy_from_user( procfsBuffer + *off, buff, len ) )
    {
        LOG("procFileRead: ERROR copy_from_user ");
        return -EFAULT;
    }
    
    *off += len;
    
    // Обновление размера внутреннего буфера
    procfsBufferSize = *off;
    
    LOG( "procFileWrite: writing done!" );
    
    return len;
}

Тестим, теперь похоже на правду:

user$ echo 0123456789 > /proc/procfs_3_note
user$ hexdump /proc/procfs_3_note -C -s 4 -n 2
00000004  34 35                                             |45|
00000006

Но все же разбираться начали с proc_set_size. (Напомню, сейчас установлен в 10)

Попробуем установить сдвиг > 10:

user$ hexdump /proc/procfs_3_note -C -s 11
0000000a

Пусто) Заглянем в лог и видим, что функция чтения даже не была вызвана:

user$ sudo dmesg | grep procfs_
...
[26859.362492] procfs_3_note: procfsOpen
[26859.362568] procfs_3_note: procfsClose

Судя по всему, стоит передавать в proc_set_size размер внутреннего буфера, по крайней мере в тривиальных случаях.

Итог

После всех поисков и разбирательств, написал модуль по образу и подобию вышеуказанных, но с добавлением некоторых комментариев и исправлений, которых нехватало мне. Может быть когда-то кому-то это чем-то поможет, спасибо.