Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp891552yba; Fri, 26 Apr 2019 10:27:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqzTTj8EZWf+c3/hye6TBxk80wAPf4+Atrbbu4XoDNyDEDlKFsK9bJTdkRKp3K2qlV8kbYnt X-Received: by 2002:aa7:820c:: with SMTP id k12mr48159073pfi.177.1556299636050; Fri, 26 Apr 2019 10:27:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556299636; cv=none; d=google.com; s=arc-20160816; b=D5QsDdYGQtWKEXNdQ+lFpoRPQ2hDTwWyPurgr5lzMzQ3SQs9vZO6MJtQMk/JI0shok zsiIbj9hMJIbkWk4UVo3zE492cfCQsVfTq9R9YZGFvwXt8HX/yvIup8sL+k4hbvUU3gh l+Z9azSLkZaMGIA8dFruJN6bug/4Qj46t/ptOghoWG4HVs9wMO95ttZtzBMtFKlAS5uT h1UXQEVzTrZWdgVzJ3Lps4BmDzRBZRJnGz3HT/S8YuFaFuIjsaor24O4JPG7kmD4T0Pk Q/+jpHAcApVVTaF4Kbv27WZTf12uerLoPnpa7w2PJ1VTyTkuNEwEdXMrX6ylgsRp/fgT f4Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=0R0zKKad1LluAuAg+aebvByAUW+gKKtAQn2bc3N5PBk=; b=lOB+u8zFhU2znY+3ZAN05paHmGf4aAO5RB/b7JbM0y2C6yjoJrZArKsJueQW+6M5+0 194+ZJgTTn9kTookkVicn3e9uxN+zGN4j2erH0qzMIWOuSfkNkgyHh+NynDjT2sOMGrS E788E0eVRu/7Iix3JWTTjSfGXJpswWgnoBwjEUmFP3FbWklAji7/p2MiJCIOYfHXHjoV TCyRKlFV+wdkPlHDdcEbJw1VvZjXEsYqMsYMdhYHMKKU9lWC2d4Df0kVGEETXx4N9HVj ZwtXEVUzNS8NQcmM+gGZFdWmgfNmAx+wZ2YAxGs9cvgkm/+f2g6T4vNanQgWVrTIfuIq vz4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="R6U/Yor1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a20si8503394pgk.90.2019.04.26.10.26.58; Fri, 26 Apr 2019 10:27:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="R6U/Yor1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726253AbfDZR0G (ORCPT + 99 others); Fri, 26 Apr 2019 13:26:06 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:46839 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbfDZR0G (ORCPT ); Fri, 26 Apr 2019 13:26:06 -0400 Received: by mail-pf1-f195.google.com with SMTP id j11so2025832pff.13 for ; Fri, 26 Apr 2019 10:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0R0zKKad1LluAuAg+aebvByAUW+gKKtAQn2bc3N5PBk=; b=R6U/Yor1OJkJyD71Twn7FGvpzVbGMhBazytbC3VNUXEY1uAXvIoLhg3yDyMCUSTaKS 4h4gfSGMZ8Apcw7m0pTqhFANCL8EtLUz4gpJuv+4idLW/Soa4eF7Qeq8qYhrkksZ9TAP z5AD429/1jfxqVC406MgRJwx/yLWVpZ5/KJxg= 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:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0R0zKKad1LluAuAg+aebvByAUW+gKKtAQn2bc3N5PBk=; b=GKo8jzTvQ5ts8wyAYgMZ7xHGtVBXHa9/yU71bpCzxQoqmuVBbNthOcnW8yDRtBImhH QmNCNskHXhrRqYWDrVwTrVKu6isdbpxaFI19mOT7oJ8NCon9/wVo0rTPqok+ekhZ5kgo hjOW3W8acMJu5IPLU0VExo3YsVUMccbUHo352ASICet4Zhhf/OMtItcweBkZ1fe7x4aA YTDTIbQBPwvQJo9Hd41nHnxUy0gxMjEqJXpmWdn90iKyPKk5bNfy8W2QQhHsxmrVhaKa zaB8uwBum0+eeDkaxpV8odgORgwdzA1NRuM6MHA0MGlc5pTOLnC8S4IIYwxSuDMNAy64 PXWQ== X-Gm-Message-State: APjAAAW6nwt2CaY4k82ECo0dXTflF0xhnxpYH5w4X8GeXpPlpPZhYc4I K9BA0WqWy007Klu2nxYwOFSKKg== X-Received: by 2002:a63:d349:: with SMTP id u9mr42447261pgi.83.1556299565072; Fri, 26 Apr 2019 10:26:05 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id n26sm48563567pfi.165.2019.04.26.10.26.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 10:26:04 -0700 (PDT) Date: Fri, 26 Apr 2019 13:26:02 -0400 From: Joel Fernandes To: Daniel Colascione Cc: Christian Brauner , linux-kernel , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Greg Kroah-Hartman , Ingo Molnar , Jann Horn , Jann Horn , Jonathan Kowalski , Android Kernel Team , "open list:KERNEL SELFTEST FRAMEWORK" , Andy Lutomirski , Michal Hocko , "Peter Zijlstra (Intel)" , Steven Rostedt , Serge Hallyn , Shuah Khan , Sandeep Patil , Stephen Rothwell , Suren Baghdasaryan , Thomas Gleixner , Tim Murray , Linus Torvalds , Tycho Andersen Subject: Re: [PATCH v1 2/2] Add selftests for pidfd polling Message-ID: <20190426172602.GD261279@google.com> References: <20190425190010.46489-1-joel@joelfernandes.org> <20190425190010.46489-2-joel@joelfernandes.org> <20190425212917.yotnir4uqgpnh764@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 25, 2019 at 03:07:48PM -0700, Daniel Colascione wrote: > On Thu, Apr 25, 2019 at 2:29 PM Christian Brauner wrote: > > This timing-based testing seems kinda odd to be honest. Can't we do > > something better than this? > > Agreed. Timing-based tests have a substantial risk of becoming flaky. > We ought to be able to make these tests fully deterministic and not > subject to breakage from odd scheduling outcomes. We don't have > sleepable events for everything, granted, but sleep-waiting on a > condition with exponential backoff is fine in test code. In general, > if you start with a robust test, you can insert a sleep(100) anywhere > and not break the logic. Violating this rule always causes pain sooner > or later. I prefer if you can be more specific about how to redesign the test. Please go through the code and make suggestions there. The tests have not been flaky in my experience. Some tests do depend on timing like the preemptoff tests, that can't be helped. Or a performance test that calculates framedrops. In this case, we want to make sure that the poll unblocks at the right "time" that is when the non-leader thread exits, and not when the leader thread exits (test 1), or when the non-leader thread exits and not when the same non-leader previous did an execve (test 2). These are inherently timing related. Yes it is true that if this runs in a VM and if the VM CPU is preempted for a couple seconds, then the test can fail falsely. Still I would argue such a failure scenario of a multi-second CPU lock-up can cause more serious issues like RCU stalls, and that's not a test issue. We can increase the sleep intervals if you want, to reduce the risk of such scenarios. I would love to make the test not depend on timing, but I don't know how. And the tests caught issues that I had in my development flow, so the tests worked quite well in my experience. thanks, - Joel