On Thu, Feb 19, 2026 at 5:17 PM SeongJae Park <[email protected]> wrote: > > On Thu, 19 Feb 2026 15:36:56 -0800 Kalesh Singh <[email protected]> > wrote: > > > The rss_stat trace event allows userspace tools, like Perfetto [1], > > to inspect per-process RSS metric changes over time. > > > > The curr field was introduced to rss_stat in commit e4dcad204d3a > > ("rss_stat: add support to detect RSS updates of external mm"). > > It's intent is to indicate whether the RSS update is for the > > mm_struct of the current execution context; and is set to false > > when operating on a remote mm_struct (e.g., via kswapd or a > > direct reclaimer). > > > > However, an issue arises when a kernel thread temporarily adopts > > a user process's mm_struct. Kernel threads do not have their own > > mm_struct and normally have current->mm set to NULL. To operate > > on user memory, they can "borrow" a memory context using > > kthread_use_mm(), which sets current->mm to the user process's mm. > > > > This can be observed, for example, in the USB Function Filesystem > > (FFS) driver. The ffs_user_copy_worker() handles AIO completions > > and uses kthread_use_mm() to copy data to a user-space buffer. > > If a page fault occurs during this copy, the fault handler executes > > in the kthread's context. > > > > At this point, current is the kthread, but current->mm points to the > > user process's mm. Since the rss_stat event (from the page fault) > > is for that same mm, the condition current->mm == mm becomes true, > > causing curr to be incorrectly set to true when the trace event is > > emitted. > > > > This is misleading because it suggests the mm belongs to the kthread, > > confusing userspace tools that track per-process RSS changes and > > corrupting their mm_id-to-process association. > > > > Fix this by ensuring curr is always false when the trace event is > > emitted from a kthread context by checking for the PF_KTHREAD flag. > > > > [1] https://perfetto.dev/ > > > > Fixes: e4dcad204d3a ("rss_stat: add support to detect RSS updates of > > external mm") > > Sounds like the issue is not that critical, but user-visible? Would it be > better to Cc stable@ ?
Thanks for the reviews, SJ and Zi. I didn't add stable initially because it isn't functionally critical. However, it would be nice to get it backported, as without it, observability is much more difficult. I believe the patch should apply cleanly to stable with minimal risk. Andrew, if it isn't too much trouble, would you mind folding the following tag into the staged patch? Cc: [email protected] # 5.10+ Thanks, Kalesh > > > Cc: Andrew Morton <[email protected]> > > Cc: "David Hildenbrand (Arm)" <[email protected]> > > Cc: Joel Fernandes <[email protected]> > > Cc: Lorenzo Stoakes <[email protected]> > > Cc: Minchan Kim <[email protected]> > > Cc: Steven Rostedt <[email protected]> > > Cc: Suren Baghdasaryan <[email protected]> > > Signed-off-by: Kalesh Singh <[email protected]> > > Acked-by: SeongJae Park <[email protected]> > > > Thanks, > SJ > > [...]
