On Thu 29-08-19 15:47:19, Tejun Heo wrote: > cgroup foreign inode handling has quite a bit of heuristics and > internal states which sometimes makes it difficult to understand > what's going on. Add tracepoints to improve visibility. > > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> ... > +TRACE_EVENT(track_foreign_dirty, > + > + TP_PROTO(struct page *page, struct bdi_writeback *wb), > + > + TP_ARGS(page, wb), > + > + TP_STRUCT__entry( > + __array(char, name, 32) > + __field(u64, bdi_id) > + __field(unsigned long, ino) > + __field(unsigned int, memcg_id) > + __field(unsigned int, cgroup_ino) > + __field(unsigned int, page_cgroup_ino) > + ), > + > + TP_fast_assign( > + strncpy(__entry->name, dev_name(wb->bdi->dev), 32); > + __entry->bdi_id = wb->bdi->id; > + __entry->ino = page->mapping->host->i_ino; > + __entry->memcg_id = wb->memcg_css->id; > + __entry->cgroup_ino = __trace_wb_assign_cgroup(wb); > + __entry->page_cgroup_ino = page->mem_cgroup->css.cgroup->kn->id.ino; > + ), Are the page dereferences above safe? I suppose lock_page_memcg() protects the page->mem_cgroup->css.cgroup->kn->id dereference? But page->mapping does not seem to be protected by page lock? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
