>> Не подходит, код ядра выполняется в произвольном потоке.
> Это может быть не важно, в каком потоке он выполняется. Главное чтобы
> к Rc не было бы попыток конкурентного доступа из разных потоков.

Такие попытки как раз и будут. Приложение вызвало syscall, далее поток работает в ядре и лезет куда-то в структуры примонтированной ФС. Они общие для всех? Сколько ещё других приложений делают тот же syscall - неизвестно.

>[оверквотинг удален]
> 1. А в ядре никто и не использует std. Под ядро написана
> замена std, которая во многом похожа, но всё же заметно различается,
> например Vec::new() возвращает Result<Vec, _>, а не Vec. Я не разглядывал
> её, но подозреваю что все эти разговоры про Rc и Arc
> туда слабо применимы, потому что в ядре очень востребованы обёртки над
> сишными типами с рефкаунтами, и для создания таких обёрток Rc и
> Arc бесполезны.
> 2. Если в ядре нет кучи, то нет никакого смысла говорить про
> shared_ptr, use-after-free, и пр. Когда троллишь, следи за толщиной, потому что
> тут ты явно перебрал.

Я использовал в ядре умные указатели, потому и говорю об этом. placement new не нужна куча. Вопрос в том, как именно реализовать shared_ptr - на двусвязном списке, со счётчиком ссылок или придумать что-то с lock-free.

>> То есть выбор сводится к:
>> 1. Написать заведомо невалидируемый код.
>> 2. Висеть в примитивах синхронизации, как и в наивной реализации std::shared_ptr.
> Да, он в C++ сводится к тому же, если код пишет вменяемый
> программист. Потому что мутабельный конкуретный доступ к данным -- это гарантия
> получить пачку дата-рейсов. Бывают иногда ситуации, когда разумные люди на это
> идут сознательно, но простите в таких случаях они пишут на ассемблере,
> выверяя чёткую последовательность команд для каждой конкретной архитектуры. На C/C++/Rust
> нельзя полагаться в этих ситуациях, потому что те когда оптимизируют творят
> такую хрень, что чёткую последовательность команд получиться не удастся никак.

Можно ставить барьер.

> Подход раста в этом отношении отличается от подхода C++ только тем, что
> он не позволяет неразумным программистам организовать датарейс несознательно. Неразумный
> споткнётся об ошибки компиляции, которые он может одолеть при помощи unsafe,
> но это, простите, уже случай сознательного и целенаправленного создания датарейса. Никакие
> аппеляции к бритве Хэнлона не позволят ему отмазаться после такого.

Так вот проблема в том, что неразумным программистам в ядре делать вообще нечего, кроме как что-то сломать. С одной стороны Rust - это хорошо, а с другой, хорошо бы как-то отсеять неразумных. Когда Линус называл программистов на плюсах нетолерантным словом, он как раз это и делал.