fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
orivej has quit [*.net *.split]
wcohen has quit [*.net *.split]
jistone has quit [*.net *.split]
khaled has quit [*.net *.split]
sscox has quit [*.net *.split]
lindi- has quit [*.net *.split]
przemoc has quit [*.net *.split]
zodbot has quit [*.net *.split]
fche has quit [*.net *.split]
xar- has quit [*.net *.split]
ChanServ has quit [*.net *.split]
ema has quit [*.net *.split]
ggherdov has quit [*.net *.split]
gavinguo___ has quit [*.net *.split]
agentzh has quit [*.net *.split]
pviktori has quit [*.net *.split]
derek0883 has quit [*.net *.split]
CME has quit [*.net *.split]
xlei has quit [*.net *.split]
tux3 has quit [*.net *.split]
DUKENUKEM has quit [*.net *.split]
serhei has quit [*.net *.split]
darvon has quit [*.net *.split]
zamba has quit [*.net *.split]
eichiro has quit [*.net *.split]
DTEIT has quit [*.net *.split]
chasum has quit [*.net *.split]
irker555 has quit [*.net *.split]
tonyj has quit [*.net *.split]
modem has quit [*.net *.split]
fLiPr3VeRsE has quit [*.net *.split]
higgins has quit [*.net *.split]
derek0883 has joined #systemtap
irker555 has joined #systemtap
agentzh has joined #systemtap
fche has joined #systemtap
przemoc has joined #systemtap
DTEIT has joined #systemtap
chasum has joined #systemtap
CME has joined #systemtap
xlei has joined #systemtap
ggherdov has joined #systemtap
khaled has joined #systemtap
tonyj has joined #systemtap
zodbot has joined #systemtap
higgins has joined #systemtap
modem has joined #systemtap
tux3 has joined #systemtap
xar- has joined #systemtap
fLiPr3VeRsE has joined #systemtap
ema has joined #systemtap
zamba has joined #systemtap
ChanServ has joined #systemtap
pviktori has joined #systemtap
serhei has joined #systemtap
gavinguo___ has joined #systemtap
eichiro has joined #systemtap
darvon has joined #systemtap
DUKENUKEM has joined #systemtap
lindi- has joined #systemtap
orivej has joined #systemtap
jistone has joined #systemtap
wcohen has joined #systemtap
khaled has quit [Client Quit]
ggherdov has quit [Ping timeout: 246 seconds]
ggherdov has joined #systemtap
<kerneltoast> fche, still around?
<kerneltoast> guess not
<kerneltoast> i'll spam you tomorrow about moar bugs
<kerneltoast> bigly bugs
<kerneltoast> tremendous bugs
<kerneltoast> yuuge
<fche> never tired of yuge bugs
<fche> did flipping those lines around help the kasan ?
<kerneltoast> fche, gotta wait for my tester overseas to find out :)
<kerneltoast> but there's another issue anyway
<fche> oh no
<kerneltoast> there are name collision issues with utrace's kmem_cache_create causing mayhem
<kerneltoast> a cursory look at the source reveals something like this must've cropped up in the past:
<kerneltoast> /* PR14781: avoid kmem_cache naming collisions (detected by CONFIG_DEBUG_VM)
<kerneltoast> locally relevant variable - into the names. */
<kerneltoast> by plopping a non-conflicting token - in this case the address of a
<kerneltoast> the only problem is, this name collision is harder to work around: https://gist.github.com/kerneltoast/69ea902e5fc69be5cd9e03831806ea5b
<kerneltoast> create_unique_id() is a dirty liar
<kerneltoast> and creates the least unique id ever
<kerneltoast> this affects a lot of different kernels and a wide range of kernel versions from our testing
<kerneltoast> i think the newest kernel we reproduced it on was 5.7.12
<kerneltoast> there are two ways to work around it from inside stap: either mark each kmem_cache we make as non-mergeable (very bad), or ditch the kmem_cache entirely (not so bad)
<fche> is this just a "make CONFIG_DEBUG_FOO work despite its limitations" kind of concern
<fche> or is there an actual bug there?
<kerneltoast> look at my gist
<kerneltoast> the kernel combusted
<kerneltoast> and in other cases, staprun gets hung
<fche> yes but did it combust because of limtations of the debug code activated there, or because of an underlying latent bug
<kerneltoast> ah
<kerneltoast> no clue
<fche> who knows maybe qxl is not capable of running with that debug goo
<kerneltoast> seems unlikely
<kerneltoast> it handles crazier debug goo just fine
<kerneltoast> like KASAN
<kerneltoast> also, it doesn't look like sysfs_warn_dup() is behind any debug config
<kerneltoast> fche, on amd64, struct utrace is 144 bytes and struct utrace_engine is 56 bytes
<kerneltoast> there's not much space lost just leaving these allocations to the default kmem caches
<kerneltoast> maybe a little space lost for the utrace struct
<kerneltoast> i can shrink the utrace struct back to a power of 2 (128 bytes)
<kerneltoast> then it'd fit nicely within a default kmem cache
sscox has joined #systemtap
<kerneltoast> fche, swapping the order of that procfs stuff fixes the KASAN splat
<kerneltoast> go shippit
<fche> go
<fche> ship is a go
<fche> i repeat
<fche> ship is a go
derek0883 has quit [Remote host closed the connection]
<irker555> systemtap: sultan systemtap.git:master * release-4.4-59-g73ba59200 / runtime/transport/procfs.c: transport: procfs: fix transposed procfs removal ordering
<kerneltoast> shippt
<fche> SAILED
<fche> let's get the right marine terminology down, pal
<fche> otherwise I may have to take back half the good things I said about you
* kerneltoast searches for good things fche has said about me
* kerneltoast `No such file or directory`
<fche> ah pity that will make taking back half even easier :-)
<fche> ok so re. struct utrace shrinking .... I guess as a pure optimization ........ I mean if we/you have nothing more pressing to worry about, sure, I won't stand in its way, but certainly wouldn't worry about it
<kerneltoast> so i can shrink struct utrace and get rid of the kmem cache?
<kerneltoast> can i get rid of the utrace_engine kmem cache too?
<fche> can consider it, if it's not too ugly & actually helpfuls omehow
<kerneltoast> it'll let us remove the rcu_barrier()
<kerneltoast> that's a noice perk
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 264 seconds]
irker555 has quit [Quit: transmission timeout]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
fdalleau has joined #systemtap
khaled has joined #systemtap
derek0883 has quit [Remote host closed the connection]
mjw has joined #systemtap
orivej has joined #systemtap
fdalleau is now known as fdalleau_away
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
derek0883 has joined #systemtap
amerey has joined #systemtap
tromey has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
<kerneltoast> fche, print("hi") print("ho") will break that
<fche> break how?
<kerneltoast> "hi" will get flushed, "ho" won't get flushed till you ^C
<fche> hm, that's not what seems to happen with that code, though I think I see why it could....
<fche> probably the flush timer doesn't wake up early enough to let hi / ho get separated
<kerneltoast> yeah but it easily could
<kerneltoast> i think I'll try coding up my task worker idea
<kerneltoast> it'll be comprehensive, won't need magic numbers, and gives us the biggest bang for our bits
<kerneltoast> and it also might not even work
<kerneltoast> (:
<kerneltoast> 50/50 chance i can make it work
<kerneltoast> either it works or it doesn't
<kerneltoast> 50/50
orivej has quit [Ping timeout: 240 seconds]
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]
<kerneltoast> fche, the task worker idea fell flat on its head because i can't get the task_struct pointer to each staprun reader thread
<kerneltoast> this would be much easier with some collaboration from staprun
<kerneltoast> i guess the next available option is using per-cpu timers to swap the subbufs
<fche> hey that sounds familiar :)
<kerneltoast> :(
<kerneltoast> so many timers
<kerneltoast> we'll be polling a timer on every cpu
<kerneltoast> for every stap module
<kerneltoast> doesn't it feel nasty
<fche> not too bad
<fche> we don't need to poll frequently
<kerneltoast> yeah we do
<fche> with your penultimate patch, the bulk case works okay
<fche> it's the intermittent case that needs assistance
<fche> and intermittent is non-urgent
<kerneltoast> hmmMMMmMMMmmmmm
<kerneltoast> how much will you allow staprun to be changed
<fche> the goal is ZERO
<kerneltoast> oof
<fche> big oof
<kerneltoast> but there was the bulkmode change
<fche> we don't talk about that one
<kerneltoast> and there hasn't been a new stap release yet
<fche> well more like it ought to have worked backward-compatibly, not sure I confirmed
<kerneltoast> i don't think it will
<kerneltoast> we saw it explode with mismatching staprun and runtime
<kerneltoast> so if staprun is already rekt, we can rek it some moar
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
derek0883 has joined #systemtap
<kerneltoast> fche, okay i think there's another way
<kerneltoast> use 1 subbuf per cpu and don't do any of this switching nonsense
<kerneltoast> might be hard to code up though
<kerneltoast> the switching stuff itself is already pretty complex...
<kerneltoast> nvm it'd be too hard to code up since relay doesn't disable irqs when reading
<fche> large changes scare me
<fche> please keep in mind that I am a very very old person who is super set in his ways
<fche> any patch larger than five hunks long gives arrythmia
<kerneltoast> then i'll just have to make it one big hunk
<fche> see that's much better
<fche> in that case I might as well make pre-arrangements at the morgue
<kerneltoast> i should've given you enough shock therapy with my print patches so far
<kerneltoast> and your age is still in the double digits, that's plenty young
<fche> how do you know?
<kerneltoast> fair point, nobody these days will have enough saved up to retire by 100
amerey has quit [Quit: Leaving]
DTEIT has quit [*.net *.split]
DTEIT has joined #systemtap
orivej has joined #systemtap