Hi, [...] >>>> >>>> As I didn't understand the seq_* semantics in the first place, I didn't >>>> have a look yet what could cause this. >>> >>> Nice catch, I'll have a look at this. >>> >>> Just so I'm sure, these are two processes reading the vgic-state file >>> for the same single VM, right? >> >> Yes, just one VM. I was about to write a small test program which is a >> bit more nasty and launches <n> threads all doing lseek();read(); on the >> same file in a loop, but it turned out that this isn't necessary ;-) >> I have that now working, so I can give this a test later. >> >> I was wondering if you could ditch that lseek / offset setting feature >> at all? The smaller debugfs files don't support it as well (ESPIPE on >> lseek()). Is that an option when setting up the seq interface? >> > > I think that only works if you're guaranteed to always only print within > the buffer allocated for a single read, but if you run out of buffer > space the seq_file code will allocate more space, do the fast forward > thing, and continue reading where it left off. I feel like when we're > enumaring over 1000 irqs and could be spitting out a bunch of LPI data > later on, this is a bit fragile. > The recommendations also state you should only do this if you don't need > a lot of locking or printing small data amounts, but I'm not enough of > an expert on the seq file to know exactly when that applies and when it > doesn't, but it doesn't feel like this fits within that bracket. Thanks for the explanation, and this indeed makes some sense. I just wanted to save you some nasty debugging, instead tricking you into just papering over the issue ;-) Cheers, Andre.
