klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
<moon-child> mmmm
<moon-child> I had to stop playing that game
<moon-child> oooh uranium
<moon-child> gonna blow some shit up?
<zid> Myself, mainly
<zid> krastorio makes uranium processing spit out iron and stone, always fun to have to deal with trash
<moon-child> krastorio? Is that a mod?
<zid> yea
<klange> I think I'll release a ToaruOS 2.1.
<zid> Does it run factorio?
<klange> no, and the next person to mention factorio is getting a totally unfair kicking
<heat> facts
<heat> :100:
<zid> heat did you hear about the round american stuffed cookie with trivia on them?
<heat> no
<zid> hmm, I tried one, and I really like em, they're called fact oreos
<Griwes> Now a kick for that would be, actually, a 100% fair kicking
<zid> Agreed
<klange> SO IT SHALL BE
zid was kicked from #osdev by klange [zid]
SpikeHeron has joined #osdev
<klange> (and zid was never seen in #osdev ever again)
nyah has quit [Remote host closed the connection]
gog has quit [Ping timeout: 268 seconds]
<klange> let's see, what do we have in 2.1... Non-lazy window resize, glyph caches improving text rendering speed in a bunch of stuff, Kuroko 1.3 with bigints and all that jazz, aarch64 support is technically new but I did a preview release of that ages ago...
<klange> new signal implementation, that's pretty big I guess... ability to unmap pages, that was really important for the non-lazy window resize to not just massively leak everything...
<heat> you couldn't unmap pages before?
<klange> Yep.
<klange> The most amusing instance of this is that for the longest time the wallpaper app would kill itself when you changed wallpapers, as the allocator couldn't reliably reuse freed blocks from textures and it would take up multiple megabytes it couldn't return to the system.
corecode has quit [Ping timeout: 248 seconds]
<heat> LOL
<klange> So I just made it restart.
<geist> noice
<geist> well to be fair unmapping is where it gets hard!
corecode has joined #osdev
<geist> in general creating things is easy, tearing it all down so that it goes back to zero safely is hard
<heat> crap
<heat> how do I erm, filter out arguments from GCC's target spec?
<heat> my great hardening features backfired
<bslsk05> ​github.com: svntogit-packages/PKGBUILD at packages/xf86-video-fbdev · archlinux/svntogit-packages · GitHub
Lumia has joined #osdev
<heat> it seems to work if i -z lazy
<heat> at least in theory
Lumia has quit [Changing host]
Lumia has joined #osdev
Gooberpatrol66 has joined #osdev
zid has joined #osdev
<zid> So, factorio
antranigv has joined #osdev
<pbx> klange: uploading an image for you now
<pbx> won't be an iso, also not stable at all
Lumia has quit [Quit: ,-]
<pbx> https://peterbjornx.nl/posnk_191022_hdd.img.gz don't be too harsh, please :)
<pbx> run with qemu-system-i386 -hda posnk_191022_hdd.img -serial stdio -device rtl8139 -enable-kvm -s
<pbx> user: root, pass: none
<pbx> startxsrv > /dev/null 2> /dev/null for gui. be patient, it is slow
<zid> I want a qemu device with vblank or something
<heat> virtio-gpu
<zid> 0 hits in the pdf
<zid> 0 for blanking, 0 for retrace
<heat> i suppose it works if you take advantage of the 3d acceleration?
<heat> idk
archenoth has joined #osdev
archenoth has quit [Remote host closed the connection]
archenoth has joined #osdev
<klange> The cirrus card should have vblank, if you're okay with old-school? And I think there's an emulated radeon GPU that should have it.
<heat> qxl may have it too
Oshawott has quit [Ping timeout: 246 seconds]
<klange> hw/display/ati.c:static void ati_vga_vblank_irq(void *opaque)
<klange> Huh, from git grepping I only see references to vblank for the radeon card... and pl110.
bauen1 has quit [Remote host closed the connection]
<klange> 'vsync' gets me... other stuff but not what I expected.
<moon-child> how bout them factories
<klange> pbx: this is where i ask annoying questions like "when _will_ it be an ISO?", and "64-bit when?", and "aarch64 when?"
<klange> (still downloading, how much stuff is in this disk image???)
<klange> ah it's done
<klange> pbx: I can't seem to type on the console.
<heat> moon-child, factores
<zid> I'll take a look at the cirrus card then
theruran has quit [Quit: Connection closed for inactivity]
[itchyjunk] has quit [Remote host closed the connection]
theruran has joined #osdev
heat has quit [Ping timeout: 250 seconds]
Lumia has joined #osdev
antranigv has quit [*.net *.split]
xenos1984 has quit [*.net *.split]
vdamewood has quit [*.net *.split]
wereii has quit [*.net *.split]
zaquest has quit [*.net *.split]
smeso has quit [*.net *.split]
rorx has quit [*.net *.split]
thaumavorio has quit [*.net *.split]
eck has quit [*.net *.split]
CompanionCube has quit [*.net *.split]
fkrauthan has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
Maja has quit [*.net *.split]
thinkpol has quit [*.net *.split]
immibis_ has quit [*.net *.split]
sortie has quit [*.net *.split]
AmyMalik has quit [*.net *.split]
vin has quit [*.net *.split]
JerryXiao has quit [*.net *.split]
corank_ has quit [*.net *.split]
ids1024 has quit [*.net *.split]
renopt has quit [*.net *.split]
seer has quit [*.net *.split]
Andrew has quit [*.net *.split]
koolazer has quit [*.net *.split]
Andrew has joined #osdev
klange has joined #osdev
smeso has joined #osdev
sortie has joined #osdev
JerryXiao has joined #osdev
fkrauthan has joined #osdev
xenos1984 has joined #osdev
seer has joined #osdev
m5zs7k has joined #osdev
CompanionCube has joined #osdev
corank_ has joined #osdev
eck has joined #osdev
antranigv has joined #osdev
Maja has joined #osdev
Ellenor has joined #osdev
wereii has joined #osdev
thaumavorio has joined #osdev
koolazer has joined #osdev
vdamewood has joined #osdev
rorx has joined #osdev
<geist> so i always hear that john carmack figuring out This One Trick to make scrolling smooth for commander keen was a big thing
<geist> now i wonder, what precisely is the trick?
<zid> EGA register buggery
<geist> maybe some mechanism to move the framebuffer(s) (i think EGA was tiled) by one pixel at a time
<zid> hardware scrolling using a slightly wider backbuffer than the viewport
<zid> 64px of underscan
<zid> which is just totally standard on say, a NES/gameboy/etc
<zid> but his thing also has to deal with hw sprites and dirty-update
<zid> err non-hw
<geist> yah
<geist> and the tiled stuff iirc
<geist> though there was some reason that modeX's tiling was faster, etc
<zid> I can't find my mouse
<geist> huh doing an apt-get and it seems that dpkg is taking forever
<geist> 100% cpu, not waiting on anything
<geist> it's making forward progress, just really slow
<zid> I'll have to get a mouse trap tomorrow
<geist> yeah i have a cat that occasinoally performs her duty
Lumia has quit [Remote host closed the connection]
Lumia has joined #osdev
<zid> cat is busy asleep downstairs
klys has quit [Remote host closed the connection]
<geist> mjg_: oh FWIW this pentium 4 has DDR2-400 ram. seems to get about 1800MB/sec in memtest86
<geist> just FYI
smach has quit []
Lumia has quit [Ping timeout: 246 seconds]
kindofwonderful has joined #osdev
<kindofwonderful> good morning
<geist> just found a weird bug... and it turned out to be an inline assembler problem that's always been there
<bslsk05> ​github.com: lk/x86.h at master · littlekernel/lk · GitHub
<geist> (hint all of the rep versions of those macros have it, i think)
<kindofwonderful> so that's your github page ...
<zid> doesn't clobber _buffer[0] through _buffer[reads-1]
<zid> like it probably should
<geist> it does
<zid> howso?
<zid> I had a bear of a time teaching gcc that in one of my things, and I didn't wanna just give "memory" as a clobber
<geist> that was my first thought, because the bug is some code that used inpwprep was trashing some local variable
<geist> but no, it colors within the lines
<geist> it's more subtle than that
<zid> I still think it isn't clobbering it
<geist> isn't clobbering what?
<zid> buffer[0], buffer[1], etc
<geist> okay. anyway, that's not the bug
<geist> (and yes i will add "memory" to all the ins, that's i think another bug)
<zid> Finding *two* bugs at once is harrrrd
<geist> it's not the memory clobber though
<zid> missing sti?
<zid> idk what the architectural constraints are or if they matter
<geist> nope, the popf recovers that
<kindofwonderful> geist: you will do something on a basis that you THINK it's wrong ?
<zid> oh right so it does
<zid> completely forgot i is inside flags on x86 for a minute there
<zid> lots of cpus it ain't
<geist> kindofwonderful: no i already know the bug, though i spent like an hour debugging it
<geist> it's a subtle inline assembly issue
<geist> and once again why you should avoid it if you can
* zid opens the manual
<geist> it's so easy to make subtle mistakes that stick around *forever*
<zid> d reg, di reg, c reg constraints.. isn't accidentally clearing eax along with edx using the wrong one.. volatile marked..
<zid> all arguments are used/constrainted/clobbered..
<kindofwonderful> according to your experience where inline assembly is needed ? and why C is not enough there ?
<geist> yep but you're getting close
<Mutabah> Didn't mark a memory clobber?
<zid> all three look like they should be inputs
<geist> Mutabah: nope. though i think that's also something it should do (and i will do that soon)
<zid> need to mark ecx as a clobber?
<Mutabah> Yeah... although, they are in the input position (I think?)
<geist> zid: bingo
<zid> phew got there in the end
<Mutabah> yeah... might be missing D/S/c as clobbers
<geist> the rep part of the instruction modifies edx and ecx
<zid> yea it counts ecx down, also increments D I guess
<geist> the codegen i was getting at the time was putting the pointer in EDX and then expecting the same pointer to still be there afterwards
<Mutabah> well.. `rep` modifies ecx, `insb` modifies edi
<geist> so i was noticing it mallocing a buffer at say 0x500 and then freeing it at 0x700
<zid> I assume they were actually basically all different instructions, which is why it knows what to increment and what not to
<geist> after reading 512 bytes of data into it
<geist> just so happened it would happen if the codegen reuses the reg afterwards
<zid> My last inline assembly bug was like
<zid> char s[2]; asm("...", "m" (s)); ...
<zid> and I didn't clobber s[0] and s[1], so it just saw it as empty do-nothing code and deleted it
<zid> so my serial code was outputting nothing
<geist> yah that's a case of need a volatile
<zid> the volatile didn't help :(
<geist> though fun fact i learned: you dont need asm volatile if the code takes no args
<zid> you don't need volatile if you have no outputs
<kindofwonderful> wow osdev is hard
<geist> though i generally do in that case just to be safe
<geist> and make it obvious i want it to run
<kindofwonderful> something that MIGHT be a problem created this discussion
<geist> no it *is* a bug. i just debugged it
<zid> It's super rare that adding volatile makes anything worse at least
<klange> computers were a mistake
<geist> i was just running it by the room as a 'oops look at my fuckup' thing
<zid> channel :P
<geist> oh shit i'm getting infected by discord
<Mutabah> geist: I appreciated the reminder of how big a footgun inline assembly can be
<kindofwonderful> i think this is beautiful, one have a problem and the entire channel pulling their hairs trying to figure out what's going on
<geist> so based on that paste all of the in instructions need a "memory" clobber right?
<Mutabah> (And this, everybody, is why I use external assembly!)
<zid> I actually.. cast it to a VLA and clobber that :D
<kindofwonderful> i think that's what im missing
<kindofwonderful> the fire
<Mutabah> geist: I'm not 100% sure of the rules - but it can't hurt - you are modifying memory with that instruction
<geist> yeah
<Mutabah> (the optimiser might be able to see that it happens because a pointer is passed)
<zid> it needs one, "memory" always feels a little.. sledgehammery though when dealing with arrays
<kindofwonderful> Mutabah: you are multitasking :)
<zid> so I've had to manually figure out how to restrict it down to just the changed array bytes
<geist> so looks like i need.... + constraint and put it in the output list. can do!
<geist> (always have to re-read the gcc bits for thsi)
<bslsk05> ​gcc.gnu.org: Modifiers (Using the GNU Compiler Collection (GCC))
<zid> that means the value of the pointer can change I think
<kindofwonderful> ok im going to do something
<kindofwonderful> code wise
<kindofwonderful> im leaving you alone
<zid> oh I found it
<zid> https://godbolt.org/z/cf9T9raGz That's roughly the code/codegen I had, whoopsie
<bslsk05> ​godbolt.org: Compiler Explorer
<zid> 'return 3;'
<geist> oh intresting yeah
<geist> but sure enough if you add a memory to it. boom
<bslsk05> ​godbolt.org: Compiler Explorer
<geist> also fairly certain you dont need to pass that as a memory operand, because "memory" will globally dump it
<bslsk05> ​godbolt.org: Compiler Explorer
<zid> If you tell it s[0] gets overwritten, rather than *read* from instead, it works as intended, oopsie
<geist> but yeah may be more precise to do it on just the bits
<zid> yea I didn't want it dropping all my other regs, which is what "memory" might do
<geist> and the 'volatile' part should keep it from rearranging other memory accesses around it
<zid> if they hold values from previous ops in parent funcs in scratch regs
<mxshift> Reminds me of an interview where the interviewer insisted that a volatile asm with memory clobber was a portable way to make a memory fence.
<zid> that's.. not what fences are :(
<mxshift> Yup. They seemed to only have experience with in-order microcontrollers
<mxshift> I didn't get that job
<zid> and besides, if what you're trying to achieve is 'reloading a value from memory', that's what volatile * already does
<zid> so like not only is it wrong, it's wrong even if it were right
<zid> because C already provides
<mxshift> They thought they were doing more than that but were entirely ignorant of why fence instructions exist
lg has quit [Ping timeout: 248 seconds]
<geist> one thing i totally dig from systemd: full path names in devices
<geist> `qemu-system-x86_64 -fda /dev/disk/by-id/usb-TEAC_TEAC_FD-05PUB -serial stdio`
<geist> much harder to mess up accessing the wrong disk when you have the full path to it
lg has joined #osdev
<mxshift> Is that a systemd thing? I thought that came with udev before systemd existed
<geist> oh maybe
<mxshift> But yes, it's a great improvement. There was one generation of machines I worked with that had non-deterministic enumeration order
<zid> I turn the determinism off
<mxshift> Manually finding out which disk was which was tedious
<zid> eth0 for life, ensp0p1 or whatever can die
<mxshift> It's a different matter when sdb will change what port it maps to on every boot
<zid> so.. insane bios?
klys has joined #osdev
bauen1 has joined #osdev
<mxshift> And hardware. It was a machine of compromises
wand has quit [Ping timeout: 258 seconds]
wand has joined #osdev
<geist> been booting the kernel on this old p4 which is finding all sorts of fun edge cases i hadn't tried before
<geist> yay old hardware stress test
the_lanetly_052 has joined #osdev
wand has quit [Ping timeout: 258 seconds]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 252 seconds]
poyking16 has joined #osdev
wand has joined #osdev
<zid> p4, otherwise known as p6
<zid> thanks intel
<zid> p6++++
<kindofwonderful> are you guys using vim ?
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
Burgundy has joined #osdev
<moon-child> Sometimes, you use vim. But sometimes--well, sometimes vim uses you.
<moon-child> Vim is like 'that girl'. You know the one. You never really went steady, but you'd run into her from time to time while knocking around in disreputable emacsen...
<zid> are you okay
<klange> I have been using my own editor for four years now.
<bslsk05> ​web.archive.org: [FoRK] And then there's Haskell... (was: Bone / Greenspun, etc.)
<zid> sorry I wasn't born in 2007
<zid> I was born in the 80s infact.
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
Burgundy has quit [Ping timeout: 246 seconds]
<mjg_> geist: slightly related, i hear booting os/2 is *the* test for a hypervisor
GeDaMo has joined #osdev
<kindofwonderful> mjg_: don't get smug
netbsduser has joined #osdev
kindofwonderful has quit [Ping timeout: 246 seconds]
Ellenor is now known as AmyMalik
kindofwonderful has joined #osdev
<netbsduser> i've thought a bit more about efficient approaches to a single-level store
<netbsduser> one way: try to eliminate as much cyclic referencing as possible, rely primarily on refcounting. since a generational/moving GC is now no longer needed, more viable to do physical (i.e. simply persist pages of the heap, don't need an object-based approach) approach to persisting
<netbsduser> since i don't think i can *eliminate* reference cycles from smalltalk, need cycle detection - can use a low-priority process and have it perform a cycle detection run on a checkpointed state
<netbsduser> GeDaMo: cheers for that link, this looks marvellously detailed. system/38 (along with IBM i, but there appears to be no thorough technical documentation of its internals available outside of big blue itself) are very interesting platforms
potash has quit [Read error: Connection reset by peer]
<GeDaMo> Page 5, top of the middle column appears to be referring to single level store
potash has joined #osdev
<GeDaMo> The references are all in that same PDF
<pbx> klange: thats odd. never had any issues with the console
<pbx> why large? static link, plus its basically a full sysroot
<pbx> so all hdrs libs etc
<pbx> could do an iso but atm i dont have a cdrom driver nor iso9660 fs
<moon-child> netbsduser: there was an 'international workshop on persistent object systems'. It has not been held in over 20 years, but you will likely find useful threads: https://dblp.org/db/conf/pos/index.html
<bslsk05> ​dblp.org: dblp: Workshop on Persistent Objects (POS)
<pbx> so that'd be a ramdisk boot, which is slow for few hundred meg images
<klange> I tried a few different configurations of QEMU, but the keyboard just doesn't seem to do anything - curious what version you're running, might give me a hint on hardware config differences
<moon-child> netbsduser: for my money, tracing gc is fine; and outlawing cycles is not very nice
<pbx> hmm. i've moved my dev env across qemus from 2013 to now, never had that issue
<pbx> only had it show up on real pentium ii hw
<pbx> what version are you using
<klange> 6.2
<pbx> i'm on 5.2.0
<moon-child> netbsduser: (in particular, refcount-chasing is slow, and a gc pass on persistent old-space is unlikely to be slower than a cycle detection pass on persistent oldspace)
<klange> Hm, not a lot different between the two releases...
DarkL0rd has joined #osdev
<netbsduser> moon-child: interest in this field really dwindled from the point of having symposiums and workshops to being almost untouched nowadays as far as i've seen (a few projects like CapROS aside, does it still exist?). i had thought of taking a tracing gc approach but i saw a lot of difficulties - it would be trickier to square it with the simpler model of persisting the object heap at page granularity without regard to what's within pages
<moon-child> how's that?
<moon-child> I mean, aside from a page being associated with a particular generation/region/what-have-you in the gc
the_lanetly_052_ has joined #osdev
<netbsduser> because if i used a generational copying approach, for example, that would generate much larger deltas between checkpoints, which would result in a lot more writing to disk than i'd prefer. alternatively i could change the on-disk format from a simple representation of the object heap as it's physically laid out in RAM into something more abstract - i thought about one big table of objects containing members universal to all objects, with pointers
<netbsduser> to space where class-specific data is stored - that could allow for more efficient disk use, but i expect it would be very challenging to implement
the_lanetly_052 has quit [Ping timeout: 246 seconds]
<moon-child> you need to have the ability to compact your oldspace anyway, to deal with worst-case pathological fragmentation
<moon-child> probably that could be an offline thing though in any event. Beyond that, you don't necessarily need to copy oldspace
<moon-child> probably more compelling is an incremental approach (tricolour or so, perhaps) to avoid latency spikes
<moon-child> for interactive use
<moon-child> anyway going to bed now; chat more tomorrow
smach has joined #osdev
sav_ has joined #osdev
smach has quit [Ping timeout: 260 seconds]
dzwdz has quit [Ping timeout: 264 seconds]
dzwdz has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 252 seconds]
Burgundy has joined #osdev
<klange> pbx: i extracted your kernel and used some of your old sources as a reference to poke around in gdb and it looks like you aren't specifically enabling the keyboard ps2 port. I threw a `call i8042_write_command(0xae)` at it and now I can type.
truepassion has joined #osdev
<truepassion> hi, arm cpus, what does MP<number> mean? e.g. Arm Cortex-A510 Core (MP164) in https://developer.arm.com/documentation/SDEN1873361/latest
<bslsk05> ​developer.arm.com: Documentation – Arm Developer
<mjg_> klange: wut
<mjg_> now porting doom is an A+ idea
<sham1> Should clearly port Crysis
xenos1984 has quit [Read error: Connection reset by peer]
<sham1> So then we can answer the question of whether it can run Crysis
MiningMarsh has quit [Ping timeout: 252 seconds]
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
<pbx> klange: thanks :)
<pbx> klange: yeah. main reason i'm doing these ports is as a mix of ADHD instant gratification food and stress test for the project to expose bugs
<pbx> seems like i'm leaking something (pbufs?) in the AF_UNIX or sockets code
xenos1984 has joined #osdev
kindofwonderful has quit [Ping timeout: 246 seconds]
<mjg_> pbx: wnat some fun? port syzkaller
<mjg_> afair it's not *that* much work
<mjg_> well you want kmsan, kasan or kcsan as well, these may be some work :-P
awita has joined #osdev
<pbx> kasan might well be worth it :)
<pbx> but that's crossing into *work* domain. this is my hobby, i want to keep the offensive security stuff out of it
<mjg_> why security
<mjg_> this is stability stuff first and foremost
dude12312414 has joined #osdev
y0m0n has joined #osdev
Burgundy has quit [Ping timeout: 246 seconds]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
m5zs7k has quit [Ping timeout: 260 seconds]
elastic_dog has quit [Ping timeout: 260 seconds]
<pbx> true. but fuzzing, meh, too close to work
m5zs7k has joined #osdev
heat has joined #osdev
awita has quit [Ping timeout: 252 seconds]
kindofwonderful has joined #osdev
sav_ has quit []
awita has joined #osdev
<pbx> /wind 3
<pbx> oops
epony has quit [Quit: QUIT]
y0m0n has quit [Ping timeout: 264 seconds]
smach has joined #osdev
awita is now known as Cheeriotl
Cheeriotl has joined #osdev
Cheeriotl has quit [Changing host]
poyking11 has joined #osdev
Cheeriotl is now known as awita
carbonfiber has joined #osdev
poyking11 has quit [Ping timeout: 260 seconds]
smach has quit []
MiningMarsh has joined #osdev
* geist yawns
<geist> had to get up early today for a meeting. going to be so tired later
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
MiningMarsh has quit [Client Quit]
<geist> truepassion: good question, i can't figure it out either
<geist> thought it was maybe just the document number, but seems to not be the case. it's SDENxxxx as they usually name it
MiningMarsh has joined #osdev
justache is now known as justHaunted
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
[itchyjunk] has joined #osdev
kindofwonderful has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
kindofwonderful has joined #osdev
<bslsk05> ​lwn.net: The search for the correct amount of split-lock misery [LWN.net]
gog has joined #osdev
<gog> afternoon, nerds
<heat> TIL there's a way to detect split locks
<heat> gog, hi, i was just in the middle of nerding, how are you?
<gog> hi
<gog> i'm well
<gog> took off early from work because my boss isn't around and i need to ask his permission before doing a thing i want to do
<gog> and tomorrow i'm off because it's birthday
<sham1> Good evening lads and lasses
<heat> happy bday if i forget
<heat> but i'll try to remember
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
<mrvn> heat: obvious comments on that LWN article: 1) why is there no option to kill processes that exceed the rate limit? 2) why wasn't that a runtime adjustable parameter from the start? 3) why isn't that a per process limit?
<heat> what's the point of having a rate limit if it doesn't limit but rather kill?
<mrvn> heat: so that code that does a split lock once a second keeps running but the DOS attack doing it 1 billion times in a row dies.
<mrvn> you could have a warn limit and kill limit too
<heat> but the 5.19 patch just delays you
<mrvn> But killing a process just because it does one split lock is rather harsh.
<heat> just so it's not noticeable
<mrvn> I think that's the worst solution. It makes actual use cases unbearably slow while DOS attackers don't care. They simply don't succeed.
<mrvn> Which brings me to the 3rd point: You want to mark "God of War" as being allowed to split lock without enabling it for everyone.
<heat> DOS attackers care
<heat> they failed
<mrvn> they aren't going to "fix" their code to not split lock.
<heat> ok? they're attackers, and they failed
<mrvn> slowing them down isn't better than killing them. There really is no point in lettimg them run even slow.
<heat> there is
<heat> this rate limiting is only for the dmesg warning
<heat> the split lock fault itself does not have rate limiting
xenos1984 has quit [Ping timeout: 264 seconds]
<mrvn> heat: that was about the 10ms delay option.
<mrvn> The original warn solution really does nothing at all against DOS except make it worse because now you also get syslog messages.
awita has quit [Ping timeout: 246 seconds]
<heat> if I get your process to generate a bunch of split locks, you get rate-limiting-SIGKILLED and die?
<heat> "anything else creates an easily exploitable denial-of-service vulnerability."
<kindofwonderful> mrvn: hi
<kindofwonderful> welcome back
<mrvn> heat: true. that is a DOS on the faulty service while preventing a DOS on the whole system.
<heat> but you don't want a DOS at all
<heat> 10ms delay is the least shitty of the shitty worlds
<heat> services notice they're running very slow, and no one gets DOS'd
<heat> well, you do get DOS'd a bit
<mrvn> heat: possibly. except that pretty much was a DOS for the game.
<mrvn> heat: why wasn't the 10ms delay coupled with a rate limit? A malicious program will flood the system with split locks. So rate limit them and if the limit is exceeded add the 10ms delay.
<heat> idk
<Griwes> > He also suggested filing a bug with the publishers of God of War to get its misbehavior fixed.
<Griwes> Bless his heart
<Griwes> What a sweet summer child
<mrvn> hehe. How many years past release if God of War?
<gog> 13?
<gog> oh shit
<GeDaMo> Closer to 20, I'd think
<gog> 18
<mrvn> anyway, split lock sounds like something that realy doesn't scale with the number of cores.
<GeDaMo> I have it on the PS2
<mrvn> Do modern CPUs still halt the whole bus for all cores or do they have something smarter now?
<heat> it's the new god of war
<heat> not the old one
<GeDaMo> Ah
<Griwes> Still
<Griwes> Asking gamedevs to fix a "bug" of this kind?
<mrvn> Griwes: it's reasonable for a game that's still getting updates.
xenos1984 has joined #osdev
<Griwes> They can usually barely fix actual bugs
<heat> it's not a native linux game
<mrvn> Griwes: they just have to find the library that causes the split lock and report it there
<heat> it's under wine lol
<Griwes> Also that yeah
<heat> "hey, this weird behavior of a system you don't support is breaking your game running under like 2 compat layers. pls fix ty"
<Griwes> Like, if you send me a bug report saying I'm doing funny atomics that break a system I don't support, I'll laugh lol
<mrvn> Problem with wine games is that they are usualy some other firm buying the right to publish the wine version and the original firm doesn't care about linux bugs at all
<heat> hm?
<heat> what's a "wine version"?
<mrvn> (or just private people playing it in wine)
<heat> steam distributes proton (wine + a bunch of shit)
<mrvn> heat: a linux version of the game that just comes with wine
<heat> if you decide to play video games with it, it's your fault
<zid> wine version is a real thing, kinda weirdly
<heat> i'm not aware of such shenanigans
<zid> a linux version that's easier to emulate in wine than normal :P
<heat> that's also like, a poor idea
<heat> blob'd, non-updatable wine, yay!
<mrvn> heat: that exists too
<mrvn> wine patched to work around bugs in the game
awita has joined #osdev
elastic_dog has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
Matt|home has quit [Ping timeout: 246 seconds]
awita has quit [Quit: Leaving]
<zid> Finally found out what to do with bulging lithium pillows
gildasio has joined #osdev
<heat> seems solid
<heat> your house may stop being solid though
puck has quit [Excess Flood]
<mrvn> "may help prevent soot formation"? Does that only work on mondays?
puck has joined #osdev
<mrvn> Do LiPol batteries have much zinv?
<mrvn> zinc
<zid> well I've always wanted a sublime house
<mrvn> indoor fireworks
Burgundy has joined #osdev
<GeDaMo> Why is 'sublime' a word but not 'sublemon'? :|
<heat> checkmate liberals
<zid> what the fuck linguistic gap is the latter trying to fill
<heat> worse lemons
<zid> oh fuck sake
<sham1> Damn Latin words confusing people
<zid> sublemon means under the man doesn't ti
bauen1 has quit [Ping timeout: 260 seconds]
<mrvn> sham1: Damnant verba Latina confundens populum
<zid> under the my, even
<sham1> Assentiō
<heat> alexa, how do you say nerds in latin
<zid> heaticus
<mrvn> heat: nerds (according to google)
<heat> zidus
<zid> zidus zidus
<mrvn> zid: the wall, the wall?
<mrvn> are you a croatien wall?
<gog> sublime implies the existence of domline
<mrvn> domline?
<gog> domlime
<zid> I thought it implied the existence of SUPER LIMES
<zid> but maybe I am just not as filthy as some people I might mention
<sham1> This underlimes all the weirdness
<bslsk05> ​me.me: Lime Sublime Domlime | Sublime Meme on ME.ME
<gog> sory
<zid> I didn't tell you to stop
<gog> yes, sir
<mrvn> Is domline when a gas turns directly into a solid?
<gog> yes
<gog> condensation, domlination, sublimation, evaporation
<j`ey> now you can try serenity without building it https://copy.sh/v86/?profile=serenity
<bslsk05> ​copy.sh: Virtual x86
<sham1> neat
<zid> I should have opened this in chrome
<zid> I'm very surprised it even loaded in pale moon, I am getting several mips
<heat> j`ey, do they distribute images yet?
<j`ey> no idea, i assume not
<zid> I got to 128
<zid> is too laggy to do more
<j`ey> at least not on github
<heat> oof
<zid> I don't think that 'kernel' entry is very correct
<heat> copy.sh cannot handle the might of boros
<heat> im getting burger king
<heat> yall want some
<zid> yes please
<zid> Also if you walk past a mcdonalds on the way, get me a bigmac
<heat> sorry, uber eats
<zid> an ubered eated whopper sounds like it'd cost a fortune
<heat> its uber eats
<heat> everything costs a fortune
<gog> i had pasta
<zid> I had chili
<gog> nice
<zid> chopped bird eye chilis, mushrooms, garlic, shallots, ginger powder, a metric fuck ton of chilli powder, soy sauce, salt, mashed cow
<zid> basmati rice
<zid> oh and pasata
<zid> passata
joe9 has quit [Quit: Lost terminal]
<sham1> Kebab
<zid> I ate too many kebab at once and now I can't kebab
<gog> pasta in chili?
<gog> hm
<zid> chili on pasta is good
<zid> it's like bolognese but better
<gog> i was gonna say basically a bolognese anyway
<gog> i might have to try that
joe9 has joined #osdev
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<truepassion> geist: yeah my inital guess was may be RTL version? but not sure
Lumia has joined #osdev
bauen1 has joined #osdev
Lumia has quit [Ping timeout: 272 seconds]
carbonfiber has quit [Quit: Connection closed for inactivity]
Lumia has joined #osdev
<heat> some linux sockets can be mmaped
gildasio has quit [Ping timeout: 258 seconds]
wand has quit [Ping timeout: 258 seconds]
<sham1> That sounds horrible
gildasio has joined #osdev
<heat> why
<heat> it's like files, but sockets
<heat> and sockets being literally files with a special syscall, I don't see what's wrong
<mjg_> sockets are not seekable so there is that
wand has joined #osdev
<mrvn> heat: how is that going to work? How do you seek on a socket?
<heat> idk
<heat> but seeking is not required for mmap
<heat> plenty of character devices implement mmap but don't seek, nor do they have a read/write
<mrvn> they do? which ones?
<mrvn> Do they map some MMIO regs?
<heat> /dev/fb0 is an easy one
<heat> yeah
<heat> or whatever
<mrvn> That's not really a char device.
<heat> mmap does not require seek whatsoever, at least in standardish kernels
<mrvn> It does require random access though
<heat> no
<heat> why would it?
<heat> if your thing wants to map a thing, it maps it
<mrvn> because if someone reads from base+1GB you don't want to wait and map 1GB of data before the page fault returns.
<heat> of course these sockets that implement mmap must not be mapping a TCP stream, because that's impossible/very hard+useless
<heat> AF_PACKET is one
<mrvn> I guess you could have something like RDMA pretend to be a socket and internaly it then read/writes the respective pages over the network.
<mrvn> AF_PACKET is just a placeholder for implement-the-protocol-yourself :)
<heat> no
<mrvn> heat: does linux have a socket type that allows mmap?
<heat> that's very much not AF_PACKET
<heat> you're thinking about AF_RAW there
<mrvn> "Packet sockets are used to receive or send raw packets at the device driver (OSI Layer 2) level. They allow the user to implement protocol modules in user space on top of the physical layer." They kind of are :)
<heat> AF_PACKET is what tcpdump/wireshark uses to capture packets
<heat> it's pretty much it's usage
<mrvn> heat: SOCK_RAW is the socket type. That goes along with AF_PACKET. The other type is SOCK_DGRAM which is slightly higher level.
<heat> and it implements mmap so you don't even need to travel
<heat> (to the kernel)
<heat> yes, you're right, my bad
<mrvn> heat: I think wireshark uses pcap, which uses a subset of AF_PACKET.
<heat> yes
<heat> but AIUI you usually use mmap there
<heat> so, see, mmappable sockets :)
<mrvn> heat: is that a ringbuffer then? An early implementation of kernel uring?
<heat> yeah i believe it's a ringbuffer
<heat> there's a whole doc on it in Documentation/
<mrvn> So basically the same as the /dev/fb0 case. Missusing the FD to connect a bunch of kernel memory to the user space.
<heat> it's not misusing the fd
<heat> devices don't need to be read/write-able
<heat> what would you do with a read() on /dev/fb0?
<heat> or a write()?
<heat> if you want to send commands, you usually opt for an ioctl
<mrvn> it's not mapping the socket data, just a ring buffer that gets constantly overwritten. So it's a (good) hack to get fast access to the data as it passes by.
<heat> it's simpler and faster
kindofwonderful has quit [Quit: WeeChat 3.6]
<heat> again, what would you do on the /dev/fb0 case?
<mrvn> heat: you can read/write on fb0 just fine.
<heat> read what?
<heat> the framebuffer itself?
<mrvn> the graphics memory.
<heat> eh
<mrvn> yep. the /dev/fb0 is really just a fixed sized memory buffer.
<heat> and then constantly rewind, etc
<heat> for no gain really
<mrvn> Oh no. you can read up to the FB size.
<heat> DRM nodes are even worse
<heat> what would you read on /dev/dri/card0?
<mrvn> You would do pread() on the FB, read + seek is kind of stupid.
Lumia has quit [Ping timeout: 260 seconds]
<heat> pread is relatively new, UNIX-speaking
<mrvn> No idea about /dev/dri/card0. I think that's rather driver specific.
<heat> ok, an intel GPU for instance
<heat> would it read INTELINTELINTEL in a loop? ;)
<mrvn> no idea
<heat> most devices map well to ioctls and mmap, NOT read/write
<heat> taking a trip to the kernel and back to read /dev/fb0 is just a poor idea
<mrvn> I just worked with /dev/fb0 on m68k. The generic framebuffer is just a memory based file with some ioctls.
<mrvn> heat: the FB implements the lowlevel read/write functions in the kernel and then the generic mmap code just works on it. You aren't really supposed to constantly read/write it.
<mrvn> but you can
<heat> oh wow you can actually read/write to it
<mrvn> Want to make a screenshot? open /dev/fb0, read
<heat> TIL
<heat> anyway, the DRI node is a better example
<heat> there's no good answer for "What should be read/written" except "idk, a packeted command structure?"
<mrvn> heat: I believe the reason for that is that linux has a file_ops struct with callbacks for read/write but nothing for just mmap. So they overload read/write and everything just works then.
<heat> and if you're moving packeted commands back and forth through read/write, you lost and that's horrible
<heat> there's absolutely an mmap callback
<heat> mmap does not work in terms of read/write
<mrvn> maybe now. It's like 30 years ago when I worked on the FB
<heat> in 1992? hi linus :v
<mrvn> close, 95
<heat> oh yeah /dev/zero is a great example
<heat> it's "seekable"
<heat> but you don't actually seek anywhere because everything is a lie and it just memsets your buffer
<mrvn> you can also read from it
<heat> sure
<heat> but mmap will never work on an infinite buffer
<mrvn> but what happens whem you map it SHARED :)
<heat> as in, there's no infinite buffer to represent the whole device, so it fucks around with .mmap
<heat> it's just a normal shared mapping AFAIK
<heat> of anon-backed memory
<mrvn> why does it even need to fuck around with .mmap? .read simply does a bzero() and you are done.
<heat> yes
<heat> but if you're mmaping it
<mrvn> then mmap calls .read() and gets bzero of the page.
<heat> it's a size 0 file
<mrvn> yeah, that bit you have for fudge around with
<heat> unix is built on lies
<mrvn> but it's a char device. so file size is kind of out there
<mrvn> good example for an mmap-able char device.
<mrvn> heat: YOU CAN'T HANDLE THE TRUTH!
<mrvn> can you seek to the end on /dev/zero?
<heat> i highly doubt it
<heat> everything is a file, except not really. everything is read/write-able, except directories, symlinks, and most block/char devs. mmaping maps the "contents of the file", except on directories, symlinks and pipes where it doesn't exist, and block, char when it's not implemented
<heat> also block and character devices can map things when not read/writeable, and so can sockets!
<heat> unix is the crème de la crème of design
<heat> the best part of Great UNIX Design(tm) is when you read from /proc, but you don't read everything so you get stale data
epony has joined #osdev
<mrvn> you don't get stale data I believe, you always get the data from offset 0
<heat> i believe you get stale data, it's buffered
orthoplex64 has joined #osdev
<heat> a call to a procfile's .read buffers a whole bunch of data, and you read it bit by bit
<mrvn> that would actually be usefull then
<mrvn> and consistent
<mrvn> also would be just like readdir
<mrvn> sort of
<mrvn> reading a dir while files are created or deleted has strange effects
<heat> yes, there's no consistency in readdir
netbsduser has quit [Remote host closed the connection]
<mrvn> there is some but it's strange.
<heat> where?
<mrvn> I don't see it in the manpage anymore but afaik there are some conditions on what successive calls to readdir may return
<mrvn> new and deleted files may or may not appear but existing files can not be skipped because the FS resized the hashtable or something.
<mrvn> what it comes down to is that the libc may do readdir_plus and buffer entries so you get stale data. Or not and you get latest data. or any mix. But the stream doesn't skip.
<heat> or link + unlink + link + unlink + link + ... ;)
<AmyMalik> snerf.
<klange> pbx: correction to my previous debugging report, it seems all I need to do is inject a `i8042_read_ram(0)` and this gets the keyboard working
poyking16 has quit [Quit: WeeChat 3.5]
<pbx> hmm. any reason for that? i8042 weirdness?
<pbx> forgetting to init it seemed logical, but does read_ram also do that?
<kazinsal> hoo boy. one of my coworkers brought a bottle of plum brandy back from his trip visiting family in Romania and we had a tasting in the office and I did not realize it was 60% ABV
<AmyMalik> unix is not atomic
<zid> -which is weird, because when unix was designed, everything was atomic
<zid> it was super fashionable
<zid> atomic toaster, atomic trains, etc
<gog> hi
<zid> the words atomic toaster apparently summon gog
<gog> it was actually "trains"
<AmyMalik> where's magog when you need them
<zid> ah, that sort
<gog> yes
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
smach has joined #osdev
<kazinsal> WITH THE GUARDS OF MAGOG SWARMING AROUND / THE PIED PIPER TAKES HIS CHILDREN UNDERGROOUUUUND
eroux_ has quit [Ping timeout: 260 seconds]
<geist> had to look that one up!
<klys> molecular sequence, cellular energy, printed protein
eroux has joined #osdev
<klys> micron nanotech, computing bacterium, nucleic memory