Honestly fuck brk() and all its works

@ljs what's brk()?

@ljs you can buy your very own brk, maybe mihai will deliver it this time

https://www.imago.cz/brk-na-psani-kruti

@fredbrooker https://www.man7.org/linux/man-pages/man2/brk.2.html - system call, sort of old school way of requesting more memory from the kernel, but is used heavily by userland allocators so is a very sensitive place in mm for perf...

And I appear to have regressed it by... 5% :>))

@pony oh hai Mihai 🍷

@ljs

Avoid using brk() and sbrk() for memory allocation. The malloc(3) memory allocation package offers a more portable, convenient, and efficient approach. Here's why:

Portability:

malloc() is a standard C library function, ensuring its availability across various platforms and operating systems.

brk() and sbrk() are system-specific functions that may not be available or have different behaviors on different systems.

@fredbrooker yeah, malloc() uses it, so you shouldn't.

But you use malloc() a LOT typically so you know, from the kernel perspective this system call gets hit a lot

@ljs

I am glad to be a PHP/bash programmer

@fredbrooker you have seen the film IT right? We kernel developers are the clowns in the drains asking whether you want your paper boat back

@ljs which movie exactly? (URL)

@ljs I used sbrk() when I had to implement a malloc() back at university. I didn’t touch it again afterwards and I will only do that again if I really must 😂

@fredbrooker

Original

https://www.youtube.com/watch?v=WeTgEtu1uoQ

Remake

https://www.youtube.com/watch?v=KrpSzRltoVc

@frankenmichl yeah I would strongly recommend you don't touch it unless you're implementing a userland allocator :>)

@ljs

found it

3b236f1e93c08e96ab77202bdcbceef0fb52ac90

@ljs I've seen the old version (I was first assuming IT = Information Technology)

@fredbrooker well IT is sort of a horror show so :P

@ljs

definitely :)

@ljs @frankenmichl I wouldn't touch it even then, as there are better alternatives

@vbabka @frankenmichl meh I think you can argue it's useful.

But you could probably just mmap() a big PROT_NONE and do it that way instead

@ljs @frankenmichl @vbabka glibc does that - the main thread's arena IIRC uses brk(), but other arenas (which start being created when you create more threads) use a big PROT_NONE allocation that is progressively made accessible.
(Which, by the way, gives us this fun behavior: https://lore.kernel.org/all/20241008-stack-gap-inaccessible-v1-1-848d4d891f21@google.com/ )

@jann @frankenmichl @vbabka JANN STOP BREAKING THINGS

@ljs @frankenmichl @vbabka I DON'T FIND THE BUGS, THE BUGS FIND ME

@jann @frankenmichl @vbabka have to give the standard tut tut that get_maintainer.pl would tell you that mm/mmap.c needs to be cc'd to me and Liam too as we're reviewers ;)

Will take a look when I have a sec + will ping Liam about it

@ljs @frankenmichl @vbabka Why? Nothing gets really allocated at brk() or mmap() time. Map your entire address space read/write and be done. As a bonus, you can get a rough feeling of what debugging bad pointers was like before MMUs were invented…

@ptesarik @frankenmichl @vbabka /exec

@ljs @frankenmichl @vbabka
/me disappears in the box of shame

@jann @frankenmichl @vbabka nah sorry man there's no need to feel shame, it's not like the kernel makes this easy given get_maintainers.pl gives you shit a lot of the time.

You're one of the smartest guys I've dealt with in the kernel just to be clear + hugely respect you... if I'm critical of the patch it's the patch not you!

I mean I'm kind of critical of how the fuck we dealt with this stack gap stuff in the first place but you know that's kernel cruft for ya...

Sometimes I think we don't say positive things enough :)

So some anti-Kent stuff above ^

@ljs @frankenmichl @vbabka I did not actually directly run scripts/get_maintainers.pl and instead used "b4 prep --auto-to-cc" and then, when that gave me a bunch of Rust maintainers because I mentioned Rust once in the diff, threw away the entire recipient list and wrote my own one manually...

And I mean, I also think my patch wasn't pretty, I agree with you on that. 😛

Yeah, I wish the kernel never had the concept of stacks that grow...