dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
leon-anavi has quit [Quit: Leaving]
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
goliath has quit [Quit: SIGSEGV]
<vmeson> 2nd run on anujm/hardknott -> BUG: is there.... starting a (manual) git bisect of poky-contrib+ltp patch
<vmeson> gotta remember to cherry-pick RP's ltp commit
<vmeson> paulg: any luck with using actual brain cells rather than brute computational force ?
<JPEW> RP: yep, that's solvable, and makes sense why people would do that. At least I know now :)
RP has quit [Ping timeout: 252 seconds]
RP has joined #yocto
sakoman has quit [Quit: Leaving.]
pidge has quit [Ping timeout: 252 seconds]
fabatera[m] has quit [Ping timeout: 244 seconds]
Spectrejan[m] has quit [Ping timeout: 244 seconds]
shoragan|m has quit [Ping timeout: 244 seconds]
Pierre-jeanTexie has quit [Ping timeout: 244 seconds]
Jari[m] has quit [Ping timeout: 244 seconds]
Saur[m] has quit [Ping timeout: 244 seconds]
ejoerns[m] has quit [Ping timeout: 244 seconds]
khem has quit [Ping timeout: 244 seconds]
Andrei[m] has quit [Ping timeout: 244 seconds]
barath has quit [Ping timeout: 244 seconds]
dwagenk has quit [Ping timeout: 264 seconds]
asus_986_gpu[m] has quit [Ping timeout: 264 seconds]
alex88[m] has quit [Ping timeout: 264 seconds]
AlessandroTaglia has quit [Ping timeout: 264 seconds]
ndec[m] has quit [Ping timeout: 264 seconds]
janvermaete[m] has quit [Ping timeout: 264 seconds]
cody has quit [Ping timeout: 264 seconds]
kayterina[m] has quit [Ping timeout: 264 seconds]
Emantor[m] has quit [Ping timeout: 264 seconds]
shoragan[m] has quit [Ping timeout: 264 seconds]
jordemort has quit [Ping timeout: 264 seconds]
Vonter has joined #yocto
vmeson has quit [Ping timeout: 268 seconds]
vmeson has joined #yocto
paulg has quit [Ping timeout: 265 seconds]
beneth has joined #yocto
wesm has quit [Ping timeout: 252 seconds]
wesm has joined #yocto
zyga-mbp has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudX
chrfle_ has joined #yocto
mckoan|away is now known as mckoan
<mckoan> LetoThe2nd: Hi
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
mvlad has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wesm has quit [Ping timeout: 245 seconds]
zyga-mbp has joined #yocto
wesm has joined #yocto
gsalazar has joined #yocto
leon-anavi has joined #yocto
ant_ has quit [Quit: Leaving]
rob_w has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Andrei[m] has joined #yocto
kayterina[m] has joined #yocto
jordemort has joined #yocto
janvermaete[m] has joined #yocto
Jari[m] has joined #yocto
khem has joined #yocto
Emantor[m] has joined #yocto
ndec[m] has joined #yocto
Saur[m] has joined #yocto
Pierre-jeanTexie has joined #yocto
shoragan[m] has joined #yocto
cody has joined #yocto
ejoerns[m] has joined #yocto
barath has joined #yocto
shoragan|m has joined #yocto
Spectrejan[m] has joined #yocto
alex88[m] has joined #yocto
AlessandroTaglia has joined #yocto
asus_986_gpu[m] has joined #yocto
fabatera[m] has joined #yocto
dwagenk has joined #yocto
BCMM has joined #yocto
wallnut_experien has joined #yocto
<wallnut_experien> Hi all,
<wallnut_experien> anyone knows if bitbake config parser is available as a lib?
<wallnut_experien> The use case is I need to script some builds and change the local.conf for each build
<wallnut_experien> So far I'm "sed"-ing but this is becoming very dirty very quick
<wallnut_experien> Am hoping to add a helper script which would do something like:
<wallnut_experien> `bb_conf_helper add 'MACHINE ??= "qemux86-64"'`
<wallnut_experien> `bb_conf_helper remove MACHINE`
<wallnut_experien> `bb_conf_helper replace 'MACHINE ??= "qemux86-64"'`
<wallnut_experien> It is purely a CLI helper to script doing changes in local.conf
<wallnut_experien> I know bitbake needs to have a parser for this in which case I don't have to quickly patch up a config parser
<wallnut_experien> My question is, does anyone know it the bitbake parser has an API?
<mckoan> wallnut_experien: AFAIK no
<wallnut_experien> Tnx. So any best practices how to script bitbake then?
ant_ has joined #yocto
fiorentinoing has joined #yocto
<fiorentinoing> Hi folks, anyone is experiencing download issues during fetch of icedtea7(-native) package?
tnovotny has joined #yocto
<LetoThe2nd> fiorentinoing: yes unfortunately. see: https://lists.yoctoproject.org/g/yocto/message/53785
<fiorentinoing> How can I join the discussion? I have the tarball too, but the configure fails later on
wallnut_experien has quit [Quit: Client closed]
<mckoan> fiorentinoing: subscribe the ML : https://lists.yoctoproject.org/g/yocto
<fiorentinoing> done ;) thanks
pbaptista has joined #yocto
<ismail> I've a very simple build fix for kernel, can I just send a patch or do I need a git tree which one can pull from?
<LetoThe2nd> ismail: to poky?
vemraete has joined #yocto
<vemraete> Konrad?
<vemraete> is there a way to create the CVE manifest only for the none native recipes?
<LetoThe2nd> ismail: i'd just put it on the yocto ml, cc bruce ashfield and see what happens
<ismail> LetoThe2nd: Thanks
hpsy has joined #yocto
<ismail> Patch sent, let's see
patrick_r has joined #yocto
fiorentinoing has quit [Ping timeout: 250 seconds]
fiorentinoing has joined #yocto
<fiorentinoing> ismail could we have a preview of the patch to be tested?
<ismail> fiorentinoing: I sent the email with the patch
<ismail> I tested on an NXP board
<fiorentinoing> ismail ok I'll wait the digest then ;)
<ismail> Ah let me find the link :)
goliath has joined #yocto
fiorentinoing has quit [Quit: Client closed]
vemraete has quit [Quit: Client closed]
rob_w has quit [Quit: Leaving]
zyga has joined #yocto
zyga-mbp has quit [Ping timeout: 244 seconds]
zyga has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tnovotny has quit [Quit: Leaving]
zyga has joined #yocto
<RP> pseudo changes to work with uninative break it for eSDK :(
* RP wonders if we have anyone who fancies trying to fix it?
ant_ has quit [Quit: Leaving]
<RP> vmeson, zeddiii: This *maybe*, just maybe an issue between qemu 5.1.0 and 5.2.0
mihai has joined #yocto
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
fiorentinoing has joined #yocto
pbaptista has quit [Ping timeout: 250 seconds]
* zeddiii RP, I'd hope fray might be the guy to work on the psuedo thing
<zeddiii> RP: interesting on the qemu, I saw your swat email update. I'll tweak my kernel config more here. My test ran over night with no issues.
<RP> zeddiii: I can't tell if this is the same kernel bug or not with gatesgarth :/
<RP> It is looking like vanilla 5.2.0 qemu is ok but 5.2.0 with CVE fixes breaks
<RP> only 27 patches to choose from
prabhakarlad has quit [Ping timeout: 250 seconds]
<zeddiii> and our qemu 6.0 in master inherits that same issue that was introduced in that window. For a second, I thought you meant we had backported patches and it was only on those versions
<RP> zeddiii: it looks like setting CONFIG_SCHED_DEBUG "fixes" the kernel and stops the error happening
<RP> zeddiii: so I guess that means the situation is defconfig sensitive
<zeddiii> some sort of scribbler could be avoided with the extra debug space or different code path. I'll have a look at what that really changes code wise.
<zeddiii> hah. I just noticed now that I got an extra 'i' ...
zeddiii is now known as zeddii
zeddii is now known as zedd
* zedd has defeated the iis
<RP> zedd: do we know you?
<zedd> in my haste to get to libera, it never dawned on me that zedd might not be registered :D
<JPEW> Hmm, apparently I've been banned from freenode completely
<zedd> bad behaviour.
<RP> JPEW: Crofton can tell you about that I think
prabhakarlad has joined #yocto
<Crofton> reconnect it will go through
<Crofton> I assume they are cleaning unattended accounts
<Crofton> wel that is one theory
<yannd> I'm surprised, in gartesgarth/hardknott mesa.bb does not provide virtual/egl, virtual/libgles2 and friends, though several packages depend on it - shouldn't mesa-with-panfrost take care of that ?
hpsy has quit [Ping timeout: 264 seconds]
<RP> zedd: for fun I turned on default debug stuff apart from SCHED_DEBUG and it still breaks so there is something about that option
<yannd> duh, bad PACKAGECONFIG probably, sry for the noise
<fiorentinoing> coming back to icedtea7-native, someone has the url of a MIRROR of this package of meta-java? (I'm stuck to morty till August)
<JPEW> Crofton: Ya, that worked
* RP is starting to hate bisection
fiorentinoing has quit [Quit: Client closed]
* vmeson plods ahead with the bisect: scripts/buildhistory_analysis: Avoid tracebacks from file comparision code (Thu Oct 29 15:21:35 2020) has no BUG
<vmeson> next step of 10! 41f96b141e oeqa/ethernet_ip_connman : add test for network connections
hpsy has joined #yocto
paulg has joined #yocto
<RP> vmeson: will be interesting if you reach the some conclusion I do about the cause. I appear to have narrowed it to a single qemu patch. It is just rather odd
<paulg> sounds like I missed the "big reveal"...
<RP> paulg: its weird enough I'm not prepared to say :)
<paulg> I can add this interesting data point - going to what I'd said elsewhere last night - that my "good" boot survived 50 runs in a row overnight, booting exactly what crashed earlier in short order.
<paulg> [06/10 23:23] <paulg> I'm wondering if you get a "good boot" -- i.e. a fortuitous alignment or similar ; then it stays working - this is where "-c testimage" can let you down ; it reboots each time.
<v0n> which package provides systemd-escape on the host? (for DEPENDS)
<RP> So this sounds insane, but adding this patch: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b8d7f1bc59276fec85e4d09f1567613a3e14d31e to qemu 5.2.0 on gatesgarth causes it to then crash after that point
<RP> vmeson, paulg, zedd: ^^^
* paulg clicks
<RP> and yes, I know what that code is
<paulg> does our build of qemu6 even make an object file for old IDE crap? I can never keep track of how old the hardware qemu is pretending to be ; for all I know it still might be a 1998 i440bx chipset (still!)
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
<paulg> the "big" machine seems to be the most reliable reproducer for me ; anyone tried reverting that on master / qemu6 and retesting yet?
<RP> paulg: it is built and there is a message about ATAPI during boot
<RP> paulg: the revert is my next test
<paulg> ok, I'll go get coffee and popcorn then.
<paulg> and look at the damn patch in more detail.
<zedd> if our kernel configs are turning on devices that are not really used, but yet trigger the crash when exercised, we can turn them off .. a little sweeping under the rug :P
<zedd> which just means we'll trip on the rug later and hurt ourselves
zyga has quit [Ping timeout: 264 seconds]
<v0n> Is there a systemd-extra-utils-native package?
sakoman has joined #yocto
<RP> zedd: lets see if reverting this really does "fix" it. If it does we should likely be removing the cdrom support from the qemu kernels :)
<RP> and report this upstream to qemu
<vmeson> v0n: I don't think there's a systemd-extra-utils-native package. If you explain why you're asking maybe someone can help .
chrfle_ has quit [Remote host closed the connection]
chrfle_ has joined #yocto
<v0n> vmeson: there's none indeed. I'll escape things myself ^^
* RP wonders why half the world is rebuilding and decides he doesn't want to know
zyga has joined #yocto
* paulg copies all qemu-* aside as backups before vandalizing things
goliath has quit [Quit: SIGSEGV]
<RP> that patch looks ok to me, the only bit I can't quite tell with is the change to unsigned
<RP> gah, confirmed reverting that from 6.0.0 does not fix things
<RP> so I've messed up the bisection somewhere
* vmeson continues to bisect, no on: 43c40ea7e0 libdnf: replace a musl fix with a better one
<paulg> if you guys are both bisecting qemu ; you probably should pool your qemu "bad" points, since a bad is a bad, but a ten run pass is still just a "maybe ok, not sure."
dti has joined #yocto
Vonter has joined #yocto
<vmeson> paulg: not sure about RP but I'm bisecting poky!
<paulg> whee.
dtometzki has quit [Ping timeout: 264 seconds]
<RP> paulg: I'm bisecting qemu patches on top of 5.2.0 so quite different
<paulg> I was thinking whether it makes sense to convert qemu from tarball to git and build within yocto; or build it independently...
dti is now known as dtometzki
<RP> paulg: I was going to do that until I found deleting the 5.2.0 cve patches seemed to work
<paulg> I recall doing the former for some gfx libs with interdependencies for zedd like 5+ years ago
<JPEW> I usually do externalsrc for bisecting
<paulg> of course, life being what it is, I'm sure older qemu bisect points will blow up with gcc-11 just to keep life interesting... :-/
<paulg> would also want to tell qemu to not build arm/mips/blah blah blah.... in order to speed things up, I'd think....
<RP> paulg, zedd: The other change this keeps showing me is this one: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8bc1f1aa51d32c3184e7b19d5b94c35ecc06f056
<RP> some kind of race on those flags not being set together?
<RP> do we use those codepaths?
<paulg> NFI.
<RP> paulg: I though you were a kernel dev? :)
dmoseley has joined #yocto
<paulg> don't feel bad, you aren't the 1st person who has made the mistake of believing I actually know something useful.
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
dmoseley has joined #yocto
<paulg> pretty much happens every day. ;-)
* RP suspects we don't use those codepaths
zyga has quit [Remote host closed the connection]
zyga has joined #yocto
* RP suspects 5.2.0 is probably bad on gatesgarth but I just can't provoke it
<paulg> the fact that I was able to do a run of 50 w/o issue on the identical load that went splat in less than 3 just prior does mean only the bad points are known to be truly bad
<paulg> everyting else is a "maybe ok".
<paulg> I've got four fails in 21 runs on the big machine. So anything less than 10 runs w/o fail isn't really a useful data point.
<vmeson> Yikes...
<vmeson> paulg: maybe it's cosmic rays!
* vmeson runs
pbaptista has joined #yocto
<paulg> oh yay - qemu uses submodules!
pbaptista has quit [Quit: Client closed]
ncaidin_lf has joined #yocto
<RP> plain 5.2.0 does looks like it has the bug under gatesgarth
<vmeson> RP: :(
<RP> vmeson: I still think 5.1.0 is "clean" so it could be some delta between 5.1 and 5.2
* RP should try 5.1.0 with master
<vmeson> RP okay. Btw, how many times are you running your tests? Can you confirm paulg's 4 of 21 stat?
<vmeson> I'm testing 5 times at each bisect.
<RP> vmeson: I'm more at the 5 times but I did test gateagarth specifically much more
<vmeson> k, currently on: 5d9a91a2ae uboot: Deploy default symlinks with fitImage -- Bisecting: 253 revisions left to test after this (roughly 8 steps) - Fun!
<RP> vmeson: will be interesting to see where that puts the issue
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<vmeson> RP: Yep, that commit has qemu_5.2 so it should show up....
zyga has quit [Quit: Leaving]
<paulg> ended up building qemu outside of yocto ocne I saw it used submodules...
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
<paulg> can one get to the qemu console during testimage? I'd like to just be sure with a version check I'm running what I built and not the old binary or the distro binary somehow.
<RP> paulg: not easily
<RP> paulg: I see what you mean about submodules. Ick :/
* RP throws gitms:// at it
<RP> gitsm://
<paulg> I know I'm running my qemu binary 'cause I apparently borked gfx - but testimage is still running and I can ssh into the instance. So who cares about gfx!!!
<paulg> I built top of tree for starters...
<RP> paulg: fwiw it looks like the gitsm fetcher can handle this
<paulg> I wasn't that brave
<paulg> I gave qemu its own empty install bin dir and then just symlinked those babies into tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin
<paulg> ugly, but seems to be good enough for what I want here.
<paulg> kept the originals of course, in case I want to switch back.
<paulg> and lo and behold... 1st run with qemu at top of tree..
<paulg> root@qemux86-64:~# dmesg|grep BUG
<paulg> [ 239.049107] BUG: kernel NULL pointer dereference, address: 0000000000000008
<paulg> [ 239.087337] BUG: kernel NULL pointer dereference, address: 0000000000000008
<paulg> [ 239.127447] BUG: kernel NULL pointer dereference, address: 0000000000000008
<paulg> knew sth was up when the test went beyond 5m
<paulg> whole raft of tehm as ususal; just pasted top 3.
FO3 has joined #yocto
<paulg> so there is our 1st officially bad bisect point.
<paulg> top of tree. QEMU emulator version 6.0.50 (v6.0.0-1552-g894fc4fd67)
gjohnson has joined #yocto
<paulg> ok, so what do you clowns think is "good" ? Some v5.x version?
<RP> paulg: 5.1.0
<paulg> I also built qemu out of the source tree, so I'll have each bisect point to go back to .
<paulg> lemme checkout 5.1.0 and see if it builds on this host.
<RP> paulg: and I know 5.2.0 is bad
dev1990_ has joined #yocto
dti has joined #yocto
<paulg> Guess today is my crash course on submodules....
<rburton> git clone --recurse-submodules [url]
<rburton> why that's not the default i don't know
Shaun_ has joined #yocto
<rburton> saves you having to faff about with git submodule, because i can never remember the right commands to get it to do the right thing
Vonter_ has joined #yocto
<gjohnson> rburton git submodule init; git submodule update
<paulg> I've already got all the poo ; I just want to checkout at different points ; not reclone each friggin bisect point.
<paulg> qemu$git checkout v5.1.0
<paulg> warning: unable to rmdir 'meson': Directory not empty
<paulg> M slirp
<paulg> M ui/keycodemapdb
<paulg> M capstone
<paulg> Note: switching to 'v5.1.0'.
<paulg> Not liking those "M" though
<rburton> i hate submodules
* paulg does too, but resorts to RTFM anyway
Vonter has quit [*.net *.split]
dtometzki has quit [*.net *.split]
Emantor[m] has quit [*.net *.split]
shoragan[m] has quit [*.net *.split]
barath has quit [*.net *.split]
cody has quit [*.net *.split]
Andrei[m] has quit [*.net *.split]
dev1990 has quit [*.net *.split]
sgw has quit [*.net *.split]
FO2 has quit [*.net *.split]
JPEW has quit [*.net *.split]
Tartarus has quit [*.net *.split]
CosmicPenguin has quit [*.net *.split]
angolini has quit [*.net *.split]
Shaun has quit [*.net *.split]
goliath has joined #yocto
<gjohnson> I want to have a variable in my local.conf called SSH_ROOT_LOGIN, based on this I want to have openssh and refpolicy targeted to be configured to allow root to login over ssh for debugging purposes. I can't figure out how to get openssh to rebuild when the SSH_ROOT_LOGIN variable changes. Here is the last thing I tried https://termbin.com/4hsx5
Vonter_ is now known as Vonter
<gjohnson> I can see the do_configure hash changes when the variable changes but that isn't causing the recipe to be rebuilt.
robbawebba has joined #yocto
mckoan is now known as mckoan|away
<paulg> "git submodule update" took friggin forever, but now I'm "M" free.
<paulg> qemu$git checkout v5.1.0
<paulg> HEAD is now at d0ed6a69d3 Update version for v5.1.0 release
<paulg> lets see if I can build it...
<paulg> qemu-v5.1.0$./x86_64-softmmu/qemu-system-x86_64 --version
<paulg> QEMU emulator version 5.1.0 (v5.1.0-dirty)
<paulg> Not sure why it thinks it is dirty ...
<RP> paulg: it uses submodules? :)
<paulg> heh, could be. ANyway "git submodule foreach git status" and git status at top show nuttin' so I'm ignoring it for now
<RP> paulg, vmeson: with master I just had 5.1.0 fail :(
<paulg> I'm doing several runs at top-of-tree before moving on to testing ... well maybe not testing v5.10....
<paulg> I guess to be fair, we've not concretely blamed qemu at this point -- vs. being the prime suspect.
<paulg> 2nd run at top-of-tree didn't barf, so stats there stand at 50/50 with an error margin of 100%. :-/
<RP> paulg: what is weird is that the NULL derefs happen at about 210s on master yet at 44s on gatesgarth
angolini has joined #yocto
CosmicPenguin has joined #yocto
Tartarus has joined #yocto
JPEW has joined #yocto
<vmeson> RP: paulg. with 1 run, qemu-5.2 did NOT fail for me. Doing more tests now. I might do 10-20. over lunch break.
<RP> vmeson: I'm getting varying results. I have seen 5.1.0 fail now
<vmeson> Yeah, this is going to be annoying...
<paulg> not to mention a giant time sink.
<RP> I need to go and get food, think I've done what I can with this today
<vmeson> This is probably obvious but all the BUG warnings look like a pointer offset problem in that the address given i a small number of bytes: 8, 12, etc.
<paulg> shame there isn't an unmapped page at the bottom to catch all these foo->bar where foo = NULL and flag them as null deref.... oh wait.
<vmeson> paulg: sure, so some pointer in the kernel is getting over-written with NULL, could one (i.e. paulg) put a gdb HW breakpoint on the address that is 'usually' involved to see what is doing the corrupting?
<vmeson> I haven't done that with qemu and the guest kernel but it seems like it might be worth trying. Waste of time paulg?
<vmeson> my test at: 5d9a91a2ae uboot: Deploy default symlinks with fitImage -- which as qemu_5.2.0 did not get a BUG: 5 times. Running 15 more while breaking for lunch.
leon-anavi has quit [Quit: Leaving]
shoragan[m] has joined #yocto
barath has joined #yocto
Emantor[m] has joined #yocto
BCMM has quit [Ping timeout: 268 seconds]
<v0n> Is there a way to not install the *-py3.9.egg-info directories?
ant_ has joined #yocto
Andrei[m] has joined #yocto
ncaidin_lf has quit [Quit: Client closed]
cody has joined #yocto
robbawebba has quit [Quit: WeeChat 3.0.1]
robbawebba has joined #yocto
bps has quit [Remote host closed the connection]
BCMM has joined #yocto
<paulg> RP, if you happen to stumble by again, can you run this on your tesimage boot logs?
<paulg> testimage$for i in `grep -l BUG qemu*` ; do grep -A 10 BUG $i | grep RIP: | head -n1 ; done
<paulg> my data set looks like this:
<paulg> [ 183.232662] RIP: 0010:do_mkdirat+0x6c/0x130
<paulg> [ 236.180131] RIP: 0010:0xffffa0ffc566f978
<paulg> [ 237.870061] RIP: 0010:kernfs_sop_show_path+0x1c/0x60
<paulg> [ 224.511907] RIP: 0010:d_alloc_parallel+0xd5/0x570
<paulg> [ 234.441805] RIP: 0010:d_alloc_parallel+0xd5/0x570
<paulg> [ 230.232456] RIP: 0010:d_alloc_parallel+0xd5/0x570
<paulg> [ 205.094018] RIP: 0010:do_mkdirat+0x6c/0x130
<paulg> the one instance of "non-function" above comes from the one and only instance of NX I got.
<paulg> [ 236.167664] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
<paulg> 0xffffffff81259f1c is in do_mkdirat (/ala-lpggp31/paul/poky/build/tmp/work-shared/qemux86-64/kernel-source/fs/namei.c:3660).
<paulg> (gdb) l *do_mkdirat+0x6c
<paulg> 3660 if (!IS_POSIXACL(path.dentry->d_inode))
<paulg> 3661 mode &= ~current_umask();
<paulg> I can almost similary convince myself the parallel case also comes from a null dentry....
rcw has joined #yocto
* paulg wanders off away from The Giant Time Sink for a while.
patrick_r has quit [Quit: Client closed]
tperrot_ has quit [Ping timeout: 265 seconds]
tperrot has joined #yocto
dti is now known as dtometzki
FO3 has quit [Read error: Connection reset by peer]
<paulg> another finger pointing at dentry magik
<paulg> qemu_boot_log.20210611183517:[ 210.586648] WARNING: CPU: 0 PID: 1902 at fs/dcache.c:338 dentry_free+0x69/0x70
<paulg> qemu_boot_log.20210611183517:[ 210.598391] WARNING: CPU: 1 PID: 1903 at fs/dcache.c:338 dentry_free+0x69/0x70
<paulg> static void dentry_free(struct dentry *dentry)
<paulg> WARN_ON(!hlist_unhashed(&dentry->d_u.d_alias));
<paulg> {
halstead has quit [Quit: Leaving]
sakoman has quit [Read error: Connection reset by peer]
halstead has joined #yocto
prabhakarlad has quit [Quit: Client closed]
tgamblin has quit [Quit: Leaving]
gsalazar has quit [Ping timeout: 244 seconds]
tgamblin has joined #yocto
AdrianFGuest39 has joined #yocto
AdrianFGuest39 has left #yocto [#yocto]
AdrianF20 has joined #yocto
sakoman has joined #yocto
<v0n> how can you make a squashfs image containing only (and only) a package and its dependencies?
AdrianF20 has quit [Quit: Client closed]
<v0n> An image with IMAGE_INSTALL = "foo" always brings into a lots of files with it
<vmeson> v0n: I haven't done this but it seems like this might help: Application Container Example -- https://elinux.org/images/6/62/Building-Container-Images-with-OpenEmbedded-and-the-Yocto-Project-Scott-Murray-Konsulko-Group-1.pdf
Vonter has quit [Ping timeout: 264 seconds]
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
prabhakarlad has joined #yocto
<smurray> v0n: there's a bit more support bits now, though I suspect you don't need OCI container images
chrfle_ has quit [Ping timeout: 252 seconds]
<paulg> commit 4898e857db85ed20417b1308221d41a2057900bc
<paulg> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
<paulg> Date: Tue May 11 11:47:17 2021 +0100
<paulg> qemu-x86: Add commandline options to improve boot
* paulg eyes RP and his "rcupdate.rcu_expedited=1" suspiciously
<zedd> the plot thickens!
<paulg> yeah. I think I've increased reproducibility a whole bunch.
<paulg> or I thought I did after a kernel hack got me two (three?) in a row.
<paulg> theory is a jrw trick ; increase the window for a possible UAF. https://paste.debian.net/1200909/
<paulg> and why I'm looking at RP 's additional bootarg is the dentry free where you'll see...
<paulg> /* if dentry was never visible to RCU, immediate free is OK */
<paulg> we've been trying to brute force the answer out of this turd so far, and I figured it was about time I should look into what it is trying to tell us and make a better educated guess.
<zedd> ahah
<paulg> keyword is still "guess" at this point
<paulg> my baremetal testing was obviously not using any funky rcu bootargs...
<paulg> neither is 99.99993721347% of the rest of the world...
* zedd nods
<RP> paulg: I thought I'd removed that argument and still seen it :/
<paulg> I guess if vmeson got a "bad" in his global bisect that predates the RP band-aid fix above, then that would vindicate RP.
<paulg> ...or that. :)
<RP> paulg: do you still need that grep over the logs. I need to power the machine back :)
<RP> It is far too hot here atm :/
<paulg> RP, I was just trying to confirm the "dentry appears too close to the RIP every time
<paulg> ....every time" theroy.
<paulg> I think ATM it is pretty hard to ignore that fact, so no rush to confirm that.
<RP> paulg: I'd agree it seems related
<paulg> I've got my local machine running the udelay hack and in a loop of 10 runs while I go do an errand ; will BBL 'cause this is pissing me off and I want it solved.
<wesm> my git server uses gitolite and specifies repos with a colon, like <server>:<repo>. The git fetcher chokes on the : expecting an int port number
<wesm> I specified protocol=ssh but that still tries to parse the port
<abelloni> use a / instead of the :
<abelloni> i.e. git://git@git.example.com/linux;protocol=ssh will fetch git@git.example.com:linux
<wesm> abelloni: thank you, I didn't see that in the docs
<RP> paulg: mailed you the output
* paulg probably should check e-mail more than once a day....
<paulg> heh. my "ran 50x overnight" local box died on the 1st run after adding the udelay hack-patch.
<paulg> [ 268.674213] RIP: 0010:kernfs_sop_show_path+0x1c/0x60
<RP> paulg: I'm puzzled why I see a totally different trace with 5.8 on gatesgarth :/
<RP> paulg: making it more consistent would certainly help!
<paulg> yeah, no kidding! Not sure what to make of the v5.8 datapoints.
<paulg> but it seems you have the same 3 usual suspects in your other data block as I do ; sop/parallel/mkdirat
<paulg> which IIRC is where I sprinkled delays - and yes "200" was just a number out of the air.
<RP> paulg: as good as any place to start
roussinm has quit [Quit: WeeChat 3.1-dev]
* vmeson continues bisecting and testing between errands/dinner/etc: https://paste.debian.net/1200924/
<paulg> the RCU based dentry free code goes back to 2011, (in dea3667bc) so one would like to think that isn't fundamentally racy.
<vmeson> I haven't seen the bug all afternoon but I'm hopefully narrowing it down. 15 tests at each commit.
<paulg> vmeson, all those "good" are troublesome. Typical of a rare-ish reproducer.
<vmeson> I had been rebuilding without sstate just to be careful but I've decided that speed is more important now.
<vmeson> paulg: yeah. Each test takes ~ 7 minutes so for tonight, I'll continue with 15
* vmeson goes for dinner
<RP> vmeson: I doubt sstate matters from this perspective
<RP> vmeson: those "exclude cve from cve-check" won't matter FWIW
<paulg> this is my pass/fail log for all runs on the big machine https://paste.debian.net/1200925/
<paulg> any log that is 240-250k is a pass. Any short or long ones are a splat fest.
<RP> I suspect we could shorten the test list to speed things up a little too
<paulg> So I've managed 11 fails give or take on that one machine.
angolini has quit [Quit: Connection closed for inactivity]
robbawebba has quit [Quit: WeeChat 3.0.1]
hpsy1 has joined #yocto
hpsy has quit [Ping timeout: 252 seconds]
wesm has quit [Quit: Leaving.]