From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C1ABC2BD09 for ; Thu, 27 Jun 2024 19:31:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB7A76B0096; Thu, 27 Jun 2024 15:31:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C66AC6B0099; Thu, 27 Jun 2024 15:31:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B07566B009D; Thu, 27 Jun 2024 15:31:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8F8DD6B0096 for ; Thu, 27 Jun 2024 15:31:13 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3C1CC81073 for ; Thu, 27 Jun 2024 19:31:13 +0000 (UTC) X-FDA: 82277662026.02.1A68412 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf05.hostedemail.com (Postfix) with ESMTP id 49B9A10000E for ; Thu, 27 Jun 2024 19:31:11 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gLia6muB; spf=pass (imf05.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719516663; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ny6HkmE+qY2SG56r9G2DPsCtupADeB7549mmgxbkcn8=; b=crjoEi/iYFRskc9PYkJKcLa51zU7QH78D8EZdyK0GPYc75JwRkobVFUBkm/bLewKnEND0m 0E99cJZYQfpkhg0B7TdazBjiuerqFc07rtCGRgFj+4nrU3/resHvxETDzoTKNKw/NUDzzc GQl37ppvDGzVj7GmzsRQtm4qFNLn0d0= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gLia6muB; spf=pass (imf05.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719516663; a=rsa-sha256; cv=none; b=gzKj75cltM1i0o8YcrqpR7m2tWo0sQX6cEpB48gfWcvw6AYuKcMvSvn6ET32cLAW/y86sM y+Pr3FQ1kFTDhuMZmRU86vQJJXVD3c6rjR/q9/rJHsukaROBSJOlJv62gsnUCJHUJPYrCr J5V+MHQOAsCuuaI4eoSnC45zHM0RPD8= Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-42562a984d3so13047795e9.3 for ; Thu, 27 Jun 2024 12:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719516670; x=1720121470; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Ny6HkmE+qY2SG56r9G2DPsCtupADeB7549mmgxbkcn8=; b=gLia6muB4exLfbkXGviygMJaOhpqEDmgGSi18UYeuDQ13nYDKZZ97NlIORq4cLCVnS wiiXg6vShROuoEJD2RwgZm0Ubyn10uhkaNLBVyDpuZbbbeAenYwYLQm0AaeHKQM5UBI7 zOLcrNzwSuHkZDsHfFNANmh3VesBhbN6caXtnoyV+rWewJYQv48DjTFrPbOWrFr7Kl4Z 8se8thoeteToiQNySD3PvLRr/HHJyM5CZCozatlSlZqD+jJ7rOG4HthI8DxFkUJk03Sx mr66kFdPnGQMPjEzsFAAc7rl3lkK9JQgavybfYZNdazsV0TMGYasT2GNYjO3NfB/8RUD nLJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719516670; x=1720121470; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ny6HkmE+qY2SG56r9G2DPsCtupADeB7549mmgxbkcn8=; b=dMVdcoAxxrfV9TZo0iRk+sefB341TVyLbKphEYOrodVTJbcaDTysAn6y/wVGoAX+v0 9+rnmolHoElu7Qeov1SMwe/Ewvc0lkiDS0Koz2Itkx2Tr88XRz4v82P1F4SE57UZzjwH 31IyIClWr/l5cTzesR8BhfK+jePveNX3RdL/dtGErK2EOqkDL0LU8DQNj2bF6KHrZgns UvtYnU/CLkC4b/Ewz20CYNgZVgc1eMY9IAT++9jLNSSF8m1+7tZ/zypNuVIw2NcBzVGr YIFUYKMNQNZF5UvdQdPDZ1H9MSyBahFjvdxOrA3uSCt2tqCA7Lc9hakRN+Kb2P7rLZIN NrWw== X-Forwarded-Encrypted: i=1; AJvYcCVb8a2UyaVdx39lEIRgyQwxpfAolsZsuzSzoxV5UEOpMiFSwbK9/mZp2G1BRKqecDzTkToR0yWPyHQjkdbiZgmxiBo= X-Gm-Message-State: AOJu0YwKjPzdz5XryEiw7cX8whg/vC4DkXyr+E35mPZJAO8XMolOUzdE DyMacOKaoQxWl5fPlPnrYj1ziROg2ZghOjTJnMD2H3+xUVqwb+iA X-Google-Smtp-Source: AGHT+IFdGRQfUdkuH5BgVEfuVw+NW9O3Tjn8vpqf3zKF2lgWTc6D8XAyOko55+jbazGHrKeARtK6gQ== X-Received: by 2002:a7b:c3d8:0:b0:424:a4ab:444f with SMTP id 5b1f17b1804b1-424a4ab464cmr56536255e9.33.1719516669623; Thu, 27 Jun 2024 12:31:09 -0700 (PDT) Received: from localhost ([2a00:23cc:d20f:ba01:bb66:f8b2:a0e8:6447]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4256af5ba67sm5239905e9.19.2024.06.27.12.31.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jun 2024 12:31:08 -0700 (PDT) Date: Thu, 27 Jun 2024 20:31:07 +0100 From: Lorenzo Stoakes To: "Liam R. Howlett" , Kees Cook , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Vlastimil Babka , Matthew Wilcox , Alexander Viro , Christian Brauner , Jan Kara , Eric Biederman , Suren Baghdasaryan Subject: Re: [RFC PATCH 7/7] tools: add skeleton code for userland testing of VMA logic Message-ID: References: <22777632a0ed9d2dadbc8d7f0689d65281af0f50.1719481836.git.lstoakes@gmail.com> <202406270957.C0E5E8057@keescook> <5zuowniex4sxy6l7erbsg5fiirf4d4f5fbpz2upay2igiwa2xk@vuezoh2wbqf4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5zuowniex4sxy6l7erbsg5fiirf4d4f5fbpz2upay2igiwa2xk@vuezoh2wbqf4> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 49B9A10000E X-Stat-Signature: o6f9f8n6rrphspmxnpsambydg6etb19z X-HE-Tag: 1719516671-69086 X-HE-Meta: U2FsdGVkX19A+qc/gOaMukwhpOEQSK7mrMDxq2xTct7ZO/RY1wmvluidOfmjFOei83/T6oR2M2o4pXQTdafxqSSZEhgrzz++IfeL6UISD+T9zChdouF8u2w+w6h1QUO5Pr6JEjI3oCD0Ko1IEwVXZmsSGHzFGi/LxcOGLfpNbbXOObxsSDy0wwv9UxE+qCfmtpPR9EqsEi7tZbSIB13+sqI8ISRbX/zKa7ROo8mQSt9DBj/BxEyhS1OBqa2qt9p07vMpCKkNdJwGsJWLQcERdfLWJ9dwpPIai4xKjYDj95MfD30/vvIw/nNrkJs7JSV9q8Moxjn9+ThLNlKD25vkl3+70fQvs/5lyJVF+SQVZqYB1LGnE6+r3V+TUsPKRTbvOYljxlz0mBbJiBfyf0vgMFJYrQZx/E6kJ4rYFpHu59yY96DAutcEKgZMEEKqA+syj4IIIcnxCDB84C81oURw/WBdfZc0CPqWxD2lfaLsxeCFAn/GFR0d5a3Swyg3VI2oqv1d7Ztx+KW/FPwxa7YWa5b0AnEv/Q5Q6aBbOaoGcnxWqrIJXQyFbN/JPzFr2qTFyy8bv2is5WR5CDv+Q5QYiWx3iYmgEqwBVKocVNxXytaIGSPz7Q4/iHGHEIJjYlp7iv0NraS6K8kof4y3jfToipOWAijS0uDAn7CclmdfKz2vYKnJYgOkrsqMV2+UC35ihwFhIekC8FPSrsFEj6ydS2mJoYmZAYoPLDyv2rCouxVLdzPFIqAdBkJ6/BNYGSUl1neKvf+lpvt35zGrgAEyW/0yddHrAqCcs/omVWOtztgptwmWYsMhqRU1I0Fo1/TDTbwEtHnbq52RX7Yz68ZPR4PinCraA5XCvpCALMIf5CvzbZeYAQ+PjdspGHrYWO0BbUzyeQqkxVbSaSY4L7ZM1hb9prL+2nG1ofu8bze0ZvD1myGIa7SYIEwkCS2gdF5ct80rxHPMtMqCx4zn1UR femtBtz7 UwI0A6rw0pIX3JbKDcocniM17x3d1OQ5tthdPE16iGsiRWaL6lyhyHv4/3UHBn6z9Q6qNNJq1WEQHZ2RyNPgaAasYrcgC1JZUA8YH3Q4lFp99XL7O5ZuGuWP0pXpfQ4sP9F+sHqkrERMqklYiMsGG8mXAorLiKWloVLIfzBTj/gQLKaBY3ARQ8on8munuRFMr8vc3QnI59+Dfu9pTLFbEy0suKzYOMIajKEUB4rZ1EQ78a4qk/ovWmtAZtU7gKKT1tjsTSJLa7NBfFJARZH6Lizq0FHA+XwM+JKsDXENr0C9LW7QSOw7CzCwdiEJnvidTZZ9dUSpiRACfcSvQlvZIF+qVwp+twydcYTdnS+2PXJqGZJsLILUBaTuuxaxZbT1+s34N61bQsHL1nVrULtjvUR0p2BZ31i+HZ/qR6kc22HcwD8IfjSev8OgnBuIA6hxwfAkqvlV4FFia50iiWFgLqZbEGn58p+4KVYx+EGUZvfjkYo4zagFWad5GLRFjLx/NobP7LFBe5UFIdCfu1FaXPTixfg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jun 27, 2024 at 02:25:36PM -0400, Liam R. Howlett wrote: > * Kees Cook [240627 12:58]: > > On Thu, Jun 27, 2024 at 11:39:32AM +0100, Lorenzo Stoakes wrote: > > > Establish a new userland VMA unit testing implementation under > > > tools/testing which utilises existing logic providing maple tree support in > > > userland utilising the now-shared code previously exclusive to radix tree > > > testing. > > > > > > This provides fundamental VMA operations whose API is defined in mm/vma.h, > > > while stubbing out superfluous functionality. > > > > > > This exists as a proof-of-concept, with the test implementation functional > > > and sufficient to allow userland compilation of vma.c, but containing only > > > cursory tests to demonstrate basic functionality. > > > > Interesting! Why do you want to have this in userspace instead of just > > wiring up what you have here to KUnit so testing can be performed by > > existing CI systems that are running all the KUnit tests? > > The primary reason we did the maple tree testing in userspace was for > speed of testing. We don't need to build the kernel, but a subset of > APIs. Debugging problems is also much quicker since we can instrument > and rebuild, iterate down faster. Tracing every call to the maple tree > on boot alone is massive. > > It is also difficult to verify the vma correctness without exposing APIs > we don't want exported (or, I guess, parse proc files..). On my side, I > have a module for testing the overall interface while I have more tests > on the userspace side that poke and prod on internal states, and > userspace rcu testing is possible. I expect the same issues on the vma > side. > > Adding tests can also be made very efficient with tracepoints dumping > something to add to an array, for example. > > Finally, you have ultimate control on what other functions return (or > do) - so you can fail allocations to test error paths, for example. Or > set the external function to fail after N allocations. This comes in > handy when a syzbot reports a failed allocation at line X caused a > crash. > > This has worked out phenomenally on the maple tree side. I've been able > to record boot failures and import them, syzbot tests, and fuzzer tests. > The result is a huge list of tests that allowed me to rewrite my node > replacement algorithm and have it just work, once it passed the > collected tests. > > I haven't used kunit as much as I have userspace testing, so I cannot > say if all of these points are not possible, but I didn't see a way to > test races like I do with rcu in userspace. > > Thanks, > Liam Liam's response is excellent, and obviously I agree wholeheartedly. Additionally, I'm not really experienced with kunit, but surely it's implemented as a kernel module somehow? If so, these interfaces are largely not exported so it wouldn't be functional as a unit test. And also as Liam says, it'd be very difficult to test this stuff _in_ the kernel without unwanted side-effects triggering and it'd be very difficult to isolate or mock components we don't want to play a role (for instance - rlimits that we might not be able to control). But overall (again as Liam says) the performance benefit, flexibility and ability to recreate things at a whim are huge. And the fact maple tree (which forms a HUGE part of these VMA operations) and related radix tree and other shims/stubs already exist means that it wasn't anywhere near as huge a task to implement this as it would be otherwise.