From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05AD517E for ; Thu, 28 Mar 2024 00:05:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.166.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711584350; cv=none; b=S103AygqIbbysuyHsXo8fcQ11af+EFnxnudBMeCtZllZsDjc6YnrA62BudS0bB4NO8CXCyncVvUEZSUWWhjTnWtXlQp28Pi71VkgzKcSDCnBXZAK3ZO5zfqNo0fhAyFsW34YKtx9mtc2Ci98Lvms1KDIsllLv0wdcoCDcw++XqY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711584350; c=relaxed/simple; bh=UTFyWoS2y5wH6iR9AcEHg/ju7M8hZpmsWIUw0geaDIg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LtoCDSVu84L9Z3hdPH+ure0q9hWTRRiOMl+knbTy0vP4EDFHD6w02y+WxGOXRD4OH70lqjyRfGev4UftkCp0r8UqCc697/qVk9fhWRfmUNMtvD1m8JgBrJ7aVmG69gHCrVnCgMmDUikpdgZb4zS9IXV+vSZ+7aO/sNfuzL2NUy0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=GlYgy2ek; arc=none smtp.client-ip=209.85.166.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="GlYgy2ek" Received: by mail-il1-f176.google.com with SMTP id e9e14a558f8ab-3688f1b7848so612635ab.0 for ; Wed, 27 Mar 2024 17:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; t=1711584348; x=1712189148; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SCTMIq8WtfXbFIqQEZh1qfZYEzZdHCH9y3zHSAgcufU=; b=GlYgy2ekBWL+8zD1oMJ57If38ZN9Fg8igjwy0+IWRFuIKi3rwbo6W9lmj5hSkLwqaE AL9WbjKK/p8pVHOdycBvIA/9UfnGgcEQtgkzTWJyZlwTgMGrMEdf88+SEZGdMz8QFgcs E7p+Gl/qmuBDxL5GFz5sYvA4bSoLIrtViGRlU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711584348; x=1712189148; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SCTMIq8WtfXbFIqQEZh1qfZYEzZdHCH9y3zHSAgcufU=; b=ri1csZs7y6DdUxT+zt0GYanmIhzqQSfkEDCV0gQRdi4A2qFrEsRRQBpxs2xIdirFdg Fo4uHeAMypMq6I4OtkOXA83r3Ua5o1x6YJhysdsrTozrz8hRCLlHhPUc3x43VThUEp5b gj+9e3h8d10+eHSvR5tboBrezUaQ/nagFyJVBku5X8TLqloPTfWdB94La6gFxCp8HBNx jFmg1O3cmFYaeKOopLfHosvrBNU2tsAvGZuNhcx7otF4TnKfOe2211uKWDEtNmtFeGzV kmdyy3QUcO8kbcyrkHIXGb/Z62p4V4Gk7Gq/DCJq6nsH74jRCoM2EuyMaAkqktVlaI0J UI+A== X-Forwarded-Encrypted: i=1; AJvYcCWLDEFnMidzvmuGjNBVh4UoXFKixgNvkR/+DiSyEfgeJHn9zdXbuNnWQ585k03f/WJbf0JDTPIKiH0YNw6/Oz/06Wlz5bQz/ixYAhRl X-Gm-Message-State: AOJu0Yy/VrOjRL9uVVg5A/AAX8y1CokyOtaSqe45FpvhA6c8zvplN3FG GeO5LBVQ92sOogKkFMTtnY1sdlvEY2p/kUMaJ5lT4psAmKwg4wDE5BKeSva30/E= X-Google-Smtp-Source: AGHT+IFDM3R/PlIPv7Hx0hHfbsCS5Kf6sx6RMyDmHA0pdbH7D4okpLEyaqSJhoa1zGqNlJk0CdVgmA== X-Received: by 2002:a92:c645:0:b0:368:80b8:36fa with SMTP id 5-20020a92c645000000b0036880b836famr1540423ill.2.1711584348147; Wed, 27 Mar 2024 17:05:48 -0700 (PDT) Received: from [192.168.1.128] ([38.175.170.29]) by smtp.gmail.com with ESMTPSA id u17-20020a92da91000000b00368706996b8sm69730iln.38.2024.03.27.17.05.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Mar 2024 17:05:47 -0700 (PDT) Message-ID: <24c54707-421f-4c5b-8a34-245328cad347@linuxfoundation.org> Date: Wed, 27 Mar 2024 18:05:46 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] seltests/iommu: runaway ./iommufd consuming 99% CPU after a failed assert() To: Jason Gunthorpe , Joao Martins Cc: Mirsad Todorovac , iommu@lists.linux.dev, Kevin Tian , Shuah Khan , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Shuah Khan References: <0d5c3b29-fc5b-41d9-9556-5ce94262dac8@alu.unizg.hr> <20240319135852.GA393211@nvidia.com> <20240325135207.GC6245@nvidia.com> <20240327114029.GC946323@nvidia.com> <20240327163832.GJ946323@nvidia.com> Content-Language: en-US From: Shuah Khan In-Reply-To: <20240327163832.GJ946323@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/27/24 10:38, Jason Gunthorpe wrote: > On Wed, Mar 27, 2024 at 03:04:09PM +0000, Joao Martins wrote: >> On 27/03/2024 11:40, Jason Gunthorpe wrote: >>> On Wed, Mar 27, 2024 at 10:41:52AM +0000, Joao Martins wrote: >>>> On 25/03/2024 13:52, Jason Gunthorpe wrote: >>>>> On Mon, Mar 25, 2024 at 12:17:28PM +0000, Joao Martins wrote: >>>>>>> However, I am not smart enough to figure out why ... >>>>>>> >>>>>>> Apparently, from the source, mmap() fails to allocate pages on the desired address: >>>>>>> >>>>>>>   1746         assert((uintptr_t)self->buffer % HUGEPAGE_SIZE == 0); >>>>>>>   1747         vrc = mmap(self->buffer, variant->buffer_size, PROT_READ | >>>>>>> PROT_WRITE, >>>>>>>   1748                    mmap_flags, -1, 0); >>>>>>> → 1749         assert(vrc == self->buffer); >>>>>>>   1750 >>>>>>> >>>>>>> But I am not that deep into the source to figure our what was intended and what >>>>>>> went >>>>>>> wrong :-/ >>>>>> >>>>>> I can SKIP() the test rather assert() in here if it helps. Though there are >>>>>> other tests that fail if no hugetlb pages are reserved. >>>>>> >>>>>> But I am not sure if this is problem here as the initial bug email had an >>>>>> enterily different set of failures? Maybe all you need is an assert() and it >>>>>> gets into this state? >>>>> >>>>> I feel like there is something wrong with the kselftest framework, >>>>> there should be some way to fail the setup/teardown operations without >>>>> triggering an infinite loop :( >>>> >>>> I am now wondering if the problem is the fact that we have an assert() in the >>>> middle of FIXTURE_{TEST,SETUP} whereby we should be having ASSERT_TRUE() (or any >>>> other kselftest macro that). The expect/assert macros from kselftest() don't do >>>> asserts and it looks like we are failing mid tests in the assert(). >>> >>> Those ASSERT_TRUE cause infinite loops when used within the setup >>> context, I removed them and switched to assert because of this - which >>> did work OK in my testing at least. >> >> Strange because we make use of ASSERT* widely in our selftests fixture-setup. >> >> setup_sizes() is run before the tests so it can't use ASSERT macros for sure; >> maybe that's what you refer? > > No, it was definately ASSERT/etc if you hit those in the wrong spot > the thing infinite loops. Maybe that was teardown only. > By adding assert(), you are mixing frameworks and the overall test behavior will not be consistent. ASSERT_*() is supposed to exit the test right away. If this isn't happening it needs to be debugged. There are several tests that use this framework. Maybe you can refer to another test for examples of how to use the framework. thanks, -- Shuah