linux-kernel - Re: [RFC 16/19] staging: qlge: remove deadcode in qlge_build_rx

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: <20210627105349.pflw2r2b4qus64kf@Rk>
Date:   Sun, 27 Jun 2021 18:53:49 +0800
From:   Coiby Xu <coiby.xu@...il.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     linux-staging@...ts.linux.dev, netdev@...r.kernel.org,
        Benjamin Poirier <benjamin.poirier@...il.com>,
        Shung-Hsi Yu <shung-hsi.yu@...e.com>,
        Manish Chopra <manishc@...vell.com>,
        "supporter:QLOGIC QLGE 10Gb ETHERNET DRIVER" 
        <GR-Linux-NIC-Dev@...vell.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 16/19] staging: qlge: remove deadcode in qlge_build_rx_skb

On Thu, Jun 24, 2021 at 03:49:26PM +0300, Dan Carpenter wrote:
>On Thu, Jun 24, 2021 at 07:25:00PM +0800, Coiby Xu wrote:
>> On Tue, Jun 22, 2021 at 10:29:39AM +0300, Dan Carpenter wrote:
>> > On Mon, Jun 21, 2021 at 09:48:59PM +0800, Coiby Xu wrote:
>> > > This part of code is for the case that "the headers and data are in
>> > > a single large buffer". However, qlge_process_mac_split_rx_intr is for
>> > > handling packets that packets underwent head splitting. In reality, with
>> > > jumbo frame enabled, the part of code couldn't be reached regardless of
>> > > the packet size when ping the NIC.
>> > >
>> >
>> > This commit message is a bit confusing.  We're just deleting the else
>> > statement.  Once I knew that then it was easy enough to review
>> > qlge_process_mac_rx_intr() and see that if if
>> > ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_DL is set then
>> > ib_mac_rsp->flags4 & IB_MAC_IOCB_RSP_HV must be set.
>>
>> Do you suggest moving to upper if, i.e.
>>
>>         } else if (ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_DL && ib_mac_rsp->flags4 & IB_MAC_IOCB_RSP_HS) {
>>
>> and then deleting the else statement?
>>
>
>I have a rule that when people whinge about commit messages they should
>write a better one themselves, but I have violated my own rule.  Sorry.
>Here is my suggestion:
>
>    If the "ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_DL" condition is true
>    then we know that "ib_mac_rsp->flags4 & IB_MAC_IOCB_RSP_HS" must be
>    true as well.  Thus, we can remove that condition and delete the
>    else statement which is dead code.
>
>    (Originally this code was for the case that "the headers and data are
>    in a single large buffer". However, qlge_process_mac_split_rx_intr
>    is for handling packets that packets underwent head splitting).

Thanks for sharing your commit message! Now I see what you mean. But I'm
not sure if "ib_mac_rsp->flags4 & IB_MAC_IOCB_RSP_HS" is true when  
"ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_DL" is true. We only know that
the head splitting case is exclusively dealt with by the function 
qlge_process_mac_split_rx_intr,
     /* Process an inbound completion from an rx ring. */
     static unsigned long qlge_process_mac_rx_intr(struct qlge_adapter *qdev,
     					      struct rx_ring *rx_ring,
     					      struct qlge_ib_mac_iocb_rsp *ib_mac_rsp)
     {
         ...   
     	if (ib_mac_rsp->flags4 & IB_MAC_IOCB_RSP_HV) {
     		/* The data and headers are split into
     		 * separate buffers.
     		 */
     		qlge_process_mac_split_rx_intr(qdev, rx_ring, ib_mac_rsp,
     					       vlan_id);
     	} else if (ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_DS) {
		

And skb_build_skb is only called by qlge_build_rx_skb. So this part of
code that deals with the packets that don't go through head splitting
must be dead code. And the test that ping the NIC with packets of
different sizes could also confirm it.

>
>TBH, I don't know the code well enough to understand the second
>paragraph but the first paragraph is straight forward.
>
>regards,
>dan carpenter

-- 
Best regards,
Coiby