/g/ - syscall of the day: m(un)lock(all/2) - Technology


08/21/20	New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17	New trial board added: /bant/ - International/Random
10/04/16	New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]

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

File: 1741747320342433.jpg (62 KB, 736x540)

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

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/

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

Anonymous 04/11/26(Sat)10: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)10:18:54 No.108582561

Anonymous 04/11/26(Sat)10: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)10:29:00 No.108582644

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

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

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

Anonymous 04/11/26(Sat)10: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)10:44:08 No.108582738

Anonymous 04/11/26(Sat)10: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)10:44:47 No.108582742

Anonymous 04/11/26(Sat)10: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)11:06:18 No.108582893

Anonymous 04/11/26(Sat)11: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)11:57:26 No.108583191

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

No usecase.

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

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

>>108583191
cryptography

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

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

>>108583264
Encrypt your swap.

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

Anonymous 04/11/26(Sat)12: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)12:27:53 No.108583380

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

>>108583369
>enable
Errr, disable.

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

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

>>108582499
me on the right

Name
Options
Comment
Verification	4chan Pass users can bypass this verification. [Learn More] [Login]
File
Please read the Rules and FAQ before posting. You may highlight syntax and preserve whitespace by using [code] tags.