linux-kernel - Re: BUG: ib_mad ftrace event unsupported migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Nov 2022 14:22:01 +0200
From:   Leonid Ravich <lravich@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Jason Gunthorpe <jgg@...pe.ca>,
        Leonid Ravich <leonid.ravich@...anetworks.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Yigal Korman <yigal.korman@...anetworks.com>,
        "linux-trace-kernel@...r.kernel.org" 
        <linux-trace-kernel@...r.kernel.org>
Subject: Re: BUG:  ib_mad ftrace event unsupported migration

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@...il.com> 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