Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp259807ybx; Tue, 5 Nov 2019 23:34:14 -0800 (PST) X-Google-Smtp-Source: APXvYqyVE+fANYbaZl2ANV23XuYfHcCnVepX+e+FEBbYlfX7/uaIlLhXhRObeuLa013GpLMOhj4y X-Received: by 2002:a05:6402:13cd:: with SMTP id a13mr1094718edx.57.1573025654053; Tue, 05 Nov 2019 23:34:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573025654; cv=none; d=google.com; s=arc-20160816; b=Yppukdk3yoPG7zUTx8gyW0kO+7IV5TgZPQ89lvPA7r93gEVXzZRKO6MpwQ4rSIdzmm jeWGdG16oNS4ClskcojxHcIO5z2o3X8UbZDrbqB7zFG0nTOnLRHITgcft+01mVpjaeQD PcnfaYJX4SSZUNJPoVZTO6JAU4Dx+0bXjyUlY3U6RnpC62rEd/P9d5oV2K9vdbHUtSgi 9ytGQhy+UaAwGfA5RgIRMuWgmpNf6bjQvn14K9PC4hpYrQgvIJ4b57QUl52ma0PMFqsA 0P/NtpdG9Pzi/pr5a3qJpa1NHamWn540ZTZZvRLjwcaw18NFcbymwAmTF3PbCI9Id4qa WqFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fbVrCNlPLaDTmcKHIN3LtBZK21JIiPNghUTOX5jQAi0=; b=lTL40lLbKVH05qtX9YvnnGrtTD014wIr8dZr8mQVWg8GgUyjaHLY9w6jEALn/KQqhl QIKKU/Zr2Q4VgUwuHWbrLRQlOnBU6JhZuaa+E29ajqJ+rWiAWLeh74JAZTQyvAura2By lAAoCy8zpsmJSpaGv4zInPWdmM+348dMKfaw5nGJONW4exEiooZJ4GK7Ln4+f2fCWGKk W8n6azok7QXUsf713Q82ovAML1L6juqeK+tA5AtylXTfcBj1NuptZX5cM7BeY42O+BQX jqcALjIfVxcmLHY6bHQ8qtuZ+DJeHmBJ1FU7UCqPPi+hSDkzhgNteSx7bsr08TyxC3Vx vMog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@benyossef-com.20150623.gappssmtp.com header.s=20150623 header.b=tXq9+cEd; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si13514602edv.82.2019.11.05.23.33.49; Tue, 05 Nov 2019 23:34:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@benyossef-com.20150623.gappssmtp.com header.s=20150623 header.b=tXq9+cEd; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730059AbfKFHde (ORCPT + 99 others); Wed, 6 Nov 2019 02:33:34 -0500 Received: from mail-vk1-f195.google.com ([209.85.221.195]:39009 "EHLO mail-vk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728291AbfKFHdd (ORCPT ); Wed, 6 Nov 2019 02:33:33 -0500 Received: by mail-vk1-f195.google.com with SMTP id j84so5378519vkj.6 for ; Tue, 05 Nov 2019 23:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=benyossef-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fbVrCNlPLaDTmcKHIN3LtBZK21JIiPNghUTOX5jQAi0=; b=tXq9+cEdTgcUL/rTgW92c4PNWlxnqdy9ufzkcqPbyt0BmkFpZwtDr2SKTAZ2B2adPA F+XDqVbx7RMa+5XEnQg/NkxPXT5p1qsf2Il96TWl2Xo9SSM9hUuVYMdG4OSux/yBuUE8 /lt+ifyc1imI3ov8PQ2W9bkBv+/tM6c/VcGIy/P/kI10Cz+YzkEMxuP+yQO8wBG0+vvv 4n+EMc34+wsK62rjmo/p32ZrKZm00eMyRRnbQWc2dTB1jGdGHtZvt3NtPvauqSi+hfbZ LBqtHWQ+Da8ZxU44fzKnYQQKozNVLB2Tu1/P25qp5db4qn1FRQ9kkdL7iUFiBnTCljtW Vuzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fbVrCNlPLaDTmcKHIN3LtBZK21JIiPNghUTOX5jQAi0=; b=KUb+aH0p6fGL0ZCPP6fOp8l1uTteZe/CHOFNSNBI5wxfYpX+Jl0ZicE+PsCePDQ2fm N3VvzzpVV+JJGejpKwTSA/9AvXUPxYN7x58M7f/py03PY2G3ejo64ZXor5pSCcrisJTy 5k1i+jgFIfS8csCIstHN/2UtBUXIUXY5odFFckDYbnfloBZjaLNzb9mBLM/73SveKwpk q46EsyRDRjE9tsZ1XcN7oiOouOAc6HFtM3C4fbAkl3cwxdMdOSzpc4tTnD9dmNXSxxqo ChEHgOCusVBbUVlLWi2KWBvodBd7pgZTJitn0J12penjiP5isC0eNGFA2BAOk6eNpGQr t1mA== X-Gm-Message-State: APjAAAW+N6tSB/xKbHKxTU0uIkr+T8WliJ1qB2+xL9cuVYNNvxsMVwcs 0sjTv7du2B/1BCV6XXQ5jVgicpeIaUCfyZJSsLJWCQ== X-Received: by 2002:ac5:c756:: with SMTP id b22mr628305vkn.2.1573025611342; Tue, 05 Nov 2019 23:33:31 -0800 (PST) MIME-Version: 1.0 References: <20191017122549.4634-1-t-kristo@ti.com> <20191017122549.4634-10-t-kristo@ti.com> <076f0bc6-ad04-9543-db02-d7c7060db036@ti.com> In-Reply-To: <076f0bc6-ad04-9543-db02-d7c7060db036@ti.com> From: Gilad Ben-Yossef Date: Wed, 6 Nov 2019 09:33:20 +0200 Message-ID: Subject: Re: [PATCH 09/10] crypto: add timeout to crypto_wait_req To: Tero Kristo Cc: Herbert Xu , Eric Biggers , David Miller , Linux Crypto Mailing List , Ard Biesheuvel , linux-omap@vger.kernel.org, Linux ARM Content-Type: text/plain; charset="UTF-8" Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, Nov 6, 2019 at 9:25 AM Tero Kristo wrote: > > On 06/11/2019 08:39, Gilad Ben-Yossef wrote: > > Hi, > > > > > > On Thu, Oct 17, 2019 at 3:26 PM Tero Kristo wrote: > >> > >> Currently crypto_wait_req waits indefinitely for an async crypto request > >> to complete. This is bad as it can cause for example the crypto test > >> manager to hang without any notification as to why it has happened. > >> Instead of waiting indefinitely, add a 1 second timeout to the call, > >> and provide a warning print if a timeout happens. > > > > While the incentive is clear and positive, this suggested solution > > creates problems of its own. > > In many (most?) cases where we are waiting here, we are waiting for a > > DMA operation to finish from hardware. > > Exiting while this pending DMA operation is not finished, even with a > > proper error return value, is dangerous because > > unless the calling code takes great care to not release the memory the > > DMA is being done from/to, this can have disastrous effects. > > > > As Eric has already mentioned, one second might seem like a long time, > > but we don't really know if it is enough. > > > > How about adding a second API (ig. crypto_wait_req_timeout) which > > supports a calee specified timeout where > > the calle knows how to correctly deal with timeout and port the > > relevant call sites to use this? > > Yeah, that would work for me. I guess we could just swap the testmgr to > use this timeout API, as it is quite clear it should timeout rather than > wait indefinitely, and afaics, the data buffers it uses are limited > size. It doesn't really matter for it whether the timeout is 1 second or > 10 seconds, as long as it eventually times out. As long as you avoid releasing the memory used on timeout, that should work well, I think. Gilad