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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220429105715.6179fc9b@kernel.org>
Date:   Fri, 29 Apr 2022 10:57:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Maloszewski, Michal" <michal.maloszewski@...el.com>
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.