netdev - Re: [PATCH net-next] ibmvnic: Assign XPS map to correct queue index

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: <faf30f4c-42ac-5326-0c4d-7f1515ecd943@linux.ibm.com>
Date:   Fri, 24 Feb 2023 10:34:08 -0600
From:   Nick Child <nnac123@...ux.ibm.com>
To:     Pavan Chebbi <pavan.chebbi@...adcom.com>
Cc:     netdev@...r.kernel.org, bjking1@...ux.ibm.com, haren@...ux.ibm.com,
        ricklind@...ibm.com
Subject: Re: [PATCH net-next] ibmvnic: Assign XPS map to correct queue index



On 2/24/23 02:49, Pavan Chebbi wrote:
> On Thu, Feb 23, 2023 at 9:10 PM Nick Child <nnac123@...ux.ibm.com> wrote:
>> ---
>>
>> I am a little surprised that __netif_set_xps_queue() did not complain that some
>> index values were greater than the number of tx queues. Though maybe the function
>> assumes that the developers are wise enough :)
> 
> Are you sure an index greater than total tx queues was sent?
> A quick look at ibmvnic_set_affinity() suggests that the condition if
> (... || (i_txqs == num_txqs)) prevents overrunning available tx
> queues.
> 
I believe so. The issue is we were sending "i" to 
__netif_set_xps_queue() , not i_txqs.

Take an example where num_txqs == 2 and num_rxqs == 2:
total_num_q's == 4, so i will loop until until 4.
When we get to i == 2, it will attempt to map XPS values for
the second TX queue (index 1) but we would be giving the value of
i (which is 2). The index of 2 is greater than the number of available 
tx queues. Somehow __netif_set_xps_queue() is still returning a 
successful error code.
>>
>> Should __netif_set_xps_queue() have a check that index < dev->num_tx_queues?