<div>Добрый день. Спасибо за замечания.</div><div> </div><div>> Без контекста не очень ясно, на какой ветке ядра встретили срабатывание<br />> стат. анализатора и готовили исправление?</div><div> </div><div>Под контекстом имеются в виду теги Fixes или Cc? Если нет, то как его указать?</div><div>Версия ядра 6.1.164.</div><div> </div><div>> Бывает полезно осматривать<div>> состояние исследуемого кода в самом свежем апстрим-репозитории ядра [1].</div><div>> Каков статус проблемы там?</div></div><div> </div><div>Смотрел исправляемый файл в апстрим репозитории, там никаких действий по</div><div>предотвращению разыменования нулевого указателя не увидел, сделал вывод,</div><div>что ошибка всё ещё присутствует.</div><div> </div><div><div>> gfs2_assert_withdraw() предотвращает выполнение текущей функции?<br />> Насколько понимаю, нет. Т.е. от потенциального дальнейшего креша не<br />> спасёт</div></div><div> </div><div>Как я понял, после ассерта и в итоге withdraw будет выставлен</div><div>флаг SDF_WITHDRAWN (<a href="https://elixir.bootlin.com/linux/v6.1.164/source/fs/gfs2/util.c#L339)" rel="noopener noreferrer" target="_blank">https://elixir.bootlin.com/linux/v6.1.164/source/fs/gfs2/util.c#L339)</a></div><div>и тогда, сразу после ассерта, на проверке в</div><div>строчке <a href="https://elixir.bootlin.com/linux/v6.1.164/source/fs/gfs2/log.c#L1051" rel="noopener noreferrer" target="_blank">https://elixir.bootlin.com/linux/v6.1.164/source/fs/gfs2/log.c#L1051</a></div><div>будет goto out, что позволит избежать проблемы.</div><div> </div><div>Если я всё же не прав, то подскажите, пожалуйста, каким должно быть</div><div>поведение функции в случае, когда указатель нулевой.</div><div> </div><div>Кузнецов Николай</div><div> </div><blockquote><p>On Mon, 06. Apr 10:40, Nikolai Kuznetsov wrote:</p><blockquote> In gfs2_log_flush(), the pointer sdp->sd_jdesc is dereferenced without<br /> a prior check. During mount or umount, sd_jdesc may remain NULL while<br /> the log flush operation is triggered.<br /> <br /> Prevent the crash by adding a gfs2_assert_withdraw() that verifies<br /> sd_jdesc is not NULL.</blockquote><p><br />gfs2_assert_withdraw() предотвращает выполнение текущей функции?<br />Насколько понимаю, нет. Т.е. от потенциального дальнейшего креша не<br />спасёт. Также при определённых флагах монтирования ядро может<br />запаниковать внутри самой gfs2_assert_withdraw(). Польза от правки пока<br />непонятна.<br /><br />Без контекста не очень ясно, на какой ветке ядра встретили срабатывание<br />стат. анализатора и готовили исправление? Бывает полезно осматривать<br />состояние исследуемого кода в самом свежем апстрим-репозитории ядра [1].<br />Каков статус проблемы там?<br /><br />[1]: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/" rel="noopener noreferrer">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/</a><br /> </p><blockquote> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> Signed-off-by: Nikolai Kuznetsov <<a href="mailto:niku.csmsu@yandex.ru" rel="noopener noreferrer">niku.csmsu@yandex.ru</a>><br /> ---<br />  fs/gfs2/log.c | 2 ++<br />  1 file changed, 2 insertions(+)<br /> <br /> diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c<br /> index 347df29d610e..53bf9f68a842 100644<br /> --- a/fs/gfs2/log.c<br /> +++ b/fs/gfs2/log.c<br /> @@ -1036,6 +1036,8 @@ void gfs2_log_flush(struct gfs2_sbd *sdp, struct gfs2_glock *gl, u32 flags)<br />          down_write(&sdp->sd_log_flush_lock);<br />          trace_gfs2_log_flush(sdp, 1, flags);<br />  <br /> + gfs2_assert_withdraw(sdp, sdp->sd_jdesc != NULL);<br /> +<br />  repeat:<br />          /*<br />           * Do this check while holding the log_flush_lock to prevent new<br /> --<br /> 2.43.0</blockquote></blockquote>