[Devel] Бага #3626 cifs kmem_cache_destroy problem

[Evgeny Sinelnikov]

9 марта 2009 г. 17:44 пользователь Pavel Shilovsky
<piastry на etersoft.ru> написал:
> Разобрался с проблемой, связанной с появлением сообщения "Cannot allocate
> memory" во время частой перезагрузки модуля. Проблема была, в том, что поток,
> следящий за входящими сообщениями из сокета, не успевал очищать кеш запросов
> при отмонтировании шары.
>
> Ниже приведён патч, решающий эту проблему
> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> index 1ae6314..18ba45a 100644
> --- a/fs/cifs/cifsglob.h
> +++ b/fs/cifs/cifsglob.h
> @@ -176,6 +176,7 @@ struct TCP_Server_Info {
>        struct mac_key mac_signing_key;
>        char ntlmv2_hash[16];
>        unsigned long lstrp; /* when we got last response from this server */
> +       int running;
>  };
>
>  /*
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index f254235..39daaf2 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -347,6 +347,7 @@ cifs_demultiplex_thread(struct TCP_Server_Info *server)
>        bool isMultiRsp;
>        int reconnect;
>
> +       server->running = 1;
>        current->flags |= PF_MEMALLOC;
>        cFYI(1, ("Demultiplex PID: %d", task_pid_nr(current)));
>
> @@ -758,6 +759,8 @@ multi_t2_fnd:
>
>        kfree(server->hostname);
>        task_to_wake = xchg(&server->tsk, NULL);
> +       server->running = 0;
> +       msleep(20);
>        kfree(server);
>
>        length = atomic_dec_return(&tcpSesAllocCount);
> @@ -1408,6 +1411,9 @@ cifs_put_tcp_session(struct TCP_Server_Info *server)
>        task = xchg(&server->tsk, NULL);
>        if (task)
>                force_sig(SIGKILL, task);
> +
> +       while(server->running == 1)
> +               msleep(10);
>  }
>
>  static struct cifsSesInfo *
>

Такой вариант вариант ожидания называется активным, обычно для этого
используются spinlock'и. Может быть и здесь они будут уместны? Не
стоит забывать про SMP...
http://en.wikipedia.org/wiki/Spin_locking
http://www.linuxjournal.com/article/5833

>
>
> Проводился следующий тест:
> 20 раз подряд выполнялись след. действия:
> 1) загрузка модуля
> 2) монтирование шары
> 3) отмонтирование шары
> 4) выгрузка модуля
>
> Раньше этот тест падал уже на второй итерации, после применении патча он
> полностью проходит.
>

Ну, хорошо... значит проблема, скорее всего, именно в этом... Как
только подготовишь поправки для использования системных объектов для
"блокировок в цикле", продублируй патч для стабильных веток ядра...

-- 
Sin (Sinelnikov Evgeny)