Исправление kmeaw, (текущая версия) :
Ты же предлагаешь синхронно лочить мм-контекст убиваемого процесса, и начинать там что-то высвобождать.
Да, ведь ровно это и делает новый вызов.
Я предлагаю сделать следующий костыль: в реализации kill после проверки прав доступа вставить проверку -
if (sig == SIGKILL) {
/* тут сделать всё то, что делает process_mrelease,
* но без проверки установленности того бита,
* который ставит SIGKILL
*/
}
Если process_mrelease работает
не слишком надёжно,
то такой подход будет не хуже - в тех местах, где пользовательское приложение хотело бы позвать этот новый вызов, достаточно будет обычного kill. И на системах без патча процесс тоже умрёт, код будет более универсальным.
То есть, тебе бы пришлось проверять, а установлен ли обработчик?
SIGKILL всё равно нельзя обработать.
Если делать, как ты говоришь - разделить их не получится.
А в каких сценариях это полезно? Почему кто-то может захотеть убить процесс SIGKILL’ом, но оттянуть освобождение памяти на потом? И способа вызвать process_mrelease на процесс, который сейчас не находится в «умирающем» состоянии, я пока не вижу.
другой процесс ходит и подбирает ресурсы
А зачем для этого другой процесс? Почему бы ядру не подбирать ресурсы всегда?
Или речь идёт об убийстве процесса сигналом, отличным от SIGKILL (например, SIGTERM в случае, когда процесс не определил свой обработчик), когда сразу за этим следует вызов process_mrelease? Если да, то в каких случаях это полезно?
Исправление kmeaw, :
Ты же предлагаешь синхронно лочить мм-контекст убиваемого процесса, и начинать там что-то высвобождать.
Да, ведь ровно это и делает новый вызов.
Я предлагаю сделать следующий костыль: в реализации kill после проверки прав доступа вставить проверку -
if (sig == SIGKILL) {
/* тут сделать всё то, что делает process_mrelease, но без проверки установленности того бита, который ставит SIGKILL */
}
Если process_mrelease работает
не слишком надёжно,
то такой подход будет не хуже - в тех местах, где пользовательское приложение хотело бы позвать этот новый вызов, достаточно будет обычного kill. И на системах без патча процесс тоже умрёт, код будет более универсальным.
То есть, тебе бы пришлось проверять, а установлен ли обработчик?
SIGKILL всё равно нельзя обработать.
Если делать, как ты говоришь - разделить их не получится.
А в каких сценариях это полезно? Почему кто-то может захотеть убить процесс SIGKILL’ом, но оттянуть освобождение памяти на потом? И способа вызвать process_mrelease на процесс, который сейчас не находится в «умирающем» состоянии, я пока не вижу.
другой процесс ходит и подбирает ресурсы
А зачем для этого другой процесс? Почему бы ядру не подбирать ресурсы всегда?
Или речь идёт об убийстве процесса сигналом, отличным от SIGKILL (например, SIGTERM в случае, когда процесс не определил свой обработчик), когда сразу за этим следует вызов process_mrelease? Если да, то в каких случаях это полезно?
Исходная версия kmeaw, :
Ты же предлагаешь синхронно лочить мм-контекст убиваемого процесса, и начинать там что-то высвобождать.
Да, ведь ровно это и делает новый вызов.
Я предлагаю сделать следующий костыль: в реализации kill после проверки прав доступа вставить проверку - ``` if (sig == SIGKILL) { /* тут сделать всё то, что делает process_mrelease, но без проверки установленности того бита, который ставит SIGKILL */ }
Если process_mrelease работает
> не слишком надёжно,
то такой подход будет не хуже - в тех местах, где пользовательское приложение хотело бы позвать этот новый вызов, достаточно будет обычного kill. И на системах без патча процесс тоже умрёт, код будет более универсальным.
> То есть, тебе бы пришлось проверять, а установлен ли обработчик?
SIGKILL всё равно нельзя обработать.
> Если делать, как ты говоришь - разделить их не получится.
А в каких сценариях это полезно? Почему кто-то может захотеть убить процесс SIGKILL'ом, но оттянуть освобождение памяти на потом? И способа вызвать process_mrelease на процесс, который сейчас не находится в "умирающем" состоянии, я пока не вижу.
> другой процесс ходит и подбирает ресурсы
А зачем для этого другой процесс? Почему бы ядру не подбирать ресурсы всегда?
Или речь идёт об убийстве процесса сигналом, отличным от SIGKILL (например, SIGTERM в случае, когда процесс не определил свой обработчик), когда сразу за этим следует вызов process_mrelease? Если да, то в каких случаях это полезно?