<div>Здравствуйте! Отправляю исправленную версию</div><div>рассуждений по предупреждению анализатора.</div><div> </div><div>Предупреждение было ошибочным, далее привожу</div><div>обоснование.<br /><br />Согласно коммиту</div><div><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/gfs2/log.c?id=35264909e9d1973ab9aaa2a1b07cda70f12bb828" rel="noopener noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/gfs2/log.c?id=35264909e9d1973ab9aaa2a1b07cda70f12bb828</a>,<br />нулевой указатель sdp->sd_jdesc приходит</div><div>в gfs2_log_flush в ситуации гонки между</div><div>размонтированием файловой системы и</div><div><div>асинхронной обработки glock в workqueue.<br /> <div>Однако при размонтировании журнал</div><div>обнуляется уже после переведения фс</div><div>в режим readonly и сброса всех изменений</div><div>на диск, а задача из очереди вызывает</div><div>gfs2_log_flush (по цепочке glock_work_func -></div><div>run_queue -> do_xmote -> inode_go_sync -></div><div>gfs2_log_flush) без флага</div><div>GFS2_LOG_HEAD_FLUSH_NORMAL, а значит,</div><div>до gfs2_log_shutdown  (стр. 1139 log.c)</div><div>исполнение функции просто не дойдёт.</div><div> </div><div>Проблемы с вызовами log_write_header (строки</div><div>1111 и 1113) тоже нет, поскольку перед обнулением</div><div>журнала вызывается gfs2_log_flush с флагом</div><div><div>GFS2_LOG_HEAD_FLUSH_SHUTDOWN и</div><div>из-за вызовов log_pull_tail и gfs2_log_update_head</div><div>при размонтировании не будут выполнены</div><div>условия в строках 1110 и 1112.</div><div> </div><div>Кузнецов Николай</div></div></div></div><blockquote><p>On Mon, 06. Apr 18:05, Николай Кузнецов wrote:</p><blockquote>    > В чём заключается ошибка?<br />    В функцию gfs2_log_flush может прийти нулевой указатель<br />    sdp->sd_jdesc, после чего будет цепочка вызовов:<br />    gfs2_log_shutdown(sdp) -> log_pull_tail(sdp) -><br />    dist = log_distance(sdp, new_tail, sdp->sd_log_tail), а в log_distance<br />    уже происходит его разыменование. Согласен, из патча это неясно, перепишу.<br /> <br />    > То есть после патча по неизвестной (пока) причине будет пропускаться<br />    > код, который вроде как и готов обрабатывать нулевой указатель<br />    Тот код был добавлен как раз в целях избежания разыменования<br />    в конкретном месте, прикладываю ссылку на коммит:<br />    [1]<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/gfs2/log.c?id=35264909e9d1973ab9aaa2a1b07cda70f12bb828" rel="noopener noreferrer">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/gfs2/log.c?id=35264909e9d1973ab9aaa2a1b07cda70f12bb828</a></blockquote><p><br />Добавляя свою проверку в начало gfs2_log_flush(), нивелируете изменения<br />этого патча. В нём автор пишет, что да, указатель действительно может<br />оказаться нулевым на этапе gfs2_log_flush() при таких-то условиях, поэтому<br />его нужно обработать.<br /> </p><blockquote>    Там нет полноценной обработки указателя, как я понял,<br />    только обработка частной траектории выполнения.<br /> <br />    В данном коммите нет тега Fixes, я последовал примеру и не стал<br />    его добавлять.<br />    Действительно, я думал над тем, чтобы убрать обработку<br />    указателя в том месте, но старался следовать инструкции с</blockquote><p><br />Нет, проверка, добавленная в 35264909e9d1 ("gfs2: Fix NULL pointer<br />dereference in gfs2_log_flush") должна быть нужной. Зачем её предлагаете<br />убирать?<br /> </p><blockquote>    Мне показалось логичнее сделать ассерт в начале,<br />    чтобы в следующей строчке сразу было попадание на проверку<br />    withdrawn.</blockquote><p><br />Это не выглядит логичным, учитывая происходящее в коммите 35264909e9d1<br />("gfs2: Fix NULL pointer dereference in gfs2_log_flush"). Из него следует,<br />что указателю валидно быть нулевым - это не ошибочная ситуация на ассерт.<br /><br />Как вы упомянули выше, Свейс подцепил один конкретный путь<br />gfs2_log_shutdown(sdp) -> log_pull_tail(sdp) -> log_distance(). Возможно<br />суть кроется в этом пути?</p></blockquote>