Атомность системного вызова writev() в Linux

Question

Я искал источник ядра для ядра linux 4.4.0-57-generic и не вижу никаких блокировок в источнике writev(). Есть что-то, что мне не хватает? Я не вижу, как writev() является атомарным или потокобезопасным.

Answer 1

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

Просмотр ядра (v4.9, хотя я бы не ожидал, что это так отличается), и пытается проследить writev(2) системный вызов, я могу наблюдать последующие вызовы функций, которые создают следующий путь:

1. SYSCALL_DEFINE3(writev, ..)

2. do_writev(..)

3. vfs_writev(..)

4. do_readv_writev(..)

Теперь путь ветви, в зависимости от того, реализуется и подключил на struct file_operations поле struct file, что системный вызов со ссылкой на метод write_iter.

• Если это не NULL, путь:

5а. do_iter_readv_writev(..), который называет метод filp->f_op->write_iter(..)at this point.

• Если NULL, путь:

5b. do_loop_readv_writev(..), который неоднократно вызывает в цикле метод filp->f_op->writeat this point.

---

Итак, насколько я понимаю, writev() системный вызов как нить безопасно, так как лежащий в основе write() (или write_iter()) является, что, конечно, могут быть реализованы различными способами, например, в драйвере устройства и может или не может использовать блокировки в соответствии с его потребностями и его конструкцией.

---

EDIT:

В ядре v4.4 дорожки выглядят довольно похожи:

1. SYSCALL_DEFINE3(writev, ..)

2. vfs_writev(..)

3. do_readv_writev(..)

, а затем это зависит от того метода write_iter как поле в struct file_operations из struct file - NULL или нет, точно так же, как в случае, описанном выше в версии 4.9.

Answer 2

VFS (Virtual File System) самих по себе не гарантируетатомарности из writev() вызова. Он просто вызывает метод .write_iter с файловой системой struct file_operations.

Это ответственности конкретной реализации файловой системы для метода делает атомарной записи в файл.

Например, в функции файловой системы ext4 ext4_file_write_iter использует

mutex_lock(&inode->i_mutex); 

для макияжа сочинительство атомарным.

Answer 3

Нашел в fs.h:

static inline void file_start_write(struct file *file) 
{ 
    if (!S_ISREG(file_inode(file)->i_mode)) 
     return; 
    __sb_start_write(file_inode(file)->i_sb, SB_FREEZE_WRITE, true); 
} 

, а затем в super.c:

/* 
* This is an internal function, please use sb_start_{write,pagefault,intwrite} 
* instead. 
*/ 
int __sb_start_write(struct super_block *sb, int level, bool wait) 
{ 
    bool force_trylock = false; 
    int ret = 1; 

#ifdef CONFIG_LOCKDEP 
/* 
* We want lockdep to tell us about possible deadlocks with freezing 
* but it's it bit tricky to properly instrument it. Getting a freeze 
* protection works as getting a read lock but there are subtle 
* problems. XFS for example gets freeze protection on internal level 
* twice in some cases, which is OK only because we already hold a 
* freeze protection also on higher level. Due to these cases we have 
* to use wait == F (trylock mode) which must not fail. 
*/ 
    if (wait) { 
    int i; 

    for (i = 0; i < level - 1; i++) 
     if (percpu_rwsem_is_held(sb->s_writers.rw_sem + i)) { 
      force_trylock = true; 
      break; 
     } 
    } 
#endif 
    if (wait && !force_trylock) 
    percpu_down_read(sb->s_writers.rw_sem + level-1); 
    else 
    ret = percpu_down_read_trylock(sb->s_writers.rw_sem + level-1); 

    WARN_ON(force_trylock & !ret); 
    return ret; 
} 
EXPORT_SYMBOL(__sb_start_write); 

Еще раз спасибо.