On Mon 09-12-24 13:56:47, Klara Modin wrote: > Hi, > > On 2024-12-09 13:31, Jan Kara wrote: > > Hello! > > > > On Sun 08-12-24 17:58:42, Klara Modin wrote: > > > On 2024-11-15 16:30, Josef Bacik wrote: > > > > FS_PRE_ACCESS or FS_PRE_MODIFY will be generated on page fault depending > > > > on the faulting method. > > > > > > > > This pre-content event is meant to be used by hierarchical storage > > > > managers that want to fill in the file content on first read access. > > > > > > > > Export a simple helper that file systems that have their own ->fault() > > > > will use, and have a more complicated helper to be do fancy things with > > > > in filemap_fault. > > > > > > > > > > This patch (0790303ec869d0fd658a548551972b51ced7390c in next-20241206) > > > interacts poorly with some programs which hang and are stuck at 100 % sys > > > cpu usage (examples of programs are logrotate and atop with root > > > privileges). > > > > > > I also retested the new version on Jan Kara's for_next branch and it behaves > > > the same way. > > > > Thanks for report! What is your kernel config please? I've just fixed a > > bug reported by [1] which manifested in the same way with > > CONFIG_FANOTIFY_ACCESS_PERMISSIONS=n. > > > > Can you perhaps test with my for_next branch I've just pushed out? Thanks! > > > > Honza > > My config was attached, but yes, I have Ah, sorry, somehow I've missed that. > CONFIG_FANOTIFY_ACCESS_PERMISSIONS=n. I tried the tip by Srikanth Aithal to > enable it and that resolved the issue. > > Your new for_next branch resolved the CONFIG_FANOTIFY_ACCESS_PERMISSIONS=n > case for me. Thanks for testing! Glad to hear the problem is solved. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
