Messages in this thread | | | Subject | Re: [PATCH V4] mm: fix kernel crash in khugepaged thread | From | Vlastimil Babka <> | Date | Tue, 17 Nov 2015 08:43:45 +0100 |
| |
On 17.11.2015 4:58, yalin wang wrote: > >> On Nov 17, 2015, at 10:43, Steven Rostedt <rostedt@goodmis.org> wrote: >> >> On Tue, 17 Nov 2015 10:21:47 +0800 >> yalin wang <yalin.wang2010@gmail.com> wrote: >> >> >> >> Because the print_fmt has nothing to do with the fields. You can have >> as your print_fmt as: >> >> TP_printk("Message = %s", "hello dolly!") >> >> And both userspace and the kernel with process that correctly (if I got >> string processing working in userspace, which I believe I do). The >> string is processed, it's not dependent on TP_STRUCT__entry() unless it >> references a field there. Which can also be used too: >> >> TP_printk("Message = %s", __entry->musical ? "Hello dolly!" : >> "Death Trap!") >> >> userspace will see in the entry: >> >> print_fmt: "Message = %s", REC->musical ? "Hello dolly!" : "Death Trap!" >> >> as long as the field "musical" exists, all is well. >> >> -- Steve > Aha, i see. > Thanks very much for your explanation. > Better print fat is : > TP_printk("mm=%p, scan_pfn=%s, writable=%d, referenced=%d, none_or_zero=%d, status=%s, unmapped=%d", > __entry->mm, > __entry->pfn == (-1UL) ? "(null)" : itoa(buff, __entry->pin, 10), …..) > > is this possible ?
I doubt so.
Why don't we just do (with %lx): __entry->pfn != -1UL ? __entry->pfn : 0,
Status already tells us that it's not a real pfn 0 (which I doubt would be userspace-mapped and thus reachable by khugepaged anyway?). Also it's what some other tracepoints do, see e.g. mm_page class in include/trace/events/kmem.h.
> Thanks > > > > > > > >
| |