Как избежать разыменования нулевого указателя, на примере одного исправления в ядре Linux

Как избежать разыменования нулевого указателя, на примере одного исправления в ядре Linux

435
ПОДЕЛИТЬСЯ

Чтоб не было разыменования нулевого указателя, необходимо, чтоб не было нулевого указателя. В текущей, на тот момент, эту делему тоже поправили, но по другому. Мысль в последующем. Ваш КО. Так сложилось , что в один прекрасный момент я поправил маленькую делему в ядре Linux, но это была не текущая ветка ядра, а стабильная.

Неувязка была обычная и очень всераспространенная. Как избежать данной ситуации? Можно вынудить один поток подождать, пока 2-ой употребляет буфер, решение обычное, но не действенное, иногда громоздкое. Один поток высвобождает буфер, во время, пока 2-ой продолжает его применять. Состояние гонки.

1-ый вариант

Таковым образом, получаем действенное и наиболее обычное решение, чем решение в лоб. Давайте оставим его в покое, буфер маленький 512 б погоды не сделает. Это намного облегчит процесс синхронизации 2-ух потоков ядра, о этом просто не нужно будет мыслить. Мое решение было иным, а для чего, фактически ожидать, пока освободиться буфер, чтоб здесь же его стереть? А данные, которые останутся в буфере, в любом случае могут быть, т.к. поступают туда по прерыванию, и даже, раз бы мы освободили крайний буфер, в тот же момент, по прерыванию, может быть выделение новейшего буфера и запись туда новейших данных. Удалим все остальные буферы, которые точно в данный момент не употребляются, а крайний оставим. Пришлось удалять 1-ое исправление и добавлять свое, что сделало исправление намного больше, чем обязано было быть.

2-ой вариант
Начальный вариант.—
diff —git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
— a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct tty_buffer *thead;

— while ((thead = tty->buf.head) != NULL) {
— tty->buf.head = thead->next;
— tty_buffer_free(tty, thead);
+ if (tty->buf.head == NULL)
+ return;
+ while ((thead = tty->buf.head->next) != NULL) {
+ tty_buffer_free(tty, tty->buf.head);
+ tty->buf.head = thead;
}
— tty->buf.tail = NULL;
+ WARN_ON(tty->buf.head != tty->buf.tail);
+ tty->buf.head->read = tty->buf.head->commit;
}

/**
Чтоб убрать «if», отлично бы 1-ый буфер выделять при открытии файла устройства, а не когда покажутся 1-ые данные, но это, усложнило бы «patch».

Мне кажется что плохо, сам процесс внесения конфигураций в ядро смотрится, как какая-то гонка, кто успел тот и внес конфигурации, а последствия, позже разберемся. habrahabr.ru Мне кажется, что таковых исправлений в ядро попадает очень много, что еще больше запутывает и так не обычный код. Мое мировоззрение о разработке ядра LinuxХорошо латать дыры первым попавшимся способом либо плохо?