Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

From: Denis Medvedev <nbr@altlinux.org>
To: Alexey Sheplyakov <asheplyakov@basealt.ru>
Cc: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y
Date: Wed, 8 Sep 2021 15:58:41 +0300
Message-ID: <20210908155841.06ab8f74@homerun.localdomain> (raw)
In-Reply-To: <717cfd00-8805-7f20-6ca0-3de8b92f89a1@basealt.ru>

В Wed, 8 Sep 2021 14:47:35 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> On 08.09.2021 14:14, Denis Medvedev wrote:
> > В Wed, 8 Sep 2021 13:17:06 +0400
> 
> >>> Вот мне бы интересно было, если бы malloc мог (при включении
> >>> какой-либо опции) при отсутствии памяти  ждать ее появления ,
> >>> выдавая процессу SIGTSTP.
> >>
> >> Сколько примерно времени займёт адаптация userspace к новому
> >> поведению? В частности, как определить те места, где ответ "сейчас
> >> нет, жду" заведомо неприемлем?
> > "сейчас нет, жду" - это не ответ, не код возврата, это поведение.
> 
> Тогда это ещё хуже.
> 
> > А почему вообще userspace это интересно?
> 
> 1. Потому что время имеет значение.
Когда как. Поэтому такое поведение стоит включать явно каким-либо
специальным ключом компиляции, там где такое поведение не будет
фатальным.
> 2. Приход сигнала, в том месте, где его не ожидает - это очень, очень
> плохо.
Невыделение ожидаемой памяти обычно плохо не меньше.
> 
> > Ему malloc возвратит память - чаще чем обычно. И всё. Оно просто
> > чаще не получит NULL, его либо снимут явным kill ВНУТРИ malloc либо
> > дадут памяти и волшебный пендель SIGCONT. Зато это явно безопаснее,
> > чем если далее не будет проверен код возврата и будет разыменован
> > NULL.
> 
> С точностью до наоборот: появляется ещё одно место, где возможен
> нелокальный выход, и дополнительные возможности для атаки (я даже не
> говорю про DoS).
Нелокальный выход возможен всегда по получении SIGKILL. 
> 
> > Привеите пример ситуации, когда ответ "сейчас нет, жду" хуже чем 
> > "нет памяти"?
> 
> С ходу:
> 
> pthread_mutex_lock(&mutex);
> result = realloc(global_buf, size*2); /* и тут закончилась память */
Ну и что? Ну подождет realloc выделения памяти в системе и продолжит.
Что тут такого? Проблема будет если кто-то стопнутый процесс или
нить прибьет
- ну а никто не мешает его и просто так прибить SIGKILL-ом.
pthread_mutex_lock ведь касается только набора нитей, а следящий
процесс к этим нитям отношения не имеет и ему эти локи до лампочки.
Он отдельный процесс Linux если что. 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel