[lvc-project] [PATCH] gfs2: Fix NULL pointer dereference in gfs2_log_flush

[Fedor Pchelkin]

On Mon, 13. Apr 22:12, Николай Кузнецов wrote:
>    Здравствуйте!
>    > уверены, что этот коммит валиден?
>    Не знаю, насколько это актуальная информация,
> 
>    но, как я увидел, коммит касается не только log.c,
>    но и super.c, на всякий случай прикладываю:
>    [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/gfs2/super.c?id=35264909e9d1973ab9aaa2a1b07cda70f12bb828
>    Не понял, как на git.kernel.org открыть коммит
>    целиком, а не по отдельному файлу. Вот также
>    он целиком на другой платформе:
>    [2]https://patchew.org/linux/20260205044147.1948143-1-black.hawk@163.com/
>    Не знаю, влияет ли это на актуальность ваших
>    вопросов, но на всякий случай отправляю.

Для оформления ссылки на полный коммит следует убрать путь к конкретному
файлу/директории из URL:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35264909e9d1973ab9aaa2a1b07cda70f12bb828

> 
>    > стоит изучить, действительно ли возможно
>    > состояние гонки, которое он правит:
>    > где зануляется указатель sdp->sd_jdesc
>    Меняется при размонтировании фс в
>    put_super: вызывается gfs2_jindex_free(),
>    внутри которой под
>    down_write(&sdp->sd_log_flush_lock) и
>    выставляется NULL:
>    ссылка на вызов gfs2_jindex_free() в
>    put_super():
>    [3]https://elixir.bootlin.com/linux/v6.1.164/source/fs/gfs2/super.c#L639

Там ещё вторая часть вопроса была :)  про жизненный цикл асинхронно
выполняемой работы &gl->gl_work.  Для понимания гонки это также важно,
чтобы понимать, как параллельное выполнение потока с размонтированием
ФС, где выполняется gfs2_jindex_free(), коррелирует с выполнением
обработчика этой &gl->gl_work.

Основные понятия про work queues:
https://litux.nl/mirror/kerneldevelopment/0672327201/ch07lev1sec4.html

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

>    Следовательно, если мы имеем нулевой
>    sdp->sd_jdesc в gfs2_log_flush(), то мы
>    тем более имеем и стёртый SDF_JOURNAL_LIVE,
>    а значит, в
>    [9]https://elixir.bootlin.com/linux/v6.1.164/source/fs/gfs2/log.c#L1051
>    выйдем по метке out, где разыменования вроде
>    как не будет. То есть вроде как и добавленная в
>    обсуждаемом коммите проверка указателя на
>    NULL в gfs2_log_flush действительно излишняя -

Да, согласен, спасибо.

Следующим шагом будет подготовка патча [1].  Подготовьте пожалуйста патч,
грамотно составьте его описание, обосновав своё видение (сильно
разжёвывать и размусоливать не надо, главное постараться всё чётко
сформулировать) и сделайте необходимые изменения кода.  Патч стоит
отправить пока только по адресу lvc-patches at linuxtesting.org.

Перед финальной отправкой команда git send-email спрашивает, кому будут
направлены письма и выводит окончательный список адресатов.

Важно. git send-email по умолчанию добавляет в копию адреса, имеющиеся в
тексте патча (например, если указан тег Cc: stable at vger.kernel.org). При
отправке патча для предварительного внутреннего обсуждения внешние
адресаты нежелательны. В таких случаях их можно убрать, передав команде
опцию --suppress-cc=all.

Я постараюсь оперативно ответить.  По результатам этого обсуждения, если
всё в порядке, можете сразу пинговать Алексея Хорошилова, а то дедлайн
близко.

Потом чтобы довести дело до логического конца, надо будет отправить патч
в международное сообщество, чтобы сопровождающий драйвера Andreas
Gruenbacher его также оценил и, если всё ОК, принял.  Это уже возможно
будет более растянутый во времени процесс, а может и нет, зависит от
мэйнтейнера.

[1]: https://portal.linuxtesting.ru/How-to-send-patches-to-kernel.html