OSDev

А как контролировать переполнение в обе стороны? Будет ли правильно просто разделить разные стеки недоступными страницами, или нужно что-то еще?

Ну и по-поводу стеков ядра - вопрос спорный. Лично я делаю нереентерабельное и невытесняемое ядро, так что стеки ядра навреное не нужны.

_________________
Found a CPU. LAPIC ID: 00

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

Я описал то, что имею. Спорить не нужно. Есть какие-то собственные идеи, экспериментируй, а не спрашивай.

Прикладной стоп-фрейм может быть больше одной страницы. Это связано с проблемой неумышленного перехода через стоп-фрейм при выделении в стеке областей под большие структуры данных. Тут нужен компромисс.

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

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

Она в любом случае может произойти. ИМХО, достаточно обычной защиты памяти: для чужих областей -- никакого доступа, для своего кода -- чтение/выполнение, для данных (в т.ч. стека) -- чтение/запись. Во всяком случае, о "чересполосице" областей разного доступа (что нужно для защиты стеков) сама ОС по своей инициативе заботиться не должна никак. Если программист сочтёт нужным, он должен построить задачу соответствующим образом, выделив каждый стек в отдельную секцию со своими атрибутами доступа и объяснив загрузчику, что они должны грузиться с промежутками, а не вплотную (тогда защита, понятное дело, организована быть не может).

А как отлаживать без контроля?
Провокационный вопрос: а через сегменты не проще?
ПС: это не троллинг. идея правда мне только сейчас пришла.

_________________
Found a CPU. LAPIC ID: 00

Что значит "чужих областей"? Я говорил о стеках многопоточного приложения. Слишком глубокий стек может наложиться на другой стек или лежащие под ним данные.

Что касается разделения областей по назначению, то часто аппаратура не позволяет выставить абсолютно все требуемые для секции атрибуты. Я например не требую, чтобы приложение обязательно использовало стек, расположенный в стековой области. Оно может переопределить указатель стека на область данных, но тогда автоматически уменьшается гарантия того, что при наложении стека на данные возникнет исключение или что стек будет неисполняемым, т.к. данные у меня сейчас всегда исполняемые (IA-32), потому что иначе было бы невозможно в адресном пространстве приложения запустить какой-либо модуль кроме основного (секции отдельного модуля по возможности группируются вместе). Неисполняемой может быть только стековая область, да и то это не гарантированное поведение системы, а бонус конкретной версии ядра. Что касается "чересполосицы", то ядру ее нетрудно обеспечить, выставляя нужные атрибуты для соответствующих страниц. Другое дело, управление прикладными стеками на уровне ядра, как цельными объектами. Сейчас это реализовано в ядре, но я не исключаю вынос подобных функций на прикладной уровень в будущем.

Не проще. Все, что за гранью FLAT-адресации, не проще. Поэтому и приходится шаманить с сегментами, чтобы и их по возможности задействовать и остаться в рамках FLAT-адресации. К тому же не следует забывать о 64-разрядной архитектуре с практически полностью вырожденной сегментацией.

Кстати есть еще один способ работы со стеками. Сделать стеки потоков (и ядерные и прикладные) "переотображаемыми" на одни и те же участки адресного пространства. Я подобным не занимался, но данный подход в плане экономии пространства кажется весьма перспективным.

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