<geist>
why do they keep rolling device ids for minor changes? I guess maybe that's what you're supposed to do, but seems like if it's basically compatible you should report the same id with a features/revision field inside it
<kazinsal>
looks like one new one for every PCH change, god damn
<geist>
they do this with everything else too, but at least something like AHCI you can match based on a class/subclass thing
<bslsk05>
github.com: linux/netdev.c at master · torvalds/linux · GitHub
<kazinsal>
yeah
<geist>
and via some indirects leads to a bunch of descritors of stuff
<geist>
and pointers to accessor routines. yay.
<geist>
well okay, this driver will not be fixed today then
<heat>
that's the i915 syndrome
<geist>
yah and since there's enough subtle variations, it's not even safe to generally set your driver to bind to something you haven't personally seen
<kazinsal>
yeah, the official e1000e driver is a bit of a mess
Affliction has quit [*.net *.split]
<geist>
but then since there are like a hundred variants you never see all of them
Affliction has joined #osdev
<kazinsal>
and a lot of the variants just boil down to "same shit, different coat of paint"
<heat>
the freebsd one is also horrible btw
<geist>
the gist at least for reading the mac address is apparently you have to read it out of a nvram. i bet it is ultimatley as kazinsal says: there's some flash nvram mapped into the aperture (which is larger than i'd seen in the past, 128K) and there's some structure to it
<geist>
that the i219 manual is describing. so probably you just directly read the flash structure. seems to be what these accessor routines are doing in the intel manual
duckworld has quit [*.net *.split]
Affliction has quit [*.net *.split]
duckworld has joined #osdev
duckworld has quit [Max SendQ exceeded]
Affliction has joined #osdev
Affliction has quit [Max SendQ exceeded]
duckworld has joined #osdev
Affliction has joined #osdev
<kazinsal>
aha! found something relevant in the bsd em driver
ephemer0l has quit [Remote host closed the connection]
<geist>
yah the pch ones i guess are the builtins and the tcp/adp/cnp stuff is the family name
<geist>
tiger lake, alder lake, etc
nyah has quit [Ping timeout: 276 seconds]
spikeheron has quit [Quit: WeeChat 3.7.1]
spikeheron has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
gog has quit [Ping timeout: 250 seconds]
kof123 has joined #osdev
<heat>
weird q: is there a problem in doing OOB reads on string functions (strlen, etc)?
<zid>
yes?
<zid>
Like, very a lot
<heat>
I was trying to be precise in my KASAN bounds (as in making it exactly the size the caller asked for, and not the rounded up obj size) but strlen is triggering it
<heat>
and it's not possible to not trigger it and still have a fast implementation
<heat>
reading more has zero side effects but triggers kasan
* zid
puts the string at the end of a page
<zid>
zero effects other than that page fault.
<heat>
which is why you align the pointer
<heat>
you're never getting an unwanted page fault reading 8 bytes if your pointer is 8 byte aligned
<zid>
okay then *puts a string on his gameboy stack*
<zid>
it might be a viable optim on x86 if you can prove a bunch of stuff for sure
<zid>
but it isn't.. universally legal
<heat>
it's not prove, it's that you read word-sized chunks on word-sized boundaries
epony has quit [Ping timeout: 252 seconds]
<heat>
you obv need to manually align the ptr in strlen itself
<bslsk05>
datatracker.ietf.org: RFC 8536 - The Time Zone Information Format (TZif)
<zid>
yea
<zid>
implementing tzif2
<zid>
Oh right.. I think my books are going to come out an hour later now? :(
<zid>
hopefully it's an hour earlier and I can't tell time
<GeDaMo>
Books?
dragestil_ has joined #osdev
dragestil has quit [Ping timeout: 252 seconds]
dragestil_ is now known as dragestil
fkrauthan_ has joined #osdev
fkrauthan has quit [Ping timeout: 252 seconds]
fkrauthan_ is now known as fkrauthan
epony has quit [Ping timeout: 252 seconds]
wootehfoot has joined #osdev
epony has joined #osdev
k0valski1889 has joined #osdev
<Mondenkind>
ohai FireFly. Didn't realise you were here
<Mondenkind>
and in #tendra!
puck has quit [Excess Flood]
puck has joined #osdev
DanDan has joined #osdev
<FireFly>
oh heya
<FireFly>
zid: yeah, more for cases where that's not (easily) possible, like mobile phones or whatever where the interface wants you to pick a location
poisone has quit [Remote host closed the connection]
nick64 has joined #osdev
<nick64>
`__asm__ volatile ("clac");` is sufficient to disable SMAP right? Or do I have to edit the EFLAGS as well?
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
potash has joined #osdev
poisone has joined #osdev
mahk has quit [Ping timeout: 268 seconds]
k0valski18896 has joined #osdev
k0valski1889 has quit [Ping timeout: 252 seconds]
k0valski18896 is now known as k0valski1889
* sortie
debugs the way root intended, the only primitives available is to print the current registers, and to hexdump memory addresses; proceeds to manually do a stack trace, having rebuilt a similar binary with symbols, which I manually inspect with shell commands to manually calculate offsets
<sortie>
I really need to invest in building a stable kernel debugging solution for my OS, but this qemu monitor fallback is at least theoretically able to provide all the information, if I behave like gdb in my mind
<sortie>
It's one of those days when one of my production VMs faulted on a super rare kernel bug, so VNC'd into the qemu to debug it
<bslsk05>
[According to four current employees, engineers spent Friday afternoon at Twitter dutifully printing out their code in anticipation of meetings with Musk and some of his senior engineers from Tesla. Other engineers were told to prepare for “code pairing” with Musk, in which they would sit with him and review code together.   Just after noon, an executive assistant asked engineers to begin preparing code to show to Musk. “Please print out
Raito_Bezarius has quit [Quit: free()]
<theWeaver>
lmfao
<gog>
half of my code changes are deltions, how do you represent that
<gog>
or does he just want to see the current state
<gog>
what does it even mean
<theWeaver>
the - lines on the diffs
<theWeaver>
i guess
<gog>
that was my intuition too
<gog>
just print out your last n days of diffs
<gog>
but if it's git format then you only have 3 lines of context
<theWeaver>
i knew he was a moron but i wasnt expecting this
<theWeaver>
he will have to infer the broader context himself
<theWeaver>
¯\_(ツ)_/¯
<gog>
anyhow, when my wife told me this story i was like "what the fuck does that even mean"
<theWeaver>
it means "musk is a freaking idiot"
<gog>
yes
* zid
shreds all of his code too in solidarity
<zid>
sorry to all 4 users
<theWeaver>
lol
dude12312414 has joined #osdev
<gog>
that's infinity times as many users as my code
<zid>
idk how many users it has it got pirated
<zid>
I gave it to 4 people
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05>
'Prison Break(2005) S01 E03 - I don't sleep (6/6) l Netflix' by 3 Minute Drama (00:03:40)
sprock has quit [Client Quit]
epony has quit [Ping timeout: 252 seconds]
<heat>
geist, have you played around with ASAN yet?
<fatal1ty>
heat: shut up
<geist>
not personally, aside from fuchsia
<heat>
i've been reworking my implementation this weekend
<heat>
the early memory mapping is... gnarly
<geist>
we do however have asan and kasan for fuchsia, and there are bots that run it, etc
<geist>
yeah i think it is. burns like 1/8 of ram up front for it
<geist>
(for kasan that is)
<heat>
that's not the worst
<geist>
for user space asan you can rely on overcommitting and lots of virtual memory to allocate and demand fill in the bitmap
<heat>
I can't do that because I do ASAN for vmalloc (which dynamically allocates address space)
<geist>
are we talking about user sace or kernel space?
<heat>
so I essentially implemented a CoW-like thing for the shadow mapping's page tables
<heat>
kernel
* geist
nods
<heat>
if you have asan-stack=1 you're even more screwed
Burgundy has joined #osdev
<heat>
not only do you need the early boot shadow zero mapping, but you need a real mapping for the stack because the compiler will emit code that writes directly to it
<heat>
(you have a TODO in fuchsia)
<geist>
unrelated: i read the other day that Intel Atoms from 5 or 6 years ago in the Rangeley class apparently fail over time
<heat>
isn't that normal?
<geist>
well, over time as in lots of them already have, after just a few years
<geist>
and my firewall is one of them
<heat>
oh
<geist>
it's apparently some sort of manufacturing defect that causes the i think LPC bus to fail to work, which usually causes most machines to not post
fatal1ty has quit [Read error: Connection reset by peer]
<geist>
since the bios can't talk to peripheral devices
<geist>
somethingl ike some internal clock derivatoin logic fails over time prematurely
<heat>
cpu or chipset?
<heat>
I can never tell if things are apart of the CPU itself or the chipset
<geist>
ie, intel C2338, etc. they were an earlier rev of a line of atoms with lots of built in networking stuff
<geist>
sold for exactly stuff like firewalls and whatnot. still very popular
<geist>
in fact mine is literally a C2558
<gog>
i cannot connect to the professional sortix network again :(
<geist>
anyway what people are reporting is a very high failure rate on these
<heat>
the professional sortix network had a crash
<geist>
yah its still down it seems
<heat>
sortie is on it
<gog>
ooof
<sortie>
gog, you can evacuate to #sortix on this network instead :)
<sortie>
It's the evacuation assembly point
<gog>
good to know :)
<sortie>
In case of fire, don't use the elevators for up/down in gdb
<sortie>
But yeah I managed to attach a gdb to the crashed kernel on my production VM and am right now trying to understand where the bad pointer causing a GPF came from
<gog>
oops! #GP no fun
<geist>
sortie: omg hasnt work told you you immediately roll the change back and fix the failure later?
<sortie>
geist, would do if it hit the sortix.org front page, but irc.sortix.org is my test bed for debugging critical stability issues
<sortie>
Better if it's down for a day if I debug a bad kernel crash
<geist>
heh i'm kidding. i find it kinda annoying some time (that policy) but it's the rules!
<sortie>
Oh it's def a policy for a reason and I do it all the time when I break infra
<geist>
ie, always roll back never fix forward
<geist>
yah it's just annoying when the fix forward is like a one line typo
<sortie>
And then I debug the problem and reland a fixed version
<sortie>
Well I do fix forward now and then
<sortie>
But only if a fix is obvious
<sortie>
geist, though you definitely appreciate the value of a super rare kernel crash
<sortie>
You know how stable the irc server has been for months and then whoops there's a super mysterious crash
<geist>
oh tell me about it. now that we have bazillion hours of zircon running i the field there's enough kernel crashes getting reported that there are some really bizarro ones to try to scratch your head over
<gog>
cosmic rays
<geist>
though many of them are flipped bits, or at least *have* to be, and the kernel is the canary
<gog>
fatal single-bit flip caused by a high-energy particle originating deep from outer space
<geist>
doesn't help that the kernel is very very highly asserted, so it tends to trip over anything slightly amiss. keeps a tight ship
MrBonkers has joined #osdev
MrPortmaster has quit [Ping timeout: 252 seconds]
<geist>
acyually a thing you can find is sometimes there's one or two devices in the field that clearly have bad DRAM
<geist>
and just continually generate failures. you feel bad for the owner but theres nothing you can do
<heat>
why are the asserts still compiled in for release?
<geist>
because they find problems
<heat>
but you're complaining that they're finding too many
<geist>
though to be clear we have two levels of asserts: ones that are DEBUG_ASSERTS that are turned off for production devices
<geist>
and then regular ASSERTs that are left on all the time
<geist>
sure, but it's *good*
<geist>
i'm complaining not complaining
<gog>
compilaining
<gog>
is when you bitch about gcc or clang
<gog>
get it
<gog>
do y'all get my hilarious pun
<heat>
hehehehehe
<geist>
but what i mean is when you suddenly have millions of hours on your kernel and getting live reports of kernel panics it starts to get a little intimidating
<heat>
totes
<geist>
even if it's only a few here and there. the stragglers are the real weird ones
<geist>
for example, there's an *extremely* rare bug that we've never been able to reproduce and keep adding more code to try to catch it: when tearing down an arm64 aspace, it asserts that the page tables are empty
<heat>
I don't know how it looks in the operating systems world but for distributed systems (like the one I worked on at CF) it heavily depended on the team
<geist>
ie, it's mandatory that something already called Unmap() across all of the mapped things, so by the time the aspace tears down the top level page table should be empty
<gog>
me every time one of our watchdogs sends me an exception report
<geist>
but extremely rarely it's not
<heat>
the nginx team ran an extremely tight ship. no sentry issues *ever*
<geist>
so been thinking it's a cosmic ray, but it's so hard to catch we have to just add another assert and wait another month
<geist>
and we've gone over the state machine that should ensure that unmap() was called, and no other thing could have mapped into the page tables in the interim before destructing the object, etc
<geist>
mind you *these* are the kind of failres i'm talking about we get reports on. the kernel is pretty solid, it's lingering issues like this that are tracking
<geist>
i also just made another pass through the logic to make sure all the appropriate memory barriers are in place, etc.
<heat>
yay memory barriers
<geist>
tightened it up a bit, that might fix it? perhaps there's some extremely rare case where some PT entry gets written very late to the page table, but i can't imagine how
<heat>
have you never reproduced it?
<geist>
no.
<heat>
how much info are you collecting?
<geist>
that's the thing, given that we only see it extremely rarely and there are millinos of hours in the field, probably daily, it's clearly very very hard to reproduce
<heat>
do you have coredumps?
<geist>
oh no
<geist>
just a panic message
<heat>
:(((
<heat>
get coredumps and check again
<geist>
on purpose: has to not have any user data in it, etc etc
<geist>
has to be anonymized, etc
<geist>
and has to survive a reboot, so by the time the kernel panics it squirrels the panic data in a little memory area (or an EFI capsule if there) and the next kernel grabs it
<geist>
but the space is very limited
<heat>
does it? i think the law is a bit more fine tuned than (no personal information ever)
<geist>
what do you mean?
<heat>
we had law-compliant coredumps, but they had to remain in a remote server, etc
<geist>
right, i mean perhaps, but a core dump of the kernel is... a lot
<geist>
or i guess maybe the other way of looking at is is we've never even considered building a core dump system into the kernel because i dont know how we'd be able to use that in the field
<geist>
so we get a panic message and about 4K of the kernel log leading up to it
<geist>
it's fine, that's not the problem here
<geist>
the problem here is the damn bug rarely reproduces
<heat>
if you have the hw (which you probably do) and it never reproduced there, maybe it really is just a cosmic ray
<geist>
perhaps
<geist>
that's a theory, the logic in how the PT code cleans itself up and unmaps page tables means that if there's a bit corruption somewhere in a PT it'll keep that part of the tree from being cleaned up
<geist>
that's our current working theory, but we have to add more crash time logic to confirm it
<geist>
ie, 'if we sense that the top level PT is not empty, walk the PT leaves until you find the deepest PT and print all of the nonzero entries'
<geist>
i think that's the current logic we have in there to try to catch it
<geist>
add that, wait a few months
<heat>
yeah
<heat>
i mean, if you need to wait a few months, it's not that serious
<heat>
you can keep drinking your mojitos in the sun
<geist>
sure
<geist>
but that was the original point of the discussion: it's the lingering rare bugs that are really annoying
<heat>
linux gets around this by not having any automated bug reports
<heat>
easy
* gog
gets the crushed ice and muddles some mint
<heat>
i wonder how windows' bug reports look
<heat>
probably way scarier
<heat>
think about it, you're running a relatively controlled experiment with devices you know and that were made by Google itself
<heat>
not a crappy 2006 laptop
<geist>
oh totally
<geist>
the anonymization is frustrating though. for example if we see a device that continually blows up due to bad dram, there's no way to tie it to a user
<geist>
i'd love to get the device back and send them a new one, but there's no way to do it
<geist>
i mean i am 100% for all the anonymization but this is the one case where you feel bad for the owner but can't do anything about it unless they report it
<heat>
maybe you could add some bad hw detection stuff
<heat>
like if the OS crashes way too much, etc
<geist>
i suppose. when the kernel detects it it's hard
atilla has joined #osdev
<atilla>
use risc-v
<geist>
but yeah, that's probably the only real strategy. if you get too many forced reboots that are not just due to someone unplugging it, etc, then try to get them to report it
<heat>
I don't mean memtest, but actual "your stable build of fuchsia is crashing way too much. you probably have bad hw, please talk with support..."
<geist>
yah that's the best you can do
<atilla>
that wouldnt be happening if you were using riscv
<geist>
i'll brig that up with the device metrics folks, see if they're not always thinking this
vai has joined #osdev
<geist>
s/always/already
<vai>
geist: howdy + friends
vai is now known as Jari--
<geist>
howdy Jari--
<atilla>
wassup baby
<geist>
every time i see vai i think Steve Vai
<Jari-->
geist: Finland is hot, more than 5 celcius today
<geist>
then i think of the new Polyphia song, which is growing on me
<atilla>
I am thinking of building an operating system that will keep niiggers away. How do I build one? I am thinking of detecting spelling mistakes and ebonics to initiate SSD wipe sequence
<Jari-->
Anyone in the osdev teams thought of walking to the Silicon Valley and convince the investors to get in?
<heat>
running candy crush for my mom is the world's most critical task
<geist>
the candy must flow
<geist>
today's task: rearrange some VLANs at my home network to move the main LAN traffic off the untagged network
<heat>
lk/fuchsia as a router/switch when?
<geist>
currently using pfsense, but one day i'll use LK as my router!
kori has joined #osdev
<heat>
if I had a cool embedded OS that runs everywhere I would make sure it ran everywhere
<heat>
hmm, i wonder if lwip is good for routing?
<geist>
yeah it's my general lack of focus that holds it back. too many projects at once
<geist>
my general issue with lwip, at least last time i looked at it, is it's pretty un-performant
<geist>
iirc it's general strategy is to put everything in a queue and then iterate ont he queue
<heat>
steal BSD's stack
<heat>
as is tradition
<gog>
i will not use pfsense again
<geist>
makes for a simple design and fairly easy to deal with, but there's no way that scales up to routing speed
<geist>
gog: oh? you've had issues?
<gog>
the wireguard scandal made me question their review practices
<geist>
ah
<gog>
for a distro intended for secure appliances i wouldn't even consider it for a business that needs to comply with PCI-DSS
<geist>
that's fair. i'm just not sure i particularly trust anything else any better
<gog>
yeah
dutch has quit [Ping timeout: 252 seconds]
<gog>
that's the problem isn't it
<geist>
also trying to figure out why my network traffic is much higher this month
mxshift has joined #osdev
<geist>
peaking around 1.9TiB this month, which is much higher than usual
<gog>
eep
<geist>
the router seems to indicate that it's about even in/out which is suspicious
<gog>
you got a torrent runnign somewhere you forgot about?
<heat>
can it track per-host?
<geist>
sort of. i have a plugin darkstat that can, but it seems to only go back a few days
<geist>
and in that case nothing sticks out, mostly just traffic between me an google
<gog>
were you working from home more than usual this month?
<heat>
goma?
dutch has joined #osdev
<heat>
plus whatever build caching solution you have for rust
<geist>
well, that does have a fair amount to do with it. i'm looking at stuff coming from my work vlan recently
<geist>
and yeah, like one work host has moved 45GiB in the last few days
<geist>
32GB on the 'out' path
<geist>
but this makes sense: nightly backups for work machines, though they're usually deltas
<geist>
also to note: xfinity adds up both in/out traffic for that 1.9
<geist>
which is about what i see here: my router is showing 755GiB in, 617GiB out, and i restarted it last around october 10th so it mised the first 10 days of the month
<geist>
i'm just mostly curious about that 617
sprock has joined #osdev
<sortie>
SO. I debugged my weird crash. I found out the Descriptor object was alive but the Vnode it pointed to appears to have been freed and reused.
heat has quit [Remote host closed the connection]
<sortie>
The file descriptor said it was an Unix socket
<geist>
!!
heat has joined #osdev
<sortie>
It's crashing in my solanum server calling ppoll(2)
<sortie>
So I'm thinking I got a Unix socket refcount issue when they're being passed. I'm already aware of such a bug, saw a weird crash about that the other day when casually testing
<gog>
aaay
<sortie>
But hey super duper impressive.. I had a failing VM with just a qemu monitor and a kernel without symbols, and I was able to rebuild a matching debug kernel, attach gdb, recover the thread frame of the crashed thread, and then do stack traces and lots of inspections to get a clue about what caused this super weird corruption
<sortie>
Like this is a production system, not meant for debugging at all, and I was able to inspect it really powerfully and see what's going on inside it
<sortie>
I restarted my irc.sortix.org network :)
<gog>
sortix sophisticated
ids1024 has joined #osdev
<heat>
careful with "rebuilding matching debug kernels"
<heat>
pr
<sortie>
Let's see if stays up, I mean this bug is rare
<sortie>
heat, hmm?
<heat>
particularly if you don't have reproducible builds
<sortie>
Yeah at least my builds are pretty reproducible
<sortie>
I was even able build my kernel on Linux matching the binary that I got when I built it natively on Sortix
<heat>
same sha?
<sortie>
Probably not, didn't check, but offsets for all the major stuff matched
<bslsk05>
postimg.cc: Screenshot 2022 10 31 at 3 02 33 AM — Postimages
<heat>
null pointer dereference
<heat>
your kernel code is buggy
<heat>
compile with KASAN+UBSAN and you might get more info
<nick64>
I mean, why is kernel making the null pointer reference here? It is deliberately doing it to make it crash for security form smap, but I explicitly disabled security
<heat>
because you're doing it?
<nick64>
I am doing it, but just to be sure we are on same page, what do you mean by "it"?
<heat>
*(char*)0x0
<nick64>
To clarify: I am not doing NULL deref, kernel is just deliberately doing this error condition to make it crash to prevent hacking
<heat>
where? why?
<nick64>
What I can't figure out is, I have disabled security on kernel, and can't seem to understand why it is still crashing
<heat>
linux doesn't have "hacking" prevention
<nick64>
I am clearing bit 21 of CR4 register in the code
<nick64>
that is a bit to prevent hacking
<heat>
unless some weird ass security module you have is doing that
<heat>
no, that has nothing to do with deref'ing a NULL
<nick64>
From what I understand, kernel (the kernel thread) is deliberately taking the BUG branch that is usually taken for NULL Deref, to make the thread crash, and it is not an ACTUAL null deref
<heat>
what kernel thread
<nick64>
Whichever thread is running the code that is accessing usermode pages from kernel
<j`ey>
if you've changed the code, to do something different from how linux does it now, maybe you need to change more things?
<nick64>
But the actual question in, how do I ask the OS to temporarily disable smap security
<heat>
nick64, stack trace pls
<heat>
you don't
<nick64>
I have done what is recommended inthe OSDev wiki
<heat>
you omitted the stack trace, the only relevant thing here
<nick64>
Let me do a dump_stack real quick
<nick64>
Wait, that's not what you want, you want the stack trace on crash.. let me screenshot that
<nick64>
patch_code is just invoking kernels built in text patch function, not doing anything from my own implementation there: https://postimg.cc/bDM9rG0P
<nick64>
Oh and those function pointers I am passing to it via that wrapper function patch_code is something that The Almighty Kernel itself hinted me, so that can't be wrong, right? : https://postimg.cc/0MgNNP63
<bslsk05>
postimg.cc: fnptrs — Postimages
<nick64>
This wiki says that SMAP is determined by a bit in CR4 so that is what I am trying to do to avoid this error in the original screenshot, which cries out loud that it has something to do with smap. It says it is 21st bit so I am just clearing it: https://wiki.osdev.org/CPU_Registers_x86-64#CR4
<bslsk05>
wiki.osdev.org: CPU Registers x86-64 - OSDev Wiki
<heat>
I don't know, have you checked?
<gog>
nick64: "=m" (new_cr4) should be "+m"
<heat>
why are you touching smap anyway?
<gog>
actually no nvm
<gog>
you don't read it
<heat>
smap is so you don't touch user memory in kernel space without it being deliberate
<nick64>
I am not particularly doing SMA, but the kernel seems to be complaining of SMAP, so figured it maybe side effect of modifying kernel text section from a module insmod'ed from userspace
* klange
smells linux talk
<gog>
no, the kernel is being modified from kernel space
<gog>
the module becomes part of kernel space
<nick64>
Yeah, beats me why it is complaining smap, was trying to shut the kernel up about it anyway by disabling it
<gog>
what's happening is the kernel is trying to dereference a pointer at 0x0000000000000023
<gog>
which is in a userspace VMA
<gog>
idk how SMAP works exactly so i'm gonna read for a minute
<nick64>
I assumed that error message would be generic smap fault error message
<nick64>
not sure
<heat>
please show all the errors you're getting
<nick64>
because 23 is definitely not null
<nick64>
The first screenshot has all errors
<nick64>
let me find that
<heat>
0x23 is ((struct blah*)0)->field for sure
<nick64>
Oh okay got it, but still think that is generic error path taking for smap failure