> After having spent a bit of time looking into this, I think we are probably > OK, at least for reading these files. > > seq_file will loop over the file's show() callback, growing the seq_file > buffer until show() can run without overrunning the buffer. > > This means that the show() callback receives a buffer that is magically big > enough, but there may be some "speculative" calls whose output never goes > to userspace. Once seq_file has the data, it deals with the userspace- > facing I/O buffering internally, so we shouldn't have to worry about that. Doesn't this depend on the size of the user read(2) syscall request? If the total size of the resctrl file is very large, we have a potential issue: 1) User asks for 4KB, owns the resctrl mutex. 2) resctrl uses seq_file and fills with more than 4KB 3) User gets the first 4KB, releases the resctrl mutex 4) Some other pending resctrl operation now gets the mutex and makes changes that affect the contents of this file 5) User asks for next 4K (when it reaquires resctrl mutex) 6) resctrl uses seq_file() to construct new image of file incorporating changes because of step 4 7) User gets the second 4KB from the seq_file buffer (which doesn't fit cleanly next to data it got in step 3). -Tony
