netdev - RE: [PATCH net 1/2] iavf: Fix error when changing ring parameters on ice PF

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] [day] [month] [year] [list]

Message-ID: <BL1PR11MB5430AF541A6F1861B22CC8D286C69@BL1PR11MB5430.namprd11.prod.outlook.com>
Date:   Mon, 9 May 2022 15:25:19 +0000
From:   "Maloszewski, Michal" <michal.maloszewski@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        Sylwester Dziedziuch <sylwesterx.dziedziuch@...el.com>,
        "Jankowski, Konrad0" <konrad0.jankowski@...el.com>
Subject: RE: [PATCH net 1/2] iavf: Fix error when changing ring parameters on
 ice PF

>On Fri, 29 Apr 2022 13:14:12 +0000 Maloszewski, Michal wrote:
>> >> When we have state which is running, it does not mean that we have 
>> >> queues configured on PF. So in order to configure queues on PF, the 
>> >> IAVF_FLAG_QUEUES has to be disabled. I use here EAGAIN, because as 
>> >> long as we are not configured with queues, it does not make any 
>> >> sense to trigger command and we are not sure when the configuration 
>> >> of queues will end - so that is why EAGAIN is used.
>> >
>> >Let me rephrase the question. Does getting out of the state where 
>> >error is reported require user to change something, or is it 
>> >something that happens automatically behind the scenes (i.e. the state is transient).
>> 
>> It is something that happens automatically behind the scenes. 
>> It takes some time and there is no guarantee that it will be finished.
>
>Then either wait for it to finish (wait queue or such) or if possible record the desired config and return success. Apply the new config when the reset is finished.
>
>It really seems like you're making users pay the price for poor design of the driver's internals.

It is good idea. We had doubts if we could do that. I will try to fix it asap.