Received-SPF: pass (google.com: domain of linux-kernel+bounces-121640-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 27 Mar 2024 13:38:32 -0300
From: Jason Gunthorpe <jgg@nvidia.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>, iommu@lists.linux.dev,
	Kevin Tian <kevin.tian@intel.com>, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] seltests/iommu: runaway ./iommufd consuming 99% CPU after
 a failed assert()
Message-ID: <20240327163832.GJ946323@nvidia.com>
References: <0d5c3b29-fc5b-41d9-9556-5ce94262dac8@alu.unizg.hr>
 <20240319135852.GA393211@nvidia.com>
 <a692d5d7-11d5-4c1b-9abc-208d2194ccde@alu.unizg.hr>
 <cdc9c46b-1bad-41cd-8f98-38cc2171186a@oracle.com>
 <20240325135207.GC6245@nvidia.com>
 <f8e03425-98cf-4076-8959-d85eda846bab@oracle.com>
 <20240327114029.GC946323@nvidia.com>
 <ab5d2b61-2dd2-46d6-a106-a9aea69b0a1a@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ab5d2b61-2dd2-46d6-a106-a9aea69b0a1a@oracle.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?N1R0TzF2M2FCSVRsbzN0bHJVd3p1eDc1OFp3cG9TM2t6eHRqb0hMVEtjNkp3?=
 =?utf-8?B?UUdCZnZGZlJ4THY5V0hmTWsvK0sxbm9Qcml1Q1VNb2llOXhQcGFXNnpFOU5z?=
 =?utf-8?B?S3k2c2xacmpSRkxpdVdVQ1BsbG1yOGduVDF2ZjFhd1kvN3ZHNXFrb0RWQzBx?=
 =?utf-8?B?RjZvZ05NeXA2dWtlaWZDRm05SitERGV2aGh1UVk3QTRvemtvam5DbFBRTXZK?=
 =?utf-8?B?ZW1yVS95Y1gwS09YR3QxdmlLK1BRdWk3Ymx6cm5XT2hPU2JNc0ZrbFh4RU9F?=
 =?utf-8?B?eFFTVWx3SVFHcjVLb2xnZGI2aENyc1BnTXdpTTVXblM1Vk9xS2VnKytpdkxG?=
 =?utf-8?B?WTBpNkNVVzZjdDNxRjNKc2hXdjlocDA0d0FEek5xUUI5bzhVZmFnYmljRGdo?=
 =?utf-8?B?T2FneTZpMUVqNXRWbW1DVTJMQW1ZdmxWN0Q5dXpSNXd5ZWVjaW9vRmNhK0lZ?=
 =?utf-8?B?OE5QT05GdCtVMEZVYW51eHJCOTdLb2FOZUQ5Y1R3MVMzLzJYTDZRdUhiK0JB?=
 =?utf-8?B?NE1CL1RZc05JWDhDcWt1eGpZWU5FelBkdTJGR1l3OE5OOTJJUjJCT3I5OWhm?=
 =?utf-8?B?QzFvT3NmZWtLbFZ4c05sajk5RTV3ZEFBQWptZFZxZWJyQ2FlMi9INHdRQzF4?=
 =?utf-8?B?bjlNc01BU25KcStkL285YjdJUWdBd2J1VCtFUmJVSlhMS2VOYmhST1dyQmVY?=
 =?utf-8?B?UmVxNjZvbkhzS1BYWktRZlhwTnBrOG9STUU0QVFvd0tBNkVpVVRKWDFmb1NR?=
 =?utf-8?B?NEFoNTkvMldkeEtLWUV1UjlzQ0w1VlRzOWZGVXd4N1c4RDRDd3k0ZlZsRzJO?=
 =?utf-8?B?TmZDTFg2WUs2QXJFWksxUUtsWXpMc2l1aUE3R0JIY1hVRzBxUThFdk5UY0w5?=
 =?utf-8?B?dlZOeEt5M2JKV0NMcXhRM0RmSUZqWkZ0YVplUTN4V2h0UmI0YzNXcWt5alJ5?=
 =?utf-8?B?NS9rRGt1RTlpWnVXRWo1Qnl0Qkp6YUVFS1pCRlhaYU1TYWVWRXIrcUtEN1VS?=
 =?utf-8?B?VkcwVWs3cG9xZGl1REhsQmxZejNWc1pkN2dNdEhtR0g2a2hLS05DdWZORWF5?=
 =?utf-8?B?WUhJdkdHVldMdGNpajNwN0lOaHp4MXNTdHI4d3pONVdtSnhUakFKQlJWdXdP?=
 =?utf-8?B?VVlrTlo0MTZUazRyRG1hZFdVK1Jzb1hRaSt3UGFwT1NJekRXU1RLR2ZiMzV2?=
 =?utf-8?B?TGpiakhzendkbWgreXJXR3NIRFRFL3ppT3BGZU1lMFhsSldzRmdseHIyUjZs?=
 =?utf-8?B?Tzc0Vms3RThpVUhCbnlUaXlrdDgrU0Z3NXZSQ0c1WjhqSWp3WndZaTB3eHdu?=
 =?utf-8?B?elkyNTREajdzL011c3R6Tm8wSXVnSkJFMDIrSmFjUFh3SzQ3b0REN3RLZzNk?=
 =?utf-8?B?STVPSFE2U1ptbGhnOEdGdWZydUsyU2wvelBkR2lnRVh3VDhXTENMTWU3N0lI?=
 =?utf-8?B?dkNjb3ExY2dLK3E0aGZDdUwvNTkvRXBtbmdQT1dtNWhzZ0VkclY0ak1SNTIv?=
 =?utf-8?B?am93NHQ1c3JHU0FXeHc4aFBwdWNJMUJQZFNEVzhyazRSaTdPUGQySWRIdzFM?=
 =?utf-8?B?akRDdk9WZmE1T01NbHpVQUhBN083QW9HV1pDdFRtQmFkSEhIQUw3bEJvdUpo?=
 =?utf-8?B?NElyM0piQWdRVGpodTJOQVZPazd2cWVuUmxEZFZtN3ZiL0Q3R09JeUVJRy8z?=
 =?utf-8?B?K084SUFOZ3c5Zy9nV05uUENCbnFyWS9iT2tJTGRnYnpza241TWxLMWFKbit5?=
 =?utf-8?B?R3dYMk9BWC9XWGNhODVtdDQ0RWxyclcwMXF4a3drOWszWi94Q3V6QUNQcllE?=
 =?utf-8?B?ZTdjVkxtOEFKVGVWYkM3cU9qRUErbDdMTVlSRzVhRkI2NjhoNUFyR1d4bTI1?=
 =?utf-8?B?MU5vR01TckRHTU1heWREZ0U0TUQ5M0crVzNMWW11WjVQNXBUWlZmbm5hb2g3?=
 =?utf-8?B?WTZ6TTcrQ1VGOUN5WDc3bWgydWU3ZUNPQXBBQ3dWMSt6dFlHcGh1SnUxaVBj?=
 =?utf-8?B?b2g5WThwZnV5MWtPaFVSVkhQdlI0TWVMTzNwTlE0QmRXMUExNXB3WHZ1OFRn?=
 =?utf-8?B?SzdXd2M5ZDlpNElKNDdSZ1lpY1lWRGwzQittZlRBV1RIRDM5a2tOK3hEY0VE?=
 =?utf-8?Q?gN+7LiqhNrlzqDox2eMHMGPHn?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03815655-e20f-493a-1677-08dc4e7c57f6
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2024 16:38:33.9469
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Lt1iB+osJJeiC44QaFEzvjO4muDasZ5occK8BAY5b72OgCmzOJiM5xlAYW/+Exi8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4253

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.

Jason