Чтобы не возникло противоречий с такими возможностями, ядрам Unix не разрешается уничтожать данные, содержащиеся в дескрипторе процесса, сразу после завершения процесса. Им можно сделать это только после того, как процесс – родитель сделает wait ()подобный системный вызов в отношении завершившегося процесса. Именно поэтому было введено состояние exit zombie: хотя в техническом смысле процесса больше нет, его дескриптор хранится, пока процесс – родитель не будет уведомлен.

Что происходит, если родитель завершает выполнение раньше своих потомков? В этом случае система может оказаться переполненной процессами – зомби, дескрипторы которых навсегда остались бы в оперативной памяти. Как было сказано ранее, эта проблема решается принудительным переводом всех осиротевших”процессов в потомки процесса init. Тогда процесс init уничтожит зомби при проверке завершения одного из своих законных потомков с помощью wait ()подобного системного вызова.

Функция reiease tasko отсоединяет последние структуры от дескриптора процесса – зомби. Она применяется к зомби одним из двух способов: либо с помощью функции do exito, если родитель не заинтересован в получении сигналов от потомка, либо с помощью системных вызовов wait4() или waitpid (), после того как сигнал был отправлен потомку. В последнем случае функция также произведет утилизацию памяти, занятой дескриптором процесса, а в первом —утилизация памяти будет произведена планировщиком. Эта функция выполняет следующие действия:

1. Уменьшает количество процессов, принадлежащих пользователю – владельцу завершившегося процесса. Это значение хранится в структуре user struct, упомянутой ранее в этой главе (см. шаг 4 функции сору_ process ()).

2. Если процесс отслеживается, функция удаляет его из списка ptrace_ children отладчика и возвращает оригинальному родителю.

3. Вызывает функцию exit signai о, чтобы отменить все ожидающие доставки сигналы и освободить дескриптор signai struct процесса. Если дескриптор больше не используется другими облегченными процессами, функция удаляет эту структуру. Кроме того, она вызывает функцию exit itimers (), чтобы отсоединить от процесса POSIX – таймер интервалов, если таковой имеется.

4. Вызывает функцию exit sighando, чтобы убрать обработчики сигналов.

5. Вызывает функцию unhash process (), которая:

•уменьшает переменную nr threads на 1;

•дважды вызывает функцию detach pid (), чтобы удалить дескриптор процесса из хеш – таблиц pidhash типа pidtype_pid и pidtype_tgid;

•если процесс является лидером группы, опять дважды вызывает функцию detach pid (), чтобы удалить дескриптор процесса из хеш – таблиц

PIDTYPE_PGID И PIDTYPE_SID;

•вызывает макрос remove links, чтобы удалить дескриптор процесса из списка процессов.

6. Если процесс не является лидером группы, значит, лидер уже стал процессом – зомби, и данный процесс является последним членом группы потоков.

Функция отправляет сигнал родителю лидера, чтобы уведомить его о “гибели”процесса.

7. Вызывает функцию sched exitо, чтобы отрегулировать отрезок времени процесса – родителя (этот шаг логически дополняет шаг 17 в описании функции copy_process ()).

8. Вызывает функцию put task structо, чтобы изменить счетчик обращений у дескриптора процесса. Если этот счетчик сравняется с нулем, функция отменяет все оставшиеся ссылки на процесс:

•уменьшает счетчик обращений (поле count) структуры user struct,

принадлежащей пользователю – владельцу процесса и освобождает эту структуру, если счетчик обращений становится равным 0;

•освобождает дескриптор процесса и область памяти, занимаемую дескриптором thread infо и стеком режима ядра.

Функция do exit () принимает в качестве параметра код завершения процесса и выполняет следующие действия:

1. Устанавливает флаг pf exiting в поле flag дескриптора процесса, чтобы отметить тот факт, что процесс в данный момент удаляется.

2. Удаляет, если необходимо, дескриптор процесса из очереди динамического таймера, для чего вызывает функцию dei timer sync ().

3. Отсоединяет от дескриптора процесса структуры, имеющие отношение к выделению страниц, семафорам, файловой системе, дескрипторам открытых файлов, пространствам имен и битовой карте разрешений ввода/вывода, вызывая С ЭТОЙ целью функции exit_mm(), exit_sem(), exit_f iles (), exit_f s (), exit_namespace () и exit_thread () соответственно. Эти же функции удаляют перечисленные структуры, если другие процессы не пользуются ими совместно с уничтожаемым процессом.

4. Если функции ядра, реализующие область выполнения и поддержку исполняемого формата уничтожаемого процесса, входят в состав модулей ядра, функция уменьшает их счетчики обращений.

5. Записывает код завершения процесса в поле exit code дескриптора процесса. Это значение представляет собой либо параметр системного вызова

exit о или exit groupO (нормальное завершение), либо код ошибки, предоставленный ядром (аварийное завершение).

6. Вызывает функцию exit notifyO, которая выполняет следующие действия:

•обновляет отношения родитель – потомок”между соответствующими процессами. Все потомки, созданные уничтожаемым процессом, становятся потомками другого процесса в той же группе потоков, если таковой в данный момент выполняется. В противном случае они становятся потомками процесса init;

•убеждается, что поле exit signai дескриптора уничтожаемого процесса отлично от – 1, и что этот процесс является последним членом своей группы потоков (заметим, что эти условия всегда соблюдены у любого нормального процесса; см. шаг 16 в описании функции copy process о ранее в этой главе). В этом случае функция посылает сигнал (обычно sigchld) родителю уничтожаемого процесса, чтобы известить его о гибели”потомка;

•в противном случае, т. е. если поле exit signai содержит – 1, или группа потоков включает в себя другие процессы, функция отправляет сигнал sigchld родителю только в том случае, когда процесс отслеживается (в этой ситуации родителем является отладчик, который информируется о гибели”облегченного процесса);

•если поле exit signai дескриптора процесса равно – 1, а процесс не отслеживается, функция записывает в поле exit state дескриптора процесса значение exit dead и вызывает функцию reiease tasko для утилизации памяти, занимаемой оставшимися структурами данных процесса, и уменьшения счетчика обращений дескриптора процесса (см. следующий раздел). Счетчик обращений становится равным, так что сам дескриптор процесса пока не удаляется;

•если же поле exit signai дескриптора процесса не равно – 1, а процесс отслеживается, функция записывает в поле exit state значение exit zombie. В следующем разделе мы увидим, что происходит с про – цессами – зомби;

•устанавливает флаг pf dead в поле flags дескриптора процесса.

7. Вызывает функцию schedule о, чтобы выбрать, какой процесс будет выполняться следующим. Поскольку процесс в состоянии exit zombie игнорируется планировщиком, выполнение процесса прекращается сразу после вызова макроса switchto в функции schedule о. Как планировщик проверит флаг pf dead и уменьшит счетчик обращений в дескрипторе процесса – зомби, замещаемого другим процессом, чтобы отметить тот факт, что процесс больше не существует.

1. Проверяет, установлен ли флаг signal group exit у завершающегося процесса, т. е. приступило ли уже ядро к процедуре завершения данной группы потоков. В этом случае функция считает кодом завершения значение, хранящееся в поле current ->signal ->group_exit_code.
2. В противном случае функция устанавливает у процесса флаг signal_
group exit и сохраняет код завершения в поле current ->signai -> g гoup_ex i t_c ode.
3. Вызывает функцию zap other threads (), чтобы уничтожить остальные процессы в группе процесса current, если таковые имеются. С этой целью функция перебирает список идентификаторов процессов в хеш – таблице PIDTYPE TGID, определяемой полем current ->tgid. Каждому процессу в списке, отличному от current, она посылает сигнал sigkill. В результате, все эти процессы, в конце концов, выполнят функцию do exit () И будут уничтожены.
4. Вызывает функцию do exit (), передавая ей код завершения процесса. Как мы скоро увидим, функция do exit () уничтожает процесс и не возвращает управление.

Примерами потоков ядра (помимо процесса 0 и процесса 1) являются:

keventd (также называемый events) —выполняет функции из рабочей очереди keventd_wq (см. главу 4)\

kapmd —обрабатывает события, имеющие отношение к усовершенствованному управлению питанием (АРМ, Advanced Power Management);

pdflush —сбрасывает грязные”буферы на диск, чтобы утилизировать память;

kblockd —выполняет функции из рабочей очереди kblockd_workqueue. На практике этот поток ядра периодически активизирует драйверы блочных устройств, как описано в разд. ksoftirqd —выполняет тасклеты. У каждого процессора в системе есть один такой поток ядра.

Уничтожение процессов

Большинство процессов умирает”в том смысле, что они прекращают выполнять свой код. Память, открытые файлы и прочие вещи, упоминаемые в этой книге, например, семафоры.

Обычно, чтобы закончить свою работу, процесс вызывает библиотечную функцию exit (), которая освобождает ресурсы, выделенные библиотекой С, выполняет все функции, зарегистрированные программистом, и под конец делает системный вызов, удаляющий процесс из системы. Библиотечная функция exit о может быть вызвана программистом явно. Кроме того, компиляторе всегда ставит вызов exit о сразу после последнего оператора функции main ().

Завершение процесса

В Linux 2.6 существуют два системных вызова, которые прекращают выполнение приложения, работающего в пользовательском режиме:

системный вызов exit group, который завершает выполнение всей группы потоков, т. е. целое многопоточное приложение. Основная функция

ядра, реализующая этот системный вызов, называется do group exit(). Этот системный вызов должен быть сделан библиотечной функцией

exit ();

системный вызов exit (), который завершает выполнение одного процесса, независимо от других процессов, входящих в ту же группу, что и жертва. Основная функция ядра, реализующая этот системный вызов, называется do exito. Этот системный вызов делается, например, функцией pthread exit () из библиотеки LinuxThreads.

? потоки ядра работают только в режиме ядра, а обычные процессы выполняются попеременно то в режиме ядра, то в пользовательском режиме;

? поскольку потоки ядра работают только в режиме ядра, они обращаются только к линейным адресам, большим чем page offset; обычные же процессы пользуются всеми четырьмя гигабайтами линейных адресов, будь то в режиме пользователя или в режиме ядра.

Создание потока ядра

Функция kernei thread () создает новый поток ядра. Она принимает в качестве параметров адрес функции ядра, подлежащей выполнению (fn), аргумент, передаваемый этот функции (arg), и набор флагов клона (flags). Фактически она вызывает функцию do_fork () со следующими аргументами.

Флаг clone vm позволяет избежать копирования таблиц страниц вызвавшего процесса. Такое копирование было бы непроизводительной тратой времени и памяти, потому что новый поток ядра все равно не станет обращаться к адресному пространству пользовательского режима. Флаг clone untraced гарантирует, что никакой процесс не сможет отслеживать выполнение нового потока ядра, даже если производилось отслеживание вызвавшего процесса.

Параметр pregs, передаваемый функции do forkO, соответствует адресу в стеке режима ядра, по которому функция copy thread () сможет найти начальные значения регистров процессора для нового потока. Функция kernei thread () строит эту стековую область так, чтобы выполнялось следующее:

? регистры ebx и edx получили от функции copy thread () значения параметров fn и arg соответственно;

? регистр eip получил адрес следующего фрагмента ассемблерного кода:

movl %edx,%eax pushl %edx call %ebx pushl %eax call do_exit

Таким образом, новый поток ядра начнется с выполнения функции fn(arg). Если эта функция завершится, поток ядра сделает системный вызов exit (), передав ему значение, возвращенное функцией fn ().

Процесс О

Предок всех процессов, называемый процессом 0, или холостым процессом, или (по историческим причинам) процессом swapper, представляет собой поток ядра, созданный “с нуля”на этапе инициализации Linux. Этот всеобщий предок использует следующие статически выделяемые структуры (структуры для всех остальных процессов выделяются динамически):

? дескриптор процесса, хранящийся в переменной init task, которая инициализируется макросом init task;

? дескриптор thread info и стек режима ядра, хранящиеся в переменной

init_thread_union И инициализируемые МакрОСОМ INIT_THREAD_INFO;

? таблицы, на которые указывает дескриптор процесса.

Эти таблицы инициализируются, соответственно, следующими макросами.

? главный глобальный каталог страниц ядра, хранящийся в переменной

swapper_pg_dir (СМ. главу 2).

Функция start kernei о инициализирует все структуры данных, необходимые ядру, включает прерывания и создает еще один поток ядра, процесс 1, чаще называемый процессом init.

Этот новый поток ядра имеет идентификатор процесса, равный 1, и использует все соответствующие структуры данных ядра совместно с процессом 0. Будучи выбранным планировщиком, процесс init запускает функцию init ().

Создав процесс init, процесс 0 вызывает функцию cpu idie (), которая, в сущности, сводится к многократному выполнению ассемблерной инструкции hit при включенных прерываниях. Процесс 0 выбирается планировщиком, только если нет других процессов в состоянии task running.

В многопроцессорных системах процесс 0 имеется у каждого процессора. Сразу после включения питания система BIOS включает один процессор, оставив остальные выключенными. Процесс swapper, работающий на процессоре 0, инициализирует структуры данных ядра, а затем включает остальные процессоры и создает дополнительные процессы swapper с помощью функции copy process о, которой он передает ноль в качестве идентификатора нового процесса. Кроме того, ядро записывает в поле сри дескриптора thread info каждого ответвленного процесса соответствующий индекс процессора.

Процесс 1

Поток ядра, созданный процессом 0, вызывает функцию init (), которая завершает инициализацию ядра. Затем функция init () делает системный вызов execve (), чтобы загрузить исполняемую программу init. В результате поток ядра init становится обычным процессом, имеющим собственные структуры данных ядра. Процессор init продолжает существовать вплоть до выключения питания, поскольку он создает и отслеживает все процессы, реализующие внешние слои операционной системы.

fn —задает функцию, которую должен выполнить новый процесс; когда эта функция возвратит управление, потомок завершит свою работу. Функция возвращает целое число, представляющее собой код возврата процес – са – потомка;

arg —указывает на данные, необходимые для функции fn ();

flags —разнообразная информация. Младший байт задает номер сигнала, посылаемого родителю, когда потомок завершит работу (как правило, выбирается сигнал sigchld). Остальные три байта задают группу флагов клона, перечисленных в табл. 3.8;

chiid stack —задает указатель стека в режиме пользователя, который должен быть записан в регистр esp процесса – потомка. Вызывающий процесс (родитель) должен всегда выделять стек для нового потомка;

tis —задает адрес структуры, определяющей сегмент локальной памяти потока для нового облегченного процесса (см. главу 2). Имеет смысл только при установленном флаге clone settls;

ptid —задает адрес переменной процесса – родителя в режиме пользователя, где будет храниться идентификатор нового облегченного процесса. Имеет смысл только при установленном флаге clone parent settid;

ctid —задает адрес переменной нового облегченного процесса в режиме пользователя, где будет храниться идентификатор этого процесса. Имеет смысл только при установленном флаге clone child settid.

Функция clone () фактически является интерфейсной функцией, определенной в библиотеке С (см. разд. “API – интерфейсы стандарта POSIX и системные вызовы” в главе 10). Она устанавливает стек для нового облегченного

процесса и делает системный вызов clone о, скрытый от программиста. У служебной процедуры sys cione (), реализующей системный вызов clone (), нет параметров fn и а г д. Интерфейсная функция сохраняет указатель fn в стеке потомка в позиции, соответствующей адресу возврата самой интерфейсной функции, а указатель arg сохраняется в стеке потомка сразу под fn. Когда интерфейсная функция завершается, процессор извлекает адрес возврата из стека и выполняет функцию fn (arg).

Традиционный системный вызов fork о реализован в Linux в виде системного вызова clone о, у которого параметр flags задает сигнал sigchld и определяет, что все флаги клона сброшены, а параметр chiid stack является указателем на текущий стек процесса – родителя. Таким образом, родитель и потомок временно совместно используются одним стеком режима пользователя.

Системный вызов vforko, упомянутый в предыдущем разделе, реализован в Linux в виде системного вызова clone о, у которого параметр flags задает сигнал sigchld и флаги clone_vm и clone_vfork, а параметр chiid_stack является указателем на текущий стек процесса – родителя.

Функция do_fork()

Функция do_fork(), обрабатывающая системные вызовы clone о, fork о и vfork (), принимает следующие параметры:

clone flags —ТО же, ЧТО параметр flags функции clone ();

stack start —ТО же, ЧТО параметр chiid stack функции clone ();

regs —указатель на содержимое регистров общего назначения, сохраненное в стеке режима ядра при переключении из пользовательского режима в режим ядра.

stack size —не используется (всегда равен 0);

parent tidptr, child tidptr —ТО же, ЧТО параметры ptid И ctid фуНКЦИИ clone().

Функция do fork () вызывает служебную функцию copy process (), чтобы установить дескриптор процесса и прочие структуры данных ядра, необходимые для работы потомка. Приведем основные действия, выполняемые функцией do_fork():

1. Выделяет идентификатор процесса для потомка, просматривая битовую карту pidinap_array.

2. Проверяет поле ptrace процесса – родителя (то есть поле current ->ptrace). Если оно не равно нулю, значит, родитель отслеживается другим процессом, и тогда функция do_f or к () проверяет, хочет ли отладчик отслеживать процесс – потомок по своей инициативе (то есть независимо от флага clone ptrace, задаваемого родителем). В этом случае, если потомок не является потоком ядра (флаг clone untraced сброшен), функция устанавливает флаг CLONE_PTRACE.

3. Вызывает функцию copy process о, чтобы создать копию дескриптора процесса. Если все необходимые ресурсы доступны, функция возвращает адрес только что созданного дескриптора task struct. Эта функция —”рабочая лошадка” процедуры ветвления процесса, и мы обсудим ее сразу ПОСЛе фуНКЦИИ do_fork ().

4. Если либо установлен флаг clone stopped, либо необходим мониторинг процесса – потомка (то есть флаг рт ptraced в поле p ->ptrace установлен), функция переводит процесс – потомок в состояние task stopped и добавляет к нему сигнал sigstop, подлежащий обработке. Потомок остается в состоянии task stopped, пока какой-то другой процесс (предположительно, отслеживающий выполнение или родитель) не переведет его в состояние task running с помощью сигнала SIGCONT.

5. Если флаг clone stopped не установлен, функция вызывает функцию wake up new task (), которая выполняет следующие действия:

•настраивает параметры планирования родителя и потомка (см. разд. “Алгоритм планирования” главы 7);

•если потомок будет выполняться на том же процессоре, что и родитель8, и родитель с потомком не обращаются к одному набору таблиц страниц (флаг clone vm сброшен), функция заставляет процесс – потомок выполняться до родителя, занося процесс – потомок в очередь на выполнение, в которой стоит родитель, непосредственно перед родителем.

•в противном случае, если потомку не предстоит работать на одном процессоре с родителем, или если родитель с потомком совместно используют один набор таблиц страниц (флаг clone vm установлен),

функция ставит процесс – потомок на последнее месте родительской очереди на выполнение.

6. Если флаг clone stopped установлен, функция переводит процесс – потомок в состояние task_stopped.

7. Если выполнение процесса – родителя отслеживается, функция сохраняет идентификатор процесса – потомка в поле ptrace message текущего процесса и вызывает функцию ptrace notify о, которая фактически останавливает текущий процесс и отправляет сигнал sigchld его родителю. “Дедушкой”процесса – потомка здесь является отладчик, отслеживающий выполнение родителя. Сигнал sigchld уведомляет отладчик, что текущий процесс породил процесс, чей идентификатор может быть получен из поля current ->ptrace_message.

8. Если установлен clone vfork, функция ставит процесс – родитель в очередь ожидания и приостанавливает его выполнение до тех пор, пока потомок не освободит адресное пространство (то есть пока он не завершит работу или не запустит новую программу).

9. Завершает работу и возвращает идентификатор процесса – потомка. Функция copy_process()

Функция copy process () устанавливает дескриптор процесса и любые другие структуры данных ядра, которые могут потребоваться для выполнения потомка. Ее параметры такие же, как у функции do fork (), плюс идентификатор процесса – потомка. Она выполняет следующие действия:

1. Проверяет, совместимы ли флаги, переданные в параметре cione fiags. В частности, она возвращает код ошибки в следующих случаях:

•установлены флаги clone_newns и clone_fs;

•флаг clone_thread установлен, но флаг clone_sighand сброшен (облегченные процессы в одной группе потоков должны иметь общие сигналы);

•флаг clone sighand установлен, но флаг clone vm сброшен (облегченные процессы, имеющие общие обработчики сигналов, должны иметь и общий дескриптор памяти).

2. Выполняет дальнейшие защитные проверки, для чего вызывает функцию security_task_create() И, чуть ПОЗЖе, функцию security_task_alloc (). Ядро Linux 2.6 предлагает перехватчики для расширений безопасности, чтобы установить модель безопасности более строгую, чем та, что принята в традиционных Unix – подобных системах (см. главу 20).

3. Вызывает функцию dup task structо, чтобы получить дескриптор процесса для потомка. Эта функция выполняет следующие действия:

•вызывает функцию uniazy_fpu() для текущего процесса, чтобы сохранить, если необходимо, содержимое регистров FPU, ММХ и SSE/SSE2 в структуре thread info процесса – родителя. Впоследствии функция dup task struct о скопирует эти значения в структуру thread info процесса – потомка;

•выполняет макрос aiioc task structо, чтобы получить дескриптор (структуру task struct) для нового процесса, и сохраняет его адрес в локальной переменной tsk;

•выполняет макрос aiioc thread info, чтобы получить свободную область памяти для хранения структуры thread info и стека режима ядра для нового процесса, а затем сохраняет ее адрес в локальной переменной ti. Как было сказано в разд. “Идентификация процесса”ранее в этой главе, размер этой области памяти равен либо 8 Кбайт, либо 4 Кбайт;

•копирует содержимое дескриптора текущего процесса в структуру task struct, на которую указывает локальная переменная tsk, затем записывает Значение ti В ПОЛе tsk ->thread_info;

•копирует содержимое дескриптора thread info текущего процесса в структуру, на которую указывает локальная переменная ti, а затем записывает значение tsk в поле ti ->task;

•записывает 2 в счетчик обращений дескриптора нового процесса (tsk ->usage), чтобы показать, что дескриптор процесса используется и что соответствующий процесс “жив” (его состояние не exit zombie и не exit_dead);

•возвращает указатель на дескриптор нового процесса (tsk).

4. Проверяет значение, хранящееся В поле current ->signal ->rlim[RLIMIT_ nproc] .riim cur. Если оно меньше или равно текущему количеству процессов, принадлежащих пользователю, возвращается код ошибки, если у процесса нет привилегий root. Функция получает текущее количество процессов, принадлежащих пользователю, из пользовательской структуры по имени user struct. Эту структуру можно найти по указателю в поле user дескриптора процесса.

5. Увеличивает счетчик обращений структуры user struct (поле tsk -> user -> count) и счетчик процессов, принадлежащих пользователю (поле tsk ->user ->processes).

6. Убеждается, что количество процессов в системе (хранящееся в переменной nr threads) не превышает значение переменной max threads. Значение этой переменной, принимаемое по умолчанию, зависит от объема оперативной памяти в системе. Общее правило гласит, что память, занимаемая всеми дескрипторами thread inf о и стеками режима ядра, не может превышать 1/8 объема физической памяти. Впрочем, системный администратор может изменить это значение, записав новое в файл /proc/sys/kernel/threads – max.

7. Если функции ядра, реализующие область выполнения и поддержку исполняемого формата процесса, входят в состав модулей ядра, описываемая функция увеличивает их счетчики обращений.

8. Устанавливает несколько важных полей, имеющих отношение к состоянию процесса:

•инициализирует счетчик глобальной блокировки ядра tsk ->iock_depth значением 1.

•инициализирует поле tsk ->did_exec значением 0. Это счетчик системных вызовов execve (), сделанных процессом;

•обновляет некоторые флаги в поле tsk ->fiags, скопированные у родителя: вначале сбрасывает флаг pf superpriv, показывающий, воспользовался ли процесс какими-либо привилегиями суперпользователя, а затем устанавливает флаг pf forknoexec, показывающий, что потомок еще не сделал системный вызов execve ().

9. Сохраняет идентификатор нового процесса в поле tsk ->pid.

10. Если флаг clone_parent_settid в параметре cione_fiags установлен, функция копирует идентификатор процесса – потомка в переменную пользовательского режима, на которую указывает параметр parent tidptr.

11. Инициализирует структуры list head и спин – блокировки, входящие в состав дескриптора процесса – потомка, и устанавливает некоторые другие поля, имеющие отношение к ожидающим доставки сигналам, таймерам и хронометрической статистики.

12. Вызывает функции copy_semundo (), copy_files (), copy_fs(), copy_ sighand (), copy_signal (), copy_mm () И copy_namespace (), чтобы создать НОВЬЮ структуры и занести в них значения соответствующих структур родителя, если противоположное не указано с помощью параметра

clone_flags.

13. Вызывает функцию copy thread (), чтобы инициализировать стек режима ядра для процесса – потомка значениями, содержавшимися в регистрах

процессора в момент выдачи системного вызова clone о (эти значения были сохранены в родительском стеке режима ядра; см. главу 10). При этом, однако, функция принудительно записывает 0 в поле, соответствующее регистру еах (это код возврата системного вызова fork о или clone о в процессе – потомке). Поле thread, esp в дескрипторе потомка инициализируется базовым адресом стека режима ядра процесса – потомка, а адрес ассемблерной функции ret_from_fork() сохраняется в поле thread, eip. Если родитель пользуется битовой картой разрешений ввода/вывода, потомок получает копию этой карты. Наконец, если установлен флаг clone settls, потомок получает TLS – сегмент, определяемый структурой данных режима пользователя, на которую указывает параметр tIs системного вызова clone () 9.

14. Если установлен флаг clone_child_settid или clone_child_cleartid в параметре cione fiags, функция копирует значение параметра chiid tidptr В ПОЛе tsk ->set_chid_tid ИЛИ tsk ->clear_child_tid соответственно. Эти флаги говорят о том, что значение переменной, на которую указывает параметр chiid tidptr, в адресном пространстве потомка в режиме пользователя должно быть изменено, хотя физически операции записи будут выполнены позже.

15. Сбрасывает флаг tif syscall trace в структуре thread info процесса – потомка, чтобы функция ret_from_fork () не уведомляла процесс – отладчик о завершении системного вызова. Заметим, что при этом системный вызов на мониторинг потомка не отменяется, потому что этим управляет флаг PTRACE_SYSCALL В ПОЛе tsk ->ptrace.

16. Инициализирует поле tsk ->exit_signai номером сигнала, указанным в младших битах параметра cione fiags, если флаг clone thread не установлен. В последнем случае инициализирует это поле значением – 1. Как мы увидим в разд. “Завершение процесса” далее в этой главе, только завершение работы последнего члена группы потоков (как правило, это лидер группы) приводит к отправке уведомляющего сигнала родителю лидера группы.

17. Вызывает функцию sched forko, чтобы завершить инициализацию структуры данных для планировщика, принадлежащей новому процессу. Функция также переводит новый процесс в состояние task running и записывает 1 В поле preempt count Структуры thread info, отключая тем самым вытеснение в ядре. Кроме того, чтобы планирование процессов имело справедливый характер, функция делит оставшийся отрезок времени родителя между родителем и потомком.

18. Записывает в поле сри структуры thread info нового процесса номер локального процессора, полученный ОТ функции smp_processor_id().

19. Инициализирует поля, определяющие отношения между родителем и потомком. В частности, если флаг clone_parent или clone_thread установлен, функция инициализирует поля tsk ->reai_parent и tsk ->parent значением, хранящимся в поле current ->reai_parent, и в результате родитель потомка выступает в качестве родителя текущего процесса. В противном случае функция записывает в эти поля значение current.

20. Если мониторинг потомка не требуется (флаг clone ptrace не установлен), функция записывает 0 в поле tsk ->ptrace. Это поле содержит несколько флагов, используемых при мониторинге одного процесса другим. Таким образом, даже если текущий процесс отслеживается, потомок отслеживаться не будет.

21. Выполняет макрос set links, чтобы занести дескриптор нового процесса в список процессов.

22. Если мониторинг потомка требуется (флаг pt ptraced в поле tsk ->ptrace установлен), функция записывает в поле current ->parent значение поля tsk ->parent и заносит процесс – потомок в список отслеживаемых процессов, принадлежащий отладчику.

23. Вызывает функцию attach pid (), чтобы занести идентификатор нового процесса в хеш – таблицу pidhash [pidtype_pid] .

24. Если потомок является лидером группы потоков (флаг clone thread сброшен), функция:

•инициализирует поле tsk ->tgid значением из поля tsk ->pid;

•инициализирует поле tsk ->group_ieader значением из поля tsk;

•трижды вызывает функцию attach pido, чтобы занести идентификатор процесса – потомка в хеш – таблицы pidtype tgid, pidtype pgid и

PIDTYPE SID.

25. В противном случае, т. е. если потомок принадлежит к группе потоков своего родителя (флаг clone thread установлен), функция:

•инициализирует ПОЛе tsk ->tgid Значением ИЗ ПОЛЯ tsk ->current ->tgid;

•инициализирует поле tsk ->group_leader Значением из ПОЛЯ current -> group_leader;

•вызывает функцию attach pid (), чтобы занести процесс – потомок в хеш – таблицу pidtype tgid (точнее, в список, соответствующий идентификатору процесса и принадлежащий процессу current ->group_ leader).

26. Итак, новый процесс добавлен к множеству существующих процессов. Функция увеличивает значение переменной nr threads.

27. Устанавливает значение переменной totai forks, чтобы отразить в ней количество ответвленных процессов.

28. Завершает выполнение, возвращая указатель на дескриптор процесса – потомка (tsk).

В будущем, при очередном переключении процессов, планировщик окажет нашему процессу такую любезность, загрузив в соответствующие регистры процессора значения из поля thread дескриптора этого процесса. В частности, в регистр esp будет загружено значение thread.esp (то есть адрес стека процесса – потомка в режиме ядра), а в регистр eip —адрес функции ret from fork (). Эта функция, написанная на ассемблере, вызывает функцию scheduie taii о, загружает в остальные регистры значения, хранящиеся в стеке, и переводит процессор в режим пользователя, выполнение нового процесса начнется сразу по окончании работы системного вызова fork о, vfork () или clone (). Значение, возвращенное системным вызовом, содержится в регистре еах: оно равно 0 для потомка и идентификатору процесса для родителя. Чтобы понять, как это получается, вернитесь к описанию действий функции copy thread () над регистром еах для процесса – потомка. Потомок выполняет тот же код, что и родитель, с той разницей, что системный вызов fork() возвращает 0 (шаг 13 в описании функции copy process о). Разработчик приложения может воспользоваться этим фактом, применив прием, знакомый всем, кто программирует в Unix.

Традиционные Unix – системы обращаются со всеми процессами одинаково: ресурсы, которыми обладает процесс – родитель, дублируются в процессах – потомках. Такой подход делает процедуру создания процессов очень медленной и неэффективной, потому что включает в себя копирование всего адресного пространства процесса – родителя. Процессу – потомку редко нужно читать или модифицировать все ресурсы, унаследованные от родителя; в большинстве случаев он тут же делает системный вызов execve () и очищает столь заботливо скопированное адресное пространство.

Когда один из этих процессов попытается сделать запись в физическую страницу, ядро копирует ее содержимое в новую физическую страницу, которая присваивается пишущему процессу;
облегченные процессы позволяют как родителю, так и потомку совместно использовать многие структуры данных ядра, назначаемые процессам. Сюда входят таблицы страниц (и, следовательно, все адресное пространство режима пользователя, таблицы открытых файлов и диспозиций сигналов);
системный вызов vforko создает процесс, который использует адресное пространство своего родителя. Чтобы не позволить родителю переписать данные, необходимые потомку, выполнение родителя задерживается до тех пор, пока потомок не закончит свою работу или не запустит новую программу.

регистре его был установлен макросом uniazy_fpu (), поэтому, как только процесс next попытается выполнить инструкцию ESCAPE, MMX или SSE/SSE2, управляющий блок возбудит исключение “Устройство недоступно”, а ядро (точнее, обработчик этого исключения) вызовет функцию math state restore (). В этом обработчике процесс next идентифицируется как current.

void math_state_restore()

(

asm volatile (“cits”); / сбросить флаг TS в регистре crO / if (!(current ->flags & PF_USED_MATH)) init_fpu(current);

restore_fpu(current); current ->thread.status |= TS_USEDFPU;

)

Функция сбрасывает флаг ts в регистре его, чтобы последующие инструкции FPU, ММХ или SSE/SSE2, выполняемые процессом, не привели к возникновению исключения Устройство недоступно”. Если содержимое субполя thread.i387 смысла не имеет, т. е. флаг pf used math равен 0, вызывается функция init fpuo, которая сбрасывает субполе thread.i387 и устанавливает флаг pf used math процесса current. Затем вызывается функция restore fpu (), загружающая в регистры FPU соответствующие значения, хранящиеся в субполе thread.i387. Для этого применяется ассемблерная инструкция fxrstor или frstor, в зависимости от того, поддерживает ли процессор расширения SSE/SSE2. Наконец, функция math_state_restore() устанавливает флаг TS_USEDFPU.

Использование блоков FPU, ММХ и SSE/SSE2 в режиме ядра

Ядро само может использовать блоки FPU, ММХ и SSE/SSE2. Конечно, при этом оно не должно мешать вычислениям, которые выполняет текущий процесс в пользовательском режиме. Поэтому

? перед использованием сопроцессора ядро должно вызвать функцию kernel fpu begin (), КОТОрая вызывает функцию save init fpu (), Чтобы сохранить содержимое регистров, если процесс в пользовательском режиме выполнял инструкции FPU (флаг ts usedfpu), а затем сбрасывает флаг ts в регистре его;

? после использования сопроцессора ядро должно вызвать функцию kernei fpu end (), которая устанавливает флаг ts в регистре его.

Впоследствии, когда процесс пользовательского режима выполнит инструкцию сопроцессора, функция math state restore о восстановит содержимое регистров, аналогично тому, как это происходит при переключении процессов.

Следует отметить, ЧТО время работы функции kernel fpu begin () довольно велико, если текущий процесс пользовательского режима обращается к сопроцессору. Настолько велико, что этого достаточно для аннулирования выигрыша, полученного от применения блоков FPU, ММХ или SSE/SSE2. На практике ядро пользуется ими лишь в некоторых ситуациях, как правило, при переносе или очистке больших областей памяти или при вычислении контрольных сумм.

Очевидным недостатком этого архитектурного решения является невозможность для программистов применять инструкции с плавающей точкой вместе с MMX – инструкциями. Достоинство же заключается в том, что разработчики операционной системы могут игнорировать новый набор инструкций, потому что фрагмент кода, переключающего процессы, отвечающий за сохранение состояния блока FPU, может быть использован и для сохранения состояния блока ММХ.
MMX – инструкции ускоряют работу мультимедийных приложений, потому что реализуют внутри процессора конвейер SIMD (Single – Instruction Multiple – Data, одна инструкция -множественные данные”). В модели Pentium III возможности SIMD – конвейера расширяются за счет введения расширений SSE (Streaming SIMD Extensions, потоковые расширения SIMD), которые позволяют обрабатывать значения с плавающей точкой, хранящиеся в 128 – битовых регистрах, называемых ХММ – регистроми. Такие регистры не перекрываются регистрами FPU и ММХ, так что инструкции SSE можно смело смешивать с инструкциями FPU/ММХ. В модели Pentium 4 появилась еще одна функциональная возможность -расширения SSE2. В принципе, это SSE – расширения с поддержкой значений с плавающей точкой с повышенной точностью. Расширения SSE2 используют тот же набор ХММ – регистров, что и расширения SSE.

Микропроцессоры 80×86 не сохраняют автоматически регистры FPU, ММХ и ХММ в сегменте состояния задачи. Однако они предоставляют некоторую аппаратную поддержку, позволяющую ядру сохранять эти регистры только тогда, когда это действительно необходимо. Поддержка сводится к флагу ts в регистре его, причем соблюдаются следующие правила:
? каждый раз, когда производится переключение аппаратного контекста, флаг ts устанавливается;
? каждый раз, когда инструкция ESCAPE, ММХ, SSE или SSE2 выполняется при установленном флаге ts, управляющий блок возбуждает исключение “Устройство недоступно”.

Флаг ts позволяет ядру сохранять и восстанавливать регистры FPU, ММХ и ХММ, только когда это действительно необходимо. В качестве иллюстрации предположим, что процесс А пользуется математическим сопроцессором. Когда происходит переключение контекста с А на В, ядро устанавливает флаг ts и сохраняет регистры с плавающей точкой в сегменте состояния задачи, которым пользуется процесс А. Если новый процесс В не работает с математическим сопроцессором, ядру не нужно будет восстанавливать содержимое регистров с плавающей точкой. Но как только процесс В попытается выполнить инструкцию ESCAPE или ММХ, процессор возбудит исключение “Устройство недоступно”, и соответствующий обработчик загрузит в регистры с плавающей точкой значения, сохраненные в сегменте состояния задачи процесса В.

Теперь мы опишем структуры данных, применяемые при избирательной загрузке регистров FPU, ММХ и ХММ. Они хранятся в дескрипторе процесса, в субполе thread. i387, формат которого описывается объединением
i387_union:
union i387_union (
struct i387_fsave_struct fsave; struct i387_fxsave_struct fxsave; struct i387_soft_struct soft;
);
Из описания видно, что поле может хранить структуры только одного из трех типов. Тип i387_soft_struct применяется моделями процессоров без математического сопроцессора, и ядро Linux до сих пор поддерживает эти старые чипы, эмулируя сопроцессор программным образом. Впрочем, мы больше не будем обсуждать этот морально устаревший случай. Тип i387_fsave_struct используется в процессорах, имеющих математический сопроцессор и, возможно, блок ММХ. Наконец, тип i387_fxsave_struct используется процессорами, поддерживающими расширениями SSE и SSE2.
Дескриптор процесса содержит два дополнительных флага:
? флаг TS USEDFPU, ВХОДЯЩИЙ В состав ПОЛЯ status дескриптора thread_info. Он показывает, использовал ли процесс регистры FPU, ММХ и ХММ в текущем выполнении;
? флаг PF USED MATH, ВХОДЯЩИЙ В состав ПОЛЯ flags дескриптора task_struct. Этот флаг показывает, имеет ли смысл содержимое субполя thread.i387. Флаг сбрасывается (содержимое смысла не имеет) в следующих двух случаях:
oкогда процесс запускает новую программу, делая системный вызов execve () (см. главу 20). Поскольку управление не будет возвращено прежней программе, данные в поле thread.i387 никогда не понадобятся;
oкогда процесс, выполнявший программу в пользовательском режиме, запускает процедуру обработчика сигнала (см. главу 11). Поскольку обработчики сигналов асинхронны по отношению к программе, содержимое регистров с плавающей точкой может быть бессмысленным для обработчика сигнала. Тем не менее ядро сохраняет регистры с плавающей точкой в поле thread.i387 до начала выполнения обработчика и восстанавливает их после его окончания. Поэтому обработчику сигнала разрешается использовать математический сопроцессор.
Сохранение регистров FPU
Как было сказано ранее, функция switch to () выполняет макрос uniazy
fpu, передавая ему в качестве аргумента дескриптор замещаемого процесса prev. Макрос проверяет значение флага ts usedfpu у процесса prev. Если флаг установлен, значит, процесс prev пользовался инструкциями FPU, ММХ, SSE или SSE2, и ядро должно сохранить соответствующий аппаратный контекст:
if (prev ->thread_info ->status & TS_USEDFPU) save_init_fpu(prev);
Функция save init fpu () выполняет следующие действия:
1. Сохраняет содержимое регистров FPU в дескрипторе процесса prev, после чего заново инициализирует блок FPU. Если процессор использует расширения SSE/SSE2, функция также сохраняет содержимое регистров ХММ и заново инициализирует блок SSE/SSE2. Для реализации всего этого достаточно пары строчек на мощном расширенном встроенном ассемблере; либо
asm volatile( “fxsave %0 ; fnclex”
: M=mM (prev ->thread.i387.fxsave) );,
если процессор использует расширения SSE/SSE2, либо
asm volatile( “fnsave %0 ; fwait”
: “=m” (prev ->thread.i387.fsave) );
в противном случае.
2. Сбрасывает флаг ts usedfpu процесса prev: prev ->thread_info ->status &= ~TS_USEDFPU;
3. Устанавливает бит ts в регистре его при помощи макроса stts (), который на практике возвращает следующие ассемблерные инструкции:
movl %сгО, %еах orl $8,%еах movl %еах, %сгО.

Во-первых, макрос принимает три параметра, prev, next и last. Нетрудно догадаться о назначении параметров prev и next: они играют ту же роль, что и локальные переменные prev и next, т. е. являются входными параметрами, задающими ячейки памяти, хранящие адреса дескрипторов замещаемого процесса и замещающего процесса соответственно.

А как насчет третьего параметра, last? Дело в том, что в каждое переключение процессов вовлечены не два, а три процесса. Предположим, ядро приняло решение переключиться с процесса А на процесс В. В функции schedule о переменная prev указывает на дескриптор процесса A, a next —на дескриптор процесса В. Как только макрос switch to деактивирует процесс А, его выполнение прекращается.

Впоследствии, когда ядро решит возобновить выполнение процесса А, оно должно будет приостановить некоторый процесс С (вообще говоря, отличный от В), для чего вызовет макрос switch to с параметром prev, указывающим на С, и параметром next, указывающим на А. Когда процесс А продолжит работу, он найдет свой старый стек режима ядра, где локальная переменная prev указывает на дескриптор процесса А, а переменная next указывает на дескриптор процесса В. Планировщик, который теперь выполняется от имени процесса А, не имеет ссылки на процесс С. Однако оказывается, что эта ссылка нужна для завершения процедуры переключения процессов.

Последний параметр макроса switch to является выходным и задает ячейку памяти, в которую макрос запишет адрес дескриптора процесса С (естественно, это делается после того, как процесс А возобновит выполнение). Перед переключением процессов макрос сохраняет в процессорном регистре еах содержимое переменной, идентифицируемой первым входным параметром prev, т. е. содержимое локальной переменной prev, хранящейся в стеке режима ядра, принадлежащем процессу А. У процессов, в эту ячейку записывается адрес дескриптора процесса С. В текущей реализации функции schedule о последний параметр идентифицирует локальную переменную prev процесса А, так что prev переписывается адресом процесса С.

Содержимое стеков режима ядра процессов А, В и С, а также значения регистрах. Необходимо учитывать, что на рисунке показано значение локальной переменной prev до того, как оно будет переписано содержимым регистра еах.

Макрос switch to написан на расширенном встроенном ассемблере, который довольно трудно читать. В частности, ссылки на регистры делаются с помощью специальной позиционной нотации, которая позволяет компилятору самостоятельно решать, какими регистрами общего назначения он будет пользоваться. Вместо того чтобы приводить здесь громоздкий код на расширенном встроенном ассемблере, мы опишем работу макроса switch to в архитектуре 80×86, пользуясь стандартным ассемблером. Итак, макрос switch to выполняет следующие действия:

1. Сохраняет значения параметров prev и next в регистрах еах и edx соответственно:

movl prev, %еах movl next, %edx

2. Сохраняет содержимое регистров efiags и еЬр в стеке режима ядра процесса prev. Эти регистры нужно сохранить, потому что компилятор предполагает их неизменность вплоть до окончания макроса switchto:

pushfl pushl %ebp

3. Сохраняет содержимое регистра esp В поле prev ->thread.esp, чтобы это поле указывало на верхушку стека режима ядра процесса prev:

movl %esp,484(%еах)

Операнд 484(%еах) идентифицирует ячейку памяти, адрес которой равен содержимому регистра еах, увеличенному на 484.

4. Загружает значение next ->thread.esp в регистр esp. С этого момента ядро работает со стеком режима ядра процесса next, т. е. эта инструкция фактически выполняет переключение от процесса prev к процессу next. Поскольку адрес дескриптора процесса тесно связан с адресом стека режима ядра, смена стека ядра равносильна смене текущего процесса.

movl 484(%edx), %esp

5. Сохраняет адрес с меткой 1 (о нем далее в этом разделе) в поле prev ->thread. eip. Когда замещаемый процесс возобновит свое выполнение, он выполнит инструкцию с меткой 1:

movl $lf, 480(%еах)

6. Заносит значение поля next ->thread. eip в стек режима ядра процесса next. В большинстве случаев это адрес с меткой 1:

pushl 480(%edx)

7. Переходит на выполнение функции switch to (), написанной на языке С

(см. следующий раздел):

jmp switch_to

8. Здесь процесс А, который был замещен процессом В, снова получает в свое распоряжение процессор. Выполняется ряд инструкций, восстанавливающих содержимое регистров efiags. Первая инструкция имеет метку 1:

1:

popl %ebp popf 1

Обратите внимание, что эти инструкции pop работают со стеком ядра, принадлежащим процессу prev. Они будут выполнены, когда планировщик выберет prev в качестве нового процесса, подлежащего выполнению, и вызовет макрос switch to, передав ему prev в качестве второго параметра. Таким образом, регистр esp указывает на стек режима ядра процесса

prev.

9. Копирует содержимое регистра еах (загруженное на шаге 1) в ячейку памяти, идентифицируемую параметром last макроса switch to:

movl %еах, last

Как было сказано ранее, регистр еах указывает на дескриптор только что замещенного процесса6.

Функция switch_to()

Функция switch to о выполняет основную часть работы по переключению процессов, начатой макросом switch to (). Она принимает параметры prev p и next p, обозначающие старый и новый процессы соответственно. Вызов этой функции отличается от вызова среднестатистической”функции, поскольку функция switch to о берет значения параметров prev p и next p из регистров еах и edx (в которых, как мы видели, эти значения сохраняются), а не из стека, как большинство других функций. Чтобы заставить функцию брать параметры из регистров, ядро применяет ключевые слова attribute и regparm, являющиеся нестандартными расширениями языка С, реализованными в компиляторе gcc. Функция switch toO объявлена в заголовочном

файле include/asm – i386/system.h следующим образом:

switch_to(struct task_struct prev_p,

struct task_struct next_p)

attribute (гедрагш(З) ) ;

Она выполняет следующие действия:

1. Выполняет код, возвращенный макросом uniazy_fpu() (см. разд. “Сохранение и загрузка регистров FPU, ММХ и ХММ”далее в этой главе), чтобы сохранить содержимое регистров FPU, ММХ и ХММ процесса prev p, если необходимо.

unlazy_fpu (prev_p) ;

2. Выполняет макрос smp_processor_id(), чтобы получить индекс локального процессора, т. е. процессора, выполняющего код. Макрос извлекает искомый индекс из поля сри структуры thread info текущего процесса и сохраняет его в локальной переменной.

3. Загружает значение поля next_p ->thread.espO в поле espO сегмента состояния задачи, ассоциированного с локальным процессором. Как мы узнаем из разд. “Выдача системного вызова с помощью инструкции sysenter”, любое последующее изменение уровня привилегий от режима пользователя до режима ядра, вызванное ассемблерной инструкцией sysenter, приведет к копированию этого адреса в регистр esp:

init_tss[cpu].espO = next_p ->thread.espO;

4. Загружает в глобальную таблицу дескрипторов локального процесса сегменты TLS (Thread – Local Storage), используемые процессом next p. Три селектора сегментов хранятся в массиве tis array в дескрипторе процесса (см. главу 2).

cpu_gdt_table[сри][б] = next_p ->thread.tls_array[0]; cpu_gdt_table[сри][7] = next_p ->thread.tls_array[1]; cpu_gdt_table[cpu][8] = next_p ->thread.tls_array[2];

5. Сохраняет содержимое сегментных регистров fs и gs в полях prev_p -> thread.fs и prev_p ->thread.gs, соответственно, выполняя следующие ассемблерные инструкции:

movl %fs, 40 (%esi) movl %gs, 44(%esi)

Регистр esi указывает на структуру prev_p ->thread.

6. Если сегментный регистр fs или gs был уже использован процессом prev p или next p (то есть если они содержат ненулевое значение), функция загружает в эти регистры значения, хранящиеся в дескрипторе thread struct процесса next p. Этот шаг логически дополняет действия, выполненные в предыдущем. Главными ассемблерными инструкциями при этом являются:

movl 40(%ebx),%fs movl 44(%ebx),%gs

Регистр ebx указывает на структуру next_p ->thread. На самом деле, код намного сложнее, потому что процессор может возбудить исключение, если он обнаружит недопустимое значение в сегментном регистре. Код учитывает эту возможность, прибегая к приему “обработка исключения”. Поскольку процессы редко модифицируют битовую карту разрешений ввода/вывода, она обрабатывается в ленивом”режиме. Реальная битовая карта копируется в сегмент состояния задачи локального процессора, только если процесс действительно обращается к порту ввода/вывода в текущем интервале времени. Битовая карта разрешений ввода/вывода, принадлежащая какому-то процессу, хранится в буфере, на который указывает поле io bitmap ptr структуры thread info этого процесса. Функция handie io bitmap () устанавливает значение в поле io bitmap сегмента состояния задачи локального процессора для процесса next p следующим образом:

•если процесс next p не имеет собственной битовой карты разрешений ввода/вывода, в поле io bitmap сегмента состояния задачи записывается значение 0×8000;

•если у процесса next p есть собственная битовая карта разрешений ввода/вывода, в поле io bitmap сегмента состояния задачи записывается значение 0×9000.

Поле io bitmap сегмента состояния задачи должно содержать смещение внутри этого сегмента, определяющее место хранения реальной битовой карты. Значения 0×8000 и 0×9000 указывают за пределы сегмента TSS, что послужит причиной возбуждения исключения Общий сбой защиты”, как только процесс режима пользователя попытается обратиться к порту ввода/вывода (см. разд. “Исключения” главы 4). Обработчик исключения do_general_protection() проверит Значение В ПОЛе io bitmap. ЕСЛИ ОНО равно 0×8000, функция отправит сигнал sigsegv процессу в пользовательском режиме. Если же оно равно 0×9000, функция скопирует битовую карту процесса (на которую указывает поле io bitmap ptr структуры thread info) в сегмент состояния задачи локального процессора, запишет в поле io bitmap фактическое смещение битовой карты и форсирует новое выполнение ассемблерной инструкции, приведшей к возбуждению исключения.

9. Завершает работу. Функция switch to о (написанная на языке С) заканчивается оператором:

return prev_p;

Соответствующие ассемблерные инструкции, сгенерированные компилятором, выглядят так:

movl %edi,%eax ret

Параметр prev р (сейчас хранящийся в регистре edi) копируется в регистр еах, потому что значение, возвращаемое любой функцией на языке С, передается через регистр еах. Обратите внимание, что таким образом значение регистра еах оказывается одинаковым до и после вызова функции

switch to (). Это очень важно, потому что при вызове макроса switch to

подразумевается, что регистр еах всегда хранит адрес дескриптора замещаемого процесса.

Ассемблерная инструкция ret загружает в счетчик команд eip адрес возврата, хранящийся на верхушке стека. Однако функция switch to () была вызвана простой инструкцией перехода. Поэтому инструкция ret находит на верхушке стека адрес инструкции с меткой 1, который был положен в стек макросом switch to. Если процесс next p до этого не приостанавливался, потому что выполняется впервые, функция находит начальный адрес функции ret f rom fork ().