From owner-freebsd-hackers@freebsd.org Mon Jul 9 06:27:09 2018 Return-Path: Delivered-To: freebsd-hackers@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 9FA571048A6B for ; Mon, 9 Jul 2018 06:27:09 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DBE283C4E for ; Mon, 9 Jul 2018 06:27:09 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-ed1-f45.google.com with SMTP id b10-v6so12989524edi.2 for ; Sun, 08 Jul 2018 23:27:09 -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:from:date:message-id:subject:to; bh=7Zc9VaXqmgbDV/AMr9Y05u84gYLmy6A8uuQWutiu43w=; b=OYCj1ilOHUptTZMuPwcUyYo0uZMf77SmK3f0u2CUN/SFL4TNXNxgvwaBMiEqaLyNp+ D7b2PtkZRXIVCp8WE12CLFNDcI8a7KgJ7pBtu7Y4n6wycO8cWxUWCeAhhWHNRLRjtrPt ZvFeFLr8/7KBzTUOKpFhhiQSUUexEyFZ11AR+iFLh/mIWm42bRBBjkQ/IDPGJaFoOn86 nqU5HS5FW1/BwEbiEJFvymbY+LCM8VjtRUHmXRa5zdQqjbafwM9vZ6jqyJqxOkXC/IIE IQ4iFBQ4otlm6dKj7j9idabVgCZGurq/5aUUJuY8CMIYzxSLmOvDuoVqrczNtc1MlV0D rU/A== X-Gm-Message-State: APt69E1MbJjOK+n3psbpvJESZZaJLS/vlQ73cea+9cDtlaeRPXhTKDl4 iV2ZXFRlZTa/6fkWJ/IyMKrbXXd5 X-Google-Smtp-Source: AAOMgpdeyIaz3RHwO9lsGNkK7lyQxk9vlW4bhdhBNy6cP2oPVxl7uzRC1EQw2DggCclzeNojldx3Mg== X-Received: by 2002:a50:a519:: with SMTP id y25-v6mr21079039edb.105.1531117298559; Sun, 08 Jul 2018 23:21:38 -0700 (PDT) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com. [209.85.208.48]) by smtp.gmail.com with ESMTPSA id z70-v6sm10926567ede.6.2018.07.08.23.21.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 23:21:38 -0700 (PDT) Received: by mail-ed1-f48.google.com with SMTP id u11-v6so12977778eds.10 for ; Sun, 08 Jul 2018 23:21:38 -0700 (PDT) X-Received: by 2002:a50:d313:: with SMTP id g19-v6mr7607773edh.119.1531117298385; Sun, 08 Jul 2018 23:21:38 -0700 (PDT) MIME-Version: 1.0 From: Pratyush Yadav Date: Mon, 9 Jul 2018 11:51:02 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Can contigmalloc(9) fail even when M_NOWAIT is *not* specified? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 06:27:09 -0000 Hi, The contigmalloc(9) man page says: > The contigmalloc() function does not sleep waiting for memory resources > to be freed up, but instead actively reclaims pages before giving up. > However, unless M_NOWAIT is specified, it may select a page for reclama- > tion that must first be written to backing storage, causing it to sleep. So if M_NOWAIT is *not* specified, can contigmalloc() "give up", and return NULL? -- Regards, Pratyush Yadav From owner-freebsd-hackers@freebsd.org Mon Jul 9 08:14:13 2018 Return-Path: Delivered-To: freebsd-hackers@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 3ED67102DE86 for ; Mon, 9 Jul 2018 08:14:13 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7EE189DC2; Mon, 9 Jul 2018 08:14:12 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f174.google.com with SMTP id v26-v6so16265778iog.5; Mon, 09 Jul 2018 01:14:12 -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; bh=klVzZ0iGQJ4eidlsqXXhSKgbAcGmN9PteWNj34IzgxE=; b=jqIIHY9fRh2MTOg9DsClxAFkIKUxc9XF4EWA6WsUais+Zs/JCNH+W2WwQWLCENuhoj x7MidctOKRTEKobehc5bU3rzu30XBgqm9bGx/DEd/IsMKN3vzGDKytMXpdyEB1Qdrqcp ttHDDYaFZI8O2RS2gW4HokBlx6SnbY2cKpv8VUVDVw+I9xMvTg0OGpLMMyDKP67q1ImW ZNxswDnsonJ8baZMkRz9kpfkI9d69Q1O+CfouQJFELsiSDStzWHqhCjnQYsp+wvMbZXF fWIbenr4se/QiJEOPZFmH4yboFQH1Sl1Dwz1ypzTwX6Qv7x7rYpi0S6SUiyihRjp/oFx bRnQ== X-Gm-Message-State: APt69E26hMMQs8lmDyNkZ9aesNwIWp+poa4AuynkWxBcpqAAPWU1vZML IEGC7bM5ymXntdJ3xVAZftm8ZUnH X-Google-Smtp-Source: AAOMgpc36yrjtmQSo3OLeHc7SmniPSdO+3ZRkd6pxqAlfoCMw9vQojq5Eb3Of8nChB8CYAMv0zlnmg== X-Received: by 2002:a6b:ea05:: with SMTP id m5-v6mr17072314ioc.33.1531118636061; Sun, 08 Jul 2018 23:43:56 -0700 (PDT) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com. [209.85.214.53]) by smtp.gmail.com with ESMTPSA id x201-v6sm8293253itb.12.2018.07.08.23.43.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 23:43:55 -0700 (PDT) Received: by mail-it0-f53.google.com with SMTP id l16-v6so24953876ita.0; Sun, 08 Jul 2018 23:43:55 -0700 (PDT) X-Received: by 2002:a02:10c6:: with SMTP id 189-v6mr9059806jay.54.1531118635837; Sun, 08 Jul 2018 23:43:55 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 23:43:55 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Sun, 8 Jul 2018 23:43:55 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Can contigmalloc(9) fail even when M_NOWAIT is *not* specified? To: Pratyush Yadav Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 08:14:13 -0000 Yes. On Sun, Jul 8, 2018 at 11:21 PM, Pratyush Yadav wrote: > Hi, > > The contigmalloc(9) man page says: > >> The contigmalloc() function does not sleep waiting for memory resources >> to be freed up, but instead actively reclaims pages before giving up. >> However, unless M_NOWAIT is specified, it may select a page for reclama- >> tion that must first be written to backing storage, causing it to sleep. > > So if M_NOWAIT is *not* specified, can contigmalloc() "give up", and > return NULL? > > -- > Regards, > Pratyush Yadav > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Jul 9 14:41:56 2018 Return-Path: Delivered-To: freebsd-hackers@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 A9828102BA7C for ; Mon, 9 Jul 2018 14:41:56 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56CE6727F3; Mon, 9 Jul 2018 14:41:54 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f53.google.com with SMTP id m12-v6so15449002lfc.10; Mon, 09 Jul 2018 07:41:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=bZc8Nihx5SuJgdvJb+rmA6ODzM+l/dErl/wsoRoR2UY=; b=Uc6PjZYyxGRWiW1OdPWr/QeX+a54D7ne0LlFASD4hOxgIdSWDAy51r8LHIBXiaLuGn R+hGNUn1S0ij2UQ6pzJ3oWtGHvEBBBUMh9TqB2agNPguFUEohLXAU/mpca7K/aXjExCC 1wyCrqgRa9b55Mbd0yIGeYTQdI/EIk0YZqPjTSBzQGVmVCxNz6eHvSIpx1ZgvHIFrIg1 J0mpGwsAp+pi8ePhdFUpyLvWurZGMl7sTfwH4uZYnW1R/df8V5X1pKGzePdavtl3ei0b 9bVfYy0ZJQ9KveJdN2INm5xKfYdrel7J42hmLWtPglxcUp2nzNGDZeqkSh1lZCkbosVW b72g== X-Gm-Message-State: APt69E2YbXR0/3eGsAeVT9rgWhZ34HwYWe1i6kheOByHg4uWbE0WaIGE 7J0zg/xT0LjQXn9Gl3LdPbtFS2/V X-Google-Smtp-Source: AAOMgpevTNFO2Vr0Fi9d2sGChWzmA3qXDsosihbv3GWHwbzQGytQFau16yJF+SfeUymCsrsCdxBxxA== X-Received: by 2002:a19:c218:: with SMTP id l24-v6mr14018238lfc.55.1531121569112; Mon, 09 Jul 2018 00:32:49 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id b9-v6sm2043510ljd.62.2018.07.09.00.32.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 00:32:48 -0700 (PDT) Subject: Re: Can contigmalloc(9) fail even when M_NOWAIT is *not* specified? To: Pratyush Yadav , freebsd-hackers@freebsd.org References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <77cc8c09-41e1-cbdf-7c79-90af75ee3cd9@FreeBSD.org> Date: Mon, 9 Jul 2018 10:32:47 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:41:56 -0000 On 09/07/2018 09:21, Pratyush Yadav wrote: > Hi, > > The contigmalloc(9) man page says: > >> The contigmalloc() function does not sleep waiting for memory resources >> to be freed up, but instead actively reclaims pages before giving up. >> However, unless M_NOWAIT is specified, it may select a page for reclama- >> tion that must first be written to backing storage, causing it to sleep. > > So if M_NOWAIT is *not* specified, can contigmalloc() "give up", and > return NULL? Yes. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue Jul 10 02:06:14 2018 Return-Path: Delivered-To: freebsd-hackers@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 299BB102D875 for ; Tue, 10 Jul 2018 02:06:14 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [150.101.137.139]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB40758FC for ; Tue, 10 Jul 2018 02:06:13 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-236-62.bras1.adl4.internode.on.net (HELO midget.dons.net.au) ([118.210.236.62]) by ipmail02.adl2.internode.on.net with ESMTP; 10 Jul 2018 11:31:05 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id w6A20km4038996 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 10 Jul 2018 11:31:01 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id w6A1ehw3025357 for ; Tue, 10 Jul 2018 11:10:43 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [203.31.81.59] ([203.31.81.59]) by ppp118-210-236-62.bras1.adl4.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id w6A1ebHc025354; Tue, 10 Jul 2018 11:10:43 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: Can contigmalloc(9) fail even when M_NOWAIT is *not* specified? From: "O'Connor, Daniel" In-Reply-To: <77cc8c09-41e1-cbdf-7c79-90af75ee3cd9@FreeBSD.org> Date: Tue, 10 Jul 2018 11:10:34 +0930 Cc: Pratyush Yadav , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <51DA0343-0B43-4BC6-B736-DA52493C26F8@dons.net.au> References: <77cc8c09-41e1-cbdf-7c79-90af75ee3cd9@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3445.8.2) X-Spam-Score: 1.5 (*) No, score=1.5 required=5.0 tests=HELO_MISC_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:06:14 -0000 > On 9 Jul 2018, at 17:02, Andriy Gapon wrote: > On 09/07/2018 09:21, Pratyush Yadav wrote: >> Hi, >>=20 >> The contigmalloc(9) man page says: >>=20 >>> The contigmalloc() function does not sleep waiting for memory = resources >>> to be freed up, but instead actively reclaims pages before giving = up. >>> However, unless M_NOWAIT is specified, it may select a page for = reclama- >>> tion that must first be written to backing storage, causing it to = sleep. >>=20 >> So if M_NOWAIT is *not* specified, can contigmalloc() "give up", and >> return NULL? >=20 > Yes. This seems pretty surprising to me.. Perhaps the man page could have a = warning about it - right now it fairly strongly implies that !M_NOWAIT = will wait forever. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Wed Jul 11 11:46:25 2018 Return-Path: Delivered-To: freebsd-hackers@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 4EA19103142B for ; Wed, 11 Jul 2018 11:46:25 +0000 (UTC) (envelope-from steevanxperia@gmail.com) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3AD38CFFB for ; Wed, 11 Jul 2018 11:46:24 +0000 (UTC) (envelope-from steevanxperia@gmail.com) Received: by mail-oi0-x243.google.com with SMTP id s198-v6so48649264oih.11 for ; Wed, 11 Jul 2018 04:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U73PWFzQC6kvM0wNVb7Y6t8LAqfzOfqqSbyTwENndjQ=; b=RytkGMiFv8vuYTxqkC1hmzVeX7qh2cqywzGnNk+vvzS5G/gRrBaWXAVzvlvS9/fSgb ly7fp7C4jkCt8iUKedjCXkIccpeAkGeD132HklAVk6zlJiQImwuQcNithy4BtCXyWkHR dXsQv2Y6x0ALTUJJz7BURTuZHljlhUTfRNAirXZ0pWK4j8+VRppmmlU5Uxj4fBkai8C7 r3HCudcDVEKyIcI8s3ALPDajY4pZwRHul+7OtMOJXG2fWdLiI5jYOSCCdidy9SMpauQk CzXMdCtEYqKtOnaSz1XiTnuooyG1pvaRcJuBz5OY6+wxPf/Zoez60ky1d+u4ogBb3Ikp 6A4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U73PWFzQC6kvM0wNVb7Y6t8LAqfzOfqqSbyTwENndjQ=; b=Wb1NYsMQVjx59qdRd0oqEK4VwH4cWmLq09WLWVVfJIK4xrGnchuTbn/ss6dF/qRdBj FiD31nFhVTDnl6Dc5fjjph80dVwcSz2qzPdHxB+xZ4TQsu9DSySz78/Ai275vs3MXnfb jM5mmBxo9KY3blIoqcR+nhKXLsyCO0DJqTADrKD1Q6bHdiolYcTYeV3PEzJAPu5qwkJQ DELanFEj8vQ9iD4XEC6LS5c+teszXZLnEHRvZT5hcPrjaxFIuZ5D795hGVdBWrwVUNvt BvU2D45eeCaywSbLGcC+4L2zTdV09yPteWUsk595CdS/mfYf1feyvvn1PNzerC+jftCf gtbA== X-Gm-Message-State: APt69E14dFssKOozILLIWQPEWj3vusgq+2rcV1bax7qH/g/HU1LcpMm8 DZuFUT7rCMTx60IgA+jGLfp2Y3qerusqbEorhI0EXw== X-Google-Smtp-Source: AAOMgpeDzrZzrc2m2Lr4pwSL0nc5QILy9P1XM7fVrcESryhthBfIIsE+eviP44yd9Pu/rhaxvQnQB5pA0ksDkSXkHy0= X-Received: by 2002:aca:a806:: with SMTP id r6-v6mr33301100oie.213.1531309583832; Wed, 11 Jul 2018 04:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:5bd6:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 04:46:23 -0700 (PDT) In-Reply-To: <2ae78782-6cca-452e-d004-3999885ae4e0@cs.duke.edu> References: <2ae78782-6cca-452e-d004-3999885ae4e0@cs.duke.edu> From: Steevan Rodrigues Date: Wed, 11 Jul 2018 17:16:23 +0530 Message-ID: Subject: Re: high CPU usage in FreeBSD for a PCIe card driver To: Andrew Gallatin Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 11:46:25 -0000 Hello Andrew, Sorry to bother you. I am working on this problem again after a break of few days. I ran following command to get lock statistics when I run my userspace application on a 12 core 24 thread server PC. >From this data below to looks like my driver is causing a contention on a kernel lock (pmap ). Am I right ? lockstat -x aggsize=4m -D 20 sleep 10 Adaptive mutex spin: 1122679 events in 10.013 seconds (112121 events/sec) Count indv cuml rcnt nsec Lock Caller ------------------------------------------------------------------------------- 1089662 97% 97% 0.00 65375 pmap pmap_extract+0x1d2 31805 3% 100% 0.00 14881 cdev devvn_refthread+0x142 651 0% 100% 0.00 180642 umtxql umtxq_sleep+0x1f5 254 0% 100% 0.00 30212 umtxql __umtx_op_sem2_wake+0x3b6 68 0% 100% 0.00 14218 umtxql umtxq_busy+0x17e 63 0% 100% 0.00 3441 umtxql __umtx_op_sem2_wake+0x410 59 0% 100% 0.00 1067 swi taskqueue_enqueue+0xba 42 0% 100% 0.00 1632 swi taskqueue_run_locked+0x4f 21 0% 100% 0.00 65453 umtxql do_lock_umutex+0x5ec 13 0% 100% 0.00 3693 umtxql do_sem2_wait+0x948 8 0% 100% 0.00 49129 USB device mutex usb_callback_proc+0x114 7 0% 100% 0.00 2248 swi taskqueue_run+0x117 5 0% 100% 0.00 11294 umtxql do_lock_umutex+0x632 5 0% 100% 0.00 67423 umtxql _sleep+0x2e4 3 0% 100% 0.00 697 umtxql do_cv_wait+0x619 3 0% 100% 0.00 58600 Giant _cv_wait+0x1d1 2 0% 100% 0.00 21866 umtxql __umtx_op_wake2_umutex+0x419 2 0% 100% 0.00 6097 cdev count_dev+0xe 2 0% 100% 0.00 4695 cdev vputx+0xe0 1 0% 100% 0.00 754 umtxql do_unlock_umutex+0x1027 ------------------------------------------------------------------------------- Adaptive mutex block: 10182 events in 10.013 seconds (1017 events/sec) Count indv cuml rcnt nsec Lock Caller ------------------------------------------------------------------------------- 9590 94% 94% 0.00 283901 pmap pmap_extract+0x1d2 570 6% 100% 0.00 280204 cdev devvn_refthread+0x142 13 0% 100% 0.00 36414 umtxql umtxq_sleep+0x1f5 8 0% 100% 0.00 156849 umtxql __umtx_op_sem2_wake+0x3b6 1 0% 100% 0.00 169422 cdev vputx+0xe0 ------------------------------------------------------------------------------- Spin lock spin: 683399 events in 10.013 seconds (68250 events/sec) Count indv cuml rcnt nsec Lock Caller ------------------------------------------------------------------------------- 466417 68% 68% 0.00 137603 sleepq chain MXD_ioctlFifoGetData.constprop.27+0x309 117135 17% 85% 0.00 64922 sleepq chain MXD_kUsrPutData2Fifo+0xff 16013 2% 88% 0.00 107380 turnstile chain turnstile_trywait+0x85 11157 2% 89% 0.00 9110 mos.memLock MXD_mosMemFree+0x2d 9534 1% 91% 0.00 4598 spinlock MXD_mosPerCpuCacheMemFree+0x5f 7084 1% 92% 0.00 6277 turnstile lock turnstile_trywait+0x16b 6689 1% 93% 0.00 5404 mos.memLock MXD_mosMemAlloc+0xcd 4298 1% 93% 0.00 15026 ACPI lock (0xfffff800086c0c00) AcpiOsAcquireLock+0x80 2201 0% 94% 0.00 17123 turnstile chain __mtx_unlock_sleep+0x5d 1420 0% 94% 0.00 4821 sleepq chain wakeup+0xf 1152 0% 94% 0.00 1353 spinlock MXD_mosPerCpuCacheMemAlloc+0x3a 1087 0% 94% 0.00 4561 turnstile lock turnstile_lookup+0xa3 959 0% 94% 0.00 6673 sched lock 20 sched_add+0xe5 901 0% 95% 0.00 7814 sched lock 18 sched_add+0xe5 884 0% 95% 0.00 7031 sched lock 22 sched_add+0xe5 881 0% 95% 0.00 7597 sched lock 14 sched_add+0xe5 879 0% 95% 0.00 6127 sched lock 23 sched_add+0xe5 867 0% 95% 0.00 7511 sched lock 1 sched_add+0xe5 862 0% 95% 0.00 6403 sched lock 15 sched_add+0xe5 856 0% 95% 0.00 9624 sched lock 2 sched_add+0xe5 ------------------------------------------------------------------------------- Thanks Steevan On Thu, Jun 28, 2018 at 10:17 PM, Andrew Gallatin wrote: > On 06/28/18 12:44, Steevan Rodrigues wrote: > > Thank you so much for the suggestions . I will use these commands. > > Yes, I am already working on to identify lock contentions. > > > > Re-built FreeBSD kernel by enabling lock profiling and now I am able to > > see some issues with contention. > > > > Thanks > > Steevan > > > You need-not rebuild freebsd. lockstat is based on dtrace.. > > The lock profiling you're referring to is a different mechanism. > > Drew > From owner-freebsd-hackers@freebsd.org Wed Jul 11 12:27:04 2018 Return-Path: Delivered-To: freebsd-hackers@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 5585D103800B for ; Wed, 11 Jul 2018 12:27:04 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weser.webweaving.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAF5F8F184 for ; Wed, 11 Jul 2018 12:27:03 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id w6BC3uih000200 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 Jul 2018 14:03:57 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be beeb.leiden.webweaving.org From: Dirk-Willem van Gulik Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Limits to seeding /dev/random | random(4) Message-Id: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> Date: Wed, 11 Jul 2018 14:03:56 +0200 To: "freebsd-hackers@freebsd.org" X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Wed, 11 Jul 2018 14:03:57 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 12:27:04 -0000 When feeding /dev/random from hardware USB devices like Bill = Woodcock=E2=80=99s design in PCB incarnation: https://13-37.org/de/shop/infinite-noise-trng/ Are there any caveats with regard to volume or speed of doing so ? Or is = it always a plus ?=20 Actual code at = https://github.com/dirkx/infnoise/blob/master/software/libinfnoise.c = line 122: if ((devRandomFD =3D open("/dev/random",O_WRONLY)) <0) .. error handling if (write(devRandomFD, bytes, length) !=3D length)=20 .. error handling And is there any case where length would not return the length written = =E2=80=94 it seems that the driver traps/ignores EINT, EAGAIN and short = writes ?=20 Or should one check the entropy available in /dev/random (how?) and hold = off feeding it until it is low enough (this is what the infinite-trng = seems to do on linux). With kind regards, Dw From owner-freebsd-hackers@freebsd.org Wed Jul 11 13:58:47 2018 Return-Path: Delivered-To: freebsd-hackers@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 0A35810401F3 for ; Wed, 11 Jul 2018 13:58:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 840AA72D74 for ; Wed, 11 Jul 2018 13:58:46 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 81483e65-8512-11e8-aa1a-954dbaed88ca X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 81483e65-8512-11e8-aa1a-954dbaed88ca; Wed, 11 Jul 2018 13:58:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6BDwZMJ038686; Wed, 11 Jul 2018 07:58:35 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1531317515.66719.20.camel@freebsd.org> Subject: Re: Limits to seeding /dev/random | random(4) From: Ian Lepore To: Dirk-Willem van Gulik , "freebsd-hackers@freebsd.org" Date: Wed, 11 Jul 2018 07:58:35 -0600 In-Reply-To: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 13:58:47 -0000 On Wed, 2018-07-11 at 14:03 +0200, Dirk-Willem van Gulik wrote: > When feeding /dev/random from hardware USB devices like Bill > Woodcock’s design in PCB incarnation: > > https://13-37.org/de/shop/infinite-noise-trng/ > > Are there any caveats with regard to volume or speed of doing so ? Or > is it always a plus ?  > > Actual code at https://github.com/dirkx/infnoise/blob/master/software > /libinfnoise.c line 122: > > if ((devRandomFD = open("/dev/random",O_WRONLY)) <0) > .. error handling > > if (write(devRandomFD, bytes, length) != length)  > .. error handling > > And is there any case where length would not return the length > written — it seems that the driver traps/ignores EINT, EAGAIN and > short writes ?  > > Or should one check the entropy available in /dev/random (how?) and > hold off feeding it until it is low enough (this is what the > infinite-trng seems to do on linux). > > With kind regards, > > Dw There is no way to check the entropy available in /dev/random because the whole concept doesn't apply. Entropy isn't a limited resource that can be exhausted after the prng is seeded at boot time. When asking our prng gurus for advice on writing a device driver for an on-chip entropy source, the advice I got was basically: there's no need to feed in more entropy on an ongoing basis, but no harm in doing so either, within reason. The recommendation was to feed at or below an average rate of about 128 bits/second. Pushing in more isn't harmful, just wasteful of system resources because it doesn't make anything better. -- Ian From owner-freebsd-hackers@freebsd.org Wed Jul 11 14:35:49 2018 Return-Path: Delivered-To: freebsd-hackers@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 8588010436FB for ; Wed, 11 Jul 2018 14:35:49 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weser.webweaving.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC7B074D75 for ; Wed, 11 Jul 2018 14:35:48 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id w6BEYTaS004062 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Jul 2018 16:34:30 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Limits to seeding /dev/random | random(4) From: Dirk-Willem van Gulik In-Reply-To: <1531317515.66719.20.camel@freebsd.org> Date: Wed, 11 Jul 2018 16:34:29 +0200 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Wed, 11 Jul 2018 16:34:30 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 14:35:49 -0000 > On 11 Jul 2018, at 15:58, Ian Lepore wrote: >=20 > On Wed, 2018-07-11 at 14:03 +0200, Dirk-Willem van Gulik wrote: >> When feeding /dev/random from hardware USB devices like Bill >> Woodcock=E2=80=99s design in PCB incarnation: >>=20 >> https://13-37.org/de/shop/infinite-noise-trng/ >>=20 >> Are there any caveats with regard to volume or speed of doing so ? Or >> is it always a plus ?=20 >>=20 >> Actual code at https://github.com/dirkx/infnoise/blob/master/software >> /libinfnoise.c line 122: >>=20 >> if ((devRandomFD =3D open("/dev/random",O_WRONLY)) <0) >> .. error handling >>=20 >> if (write(devRandomFD, bytes, length) !=3D length)=20 >> .. error handling >>=20 >> And is there any case where length would not return the length >> written =E2=80=94 it seems that the driver traps/ignores EINT, EAGAIN = and >> short writes ?=20 >>=20 >> Or should one check the entropy available in /dev/random (how?) and >> hold off feeding it until it is low enough (this is what the >> infinite-trng seems to do on linux). >>=20 >> With kind regards, >>=20 >> Dw >=20 > There is no way to check the entropy available in /dev/random because > the whole concept doesn't apply. Entropy isn't a limited resource that > can be exhausted after the prng is seeded at boot time. >=20 > When asking our prng gurus for advice on writing a device driver for = an > on-chip entropy source, the advice I got was basically: there's no = need > to feed in more entropy on an ongoing basis, but no harm in doing so > either, within reason. Understood. But it is not a bad thing if one also takes into account all = sort of governance stuff around certification & what not (and we got = bitten at least twice by a virtualised environment producing something = identical - which with hindsight was obvious but still). > The recommendation was to feed at or below an > average rate of about 128 bits/second. Pushing in more isn't harmful, > just wasteful of system resources because it doesn't make anything > better. Ok - so these units spit out around a 90-100 K bit/second (that is after = it has been whitewashed by a Keccack-1600). So I guess I should not pass all of that on blindly =E2=80=94 but quell = that stream by a factor thousand. Dw.= From owner-freebsd-hackers@freebsd.org Wed Jul 11 18:22:16 2018 Return-Path: Delivered-To: freebsd-hackers@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 C4BB81031C7C for ; Wed, 11 Jul 2018 18:22:16 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68E707F901 for ; Wed, 11 Jul 2018 18:22:16 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.200.3] (c-73-216-227-39.hsd1.va.comcast.net [73.216.227.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id 9F7A527000A0; Wed, 11 Jul 2018 14:22:08 -0400 (EDT) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu 9F7A527000A0 Authentication-Results: duke.cs.duke.edu; dmarc=none header.from=cs.duke.edu DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1531333328; bh=RvgsTVUfmthwWFRI37ZnzqGmGa4JCFotswKI9A2N5xg=; h=Subject:To:From:Date:From; b=FbSAk7GfU40ttTEoSoWTygKcd1OTK3aj9XYaA2dYZ6lfVwMfhR21XANNrIS8xCie7 gtDgSR4XS+b5m2SaREHjCyAtG4Jws2jzYF7zCv8AZLg2zGpfIVGtl6U+dyzm2k8o/w acLNpykjHKtuzukO7riUJRVwuzZ/Sfy8K8E2AUmO9tqhAqImIHrwh+awZ1HnUsjsno b8tHoJOrwlI8E4L1gp7eiR+TJmLbnUElxexYQDsforJuSx9NYSd0R/iAqfPHGqd0fr xqxNpzcqeDGrgc0raDlgS4yDL62eiTFgVS+D26E/wGrPgvQD82/IVAOfyy8lcJAiB0 YbdNkj+YHU7ZQ== Subject: Re: high CPU usage in FreeBSD for a PCIe card driver To: Steevan Rodrigues Cc: freebsd-hackers@freebsd.org References: <2ae78782-6cca-452e-d004-3999885ae4e0@cs.duke.edu> From: Andrew Gallatin Message-ID: <03274bb2-87b1-ab32-ee15-81e83b6f6bdd@cs.duke.edu> Date: Wed, 11 Jul 2018 14:22:07 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:22:16 -0000 On 07/11/18 07:46, Steevan Rodrigues wrote: > Hello Andrew, > > Sorry to bother you.  I am working on this problem again after a break > of few days. > I ran following command  to get lock statistics  when I run my userspace > application on a 12 core 24 thread server PC. > From this data below  to looks like my driver is causing a contention > on a kernel lock  (pmap ).  Am I right ? > >  lockstat -x aggsize=4m -D 20 sleep 10 > > Adaptive mutex spin: 1122679 events in 10.013 seconds (112121 events/sec) > > Count indv cuml rcnt     nsec Lock                   Caller > ------------------------------------------------------------------------------- > 1089662  97%  97% 0.00    65375 pmap                   pmap_extract+0x1d2 > 31805   3% 100% 0.00    14881 cdev                   devvn_refthread+0x142 Yes. You can get more information if you use the -s 10 argument to lockstat. That way, you'll see what's calling pmap_extract. Are you doing frequent device ioctls? Drew From owner-freebsd-hackers@freebsd.org Wed Jul 11 23:45:43 2018 Return-Path: Delivered-To: freebsd-hackers@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 D4BE81030641 for ; Wed, 11 Jul 2018 23:45:42 +0000 (UTC) (envelope-from steevanxperia@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EF1F8E3F6 for ; Wed, 11 Jul 2018 23:45:42 +0000 (UTC) (envelope-from steevanxperia@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id q11-v6so26919888oic.12 for ; Wed, 11 Jul 2018 16:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lzSser86VqEoks23/sqyajK5rjDhKLRATJ1K2TtANXc=; b=ZMz7PqKAfdB+Tao+oXozuP+MXWJJZ+XJkf8RzqqfOTcWrI8VMbLOrnfI12sod4ILh3 be5DOQ6yWQMGZTD58uIfPRBYZkgW4GdBrW/gcyqcAVwAzY/xNAeEmL/mrUPgPZtqLr04 0BA09y7y++aT64oBDyC/SS0eoLUtpOyHjkJiJ62sXSiMFegwC8y9OMLoiFZ1EIafiI1F bRN2iVhoxvgx3s3aRer07sOIv5cM58yxQontsoPdm7jZkMWP1G0uhWB0F0zSGxSHICgn BzW+cJ1CkRdS5FDq/KZtgy0mF0gDjK/KFEWN3tc4cVW81guvPMgbQkHHGk6tCvM2wASV 1YGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lzSser86VqEoks23/sqyajK5rjDhKLRATJ1K2TtANXc=; b=qsMUxtE4weohqoryISzMlIdvEjymlyQBWys/LQCLNeEShPREoYA5UaFXhdD8Ms/sMa SGRq+12pJW/GBDgmVLGYz00NKmod0b0HOidTwA8OTOLSIAwTZTFDbedEhnddTC0Ozdvy kMaFeW0gcVhyj7NbBYQJ+yl0S901Awv6C4rDOOnwK222Ts7rypADhxDhuA5Hiijcav1D aNjPR9fwgVoMnm0mQ16CDJxf90J/1Tjw8Dfwl3PfefIlhpmf0Yr0+L2WH60ZuaWfdJ2r /KsBADWk2JyVZGFu0Z+5NQUmWXL1Zew96NisdB//VNqF7vIrYvIFH7CCXFAI2OC/zAE5 /SpA== X-Gm-Message-State: AOUpUlHvubIOVy2uzyL5rLTs8JRqxqSo3sDQ7Ghab8cwOSfkmCFl02tM VHNt17R7C2QD4XIdlb6VKbdTfG1mwmB4XAV1rXI= X-Google-Smtp-Source: AAOMgpfGCB9ni9q8lbqo9L7vmc+3ldoi7MUtWlfW79k9Ly+T+0IWwquwBvWN2JbiOZIJmYgWfOrbA33U40KtJMjdNv0= X-Received: by 2002:aca:4e4d:: with SMTP id c74-v6mr811539oib.16.1531352741554; Wed, 11 Jul 2018 16:45:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:5bd6:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 16:45:41 -0700 (PDT) In-Reply-To: <03274bb2-87b1-ab32-ee15-81e83b6f6bdd@cs.duke.edu> References: <2ae78782-6cca-452e-d004-3999885ae4e0@cs.duke.edu> <03274bb2-87b1-ab32-ee15-81e83b6f6bdd@cs.duke.edu> From: Steevan Rodrigues Date: Thu, 12 Jul 2018 05:15:41 +0530 Message-ID: Subject: Re: high CPU usage in FreeBSD for a PCIe card driver To: Andrew Gallatin Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 23:45:43 -0000 Thanks for confirming it. Yes I do very frequent device ioctl calls . Regards, Steevan On Wed, Jul 11, 2018 at 11:52 PM, Andrew Gallatin wrote: > On 07/11/18 07:46, Steevan Rodrigues wrote: > >> Hello Andrew, >> >> Sorry to bother you. I am working on this problem again after a break of >> few days. >> I ran following command to get lock statistics when I run my userspace >> application on a 12 core 24 thread server PC. >> From this data below to looks like my driver is causing a contention on >> a kernel lock (pmap ). Am I right ? >> >> lockstat -x aggsize=4m -D 20 sleep 10 >> >> Adaptive mutex spin: 1122679 events in 10.013 seconds (112121 events/sec) >> >> Count indv cuml rcnt nsec Lock Caller >> ------------------------------------------------------------ >> ------------------- >> 1089662 97% 97% 0.00 65375 pmap pmap_extract+0x1d2 >> 31805 3% 100% 0.00 14881 cdev devvn_refthread+0x142 >> > > > Yes. You can get more information if you use the -s 10 argument to > lockstat. That way, you'll see what's calling pmap_extract. > > Are you doing frequent device ioctls? > > > Drew > From owner-freebsd-hackers@freebsd.org Thu Jul 12 12:14:31 2018 Return-Path: Delivered-To: freebsd-hackers@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 2C6A5102F449 for ; Thu, 12 Jul 2018 12:14:31 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BBACF8DD88 for ; Thu, 12 Jul 2018 12:14:30 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 728A2102F447; Thu, 12 Jul 2018 12:14:30 +0000 (UTC) Delivered-To: hackers@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 5E5C1102F446 for ; Thu, 12 Jul 2018 12:14:30 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E98678DD87 for ; Thu, 12 Jul 2018 12:14:29 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Thu, 12 Jul 2018 14:14:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1531397660; bh=k3DOlNUUO6iWEvGhV9tr/GQ4BD8la/gBVe3PZr5Yte0=; h=Date:From:To:Subject; b=3xf5iyNuIm3torwNgB1bEk/DAqBHK3Rne94fnReOhB7m4FTNSnHjAmEow3rzNIokz rDTd+dVfYAcRiVgT+/M7aGMAIN3FNdYy+gcT6/euQ5KgM7l0nVUJpql7i9p8TP/TXI V24wbQm/EBktY+P0gKDG5GdOZxf1ixMRQ/KeH67wcmlK7NfcYcdhX6q2Ad/xgphziW 1X3Rynh2XwA8ImRIk8NVYYG4qJncJhcTjVBlYpw846Q+fixa88ZeTSr1a3a2GT/unv egKXZ6snVELmaZhjU3HRCyl2u6u/Zt0/+VyHS2mpPMH2XbE8dAY2bJDJBYkH48mxi7 dXAm5WvNWsG9w== Message-ID: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> From: Alexander Leidinger To: hackers@freebsd.org Subject: crashinfo doesn't support compressed crashdumps - which way forward? User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_r02FWol4PTKYFzZPqTyVfVX"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Jul 2018 13:22:41 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 12:14:31 -0000 This message is in MIME format and has been PGP signed. --=_r02FWol4PTKYFzZPqTyVfVX Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, the crashinfo script doesn't know how to handle compressed coredumps.=20=20 What=20would be acceptable behavior (ordered by my preferrence)? 1) decompress in /var/crash and then proceed normally (already=20=20 implemented=20locally) 2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished 3) keep it like it is 4) teach tools to understand compressed dumps (gzip / zstd) Implicitly there is the question what what is the purpose of=20=20 compressing=20crashdumps, to have more RAM than space in dumpdev (which=20= =20 is=20valid in my case), or to save space in /var/crash (which I don't=20=20 care=20much about). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_r02FWol4PTKYFzZPqTyVfVX Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJbR0YRAAoJEKrxQhqFIICEWN4P/0pZOQielSic+c/gWrAI+Sqi CmviJwHhUxTxehnNv4cO+9dr4VirOJKgTEfaDg/OcGHPv33/xrtsr5lyKfz6XDr6 oqxf8F2q4rlM5QGRrpG+7ePhbO4YaoYmt9lJGHI6a1zM1VXZSYlw2mmaYP4ZsqqU LsJRgvxzAUKkd6KBK+Nppuu2v3PoK4N5UBBaMAQlxT+3drdYVTxtSNBXQh+owCI4 0CHe9ZgLW9FAtGwr3w/dNyPmKnCCOIo7Eu2fJDGNHUtEXkRVNplFuxzqN9uRY8GL aoFHTTaQX6T+2naX2/Me63CQWSIACIpnYf37ORl3RcpJ85PwpJh5cm6fne9RCSKy pQLgaTpZb+V3rM+12c3qQKMogmkpkSBm9ZxnHFKXbaUKvOyHy2HN9YQ6EtCx/M5b 7YWSHJfMzryYmGbk3ofKM4GBRtHAb5HXDVenEEAFHiIrBGl2vRypHK5l5Oknk4Xi O222031B5VDXM2FA3ZtqbFGuErJTXL4KspIGGQjXgAPUUbVu/8FXrBtWvEVEJzaI tT0WVdhkXbVk1axPJxuE9V/7j+pDJLkTOSsd1Eyp8BDsoiMWezvYN+gezyh2vFXM 7geiQB07M+pnOk525LnL4sH4SvFExR0UU7ccYakvtkQa6PbHbWxF473RPve3h7xL ms6ho25aBFFOdb+Qj9h9 =34Wm -----END PGP SIGNATURE----- --=_r02FWol4PTKYFzZPqTyVfVX-- From owner-freebsd-hackers@freebsd.org Thu Jul 12 14:31:27 2018 Return-Path: Delivered-To: freebsd-hackers@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 31A74103F33C for ; Thu, 12 Jul 2018 14:31:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B884394602 for ; Thu, 12 Jul 2018 14:31:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6F844103F333; Thu, 12 Jul 2018 14:31:26 +0000 (UTC) Delivered-To: hackers@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 4ABCE103F32E for ; Thu, 12 Jul 2018 14:31:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C68EE945FC; Thu, 12 Jul 2018 14:31:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x235.google.com with SMTP id e13-v6so7330868pff.7; Thu, 12 Jul 2018 07:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=RTZngxXh5FPmRkjIkGWN+bYgjjZcCS9aLdntj0JhCRw=; b=fGxpI788ARQyw0SvGrvN9LzJn4Cu4j1m199bBMY2Ml3Ab/63s/n4b+Jb8BNfPLgHPo Q0fb3pSK09gHgqzYApr7+iRT7umHXGZVinDfUZCePNrN2W+6vW9HqV9jTkkWD7a/5rdb eQwqrIG1uaBdNLVS07E+1mtRPY3y7F2Z7ESscpqv5A6VpudBHDCj03AcNX+7QOUJzza4 2JvM4q0jZdmNV9AC5ZKMz0CR4e8IcZhk8TsFsPK11ZCjZAMh21eiEzeX82k4N4hlX7oc +t3fagmwx7h2gBx4B7h6lxl8Uxy3I60aAAJxsWWFe1GRTiCgRfR/5/5GVR7LCEuhOg56 i/jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=RTZngxXh5FPmRkjIkGWN+bYgjjZcCS9aLdntj0JhCRw=; b=Dh89j/00YHN0rUuIWia/L621SpfiFecq+sDg4de7MhGNBbLXH0CI6ff68UEA+ZegOk DPGLFNi23dHL0lnu/EoeBfWdJSmOyYBnok89THyH2lNkc1IMH+YK574pSsFzAg8RAzqg gF3oQhXQBIgVrtnKEOFCSlD0wk67OWp2i9W3trTVHH+sF/Jvz/+iaL4er0AzQNoUBukm NHnshwn4DK8YNcp/z8sEOoHH29qI8bI6WUbXGz++5gwlJlxdYL5OUUnWmO4+BpeNbdk9 IR6PTWm9QTL+UJ+iHrqACym1TPDVVvM86vLYtMh3YuuTKMIOm7eJ0lcIFAZ5pGixRukI ZAuw== X-Gm-Message-State: AOUpUlH2FMRDu70pbrdnM2dM3gaU4frFcFDP22LfgQKhbR4Cz+iSWOKj OV1ZOSuLDdcY6y3oMn7vmvBAhA== X-Google-Smtp-Source: AAOMgpffPfg1vZveNZfGfmEP1n3A35vP0uwLWTrOQmydYwR9+cFW3yx9C+tn+HwUXHpMhJPanIM1+w== X-Received: by 2002:a65:62ce:: with SMTP id m14-v6mr2330438pgv.407.1531405884786; Thu, 12 Jul 2018 07:31:24 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-107.dsl.bell.ca. [70.52.224.107]) by smtp.gmail.com with ESMTPSA id b1-v6sm40716439pff.141.2018.07.12.07.31.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 07:31:24 -0700 (PDT) Sender: Mark Johnston Date: Thu, 12 Jul 2018 10:31:18 -0400 From: Mark Johnston To: Alexander Leidinger Cc: hackers@freebsd.org, jhb@freebsd.org Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? Message-ID: <20180712143118.GA15892@raichu> References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 14:31:27 -0000 On Thu, Jul 12, 2018 at 02:14:09PM +0200, Alexander Leidinger wrote: > Hi, > > the crashinfo script doesn't know how to handle compressed coredumps. > What would be acceptable behavior (ordered by my preferrence)? > 1) decompress in /var/crash and then proceed normally (already > implemented locally) > 2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished > 3) keep it like it is > 4) teach tools to understand compressed dumps (gzip / zstd) > > Implicitly there is the question what what is the purpose of > compressing crashdumps, to have more RAM than space in dumpdev (which > is valid in my case), or to save space in /var/crash (which I don't > care much about). I think jhb has a patch which implements 2). I do not have strong feelings on which is the right way forward, but I mildly prefer 2) to 1). It looks like crashinfo can be disabled in rc.conf, so users who are space-constrained in /var/crash can take the additional step of setting crashinfo_enable=NO. FWIW, when I committed the compression support, my use-case involved both a small dump device and a small /var filesystem. From owner-freebsd-hackers@freebsd.org Thu Jul 12 14:50:13 2018 Return-Path: Delivered-To: freebsd-hackers@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 1F23D1040FD8 for ; Thu, 12 Jul 2018 14:50:13 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A24CF953BD for ; Thu, 12 Jul 2018 14:50:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5FB621040FD6; Thu, 12 Jul 2018 14:50:12 +0000 (UTC) Delivered-To: hackers@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 3AFFD1040FD4 for ; Thu, 12 Jul 2018 14:50:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96540953B9; Thu, 12 Jul 2018 14:50:11 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id a134-v6so24476151lfe.6; Thu, 12 Jul 2018 07:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UJdNtD8N0DReTCseOdc04esOhY6RY+cfzCprI+1IME4=; b=H/18WJZ/HJ/PSKPVxWE7NFhnylnTd+FzE27twR+v25ibe3OuW9HNN6tFy8o3FMN5U6 VUucQptvBXdxG0qUEQhMEeYqXZMXJgQckLOmz7PAJvi9tYErVwgrD0hp8EEi40VSSpQo 8ebDMn0ERtYS67+b7WYDabGstMKeBwiZ31YaXEbZvWwwg6eLrBnsNna18wMNgBnkTCfh mXZG0iroGvL0CTp69x57l4dlVqzLHG9cYNhqzHWrq1AyILkijVCUqtBLmJPNgBf5O8Gr Po+hlwNizxRZCn7aiURs/eWckGksYPtNJJ941ji8Vzj7DUqOn2mz6Lzs8ELG0z3R1zMu k9Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UJdNtD8N0DReTCseOdc04esOhY6RY+cfzCprI+1IME4=; b=G9VgPff+7RHFIRbW0ti6TWZSLJgkk9Fp7Ys9lWF5cm0JKQKnS4OVud2OIszEhr/8yo ZhewoLq71BQZG7S5WkcFQRwt5kHqDvRu2bW0ol80nYFtRTC6t34RicPSN6GbhIZk7917 sQzbOo5a+SCbaF0Wq5bDQGeINLiDuyvpSLyevV1dPgN7IP7IGK8JTG/1mAHJiKCfkaJN SDa/3fTQcvFmvrL6un3DZMXYnzYVj3NWgSfU1zewEvuZmrA4HBsGlAMqXi20+ZUvlTYr 5vvuIdAtIc0q5pT5twFmdmb8gnaAfuNq/Nndt03gH4NtcUcRuz+4kQrznD7cyXtYbb9G x+Xw== X-Gm-Message-State: AOUpUlE29Ap0fGCBfJUL2Vni+1FTQISPeNEA1fCmaSlnZXUhqs4f40zE VArE5CvT4dnL+3QzI5zHci2cZUzXXdyZa9KkQLo= X-Google-Smtp-Source: AAOMgpferAaSnio3VdDNzxa0LqV0Q3YFn8YzfAYlZUw+pxviVr09CoqoQv/pVzKxpQg7wjE4WswS9vorgmgTRipFlF8= X-Received: by 2002:a19:c004:: with SMTP id q4-v6mr2098073lff.16.1531407009200; Thu, 12 Jul 2018 07:50:09 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 07:50:08 -0700 (PDT) In-Reply-To: <20180712143118.GA15892@raichu> References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> <20180712143118.GA15892@raichu> From: Alan Somers Date: Thu, 12 Jul 2018 08:50:08 -0600 X-Google-Sender-Auth: 5yQ1JpJhhhkOGBDpwQmHTvY5yCk Message-ID: Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? To: Mark Johnston Cc: Alexander Leidinger , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 14:50:13 -0000 On Thu, Jul 12, 2018 at 8:31 AM, Mark Johnston wrote: > On Thu, Jul 12, 2018 at 02:14:09PM +0200, Alexander Leidinger wrote: > > Hi, > > > > the crashinfo script doesn't know how to handle compressed coredumps. > > What would be acceptable behavior (ordered by my preferrence)? > > 1) decompress in /var/crash and then proceed normally (already > > implemented locally) > > 2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished > > 3) keep it like it is > > 4) teach tools to understand compressed dumps (gzip / zstd) > I briefly looked into this option, but it's harder than it sounds. There are several libraries that would need to be modified, and I think some of them work by mmap(2)ping the core file rather than by fread(2)ing it. I don't know of anyway to mmap a compressed file. > > > > Implicitly there is the question what what is the purpose of > > compressing crashdumps, to have more RAM than space in dumpdev (which > > is valid in my case), or to save space in /var/crash (which I don't > > care much about). > Compressed crashdumps are also great for systems with slow dumpdevs. They greatly speed up the dumping process. > > I think jhb has a patch which implements 2). I do not have strong > feelings on which is the right way forward, but I mildly prefer 2) to > 1). It looks like crashinfo can be disabled in rc.conf, so users who > are space-constrained in /var/crash can take the additional step of > setting crashinfo_enable=NO. FWIW, when I committed the compression > support, my use-case involved both a small dump device and a small > /var filesystem. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Jul 12 14:51:52 2018 Return-Path: Delivered-To: freebsd-hackers@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 CC96E10413DC for ; Thu, 12 Jul 2018 14:51:52 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 64D7D9578C for ; Thu, 12 Jul 2018 14:51:52 +0000 (UTC) (envelope-from ler@lerctr.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2610B10413DB; Thu, 12 Jul 2018 14:51:52 +0000 (UTC) Delivered-To: hackers@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 03F6910413D7 for ; Thu, 12 Jul 2018 14:51:52 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B5E595783; Thu, 12 Jul 2018 14:51:51 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=pEv3fyjQwacH6q1Ux8QLsvdHwogNG5UMmHxd3iVdqPo=; b=Ypee5oXYm4UxrlZj6c/q+Jzoqi wASb1Zp82iQXp5ZY/soOEPcjuS/GNrRq2OK2voa/R9E+7ipLX+OHiVBCIPo8xWuwJz8hkdI6FV8WW wiX5nbOiA1dVXC8dIe+Ev+YapY89MaHRmM3briFlmkRiEbt6ovHtGGp3SVsfEQeceDWQ=; Received: from [2600:1700:210:b18f:5d16:74d5:75bf:c686] (port=49314 helo=ler-imac.local) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fdcwf-000Dg8-S0; Thu, 12 Jul 2018 09:51:49 -0500 Date: Thu, 12 Jul 2018 09:51:49 -0500 From: Larry Rosenman To: Alan Somers Cc: Mark Johnston , Alexander Leidinger , "freebsd-hackers@freebsd.org" Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? Message-ID: <20180712145149.a6rt7kzaobze65gv@ler-imac.local> References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> <20180712143118.GA15892@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o7sdm5hpvbycbezs" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 14:51:53 -0000 --o7sdm5hpvbycbezs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2018 at 08:50:08AM -0600, Alan Somers wrote: > On Thu, Jul 12, 2018 at 8:31 AM, Mark Johnston wrote: >=20 > > On Thu, Jul 12, 2018 at 02:14:09PM +0200, Alexander Leidinger wrote: > > > Hi, > > > > > > the crashinfo script doesn't know how to handle compressed coredumps. > > > What would be acceptable behavior (ordered by my preferrence)? > > > 1) decompress in /var/crash and then proceed normally (already > > > implemented locally) > > > 2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished > > > 3) keep it like it is > > > 4) teach tools to understand compressed dumps (gzip / zstd) > > >=20 > I briefly looked into this option, but it's harder than it sounds. There > are several libraries that would need to be modified, and I think some of > them work by mmap(2)ping the core file rather than by fread(2)ing it. I > don't know of anyway to mmap a compressed file. >=20 >=20 > > > > > > Implicitly there is the question what what is the purpose of > > > compressing crashdumps, to have more RAM than space in dumpdev (which > > > is valid in my case), or to save space in /var/crash (which I don't > > > care much about). > > >=20 > Compressed crashdumps are also great for systems with slow dumpdevs. They > greatly speed up the dumping process. >=20 >=20 > > > > I think jhb has a patch which implements 2). I do not have strong > > feelings on which is the right way forward, but I mildly prefer 2) to > > 1). It looks like crashinfo can be disabled in rc.conf, so users who > > are space-constrained in /var/crash can take the additional step of > > setting crashinfo_enable=3DNO. FWIW, when I committed the compression > > support, my use-case involved both a small dump device and a small > > /var filesystem. I have jhb's patch applied and it works great. borg.lerctr.org /usr/src $ svn diff Index: usr.sbin/crashinfo/crashinfo.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/crashinfo/crashinfo.sh (revision 336184) +++ usr.sbin/crashinfo/crashinfo.sh (working copy) @@ -38,6 +38,13 @@ exit 1 } +# Remove an uncompressed copy of a dump +cleanup() +{ + + [ -e $VMCORE ] && rm -f $VMCORE +} + # Find a gdb binary to use and save the value in GDB. find_gdb() { @@ -133,7 +140,7 @@ # Figure out the crash directory and number from the vmcore name. CRASHDIR=3D`dirname $1` - DUMPNR=3D$(expr $(basename $1) : 'vmcore\.\([0-9]*\)$') + DUMPNR=3D$(expr $(basename $1) : 'vmcore\.\([0-9]*\)') if [ -z "$DUMPNR" ]; then echo "Unable to determine dump number from vmcore file $1." exit 1 @@ -174,8 +181,16 @@ fi if [ ! -e $VMCORE ]; then - echo "$VMCORE not found" - exit 1 + if [ -e $VMCORE.gz ]; then + trap cleanup EXIT HUP INT QUIT TERM + gzcat $VMCORE.gz > $VMCORE + elif [ -e $VMCORE.zst ]; then + trap cleanup EXIT HUP INT QUIT TERM + zstdcat $VMCORE.zst > $VMCORE + else + echo "$VMCORE not found" + exit 1 + fi fi if [ ! -e $INFO ]; then borg.lerctr.org /usr/src $ --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --o7sdm5hpvbycbezs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHABAABCgCqFiEEHjgknedhWzvJgwVzaXyZsatIp30FAltHawUsFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQGxlcmN0ci5vcmdfFIAAAAAALgAoaXNz dWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFFMzgy NDlERTc2MTVCM0JDOTgzMDU3MzY5N0M5OUIxQUI0OEE3N0QACgkQaXyZsatIp32m MQf/ZVSsnAqswOAvjWXSjnvwBszsjDm/mvnd1UbTX0cFlEMkcSCLF9csjThegEL1 ElTdV6iv5GhMYZ8mnvVyQMCUtm01ekK9HjdhgTgtljHGINBOUI/wkJI/s6BS049A 9LM4EbGKbx2SoPNfHs8KgAWbAfnQF6UaKMTbnK4FzSYj2tcBtTKvQqXpEns2hvmx IOtgLMa9Hdsr1RpkQzN9Vsq6DqQSOwN8aFBReSQtHUV1/nduYnFKw7Hw/Do/1hTz re3WHsvFA6b3vdlBHrDsws55qmJNTcdoA5GoQNqtaDCCLTWojWIw2IPv/GGj3eT8 tUZv5FiOhN9SEyKceYrK2mi14A== =YRvO -----END PGP SIGNATURE----- --o7sdm5hpvbycbezs-- From owner-freebsd-hackers@freebsd.org Thu Jul 12 15:57:57 2018 Return-Path: Delivered-To: freebsd-hackers@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 301451047241 for ; Thu, 12 Jul 2018 15:57:57 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A38F70263 for ; Thu, 12 Jul 2018 15:57:56 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wr1-x429.google.com with SMTP id h10-v6so22225642wre.6 for ; Thu, 12 Jul 2018 08:57:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iOqA2mRrNLUgKDhApltpFoKebK09N/pnLV54OJFE25A=; b=PXdkyg7OObtktl7chldThc8bTQI6rLa+zkvOvrhd1h5UwcRLS619NgdzK24sxioECb GYqaXB/00wJCjhsGL8oaLGu42fakXHTQbG2g4XNogoUU9FL9Gvv6en6ue8oGslV0RdKQ 0siVLFHPDZdEv3mkYgEmoA1yygPeJ8WTM9q265UsHddpJl19Iccmpgqz/d7xPKEEK2nW hB13jTCJ+Pevb9X5z/J/I9CbRPF+i2bFZVSg8J7mfMUxDNbHXDBj9SfanN0aQZ9kvu7A 4BkJrwnOZQ+6OwOQyYT3tOFk+W6nqrH4qEwby2AfXA83VR3g0ts26x1QaveEcaTmijRV Ljfg== X-Gm-Message-State: AOUpUlFNrR3u+6sJWb4dPeNwF6Z9d4EdANxzmApZic/8jb+MbPJKLBO9 FwQdkd4MOuSFlXyKqQ27+s3oqA== X-Google-Smtp-Source: AAOMgpdQ+w390XP4Ogd5SHDXw5eg7QJWC28Bw6V0f+N/88sT5TD/1bqwNUjRVJkYwDTSzjO3WxweVw== X-Received: by 2002:adf:a197:: with SMTP id u23-v6mr2398070wru.50.1531411075315; Thu, 12 Jul 2018 08:57:55 -0700 (PDT) Received: from gumby.homeunix.com ([90.220.84.208]) by smtp.gmail.com with ESMTPSA id u11-v6sm2250781wmf.28.2018.07.12.08.57.53 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 12 Jul 2018 08:57:54 -0700 (PDT) Date: Thu, 12 Jul 2018 16:57:51 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: Limits to seeding /dev/random | random(4) Message-ID: <20180712165751.1e5b8e24@gumby.homeunix.com> In-Reply-To: <1531317515.66719.20.camel@freebsd.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 15:57:57 -0000 On Wed, 11 Jul 2018 07:58:35 -0600 Ian Lepore wrote: > When asking our prng gurus for advice on writing a device driver for > an on-chip entropy source, the advice I got was basically: there's no > need to feed in more entropy on an ongoing basis, but no harm in > doing so either, within reason. The recommendation was to feed at or > below an average rate of about 128 bits/second. Pushing in more isn't > harmful, just wasteful of system resources because it doesn't make > anything better. This is a bit simplistic because it ignores the way that fortuna stripes entropy across 32 pools. In order to fully secure the prng at boot time you need to get 256 bits of entropy into it, and to guarantee that you need to have 256 bits in pool[0], which means you need to write 256*32=8192 bits into the random device. This should be done as early in the rc.d boot process as possible. Once the pools are primed you could trickle entropy in in smaller amounts if you wish. From owner-freebsd-hackers@freebsd.org Thu Jul 12 16:04:56 2018 Return-Path: Delivered-To: freebsd-hackers@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 2C3101047E73 for ; Thu, 12 Jul 2018 16:04:56 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weser.webweaving.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A772A708C5 for ; Thu, 12 Jul 2018 16:04:55 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id w6CG3W33044758 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jul 2018 18:03:33 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Limits to seeding /dev/random | random(4) From: Dirk-Willem van Gulik In-Reply-To: <20180712165751.1e5b8e24@gumby.homeunix.com> Date: Thu, 12 Jul 2018 18:03:27 +0200 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> To: RW X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Thu, 12 Jul 2018 18:03:33 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 16:04:56 -0000 On 12 Jul 2018, at 17:57, RW via freebsd-hackers = wrote: > On Wed, 11 Jul 2018 07:58:35 -0600 Ian Lepore wrote: >=20 >=20 >> When asking our prng gurus for advice on writing a device driver for >> an on-chip entropy source, the advice I got was basically: there's no >> need to feed in more entropy on an ongoing basis, but no harm in >> doing so either, within reason. The recommendation was to feed at or >> below an average rate of about 128 bits/second. Pushing in more isn't >> harmful, just wasteful of system resources because it doesn't make >> anything better. >=20 > This is a bit simplistic because it ignores the way that fortuna > stripes entropy across 32 pools. >=20 > In order to fully secure the prng at boot time you need to get 256 = bits > of entropy into it, and to guarantee that you need to have 256 bits in > pool[0], which means you need to write 256*32=3D8192 bits into the = random > device. This should be done as early in the rc.d boot process as > possible. Once the pools are primed you could trickle entropy in in > smaller amounts if you wish. So these HW devices [1] give us a raw feed =E2=80=94 which one usually = whitewashes [2] in order to use. It is fairly well defined how many bits of entropy we get =E2=80=98raw=E2=80= =99. During boot - can I feed the right number of bits without whitewashing - = letting the kernel do the trick (much like random_harvest_queue() does = in for example the mouse driver) ? Or should it be properly whitened first ? Our goal is to get to a point where a very stripped down BSD can be = booted up (sans network or much in terms of attached devices but for a = printer and chipcard reader) =E2=80=94 yet is know to have a solid = seeded RNG. With kind regards, Dw. 1: https://13-37.org/en/shop/infinite-noise-trng/ 2: https://github.com/manuel-domke/infnoise= From owner-freebsd-hackers@freebsd.org Thu Jul 12 16:09:06 2018 Return-Path: Delivered-To: freebsd-hackers@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 51EA610484B5 for ; Thu, 12 Jul 2018 16:09:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DD9B870B9B for ; Thu, 12 Jul 2018 16:09:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A193410484B1; Thu, 12 Jul 2018 16:09:05 +0000 (UTC) Delivered-To: hackers@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 7A14310484AC for ; Thu, 12 Jul 2018 16:09:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F1C270B97; Thu, 12 Jul 2018 16:09:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id A1F5210A87D; Thu, 12 Jul 2018 12:09:03 -0400 (EDT) Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? To: Mark Johnston , Alexander Leidinger References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> <20180712143118.GA15892@raichu> Cc: hackers@freebsd.org From: John Baldwin Message-ID: <6858738d-7eef-cc0f-10bd-900fb822fecd@FreeBSD.org> Date: Thu, 12 Jul 2018 09:09:02 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180712143118.GA15892@raichu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 12 Jul 2018 12:09:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 16:09:06 -0000 On 7/12/18 7:31 AM, Mark Johnston wrote: > On Thu, Jul 12, 2018 at 02:14:09PM +0200, Alexander Leidinger wrote: >> Hi, >> >> the crashinfo script doesn't know how to handle compressed coredumps. >> What would be acceptable behavior (ordered by my preferrence)? >> 1) decompress in /var/crash and then proceed normally (already >> implemented locally) >> 2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished >> 3) keep it like it is >> 4) teach tools to understand compressed dumps (gzip / zstd) >> >> Implicitly there is the question what what is the purpose of >> compressing crashdumps, to have more RAM than space in dumpdev (which >> is valid in my case), or to save space in /var/crash (which I don't >> care much about). > > I think jhb has a patch which implements 2). I do not have strong > feelings on which is the right way forward, but I mildly prefer 2) to > 1). It looks like crashinfo can be disabled in rc.conf, so users who > are space-constrained in /var/crash can take the additional step of > setting crashinfo_enable=NO. FWIW, when I committed the compression > support, my use-case involved both a small dump device and a small > /var filesystem. Yes, here's the patch for 2 which has been tested. 4) is pretty hard to do in practice as you have to basically decompress into RAM when reading the core to do anything useful as opposed to a format that only compressed certain parts (e.g. if the page tables were not compressed only the payload in a minidump, and if it were compressed on some kind of block boundaries so that you could locate a given block and decompress it when reading specific data). Coming up with such a format would be more useful but requires more work. Index: usr.sbin/crashinfo/crashinfo.sh =================================================================== --- usr.sbin/crashinfo/crashinfo.sh (revision 335896) +++ usr.sbin/crashinfo/crashinfo.sh (working copy) @@ -38,6 +38,13 @@ exit 1 } +# Remove an uncompressed copy of a dump +cleanup() +{ + + [ -e $VMCORE ] && rm -f $VMCORE +} + # Find a gdb binary to use and save the value in GDB. find_gdb() { @@ -133,7 +140,7 @@ # Figure out the crash directory and number from the vmcore name. CRASHDIR=`dirname $1` - DUMPNR=$(expr $(basename $1) : 'vmcore\.\([0-9]*\)$') + DUMPNR=$(expr $(basename $1) : 'vmcore\.\([0-9]*\)') if [ -z "$DUMPNR" ]; then echo "Unable to determine dump number from vmcore file $1." exit 1 @@ -174,8 +181,16 @@ fi if [ ! -e $VMCORE ]; then - echo "$VMCORE not found" - exit 1 + if [ -e $VMCORE.gz ]; then + trap cleanup EXIT HUP INT QUIT TERM + gzcat $VMCORE.gz > $VMCORE + elif [ -e $VMCORE.zst ]; then + trap cleanup EXIT HUP INT QUIT TERM + zstdcat $VMCORE.zst > $VMCORE + else + echo "$VMCORE not found" + exit 1 + fi fi if [ ! -e $INFO ]; then -- John Baldwin From owner-freebsd-hackers@freebsd.org Thu Jul 12 17:32:12 2018 Return-Path: Delivered-To: freebsd-hackers@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 26B2B102A9FA for ; Thu, 12 Jul 2018 17:32:12 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9826A74BCC for ; Thu, 12 Jul 2018 17:32:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f44.google.com with SMTP id y124-v6so2552391itc.0 for ; Thu, 12 Jul 2018 10:32:11 -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=kB98vhgTiKCC6BZnC5GZm4VzjJwvQe4rD77JZkSxOUA=; b=bSF45T3lKH+PWx2Q0c1do7Ccg0pxBQvkgkbi7ucBt2v+WzcQgqQY5iTE3Cj9ObnmzD JJJWZYCangGD7K8OLLffVYmuL096b5y4QF+TBt/eZT8grxRjg0hD/qib8yLNzlOZIfm6 gnjvNEy3f+NiWQ7BfMJQ+wkUj/XG4NcmC1U5v7yZqw+BTRQc5Bh/72FXakRWQe0xi8LH vVPOxculi9xNYUHRI1SruqHExHGRlTC4rKEz3EMhZg63Qk9CI7sLbzSrrFpyx4kddrnt 5DCfOxlvrP1yGAbf2ylQx/nkYodqBnTAbf8QZSMOMHc6hu1vVzeZvPGguVpBhU7O+WCQ 9fHQ== X-Gm-Message-State: AOUpUlExggcxOjQbQcsrTrBvbKaQS17i8H5szbbQ1UNl3JMnmrtYC/89 Qsya1H3D3ecl4nZoy9WpT3Ewe6zl X-Google-Smtp-Source: AAOMgpcm4NCdHrDbdn+kgoeHmXv1RqKdZxQ5nS73WCqSRNmkgvbDibc/3QPpNCYRZpmFsP9pCT17cw== X-Received: by 2002:a24:4dc1:: with SMTP id l184-v6mr2045976itb.20.1531416724546; Thu, 12 Jul 2018 10:32:04 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id n11-v6sm2919537itn.40.2018.07.12.10.32.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 10:32:04 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id p4-v6so7937823itf.2 for ; Thu, 12 Jul 2018 10:32:04 -0700 (PDT) X-Received: by 2002:a24:a343:: with SMTP id p64-v6mr2147850ite.61.1531416724253; Thu, 12 Jul 2018 10:32:04 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 10:32:03 -0700 (PDT) In-Reply-To: <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> From: Conrad Meyer Date: Thu, 12 Jul 2018 10:32:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Limits to seeding /dev/random | random(4) To: Dirk-Willem van Gulik Cc: RW , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 17:32:12 -0000 On Thu, Jul 12, 2018 at 9:03 AM, Dirk-Willem van Gulik wrote: > On 12 Jul 2018, at 17:57, RW via freebsd-hackers wrote: >> On Wed, 11 Jul 2018 07:58:35 -0600 Ian Lepore wrote: >> >>> When asking our prng gurus for advice on writing a device driver for >>> an on-chip entropy source, the advice I got was basically: there's no >>> need to feed in more entropy on an ongoing basis, but no harm in >>> doing so either, within reason. The recommendation was to feed at or >>> below an average rate of about 128 bits/second. Pushing in more isn't >>> harmful, just wasteful of system resources because it doesn't make >>> anything better. >> >> This is a bit simplistic because it ignores the way that fortuna >> stripes entropy across 32 pools. RW, you and Ian are talking about different things. Ian is talking about post-seed, additional entropy from a hardware device. You are talking about initial seeding. You're both right, but talking past each other :-). >> In order to fully secure the prng at boot time you need to get 256 bits >> of entropy into it, and to guarantee that you need to have 256 bits in >> pool[0], which means you need to write 256*32=3D8192 bits into the rando= m >> device. This should be done as early in the rc.d boot process as >> possible. For example, it is done by the loader, as well as the /etc/rc.d/random script using entropy saved from the RNG at shutdown on any FreeBSD with a writable /, /var, or /boot. >> Once the pools are primed you could trickle entropy in in >> smaller amounts if you wish. Right =E2=80=94 that's what Ian is suggesting. > So these HW devices [1] give us a raw feed =E2=80=94 which one usually wh= itewashes [2] in order to use. Don't feed the raw data =E2=80=94 use the washed bits. > It is fairly well defined how many bits of entropy we get =E2=80=98raw=E2= =80=99. > > During boot - can I feed the right number of bits without whitewashing - = letting the kernel do the trick (much like random_harvest_queue() does in f= or example the mouse driver) ? Why feed less random data to the kernel when you have a relatively high throughput random device available? Your device generates 90 kbps after washing =E2=80=94 it'll take at most 90 ms to fully seed /dev/random at that rate, even with a readonly filesystem embedded-type device. > Or should it be properly whitened first ? Yes :-). > Our goal is to get to a point where a very stripped down BSD can be boote= d up (sans network or much in terms of attached devices but for a printer a= nd chipcard reader) =E2=80=94 yet is know to have a solid seeded RNG. /dev/u?random never produces unseeded results. If it is not seeded, reads will just block indefinitely, until it is seeded. To seed the device without a writable filesystem, write 1kB+ of whitened random from your device into /dev/random early in boot, and you will be good to go. You can do the ongoing trickle after that if you want, but it is not necessary. On FreeBSD 12-CURRENT, you can verify /dev/random is seeded when getrandom(..., GRND_NONBLOCK) no longer returns -1 with EAGAIN errno. If you need to use a FreeBSD prior to 12, you'll know random is seeded when reads no longer block. All the best, Conrad From owner-freebsd-hackers@freebsd.org Thu Jul 12 17:43:45 2018 Return-Path: Delivered-To: freebsd-hackers@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 DB523102BD7B for ; Thu, 12 Jul 2018 17:43:44 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weser.webweaving.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B8FC755F1 for ; Thu, 12 Jul 2018 17:43:44 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id w6CHgQZN047526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jul 2018 19:42:26 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Limits to seeding /dev/random | random(4) From: Dirk-Willem van Gulik In-Reply-To: Date: Thu, 12 Jul 2018 19:42:24 +0200 Cc: RW , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> To: cem@freebsd.org X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Thu, 12 Jul 2018 19:42:26 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 17:43:45 -0000 On 12 Jul 2018, at 19:32, Conrad Meyer wrote: > On Thu, Jul 12, 2018 at 9:03 AM, Dirk-Willem van Gulik > wrote: >> On 12 Jul 2018, at 17:57, RW via freebsd-hackers = wrote: >>> On Wed, 11 Jul 2018 07:58:35 -0600 Ian Lepore wrote: >>>=20 >>>> When asking our prng gurus for advice on writing a device driver = for >>>> an on-chip entropy source, the advice I got was basically: there's = no >>>> need to feed in more entropy on an ongoing basis, but no harm in >>>> doing so either, within reason. The recommendation was to feed at = or >>>> below an average rate of about 128 bits/second. Pushing in more = isn't >>>> harmful, just wasteful of system resources because it doesn't make >>>> anything better. >>>=20 >>> This is a bit simplistic because it ignores the way that fortuna >>> stripes entropy across 32 pools. >=20 > RW, you and Ian are talking about different things. Ian is talking > about post-seed, additional entropy from a hardware device. You are > talking about initial seeding. You're both right, but talking past > each other :-). Clear thanks ! And it is indeed that space I care about. As it is there = where we see hang/wait for entropy and the very occasional identical = result in CI testing. >>> In order to fully secure the prng at boot time you need to get 256 = bits >>> of entropy into it, and to guarantee that you need to have 256 bits = in >>> pool[0], which means you need to write 256*32=3D8192 bits into the = random >>> device. This should be done as early in the rc.d boot process as >>> possible. >=20 > For example, it is done by the loader, as well as the /etc/rc.d/random > script using entropy saved from the RNG at shutdown on any FreeBSD > with a writable /, /var, or /boot. >=20 >>> Once the pools are primed you could trickle entropy in in >>> smaller amounts if you wish. >=20 > Right =E2=80=94 that's what Ian is suggesting. >=20 >> So these HW devices [1] give us a raw feed =E2=80=94 which one = usually whitewashes [2] in order to use. >=20 > Don't feed the raw data =E2=80=94 use the washed bits. >=20 >> It is fairly well defined how many bits of entropy we get =E2=80=98raw=E2= =80=99. >>=20 >> During boot - can I feed the right number of bits without = whitewashing - letting the kernel do the trick (much like = random_harvest_queue() does in for example the mouse driver) ? >=20 > Why feed less random data to the kernel when you have a relatively > high throughput random device available? Your device generates 90 > kbps after washing =E2=80=94 it'll take at most 90 ms to fully seed > /dev/random at that rate, even with a readonly filesystem > embedded-type device. >=20 >> Or should it be properly whitened first ? >=20 > Yes :-). Excellent - I have my marching orders. Much appreciated ! Is there any point - much later post boot, in a non-network, read-only = situation with essentially just 3 or 4 user processes running with no IO = or interaction - to send some entropy (withewashed (or raw with = random_harvest_queue()) to wards the PRNG ? Or is that pointless from thereon. >> Our goal is to get to a point where a very stripped down BSD can be = booted up (sans network or much in terms of attached devices but for a = printer and chipcard reader) =E2=80=94 yet is know to have a solid = seeded RNG. >=20 > /dev/u?random never produces unseeded results. If it is not seeded, > reads will just block indefinitely, until it is seeded. As we=E2=80=99ve found out the hard way (although we are not sure it is = indefinitely). > To seed the device without a writable filesystem, write 1kB+ of > whitened random from your device into /dev/random early in boot, and > you will be good to go. You can do the ongoing trickle after that if > you want, but it is not necessary. On FreeBSD 12-CURRENT, you can > verify /dev/random is seeded when getrandom(..., GRND_NONBLOCK) no > longer returns -1 with EAGAIN errno. If you need to use a FreeBSD > prior to 12, you'll know random is seeded when reads no longer block. =20 Thanks for that. Unfortunately we=E2=80=99re in a read-only situation. = And we=E2=80=99ve had CI testing yield identical results a few times = now. Dw.= From owner-freebsd-hackers@freebsd.org Thu Jul 12 18:36:04 2018 Return-Path: Delivered-To: freebsd-hackers@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 E0E6910319C3 for ; Thu, 12 Jul 2018 18:36:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD8477D9D for ; Thu, 12 Jul 2018 18:36:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2C07310319C1; Thu, 12 Jul 2018 18:36:03 +0000 (UTC) Delivered-To: hackers@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 09B8410319C0 for ; Thu, 12 Jul 2018 18:36:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DB4077D96; Thu, 12 Jul 2018 18:36:02 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x229.google.com with SMTP id l123-v6so21087606pfl.13; Thu, 12 Jul 2018 11:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uk7Pd6fZDrtkZ1f+VqJVJy74756c+CFwNCaiF1HiO2E=; b=vJZX0pbYjttRG3VvZ6I0OjH7UA9xpBK1e7T15H7dbWdF/C4FOSzmebgSNL4877+BTS mqC0mJkv7EMLxnhpJ6ZAWwTjOULscZ/tRBLWD5nk1lxlAVfeca7RBaUErdmgjaQAaQJQ PqmeiyOaRhXtIbTa73ctACNEY+nW4iD62Egj9aWjESjk0u5ZzSGUF79Qo2oGu0W5p1IH pwJaB4emxQTuuCere3vpzrDBpQu71TsOEjCr/KheLlYZNoCvlXjXmHMctCGWSpjt5xQA ywyOeUZToWHCzmXT9grHoVrFSJahEDaL6wCcsfv6uCsDcZBUAEoJKxVqEt1UPm2oObo4 /TyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=uk7Pd6fZDrtkZ1f+VqJVJy74756c+CFwNCaiF1HiO2E=; b=uQ6OkufDsSHIQQR+i1PFiSJaHGWcMhHfMIGE/gDU0T26yKzEWIITI1BkUOia9fwXMp ummgkruw4fpau72o8tazK9RxjNF+P61JbnhLtro5XMIzTB3bKG+JI/eWxKlxYDiVyuMd 6n8hhL+YQIbnb+xDczmCzkO+TlmXpv46arjZt2slSvgD72rhj4UWh9t+cAMlkIn2lZyh CltyeXBjnF0eGs7MWr5KHbr1Z+RhcrqxptN4FTxtiyNekBwwxo4dmsBdOajdsEFCY7DZ lmmUmZqOzVfWC0jhl1n/jeFM/CpZ4GVj22TLjLQj+MmBN+nP0nFNT3Jfmh8bT+rF1C2j fwlQ== X-Gm-Message-State: AOUpUlF6/4r6T9bGVj+hloh7JawFeMBRWSxl6TBo1ycpcqeKFQMkrXaW XVp85hMyw7HdARwhmye1sWLDJg== X-Google-Smtp-Source: AAOMgpegDXVeHjouu+AUbvsgCDJfzx+gpFZqYDEpsFg0dLeMng3mCANdt2PXfYY/nkR6qiA1ka73FA== X-Received: by 2002:a62:c991:: with SMTP id l17-v6mr3596135pfk.10.1531420561135; Thu, 12 Jul 2018 11:36:01 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-107.dsl.bell.ca. [70.52.224.107]) by smtp.gmail.com with ESMTPSA id d9-v6sm31043987pfb.86.2018.07.12.11.35.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 11:36:00 -0700 (PDT) Sender: Mark Johnston Date: Thu, 12 Jul 2018 14:35:57 -0400 From: Mark Johnston To: John Baldwin Cc: Alexander Leidinger , hackers@freebsd.org Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? Message-ID: <20180712183557.GD15892@raichu> References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> <20180712143118.GA15892@raichu> <6858738d-7eef-cc0f-10bd-900fb822fecd@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6858738d-7eef-cc0f-10bd-900fb822fecd@FreeBSD.org> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:36:04 -0000 On Thu, Jul 12, 2018 at 09:09:02AM -0700, John Baldwin wrote: > On 7/12/18 7:31 AM, Mark Johnston wrote: > > On Thu, Jul 12, 2018 at 02:14:09PM +0200, Alexander Leidinger wrote: > >> Hi, > >> > >> the crashinfo script doesn't know how to handle compressed coredumps. > >> What would be acceptable behavior (ordered by my preferrence)? > >> 1) decompress in /var/crash and then proceed normally (already > >> implemented locally) > >> 2) decompress to CRASHTMPDIR:/var/tmp/xxx and delete when finished > >> 3) keep it like it is > >> 4) teach tools to understand compressed dumps (gzip / zstd) > >> > >> Implicitly there is the question what what is the purpose of > >> compressing crashdumps, to have more RAM than space in dumpdev (which > >> is valid in my case), or to save space in /var/crash (which I don't > >> care much about). > > > > I think jhb has a patch which implements 2). I do not have strong > > feelings on which is the right way forward, but I mildly prefer 2) to > > 1). It looks like crashinfo can be disabled in rc.conf, so users who > > are space-constrained in /var/crash can take the additional step of > > setting crashinfo_enable=NO. FWIW, when I committed the compression > > support, my use-case involved both a small dump device and a small > > /var filesystem. > > Yes, here's the patch for 2 which has been tested. 4) is pretty hard > to do in practice as you have to basically decompress into RAM when > reading the core to do anything useful as opposed to a format that > only compressed certain parts (e.g. if the page tables were not > compressed only the payload in a minidump, and if it were compressed > on some kind of block boundaries so that you could locate a given > block and decompress it when reading specific data). Coming up with > such a format would be more useful but requires more work. That patch looks ok to me, FWIW. As I pointed out, it's easy enough to just disable crashinfo if one doesn't want the extraction to take place. From owner-freebsd-hackers@freebsd.org Thu Jul 12 18:48:28 2018 Return-Path: Delivered-To: freebsd-hackers@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 CE9E91033181 for ; Thu, 12 Jul 2018 18:48:28 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6562178E45 for ; Thu, 12 Jul 2018 18:48:28 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f169.google.com with SMTP id q4-v6so29154279iob.2 for ; Thu, 12 Jul 2018 11:48:28 -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=uB6PjrapvHM190CsljEPKX5y3eVQLJuaJsU5Jl/Yd/s=; b=ANR6yegySLK+Rl+frz8QuRgRauSkMyxUtk2QO78gNxkTlAJ3tmzSq4ngFo4zWQ5HaX XLTkZ9crExwgdb+p3cxtxTHF3v5xKdmw9EFs2GagaWneUSw5ucnEDx0dzIFY4+b7qtO6 8zOnZMBxuP7x8OmQR97KXqn6pp+T3f0KZ22xi2Tqwa/EsqxhR6WtbyvPFDh02QF2dlJ2 2WgUYR0+XrHKyY8+EzZ1Koc/s3RLxUf4WZNxrks4kmCVXN3Xat/uEyxrgLxl23WoKg9p mg7yKdnFZXuYkLJRld8X3bklG4ogTyqDXJ33Z+UTR1juQEw4hQsjLEt+fE2YqT6YCkAn 6urA== X-Gm-Message-State: AOUpUlEslatkLUFcmkmdIXHrX4CGcYIpJjb+LcUtsNuVzqVQ5C01htla Vvgu45FfNIlRWIHKY2zcQxVOoKUa X-Google-Smtp-Source: AAOMgpeHtOonLsPi9Rhc4yV+CI8XxsJtzKZOzuglvlhI94pdsuKjo6RYJm75gQa06I0kyruaj+5oCA== X-Received: by 2002:a5e:c60d:: with SMTP id f13-v6mr10289686iok.197.1531420849629; Thu, 12 Jul 2018 11:40:49 -0700 (PDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com. [209.85.223.173]) by smtp.gmail.com with ESMTPSA id r199-v6sm3432328itb.8.2018.07.12.11.40.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 11:40:49 -0700 (PDT) Received: by mail-io0-f173.google.com with SMTP id q4-v6so29134311iob.2 for ; Thu, 12 Jul 2018 11:40:49 -0700 (PDT) X-Received: by 2002:a6b:4e04:: with SMTP id c4-v6mr18980476iob.19.1531420849376; Thu, 12 Jul 2018 11:40:49 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 11:40:48 -0700 (PDT) In-Reply-To: <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> From: Conrad Meyer Date: Thu, 12 Jul 2018 11:40:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Limits to seeding /dev/random | random(4) To: Dirk-Willem van Gulik Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:48:29 -0000 On Thu, Jul 12, 2018 at 10:42 AM, Dirk-Willem van Gulik wrote: > Is there any point - much later post boot, in a non-network, read-only si= tuation with essentially just 3 or 4 user processes running with no IO or i= nteraction - to send some entropy (withewashed (or raw with random_harvest_= queue()) to wards the PRNG ? > > Or is that pointless from thereon. It isn't needed, but it doesn't hurt either (barring elevated CPU use from excessive feeding). > On 12 Jul 2018, at 19:32, Conrad Meyer wrote: >> /dev/u?random never produces unseeded results. If it is not seeded, >> reads will just block indefinitely, until it is seeded. > > As we=E2=80=99ve found out the hard way (although we are not sure it is i= ndefinitely). It is indefinite, until seeding. Maybe signals can interrupt the wait, but you should be checking the return value of read(2) of /dev/random. >> To seed the device without a writable filesystem, write 1kB+ of >> whitened random from your device into /dev/random early in boot, and >> you will be good to go. You can do the ongoing trickle after that if >> you want, but it is not necessary. On FreeBSD 12-CURRENT, you can >> verify /dev/random is seeded when getrandom(..., GRND_NONBLOCK) no >> longer returns -1 with EAGAIN errno. If you need to use a FreeBSD >> prior to 12, you'll know random is seeded when reads no longer block. > > Thanks for that. Unfortunately we=E2=80=99re in a read-only situation. An= d we=E2=80=99ve had CI testing yield identical results a few times now. Identical results are very troubling. Maybe your readonly filesystems contain a static "entropy" file that is being fed in every boot (with identical contents)? If so, you definitely want to remove that during image generation. That, in tandem with few other sources of entropy, could explain identical results. Another thing I would suggest is taking samples directly from your random device and running them through https://github.com/usnistgov/SP800-90B_EntropyAssessment to sanity check their randomness. W. Dean Freeman did some great work evaluating random sources in FreeBSD within the last couple years; you can check out his work here: https://github.com/badfilemagic/fbsd-entropy Best, Conrad From owner-freebsd-hackers@freebsd.org Fri Jul 13 13:51:54 2018 Return-Path: Delivered-To: freebsd-hackers@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 94652103D18C for ; Fri, 13 Jul 2018 13:51:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F70C86CBE for ; Fri, 13 Jul 2018 13:51:54 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: e160cb0e-86a3-11e8-8837-614b7c574d04 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id e160cb0e-86a3-11e8-8837-614b7c574d04; Fri, 13 Jul 2018 13:51:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6DDpiau044324; Fri, 13 Jul 2018 07:51:44 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1531489904.66719.43.camel@freebsd.org> Subject: Re: Limits to seeding /dev/random | random(4) From: Ian Lepore To: cem@freebsd.org, Dirk-Willem van Gulik Cc: "freebsd-hackers@freebsd.org" Date: Fri, 13 Jul 2018 07:51:44 -0600 In-Reply-To: References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 13:51:54 -0000 On Thu, 2018-07-12 at 11:40 -0700, Conrad Meyer wrote: > Identical results are very troubling.  Maybe your readonly > filesystems > contain a static "entropy" file that is being fed in every boot (with > identical contents)?  If so, you definitely want to remove that > during > image generation.  That, in tandem with few other sources of entropy, > could explain identical results. I have been reporting for years that certain kinds of embedded systems lead to zero entropy available at boot, including the fact that the kernel's attempt to harvest entropy from things such as device attach timings and so forth are, in some situations, completely ineffective and yield numbers that are identical from one boot to the next. I even posted logs of it happening years ago. Still, people just find the whole idea of this sort of reproducibility so gut-level counter- intuitive that they dismiss and deny it. It happens. Embedded systems are a different world, and if entropy is important, sometimes we have to go out of our way to provide some. -- Ian From owner-freebsd-hackers@freebsd.org Fri Jul 13 15:13:11 2018 Return-Path: Delivered-To: freebsd-hackers@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 3A7BB1040084 for ; Fri, 13 Jul 2018 15:13:11 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weser.webweaving.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B16818A81B for ; Fri, 13 Jul 2018 15:13:10 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id w6DFBpBY084822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Jul 2018 17:11:52 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Limits to seeding /dev/random | random(4) From: Dirk-Willem van Gulik In-Reply-To: <1531489904.66719.43.camel@freebsd.org> Date: Fri, 13 Jul 2018 17:11:51 +0200 Cc: cem@freebsd.org, "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <84E1C233-5855-43DC-BC58-CAFFA216D1D7@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> <1531489904.66719.43.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Fri, 13 Jul 2018 17:11:53 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 15:13:11 -0000 > On 13 Jul 2018, at 15:51, Ian Lepore wrote: >=20 > On Thu, 2018-07-12 at 11:40 -0700, Conrad Meyer wrote: >> Identical results are very troubling. Maybe your readonly >> filesystems >> contain a static "entropy" file that is being fed in every boot (with Most certainly not. >> identical contents)? If so, you definitely want to remove that >> during >> image generation. That, in tandem with few other sources of entropy, >> could explain identical results. I suspect this to be the issue. >=20 > I have been reporting for years that certain kinds of embedded systems > lead to zero entropy available at boot, including the fact that the .. > It happens. Embedded systems are a different world, and if entropy is > important, sometimes we have to go out of our way to provide some. In our case it is merely a low end machine - but diskless, read-only and = with hardly any perifials. Dw.=