/g/ - Thread 108582499

Anonymous
syscall of the day: m(un)lock(all/2) 04/11/26(Sat)14:08:50 No.108582499

syscall of the day: m(un)lock(all/2) Anonymous 04/11/26(Sat)14:08:50 No.108582499 [Reply]▶

File: 1741747320342433.jpg (62.4 KB)

previous: >>108572928
#define __NR_mlock                    149
#define __NR_munlock                150
#define __NR_mlockall                151
#define __NR_munlockall                152
#define __NR_mlock2                325
https://man7.org/linux/man-pages/man2/mlock.2.html

tl;dr:
lock/unlock memory

by lock, we mean keep the memory pinned into RAM and prevent it from being swapped out
for once, i'm actually really happy with these syscalls. super nice change of pace. having to have a v2 of something isn't ideal, of course, but i'm still of the opinion that these syscalls in particular are really well designed. i think the flags are clear, sane, and useful. so i'm actually quite impressed. kudos to the developers on this one
interestingly, this syscall is one of the very few realistic ways for a developer to cause calls to malloc to fail. if you've never played around with it, it's actually surprisingly difficult to make that happen lol. so that's a neat piece of trivia
the notes section is also pretty good. very nice writeup on the "why" for these syscalls, as well as potential footguns, etc.
god this really is a breath of fresh air. more syscalls need to be like this...

relevant resources:
man man
man syscalls
https://man7.org/linux/man-pages/
https://linux.die.net/man/
https://elixir.bootlin.com/linux/
https://elixir.bootlin.com/musl/
https://elixir.bootlin.com/glibc/

24 RepliesView Thread

Showing all 24 replies.

Anonymous
04/11/26(Sat)14:14:13 No.108582536

Anonymous 04/11/26(Sat)14:14:13 No.108582536▶

>>108582499
>interestingly, this syscall is one of the very few realistic ways for a developer to cause calls to malloc to fail
There's no equivalent of VirtualAlloc with MEM_COMMIT on Linux?

Anonymous
04/11/26(Sat)14:18:54 No.108582561

Anonymous 04/11/26(Sat)14:18:54 No.108582561▶

>>108582536
oh, no, mmap has MAP_POPULATE, MAP_FIXED, etc.
https://man7.org/linux/man-pages/man2/mmap.2.html
i meant literally malloc(3) itself, not the syscalls it uses

Anonymous
04/11/26(Sat)14:29:00 No.108582644

Anonymous 04/11/26(Sat)14:29:00 No.108582644▶

>>108582561
Oh, okay. How do you do it?

Anonymous
04/11/26(Sat)14:37:30 No.108582702

Anonymous 04/11/26(Sat)14:37:30 No.108582702▶

>>108582644
cause malloc to fail with this?

       If MCL_FUTURE has been specified, then a later system call (e.g.,
       mmap(2), sbrk(2), malloc(3)), may fail if it would cause the
       number of locked bytes to exceed the permitted maximum (see
       below).  In the same circumstances, stack growth may likewise
       fail: the kernel will deny stack expansion and deliver a SIGSEGV
       signal to the process.

Anonymous
04/11/26(Sat)14:44:08 No.108582738

Anonymous 04/11/26(Sat)14:44:08 No.108582738▶

>>108582499
>v2 of something isn't ideal
BSDs wouldn't have messed up the first time btw

Anonymous
04/11/26(Sat)14:44:47 No.108582742

Anonymous 04/11/26(Sat)14:44:47 No.108582742▶

>>108582702
>then a later system call
>e.g. malloc(3)
That's a strange thing to write in a man page. Is this glibc-specific?

Anonymous
04/11/26(Sat)15:06:18 No.108582893

Anonymous 04/11/26(Sat)15:06:18 No.108582893▶

>>108582742
i also noticed that lol
it's technically slightly incorrect, but malloc calls one of the first two under the hood, so i can forgive it

Anonymous
04/11/26(Sat)15:57:26 No.108583191

Anonymous 04/11/26(Sat)15:57:26 No.108583191▶

No usecase.

Anonymous
04/11/26(Sat)16:08:37 No.108583264

Anonymous 04/11/26(Sat)16:08:37 No.108583264▶

>>108583191
cryptography

Anonymous
04/11/26(Sat)16:14:10 No.108583290

Anonymous 04/11/26(Sat)16:14:10 No.108583290▶

>>108583264
Encrypt your swap.

Anonymous
04/11/26(Sat)16:26:52 No.108583369

Anonymous 04/11/26(Sat)16:26:52 No.108583369▶

>>108582536
You could enable overcommit and then use PROT_NONE to reserve VAS without your commit charge going up.

Anonymous
04/11/26(Sat)16:27:53 No.108583380

Anonymous 04/11/26(Sat)16:27:53 No.108583380▶

>>108583369
>enable
Errr, disable.

Anonymous
04/11/26(Sat)16:29:26 No.108583387

Anonymous 04/11/26(Sat)16:29:26 No.108583387▶

>>108582499
me on the right

Anonymous
04/11/26(Sat)18:32:38 No.108584143

Anonymous 04/11/26(Sat)18:32:38 No.108584143▶

>>108583387
hi...

Anonymous
04/11/26(Sat)19:05:08 No.108584398

Anonymous 04/11/26(Sat)19:05:08 No.108584398▶

>>108583191
Ring buffers in real time critical applications, i.e. sound servers.

Anonymous
04/11/26(Sat)19:06:54 No.108584412

Anonymous 04/11/26(Sat)19:06:54 No.108584412▶

>>108584398
That shit belongs in the kernel though.

Anonymous
04/11/26(Sat)19:10:47 No.108584442

Anonymous 04/11/26(Sat)19:10:47 No.108584442▶

>>108584412
You want to be doing audio mixing in kernelspace?

Anonymous
04/11/26(Sat)19:12:35 No.108584454

Anonymous 04/11/26(Sat)19:12:35 No.108584454▶

>>108584442
Like ALSA, yeah.

Anonymous
04/11/26(Sat)19:45:32 No.108584691

Anonymous 04/11/26(Sat)19:45:32 No.108584691▶

>>108584442
>>108584454
>>108584412
eBPF kernel mixer when

Anonymous
04/11/26(Sat)19:51:18 No.108584744

Anonymous 04/11/26(Sat)19:51:18 No.108584744▶

>>108584691
The moment they finally admit that a separation between mechanism and policy doesn't make sense in a monolithic kernel.
So basically never.

Anonymous
04/11/26(Sat)22:45:16 No.108585784

Anonymous 04/11/26(Sat)22:45:16 No.108585784▶

>>108583290
not good enough

Anonymous
04/12/26(Sun)00:13:36 No.108586240

Anonymous 04/12/26(Sun)00:13:36 No.108586240▶

>>108585784
Why not?

Anonymous
04/12/26(Sun)00:20:02 No.108586266

Anonymous 04/12/26(Sun)00:20:02 No.108586266▶

How is kernel and system programming in rust like compared to c #include <sys/header>?
Does it end up invoking the same syscalls in the kernel. And if that’s the case, rust essentially being a wrapper around syscalls, why should I use rust?

Anonymous
04/12/26(Sun)01:30:03 No.108586628

Anonymous 04/12/26(Sun)01:30:03 No.108586628▶

>>108586266
>Does it end up invoking the same syscalls in the kernel.
I think the most straightforward way is to just use bindings to libc
low level rust is surprisingly similar to C
>why should I use rust?
I might be weird, but I really like sumtypes+tuples+match statement
the stdlib is also miles better than libc

Subject
Name
Comment
File	Supported: JPG, PNG, GIF, WebP, WebM, MP4, MP3 (max 4MB)
CAPTCHA

Reply to Thread #108582499

🔍 Search & Sort