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
| ||
|
Message-ID: <ZQLLwxQ4F2GG1eo0@gondor.apana.org.au> Date: Thu, 14 Sep 2023 17:00:51 +0800 From: Herbert Xu <herbert@...dor.apana.org.au> To: Sabrina Dubroca <sd@...asysnail.net> Cc: netdev@...r.kernel.org, davejwatson@...com, kuba@...nel.org, vakul.garg@....com, borisp@...dia.com, john.fastabend@...il.com Subject: Re: [PATCH net 1/5] net: tls: handle -EBUSY on async encrypt/decrypt requests On Tue, Sep 12, 2023 at 05:37:23PM +0200, Sabrina Dubroca wrote: > > We'd have to do pretty much what Jakub suggested [1] (handle ENOSPC by > waiting for all current requests) and then resubmit the failed > request. So I think keeping the MAY_BACKLOG flag and handling EBUSY > this way is simpler. With this, we send one request to the backlog, > then we wait until the queue drains. > > [1] https://lore.kernel.org/netdev/20230908142602.2ced0631@kernel.org/ You need to handle something like ENOSPC anyhow because the underlying driver may experience a real failure (e.g., someone unplugged the hardware) which would have pretty much the same effect of ENOSPC (i.e., an error with no retries). So if the tls code can't cope with that then it has to be fixed. Cheers, -- Email: Herbert Xu <herbert@...dor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists