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: <f372a5ca-d9f1-e44e-07fb-3ec1e089e2f7@linux.dev>
Date:   Tue, 3 Jan 2023 18:05:25 -0800
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Stanislav Fomichev <sdf@...gle.com>
Cc:     ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
        song@...nel.org, yhs@...com, john.fastabend@...il.com,
        kpsingh@...nel.org, haoluo@...gle.com, jolsa@...nel.org,
        David Ahern <dsahern@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Anatoly Burakov <anatoly.burakov@...el.com>,
        Alexander Lobakin <alexandr.lobakin@...el.com>,
        Magnus Karlsson <magnus.karlsson@...il.com>,
        Maryam Tahhan <mtahhan@...hat.com>, xdp-hints@...-project.net,
        netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v5 11/17] selftests/bpf: Verify xdp_metadata
 xdp->af_xdp path

On 12/22/22 8:06 PM, Stanislav Fomichev wrote:
>>> +     /* First half of umem is for TX. This way address matches 1-to-1
>>> +      * to the completion queue index.
>>> +      */
>>> +
>>> +     for (i = 0; i < UMEM_NUM / 2; i++) {
>>> +             addr = i * UMEM_FRAME_SIZE;
>>> +             printf("%p: tx_desc[%d] -> %lx\n", xsk, i, addr);
>> Do you still need this verbose printf which is in a loop?  Also, how about other
>> printf in this test?
> In case we'd ever need to debug this test, those printfs shouldn't
> hurt, right? Or are you concerned about this test polluting the output
> with something like 'test_progs -v -v' ?
> 

Asking just in case it was some left over from the earlier rfc that is no longer 
needed. I think only failure test get logged in CI, so I don't mind to leave 
them here if they will be useful to debug other earlier/later ASSERTs.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ