On Thu, 3 Nov 2022 14:22:01 +0200 Leonid Ravich <lravich@xxxxxxxxx> wrote: > 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. Correct. > > 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. Correct. > > > > > > > > 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. It does with the right configs enable. I will NACK any change to add more checks here for the production case. This is an extremely fast path where every nanosecond counts (trace events can be under 100ns). The fact that it doesn't do anything is a feature not a bug. It's up to the developer to run their code with lockdep and other debug settings (and possibly even PREEMPT config tests) while developing their code. Not to expect the production use case to do it for them. -- Steve
