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]
Date:   Mon, 27 Jun 2022 12:36:39 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Subash Abhinov Kasiviswanathan <quic_subashab@...cinc.com>
Cc:     davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, netdev@...r.kernel.org,
        quic_jzenner@...cinc.com, cong.wang@...edance.com,
        qitao.xu@...edance.com, bigeasy@...utronix.de, rostedt@...dmis.org,
        mingo@...hat.com, Sean Tranchetti <quic_stranche@...cinc.com>
Subject: Re: [PATCH net-next v2] net: Print hashed skb addresses for all net
 and qdisc events

On Fri, Jun 24, 2022 at 03:34:25PM -0600, Subash Abhinov Kasiviswanathan wrote:
> The following commits added support for printing the real address-
> 65875073eddd ("net: use %px to print skb address in trace_netif_receive_skb")
> 70713dddf3d2 ("net_sched: introduce tracepoint trace_qdisc_enqueue()")
> 851f36e40962 ("net_sched: use %px to print skb address in trace_qdisc_dequeue()")
> 
> However, tracing the packet traversal shows a mix of hashes and real
> addresses. Pasting a sample trace for reference-
> 
> ping-14249   [002] .....  3424.046612: netif_rx_entry: dev=lo napi_id=0x3 queue_mapping=0
> skbaddr=00000000dcbed83e vlan_tagged=0 vlan_proto=0x0000 vlan_tci=0x0000 protocol=0x0800
> ip_summed=0 hash=0x00000000 l4_hash=0 len=84 data_len=0 truesize=768 mac_header_valid=1
> mac_header=-14 nr_frags=0 gso_size=0 gso_type=0x0
> ping-14249   [002] .....  3424.046615: netif_rx: dev=lo skbaddr=ffffff888e5d1000 len=84
> 
> Switch the trace print formats to %p for all the events to have a
> consistent format of printing the hashed addresses in all cases.
> 

This is obscured...

What exactly is the inconsistency here? Both are apparently hex, from
user's point of view. The only difference is one is an apparently
invalid kernel address, the other is not. This difference only matters
when you try to dereference it, but I don't think you should do it here,
this is not a raw tracepoint at all. You can always use raw tracepoints
to dereference it without even bothering whatever we print.

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ