On Wed, Nov 02, 2022 at 06:19:00PM -0400, Steven Rostedt wrote: > On Wed, 2 Nov 2022 22:01:17 +0200 > Leonid Ravich <lravich@xxxxxxxxx> wrote: > > > disagree, without CONFIG_PREEMPTION (which is the default case in some > > destros) we will not get any warning, because there will not be > > preamption disable. > > I test all for my code (NON_PREEMPT, VOLUNTEER_PREEMPT, PREEMPT) and > with and without lockdep enabled. > > This would be a bug if you called kmalloc(X, GFP_KERNEL) in *any* non > preempt section. yes, but for NON_PREEMPT trace is not non preempt section, actualy the problem is with CONFIG_PREEMPT_COUNT not set. ftrace uses preemot_enable/disable_notrace macro to "mark" it as non preempt section which do it only for CONFIG_PREEMPT_COUNT. from include/linux/preempt.h if !CONFIG_PREEMPT_COUNT #define preempt_enable_notrace() barrier() this is why there is no any warning on my system. > > > > > second issue I see and maybe it is only me, is that the assuption of > > atomicity in trace is not a common knowledge for trace users. > > Well, I suppose we could add more documentation. Would that help? Where > would you see it? In the sample code? > I think if we fix the first issue and make kernel cry for any miss behave it we do the job. > I advise not even grabbing locks in trace events, because in most cases > lockdep will not catch any issues with them (it will be hidden unless > the trace event is enabled). > -- Leonid
