From owner-svn-src-head@freebsd.org Fri Aug 17 16:01:41 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E77781073889; Fri, 17 Aug 2018 16:01:40 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A51084FC1; Fri, 17 Aug 2018 16:01:40 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f47.google.com with SMTP id d10-v6so11906201itj.5; Fri, 17 Aug 2018 09:01:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=j6WhRwLBc8OntFCtuSbgyC41CNs/HiuFhLw+nN1eerw=; b=qfiv4ZWlEtMl51x54lNZ5wgK3H6vpINJBTWId7zpq7YKYpby5VcF03zx4qHlpk04eK UTUBWy6iz2w+WkiYVfMSHsmtuseBkRLbYdUnM1T5rBAqUha8kZeIrfHAZMl4iwUAr5rZ T5maIv0w4cd4J047u85UC1g0fI3f1+B2mz0yhfZlhjnp+3lRaK+dUxd0AUU/3rMxe3hf s+3eitXu5iyQ+FV/Mma60Ga+kzxpW/NsD7D99Vm/wtfzJxbsNFEa+xhbnvJTeXxKZEuh 2FXloPT4TQjxfgcN6+Jwmm1ILhwxjwbDpKxwrkO1iWaPbbgzP7wu1C0y9l9QW60txAws cJPQ== X-Gm-Message-State: AOUpUlFLqcb/HLBNh7rOCxsvtnvJhDabAftXl3kNCl61r75LnEZDBiyD +GsxQJA4zNSVf+3Rwjlon5RXQa9t X-Google-Smtp-Source: AA+uWPzz/wHjkvQBcvpFK+BGC+TYlHFtgc68oXw/HnKYyQeVronwh5dvCTIpjGILRITIMhp+eailWg== X-Received: by 2002:a24:8a42:: with SMTP id v63-v6mr1971589itd.26.1534521693989; Fri, 17 Aug 2018 09:01:33 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id c2-v6sm1003725iob.41.2018.08.17.09.01.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 09:01:33 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id 72-v6so11922744itw.3; Fri, 17 Aug 2018 09:01:33 -0700 (PDT) X-Received: by 2002:a02:10c6:: with SMTP id 189-v6mr32057524jay.54.1534521693097; Fri, 17 Aug 2018 09:01:33 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:b472:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 09:01:32 -0700 (PDT) In-Reply-To: <6d1d2b23-978b-af1d-4022-16d09c9a42f5@yandex.ru> References: <201807180056.w6I0uPb6000705@repo.freebsd.org> <6d1d2b23-978b-af1d-4022-16d09c9a42f5@yandex.ru> From: Conrad Meyer Date: Fri, 17 Aug 2018 09:01:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r336439 - in head: share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe/crypto sys/dev/hifn sys/dev/safe sys/dev/s... To: "Andrey V. Elsukov" Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 16:01:41 -0000 Please file a PR and we can track it there. The first suggestion that comes to mind is that the XFORMS_LOCK protects modification of the xforms list =E2=80=94 not the lifetime of obje= cts in it =E2=80=94 so drop the list lock over xf_init(). It does not appear t= hat xform_init can race with xform_detach with the lock dropped. xform_init is called only by key_setsaval, which is called in two places: key_newsav, and key_update. In key_newsav, it is used on sav's that are not yet linked in to a sah. In key_update, it is on larbal sav's only (i.e., linked in to savtree_larval list but not savtree_alive list). xform_detach -> key_delete_xform only enumerates over the sahtree looking for sah's with sav's present in savtree_alive with matching xform. Since neither key_newsav nor key_update insert the sav into the sah savtree_alive list until after setsaval -> xform_init, there is no race between xform_init and xform_detach (protected by SAHTREE_WLOCK). I think this patch may be safe, and would remove the OOM-induced deadlock condition: --- netipsec/key.c (revision 337955) +++ netipsec/key.c (working copy) @@ -8676,11 +8676,13 @@ XFORMS_LOCK(); LIST_FOREACH(entry, &xforms, chain) { if (entry->xf_type =3D=3D xftype) { + XFORMS_UNLOCK(); ret =3D (*entry->xf_init)(sav, entry); - break; + goto out; } } XFORMS_UNLOCK(); +out: return (ret); } Best, Conrad On Fri, Aug 17, 2018 at 6:01 AM, Andrey V. Elsukov wrot= e: > On 18.07.2018 03:56, Conrad Meyer wrote: >> Author: cem >> Date: Wed Jul 18 00:56:25 2018 >> New Revision: 336439 >> URL: https://svnweb.freebsd.org/changeset/base/336439 >> >> Log: >> OpenCrypto: Convert sessions to opaque handles instead of integers >> >> Track session objects in the framework, and pass handles between the >> framework (OCF), consumers, and drivers. Avoid redundancy and complex= ity in >> individual drivers by allocating session memory in the framework and >> providing it to drivers in ::newsession(). > > Hi, > > this produces WITNESS warning, since crypto_newsession() allocates > memory with M_WAITOK flag while xform_init() holds mutex: > > uma_zalloc_arg: zone "crypto_session" with the following non-sleepable > locks held: > exclusive sleep mutex xforms_list (IPsec transforms list) r =3D 0 > (0xffffffff81fdb840) locked @ > /home/devel/freebsd/base/head/sys/netipsec/key.c:8676 > stack backtrace: > #0 0xffffffff80c01643 at witness_debugger+0x73 > #1 0xffffffff80c02a21 at witness_warn+0x461 > #2 0xffffffff80ed98a8 at uma_zalloc_arg+0x38 > #3 0xffffffff80e4a0ca at crypto_newsession+0x1ea > #4 0xffffffff80e3994c at esp_init+0x37c > #5 0xffffffff80e31e68 at key_setsaval+0x7f8 > #6 0xffffffff80e307e2 at key_newsav+0x302 > #7 0xffffffff80e2ba0d at key_add+0x53d > #8 0xffffffff80e263f5 at key_parse+0xac5 > #9 0xffffffff80c34dc7 at sosend_generic+0x447 > #10 0xffffffff80c34ffd at sosend+0x6d > #11 0xffffffff80c3c170 at kern_sendit+0x240 > #12 0xffffffff80c3c4be at sendit+0x19e > #13 0xffffffff80c3c30d at sys_sendto+0x4d > #14 0xffffffff8107e9c1 at amd64_syscall+0x281 > #15 0xffffffff8105846d at fast_syscall_common+0x101 > > -- > WBR, Andrey V. Elsukov >