[lvc-project] [PATCH net 0/4] Avoid using WARN_ON() on allocation failure in device_rename()

[Fedor Pchelkin]

On Thu, 27. Mar 11:01, Ivan Abramov  wrote:
> > From: Fedor Pchelkin <pchelkin at ispras.ru>
> > Sent: Thursday, March 27, 2025 12:38:36 PM
> > To: Abramov Ivan; lvc-project at linuxtesting.org
> > Subject: Re: [lvc-project] [PATCH net 0/4] Avoid using WARN_ON() on allocation failure in device_rename()
> >
> > On Tue, 25. Mar 14:39, Jakub Kicinski wrote:
> > > On Tue, 25 Mar 2025 17:17:19 +0300 Ivan Abramov wrote:
> > > > This patch series is based on
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/ and is
> > > > intended for the generic netdev maintainers, as it affects multiple
> > > > networking subsystems.
> > >
> > > But there is no dependency between the patches, AFAICT.
> > > Please send them individually to the respective maintainers.
> > > --
> > > pw-bot: cr
> >
> > Ну, получается будет лучше направить патчи отдельно, каждый к своей
> > подсистеме.
> >
> > (Для ieee802154 всё равно будет серия из двух патчей)
> >
> > И, как понимаю, разработчики всё же продолжают настаивать на полном
> > переводе к printk-версиям печати в лог, без WARN.
> 
> Kuniyuki Iwashima в ответ на патч с рефакторингом функции
> cfg802154_switch_netns() указал, что dev_net_change_namespace() тоже
> аллоцирует ядерную память и предложил заменить WARN_ON() на
> net_warn_ratelimited().
> 
> Я это оформил отдельным патчем, однако возникает ситуация, где
> в функции cfg802154_switch_netns от WARN_ON() мы полностью отказались, в
> cfg802154_pernet_exit(), который вызывает cfg802154_switch_netns(),
> WARN_ON() остался и т.д.
> 
> Меня беспокоит отсутствие единообразия; хотя выглядит так, что добиться
> его в рамках этих исправлений не получится, и это уже вопрос рефакторинга
> кода подсистем в целом.

Хм, думаю тогда лучше попробовать в том варианте, что сейчас, т.е. с
проверкой ENOMEM в условии WARN.

Макросы WARN по своему замыслу предназначаются для индикации ошибочных
состояний в ядре, которые могут свидетельствовать о багах = того, что
возможно исправить на уровне кода ядра. Возникновение ошибки выделения
памяти - не зависящее от кода явление, которое целенаправленно
провоцируется fault injection'ами (если там где-то выделяется несколько
десятков/сотен байт GFP_KERNEL, то в реальной эксплуатации NULL, более
того, не вернётся согласно особенностям аллокатора).

А вот другие коды ошибок мы здесь на самом деле вроде как и не ожидаем
увидеть. Всякие EINVAL, EEXIST и т.д. могут свидетельствовать о багах в
ядре (вызвали функцию и передали туда девайс в ненадлежащем состоянии, к
примеру). О таких случаях разумно сообщать с WARN.