История изменений

Ты же предлагаешь синхронно лочить мм-контекст убиваемого процесса, и начинать там что-то высвобождать.

Да, ведь ровно это и делает новый вызов.

Я предлагаю сделать следующий костыль: в реализации kill после проверки прав доступа вставить проверку -

if (sig == SIGKILL) {
  /* тут сделать всё то, что делает process_mrelease,
   * но без проверки установленности того бита, 
   * который ставит SIGKILL
   */
}

Если process_mrelease работает

не слишком надёжно,

то такой подход будет не хуже - в тех местах, где пользовательское приложение хотело бы позвать этот новый вызов, достаточно будет обычного kill. И на системах без патча процесс тоже умрёт, код будет более универсальным.

То есть, тебе бы пришлось проверять, а установлен ли обработчик?

SIGKILL всё равно нельзя обработать.

Если делать, как ты говоришь - разделить их не получится.

А в каких сценариях это полезно? Почему кто-то может захотеть убить процесс SIGKILL’ом, но оттянуть освобождение памяти на потом? И способа вызвать process_mrelease на процесс, который сейчас не находится в «умирающем» состоянии, я пока не вижу.

другой процесс ходит и подбирает ресурсы

А зачем для этого другой процесс? Почему бы ядру не подбирать ресурсы всегда?

Или речь идёт об убийстве процесса сигналом, отличным от SIGKILL (например, SIGTERM в случае, когда процесс не определил свой обработчик), когда сразу за этим следует вызов process_mrelease? Если да, то в каких случаях это полезно?

Ты же предлагаешь синхронно лочить мм-контекст убиваемого процесса, и начинать там что-то высвобождать.

Да, ведь ровно это и делает новый вызов.

Я предлагаю сделать следующий костыль: в реализации kill после проверки прав доступа вставить проверку -

if (sig == SIGKILL) {
  /* тут сделать всё то, что делает process_mrelease, но без проверки установленности того бита, который ставит SIGKILL */
}

Если process_mrelease работает

не слишком надёжно,

то такой подход будет не хуже - в тех местах, где пользовательское приложение хотело бы позвать этот новый вызов, достаточно будет обычного kill. И на системах без патча процесс тоже умрёт, код будет более универсальным.

То есть, тебе бы пришлось проверять, а установлен ли обработчик?

SIGKILL всё равно нельзя обработать.

Если делать, как ты говоришь - разделить их не получится.

А в каких сценариях это полезно? Почему кто-то может захотеть убить процесс SIGKILL’ом, но оттянуть освобождение памяти на потом? И способа вызвать process_mrelease на процесс, который сейчас не находится в «умирающем» состоянии, я пока не вижу.

другой процесс ходит и подбирает ресурсы

А зачем для этого другой процесс? Почему бы ядру не подбирать ресурсы всегда?

Или речь идёт об убийстве процесса сигналом, отличным от SIGKILL (например, SIGTERM в случае, когда процесс не определил свой обработчик), когда сразу за этим следует вызов process_mrelease? Если да, то в каких случаях это полезно?

Ты же предлагаешь синхронно лочить мм-контекст убиваемого процесса, и начинать там что-то высвобождать.

Да, ведь ровно это и делает новый вызов.

Я предлагаю сделать следующий костыль: в реализации kill после проверки прав доступа вставить проверку - ``` if (sig == SIGKILL) { /* тут сделать всё то, что делает process_mrelease, но без проверки установленности того бита, который ставит SIGKILL */ }

Если process_mrelease работает

> не слишком надёжно,

то такой подход будет не хуже - в тех местах, где пользовательское приложение хотело бы позвать этот новый вызов, достаточно будет обычного kill. И на системах без патча процесс тоже умрёт, код будет более универсальным.

> То есть, тебе бы пришлось проверять, а установлен ли обработчик?

SIGKILL всё равно нельзя обработать.

> Если делать, как ты говоришь - разделить их не получится.

А в каких сценариях это полезно? Почему кто-то может захотеть убить процесс SIGKILL'ом, но оттянуть освобождение памяти на потом? И способа вызвать process_mrelease на процесс, который сейчас не находится в "умирающем" состоянии, я пока не вижу.

> другой процесс ходит и подбирает ресурсы

А зачем для этого другой процесс? Почему бы ядру не подбирать ресурсы всегда?

Или речь идёт об убийстве процесса сигналом, отличным от SIGKILL (например, SIGTERM в случае, когда процесс не определил свой обработчик), когда сразу за этим следует вызов process_mrelease? Если да, то в каких случаях это полезно?