Messages in this thread | | | From | Rasmus Villemoes <> | Subject | Re: [PATCH v2 1/3] mm, printk: introduce new format string for flags | Date | Thu, 10 Dec 2015 09:41:18 +0100 |
| |
On Thu, Dec 10 2015, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, Dec 10, 2015 at 11:59:44AM +0900, Joonsoo Kim wrote: >> >> [page_ref:page_ref_unfreeze] bad op token & >> [page_ref:page_ref_set] bad op token & >> [page_ref:page_ref_mod_unless] bad op token & >> [page_ref:page_ref_mod_and_test] bad op token & >> [page_ref:page_ref_mod_and_return] bad op token & >> [page_ref:page_ref_mod] bad op token & >> [page_ref:page_ref_freeze] bad op token & >> >> Following is the format I used. >> >> TP_printk("pfn=0x%lx flags=%pgp count=%d mapcount=%d mapping=%p mt=%d val=%d ret=%d", >> __entry->pfn, &__entry->flags, __entry->count, >> __entry->mapcount, __entry->mapping, __entry->mt, >> __entry->val, __entry->ret) >> >> Could it be solved by 'trace-cmd' itself? >> Or it's better to pass flags by value? >> Or should I use something like show_gfp_flags()? > > Yes this can be solved in perf and trace-cmd via the parse-events.c file. And > as soon as that happens, whatever method we decide upon becomes a userspace > ABI. So don't think you can change it later.
So somewhat off-topic, but this reminds me of a question I've been meaning to ask: What makes it safe to stash the pointer values in vbin_printf and only dereference them later in bstr_printf? For plain pointer printing (%p) it's of course not a problem, but quite a few of the %p extensions do dereference the pointer in one way or another (at least %p[dD], %p[mM], %p[iI], %ph, %pE, %pC, %pNF, %pU, %pa and probably soon %pg).
Rasmus
| |