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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171104211605.ce02abd1ea46c248105617bf@kernel.org>
Date:   Sat, 4 Nov 2017 21:16:05 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build warnings after merge of the tip tree

On Sat, 4 Nov 2017 09:01:34 +0100
Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Masami Hiramatsu <mhiramat@...nel.org> wrote:
> 
> > > net/sctp/probe.c: In function 'sctpprobe_exit':
> > > net/sctp/probe.c:240:2: warning: 'unregister_jprobe' is deprecated [-Wdeprecated-declarations]
> > >   unregister_jprobe(&sctp_recv_probe);
> > >   ^
> > > In file included from net/sctp/probe.c:28:0:
> > > include/linux/kprobes.h:479:33: note: declared here
> > >  static inline void __deprecated unregister_jprobe(struct jprobe *p)
> > >                                  ^
> > > 
> > > Introduced by commit
> > > 
> > >   590c84593045 ("kprobes: Disable the jprobes APIs")
> > > 
> > > These days we normally don't deprecate things, just remove them.  But we
> > > do that *after* fixing up all the usages in the tree, please.
> > 
> > OK, should I remove __deprecated or revert above patch?
> > I pinged such users but no response. I can just rewrite it but not sure they can reply.
> 
> Ideal would be to just fix all these places: convert code where the facility 
> appears to be actively used, remove code where it looks unused. If maintainers 
> don't reply, I can apply them to a separate branch in -tip.

Thanks, that will help me.

> 
> For example I'm pretty sure we can just remove the jprobes usage in SCTP.

Actually TCP and DCCP jprobes usages are similar to that SCTP usage 
(maybe derived from TCP one). For those usages, we can not replace
it with kprobe/ftrace because it depends on the arguments of target funcs.
For such use-cases, we have 3 options;
 - Remove entirely feature if possible (like no more used).
 - Replace it with trace-events, and handle the event from kernel as sched tracer does.
 - Just introduce trace-events, remove usage, and trace it via ftrace or perf.

At a glance, all network probes are just used for printing out the event,
so we can just introduce trace-events and remove usage. I will try it.

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ