hm. well, I can't see any issue from just reading the code

are you able to compile a small linux binary to test with?

I guess

sec, I'll write something

i'd have to switch kernels back and forth tho

can't a macro be at fault? with clang and gcc behaving differently when expanding it?

dpaste.org/Cj4rR <-- try that

Title: dpaste/Cj4rR (Plain Code)

compile as a linux binary and run it inside and outside the chroot

all sorts of things could be at fault

in this working kernel, both return the value 0

both in chroot and non-chroot

i will now reboot into the faulty kernel, and report back

the address isn't the right one for the working kernel, it's based on the non-working one

RhodiumToad: [0x7fffffffe928] = 7fff00000000

inside chroot

and also outside chroot

(sh works but not bash, so i was able to chroot and run it from inside too)

both report the same large value

it looks to me like a register is not being fully set to 0

clang sets it and gcc does not

no

the value is supposed to be 7fffffffxxxx for some xxxx which I can't easily predict

ooh

it was 0 on the working kernel because the address is wrong there, since the code sizes change

I picked the address out of your gdb output

oooh

I don't understand why the chroot makes any difference though

you're right, it doesnt

though from this output, it seems like the bug is present outside the chroot too, it's just not being hit

segfaults without a chroot too...

aha

progress.

thats weird, when i ran a linux java runtime no problems happened

maybe a static binary?

possibly

this problem _probably_ only hits dynamic binaries

yeah

well if you want core file i can generate plenty

s

core files are not much use now. the next question is why is the value not being set, and that's going to need kernel debugging

actually before that, there is one check that can be done

let me write a quick program for you

alright, but i gotta be going to bed soon

i have aslr enabled, if thats important

Title: dpaste/eazw2 (Plain Code)

compiled and run for linux, that should dump out the linux vdso to a file "dump.out" in the current dir

that should allow inspecting the ELF headers and symbol table of the vdso to see if anything is incorrect

alright well, this kernel has a non-working linux compat

so i'll leave this for tommorow if thats ok

really need to head off to bed

if it runs ok, can you pastebin both hd dump.out and b64encode dump.out dump.out

ok, whenever

yeah alright, i'll do it tommorow and let you know

thanks, it was fun

ok, i am going to wipe current and go back to release. wish me luck

bonam fortunam habetis!

Whaou, we need to speak and write latin to FreeBSD now? Need to learn it before.

Quidquid latine dictum sit, altum videtur

("Whatever is said in latin, seems profound")

do more, do more!

whatever is said in latin, sounds like that total twat Rees-Mogg

καὶ σὺ τέκνον τῆς ἀρχῆς ἡμῶν παρατρώξῃ.

and now I don't know whether that's just a lot of ?s or whether it's something my irc client can't decode

RhodiumToad: it's Greece

Greek, even

You too, son, will take a bite of my rule. / You too, son, will take a taste of my power.

this is where the "you too, my son" from Caesar's last words comes from

RhodiumToad: dpaste.com/EBF7WH646

Title: dpaste: broken_linux_ko.dump.b64.txt

RhodiumToad: dpaste.com/BHDKJQCJE

Title: dpaste: broken_linux_ko.dump.hd.txt

gzar: oh, and can you also run the same program under the working kernel?

oh yeah, i did, was about to ask if you want the working ones too

RhodiumToad: dpaste.com/H74LUCM76

Title: dpaste: working_linux_ko.dump.hd.txt

RhodiumToad: dpaste.com/FJEYBL7RU

Title: dpaste: working_linux_ko.dump.b64.txt

if desired i can also tar-up the kernel, modules and symbols and upload it somewhere

that wouldn't be useful to me at present

hm. interesting.

so the way this is supposed to work is that the linux vdso is mapped at 0x7fffffffe000-0x7fffffffffff,

and the freebsd shared page at 0x7fffffffd000 (i.e. the previous page)

(this is for linux images, obviously, for freebsd images there's just the freebsd page at 0x7ffffffff000 or 0x7fffffffe000 depending on cpu type)

so, the linux vdso has to have a pointer to the freebsd shared timer info (in the freebsd page),

and it's exactly that pointer which is broken

here it is in the good image:

09a0 10d6ffff ff7f0000

and here in the broken one:

0920 00000000 00000000 00000000 ff7f0000

(it's at offset 928 in the broken one)

thats the value that is in RSI before it segfaults

yes

so the next question is why is it not filled in correctly

the weirder thing is, why is it correct when compiled with clang and not when compiled with gcc

the entry in the dynamic symbol table looks the same on both

could the linker somehow botch this up?

I don't think so.

then how come the same code produces different results with different compilers? could the optimizer be at fault?

what happens is that the vdso is compiled separately to a .so file, and then that's included into the linux module as a data blob

the kernel is responsible for doing the adjustment of the pointer to point to the right place, and clearly it's not happening

well, it is when clang is used

right

unless the fact that it works happens to be a lucky coincidence due to some offset/alignment happenstance

can you do objdump -x linux64.ko | grep kern_timekeep_base on the bad kernel's linux64.ko

yeah, one sec

RhodiumToad: dpaste.com/E7MBXK64G

Title: dpaste: E7MBXK64G

11:33 <gzar> well, it is when clang is used ⬅️ that seems like a pretty bad bug

yeah but i cant help but blame the compiler, since thats the only difference between a working linux64.ko and a busted one

gzar: can you get a disassembly of linux_exec_sysvec_init from kgdb linux64.ko (make sure the /usr/lib/debug subdirs are in the correct places as before)

yeah, one sec

unless I'm misreading this code, there are two separate places that both think it's their job to be initializing this,

and they may not be actually doing the same thing

RhodiumToad: dpaste.com/DLUMPVS9D

Title: dpaste: DLUMPVS9D

but without instrumenting the kernel to get details it's hard to tell

that is why i asked if you wanted the busted compiled kernel binaries and modules

do run through qemu or bhyve

I'd have to modify the code anyway, so having your compiled version wouldn't help much

maybe someone else would use a different approach

RhodiumToad: dtrace kinst not Good enough?

that's in -current, no? (I have not been using dtrace)

i dont think i have dtrace support enabled

it's in current, yes, not sure it's been MFC'd

gzar: 😒

if you're building an adventures new system, you better enable all the bells and whistles to make it debugable

i got a bunch of undefined symbol errors and i didnt expect gcc to break the kernel

its a generic kernel, i didnt consider switching a compiler would cause anything

to malfunction

do you know how long Linux took to build under clang?

no

about 12 minutes?

I mean, how long did Linux devs work on making Linux build with clang

i have no idea, honestly. Its the same language and both compilers should produce code that behaves the way it is described in the .c file

and besides the linux compat, the rest of the system seems fine

C is a weird language. and C compilers are very complex machinery

doesnt help linux kernel uses a lot of gcc extension :)

freebsd uses a lot of clang-extensions-copied-from-gcc

gzar: I probably won't be able to do more on this today.

its fine RhodiumToad , i didnt expect anything at all from this

Is there a way I can automate or manage FreeBSD upgrades in a better way? I have 2 VPS plus one local server running FreeBSD. When 13.2-RELENG was released, I had to upgrade all three servers manually. Is there a better way to upgrade/update my machines? The names of programs or directions to man pages would be great

RoyalYork: I like to use tmux-xpanes when I want to make the same mistake on several servers at the same time

😂

;-)

So you're saying manual is better?

I find that manually using freebsd-update isn't too much work, and I don't trust an automated process out of the box here because manual intervention is sometimes necessary to merge changed files

Understod. I'm not a sysadmin or network expert (just some shlep interest in BSD). In the real world, so sysadmins manualy update each server?

And that running freebsd-update between releases doesn't take up a lot of my time

It depends on many things. Try pinging AllanJude if you want to hear how he manages large amounts of servers, I remember him having a clever way of doing this

Was just wondering out of curiosity. But I hear your point. A few servers, doesn't take a lot of time.

RoyalYork: if instead of 3 servers, you had 30, i would recommend to reimage then. but 3 is like pets, not a cattle farm, so you can do whatever you want

I was gonna link that three minutes gif titled running your blog in kubernetes, that has someone build a sandwich with heavy duty tools in a carpentry shop

but all I'm finding is just graphs of the architecture of a blog run in kubernetes, so that joke is now reality

tho, for me, personally, the cutoff point isn't 30, it's more like 4

thanks meena

hello, i am once again asking for your support. I can't load vboxdrv kernel module, the error i am getting is this: linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type

gzar: what's the file type? and what are the other modules' file type(s)?

/boot/modules/vboxdrv.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), BuildID[sha1]=bc1e7274194b94bd7aad4f7fd11747772e907271, not stripped

/boot/modules/nvidia.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), BuildID[sha1]=75b022797682ef490cf72ef03e54f0cee20fea17, not stripped

that looks very much the same, tho

i know

i'll try compiling it from ports

alright, it worked

the message indicates that the module wont load on different kernel versions

this is exactly why i like freebsd

or just bsds in general

unsupported file type isn't very intuitive

looks like... linux

yuripv: so it is sorry but the talk is about BSD atleast

Title: Profesjonell bruk av fri programvare med Peter Hansteen - YouTube

luna_: what's it mean?

what's best simple image viewer?

like jpg gif

feh is simple

+1 for feh

display from imagemagick?

i often use browser

maybe somethiong on the lines of professional usage of free software

schillingklaus: yep in norweigan

Indo-European.