Що робить системний дзвінок brk ()?

Відповідно до посібника програмістів Linux:

brk () та sbrk () змінюють місце перерви в програмі, що визначає кінець сегмента даних процесу.

Що тут означає сегмент даних? Це просто сегмент даних або дані, BSS та купа разом?

Згідно з wiki:

Іноді ділянки даних, BSS та купи купу називають «сегментом даних».

Я не бачу причин для зміни розміру просто сегменту даних. Якщо це дані, BSS і купа разом, то це має сенс, оскільки купа отримає більше місця.

Що підводить мене до мого другого питання. У всіх прочитаних до цього часу статтях автор говорить, що купа росте вгору, а стек росте вниз. Але те, що вони не пояснюють, - це те, що відбувається, коли купа займає весь простір між купою і стеком?

На діаграмі, яку ви розмістили, "перерва" - адреса, якою маніпулюється brkта sbrk- є пунктирною лінією у верхній частині купи.

Документація, яку ви прочитали, описує це як кінець "сегменту даних", оскільки в традиційних (бібліотеки, що мають загальний доступ,mmap ) сегмент даних Unix був безперервним з купою; перед запуском програми ядро ​​завантажило б блоки "текст" та "дані" в оперативну пам'ять, починаючи з нуля адреси (фактично трохи вище нуля адреси, так що вказівник NULL справді нічого не вказував) і встановив адресу перерви на кінець сегмента даних. Перший виклик до цього mallocбуде використовуватися sbrkдля переміщення розбиття та створення купи між вершиною сегмента даних та новою, більш високою адресою розриву, як показано на схемі, і подальше використання mallocбуде використовувати його для збільшення купи у міру необхідності.

Тим часом стек починається у верхній частині пам'яті і зростає вниз. Стек не потребує явних системних викликів, щоб збільшити його; або він починається з стільки, скільки йому може бути надано оперативної пам’яті (це був традиційний підхід), або є область зарезервованих адрес під стеком, якій ядро ​​автоматично виділяє оперативну пам’ять, коли помічає спробу записати туди (це сучасний підхід). Так чи інакше, у нижній частині адресного простору може бути, а може і не бути, область захисту, яка може бути використана для стека. Якщо цей регіон існує (усі сучасні системи роблять це), він назавжди не має карти; якщо будь-якийстек або купа намагаються перерости в нього, ви отримуєте помилку сегментації. Традиційно, однак, ядро ​​не робило спроб застосувати межу; стек може перерости в купу, або купа може перерости в стек, і в будь-якому випадку вони переписуватимуть дані один одного, і програма вийде з ладу. Якщо вам дуже пощастило, воно б одразу вийшло з ладу.

Я не впевнений, звідки походить число 512 Гб на цій діаграмі. Він передбачає 64-розрядний віртуальний адресний простір, що не відповідає дуже простої карті пам'яті, яка у вас є. Справжній 64-бітний адресний простір виглядає приблизно так:

              Legend:  t: text, d: data, b: BSS

Це не на віддаленому масштабі, і це не повинно трактуватися як саме те, що робить будь-яка дана ОС (після того, як я намалював це, я виявив, що Linux насправді ставить виконуваний файл набагато ближче до нульової адреси, ніж я вважав, що це було, і спільні бібліотеки на дивно високі адреси). Чорні області на цій діаграмі не розміщені - будь-який доступ викликає негайне сегментування - і вони є гігантськими щодо сірих областей. Світло-сірі регіони - це програма та її спільні бібліотеки (може бути десятки спільних бібліотек); кожен має незалежнутекст та сегмент даних (і сегмент "bss", який також містить глобальні дані, але ініціалізується на "всі біти-нулі", а не займає місце у виконуваному файлі чи бібліотеці на диску). Купа більше не обов'язково суцільна з сегментом даних виконуваного файлу - я намалював це так, але схоже, що Linux, принаймні, цього не робить. Стек вже не прив’язаний до вершини віртуального адресного простору, а відстань між купою та стеком настільки величезна, що вам не доведеться турбуватися про його перетин.

Перерва все ще є верхньою межею купи. Однак те, що я не показав, - це те, що десь там, в чорному, можуть бути десятки незалежних розподілів пам'яті, зроблених mmapзамість них brk. (ОС буде намагатися тримати їх далеко від brkрайону, щоб вони не стикалися.)

Приклад мінімальної експлуатації

Що робить системний дзвінок brk ()?

Просить ядро ​​дозволити вам читати та записувати у суміжний шматок пам'яті, який називається купами.

Якщо ви не запитаєте, це може вас розставити за замовчуванням.

Без brk:

#define _GNU_SOURCE
#include <unistd.h>

int main(void) {
    /* Get the first address beyond the end of the heap. */
    void *b = sbrk(0);
    int *p = (int *)b;
    /* May segfault because it is outside of the heap. */
    *p = 1;
    return 0;
}

З brk:

#define _GNU_SOURCE
#include <assert.h>
#include <unistd.h>

int main(void) {
    void *b = sbrk(0);
    int *p = (int *)b;

    /* Move it 2 ints forward */
    brk(p + 2);

    /* Use the ints. */
    *p = 1;
    *(p + 1) = 2;
    assert(*p == 1);
    assert(*(p + 1) == 2);

    /* Deallocate back. */
    brk(b);

    return 0;
}

GitHub вище за течією .

Вищезгадане може не потрапляти на нову сторінку і не сегментуватись навіть без brk, тому тут є більш агресивна версія, яка виділяє 16MiB і, швидше за все, може бути сегментацією без brk:

#define _GNU_SOURCE
#include <assert.h>
#include <unistd.h>

int main(void) {
    void *b;
    char *p, *end;

    b = sbrk(0);
    p = (char *)b;
    end = p + 0x1000000;
    brk(end);
    while (p < end) {
        *(p++) = 1;
    }
    brk(b);
    return 0;
}

Тестовано на Ubuntu 18.04.

Візуалізація віртуального адресного простору

Перед brk:

+------+ <-- Heap Start == Heap End

Після brk(p + 2):

+------+ <-- Heap Start + 2 * sizof(int) == Heap End 
|      |
| You can now write your ints
| in this memory area.
|      |
+------+ <-- Heap Start

Після brk(b):

+------+ <-- Heap Start == Heap End

Для кращого розуміння адресних просторів вам слід ознайомитись з підкачкою: Як працює підказка x86? .

Навіщо нам потрібно і те, brkі sbrk?

brkможна, звичайно, реалізовуватися за допомогою sbrkрозрахунків + зміщення, обидва існують лише для зручності.

У бекенді ядро ​​Linux v5.0 має єдиний системний виклик, brkякий використовується для реалізації обох: https://github.com/torvalds/linux/blob/v5.0/arch/x86/entry/syscalls/syscall_64. tbl # L23

12  common  brk         __x64_sys_brk

Є чи brkPOSIX?

brkраніше був POSIX, але він був видалений у POSIX 2001, тому необхідність _GNU_SOURCEдоступу до обгортки glibc.

Видалення, ймовірно, пов'язане з введенням mmap, який є суперсетом, який дозволяє виділити кілька діапазонів і більше варіантів розподілу.

Я думаю, що не існує дійсного випадку, коли слід використовувати brkзамість цього mallocабо mmapзараз.

brk проти malloc

brkце одна стара можливість реалізації malloc.

mmapце новіший суворо потужніший механізм, який, ймовірно, всі POSIX системи в даний час використовують для реалізації malloc. Ось мінімальний mmapприклад розподілу пам'яті, який можна виконати .

Чи можу я змішувати brkі лопатити

Якщо ваша mallocреалізована brk, я не маю уявлення, як це може не підірвати речі, оскільки brkкерує лише одним діапазоном пам'яті.

Однак я нічого не можу знайти про це у документах glibc, наприклад:

• https://www.gnu.org/software/libc/manual/html_mono/libc.html#Resizing-the-Data-Segment

Тут, ймовірно, просто працюватимуть речі, оскільки mmap, ймовірно, вони використовуютьсяmalloc .

Дивитися також:

• Що небезпечно / спадщини щодо brk / sbrk?
• Чому виклик sbrk (0) двічі дає інше значення?

Більше інформації

Внутрішньо ядро ​​вирішує, чи може процес мати стільки пам'яті, і виділяє сторінки пам'яті для цього використання.

Це пояснює, як стек порівнюється з купою: Яка функція інструкцій push / pop, що використовуються в регістрах у складі x86?

Ви можете використовувати brkі sbrkсамостійно, щоб уникнути "головної накладки", на яку завжди скаржаться всі. Але ви не можете легко використовувати цей метод спільно з mallocтим, що він підходить лише тоді, коли вам нічого не потрібно free. Тому що ти не можеш. Також слід уникати будь-яких дзвінків з бібліотеки, які можуть використовуватись mallocвнутрішньо. Тобто strlenнапевно, безпечно, але, fopenмабуть, ні.

Телефонуйте sbrkтак, як ви б зателефонували malloc. Він повертає вказівник на поточний розрив і збільшує перерву на цю суму.

void *myallocate(int n){
    return sbrk(n);
}

Поки ви не можете звільнити окремі асигнування (тому що їх немає надмірних витрат , пам’ятайте), ви можете звільнити весь простір , зателефонувавши brkзі значенням, поверненим першим викликом sbrk, таким чином, перемотавши brk .

void *memorypool;
void initmemorypool(void){
    memorypool = sbrk(0);
}
void resetmemorypool(void){
    brk(memorypool);
}

Ви навіть можете скласти ці регіони, відкинувши останній регіон, перемотавши перерву до початку регіону.

І ще одна річ ...

sbrkтакож корисний у коді гольфу, оскільки він на 2 символи коротший malloc.

Існує спеціальне призначене анонімне відображення приватної пам’яті (традиційно розташоване за межами даних / bss, але сучасний Linux фактично коригує розташування за допомогою ASLR). В принципі, це не краще, ніж будь-яке інше відображення, яке ви могли б створити за допомогою mmap, але Linux має деякі оптимізації, які дозволяють розширити кінець цього відображення (за допомогою brksyscall) вгору зі зниженою вартістю блокування відносно того, що mmapабо mremapпонесе. Це робить привабливими для mallocреалізації, що використовуються при реалізації основної маси.

Я можу відповісти на ваше друге запитання. Malloc вийде з ладу і поверне нульовий покажчик. Тому ви завжди перевіряєте нульовий покажчик, коли динамічно розподіляєте пам'ять.

Купа розміщується останньою в сегменті даних програми. brk()використовується для зміни (розширення) розміру купи. Якщо купа більше не може вирости, будь-який mallocдзвінок не вдасться.

Сегмент даних - це частина пам'яті, яка містить всі ваші статичні дані, зчитувані з виконуваного файлу при запуску і зазвичай заповнені з нулем.

malloc використовує системний виклик brk для розподілу пам'яті.

включати

int main(void){

char *a = malloc(10); 
return 0;
}

запустіть цю просту програму з strace, вона буде викликати brk-систему.