LINUX.ORG.RU

[POSIX] Гонка при отправке kill

 


1

0

Есть два процесса: A и B.
1. A знает pid B, и хочет отправить ему сигнал.
2. B знает, что ему могут время ото времени присылать сигналы, но ничего не знает об A.
3. Пока A выкладывает себе на стек аргументы для системного вызова kill, шедулер ОС приостанавливает A, т.к. закончился квант времени.
4. B успевает штатным образом завершиться.
5. Сразу же после завершения B стартует процесс C, и получает такой же pid, какой был у свежезавершившегося B.
6. Шедулер пробуждает A, и A высылает сигнал не в B, а в C. Fail.

В более общем случае, A может быть просто нерасторопным, даже без вмешательства шедулера.

Вопрос: существует (маленькая) вероятность возникновения такой гонки в реальном мире? Если нет, то объясните, почему и какими стандартами это гарантиуется? Если существует, то какой правильный способ этой гонки избегать?

★★★★★

Последнее исправление: Manhunt (всего исправлений: 2)

>и получает такой же pid

емнип, не получит.

devl547 ★★★★★
()

Существует. Но для этого между снятием A с процессора и его возвращением должно пройти достаточно времени, чтобы pid'ы сделали цикл.

Если есть, то какой правильный способ этой гонки избегать?

Сигнал обычно посылается дочернему процессу, так что эта гонка просто не возникает.

tailgunner ★★★★★
()
Ответ на: комментарий от Manhunt

> Как быть?

Не париться. Во-первых, цикл pid'ов; во-вторых, uid.

Но если хочешь всё сделать правильно и гарантированно корректно, то я не вижу, как обойтись без сотрудничества с общим родителем A и B.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Можно только написав свой модуль. Вообще в ядре функции отправки сигнала используют task_struct, потому зная хоть какой-то атрибут процесса, например, имя, можно вставить дополнительную проверку, но это реально нафиг не надо.

frey ★★
()

3. Пока A выкладывает себе на стек аргументы для системного вызова kill, шедулер ОС приостанавливает A, т.к. закончился квант времени.

А не будет ли решением проблемы получение процессом A приоритета реального времени?

Deleted
()
Ответ на: комментарий от tailgunner

Не париться. Во-первых, цикл pid'ов; во-вторых, uid.

Это где-то прописано в стандартах? Т.е. цикличная раздача pid'ов.

mashina ★★★★★
()
Ответ на: комментарий от mashina

> Это где-то прописано в стандартах? Т.е. цикличная раздача pid'ов.

Нет.

tailgunner ★★★★★
()

Такого не будет если специальные действия в виде игнорирования SIGCHLD не делать. Пока родитель не получит SIGCHLD или не сделает wait() на pid ребёнка, ребёнок будет висеть зомбяком, так что его pid никто не получит. Для этого зомбяков и придумали.

slav ★★
()
Ответ на: комментарий от slav

И да, такое поведение гарантируется стандартом.

slav ★★
()
Ответ на: комментарий от slav

> Такого не будет если специальные действия в виде игнорирования SIGCHLD не делать. Пока родитель не получит SIGCHLD или не сделает wait() на pid ребёнка, ребёнок будет висеть зомбяком

В условии задачи ничего не сказано о родителе B, так что считаем, что он умер, и B усыновлен init.

tailgunner ★★★★★
()
Ответ на: комментарий от AptGet

>> Это где-то прописано в стандартах? Т.е. цикличная раздача pid'ов.

В OpenBSD, к примеру, pid случайный.

В Linux тоже есть патч рандомизации pid'ов, но от повторения это не спасает.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> В Linux тоже есть патч рандомизации pid'ов, но от повторения это не спасает.

Не спорю, повториться может даже быстрее.

AptGet ★★★
()
Ответ на: комментарий от tailgunner

В Linux тоже есть патч рандомизации pid'ов

В grsec? похоже, там больше нет этого патча.

mashina ★★★★★
()
Ответ на: комментарий от AptGet

> В OpenBSD, к примеру, pid случайный.

Это опенок, он должен быть секурным.

tensai_cirno ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.