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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 766C2C48BE0 for ; Wed, 9 Jun 2021 13:21:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 06FD8613AC for ; Wed, 9 Jun 2021 13:21:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06FD8613AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gentwo.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 812CC6B006E; Wed, 9 Jun 2021 09:21:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C29D6B0072; Wed, 9 Jun 2021 09:21:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63C0F6B0074; Wed, 9 Jun 2021 09:21:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 325766B006E for ; Wed, 9 Jun 2021 09:21:40 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C0238B7A0 for ; Wed, 9 Jun 2021 13:21:39 +0000 (UTC) X-FDA: 78234247518.36.A6FA4FC Received: from gentwo.de (vmi485042.contaboserver.net [161.97.139.209]) by imf13.hostedemail.com (Postfix) with ESMTP id 6E895E000277 for ; Wed, 9 Jun 2021 13:21:35 +0000 (UTC) Received: by gentwo.de (Postfix, from userid 1001) id A1995B0026B; Wed, 9 Jun 2021 15:21:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id A0782B000A9; Wed, 9 Jun 2021 15:21:37 +0200 (CEST) Date: Wed, 9 Jun 2021 15:21:37 +0200 (CEST) From: Christoph Lameter To: Oliver Glitta cc: brendanhiggins@google.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-mm@kvack.org, elver@google.com, dlatypov@google.com, corbet@lwn.net, linux-doc@vger.kernel.org Subject: Re: [PATCH] docs: add documentation for SLUB cache kunit tests In-Reply-To: <20210608084740.6282-1-glittao@gmail.com> Message-ID: References: <20210608084740.6282-1-glittao@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de X-Rspamd-Server: rspam02 X-Stat-Signature: 538t8tcirtepexzc9rtn1cbxa39hnf7y X-Rspamd-Queue-Id: 6E895E000277 X-HE-Tag: 1623244895-16610 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: Some spelling fixes below but it got a bit much when looking through this. Maybe rewrite this again for clarity? On Tue, 8 Jun 2021, glittao@gmail.com wrote: > +KUnit tests for SLUB debugging functionality > +============================================ > + > +These KUnit tests are used to test some of the SLUB debugging > +functionalities. functionality. > + > +KUnit tests are used for unit testing in Linux kernel and easy to run, > +so it is probably the best choice for this type of tests. > + > +There are tests, which corrupt redzone, the free objects and the freelist. > +Tests are corrupting specific bytes in cache and checking if validation > +finds expected number of bugs. Bug reports are silenced. "in a SLUB cache" .... or "in a cache" finds *the* expected number of ... > +In order to built and then run this tests you need to switch > +option SLUB_KUNIT_TEST on. It is tristate option so it can also *the* option *a* tristate option > +be built as a module. This option depends on SLUB_DEBUG and > +KUNIT options. By default it is on with all kunit tests. > + > +Error counting > + > +To get number of errors discovered in slub is used test API kunit_resource. What does that mean? > +In test_init the reference to the integer variable slab_errors is added > +to the resource of this tests. > + > +During slub cache checking always when bug should be reported or fixed function > +slab_add_kunit_errors() is called. This function find resource to kunit test > +and increment value of data in founded resource, which is slab_errors > +variable. ?? > + > +Silence bug reports > + > +The function slab_add_kunit_errors() is returning bool, which is true if there is kunit test > +with correct kunit_resource running, to silence bug reports, so they are not printed. > +We do not want to correct errors we only want to know they occurred, so these reports > +are unnnecessary. These reports are unnecessary because we do not want to correct errors. We only want to know that they occurred. > + > +KASAN option > + > +Only 2 out of 5 tests are runnig with KASAN option is on. running > +The other three tests deliberately modifies non-allocated objects. And KASAN modify > +does not detect some errors in the same way as SLUB_DEBUG. So, these tests > +does not run when KASAN option is on. do > +1. test_clobber_zone > + > + SLUB cache with SLUB_REDZONE flag can detects writings after object. This > + functionality is tested here on allocated memory. ... can detect modifying memory locations after the object. > + > + First, there is allocated memory with SLAB_REDZONE and then the first byte > + after allocated space is modified. Validation founds 2 errors, because of > + the bug and the fix of the memory. after *the* allocated space. The validation finds 2 errors. One is the fact that there is a corrupted redzone and the second due to the repair of the redzone. > +2. test_next_pointer > + > + SLUB have list of free objects and the address of the next free object > + is always saved in free object at offset specified in variable offset > + in struct kmem_cache. This test try to corrupt this freelist and > + then correct it. SLUB *has a* .... is ** saved in a *freed object* at *the* offset ... > + > + First, there is allocated and freed memory to get a pointer to free object. > + After that, the pointer to next free object is corrupted. The first validation finds > + 3 errors. One for corrupted freechain, the second for the wrong count of objects > + in use and the third for fixing the issue. This fix only set number of objects > + in use to a number of all objects minus 1, because the first free object > + was corrupted. > + > + Then the free pointer is fixed to his previous value. The second validation finds > + 2 errors. One for the wrong count of objects in use and one for fixing this error. > + > + Last validation is used to check if all errors were corrected so no error > + is found. > + > +3. test_first_word > + > + SLUB cache with SLAB_POISON flag can detect poisoning free objects. This > + functionality is tested in this test. The test tries to corrupt > + the first byte in freed memory. > + > + First of all, memory is allocated and freed to get a pointer to a free object > + and then the first byte is corrupted. After that, validation finds 2 errors, > + one for the bug and the other one for the fix of the memory. > + > +4. test_clobber_50th_byte > + > + In this test SLAB_POISON functionality is tested. The test tries to > + corrupt the 50th byte in freed memory. > + > + First, pointer to a free memory is acquired by allocating and freeing memory. > + Then 50th byte is corrupted and validation finds 2 errors for the bug and > + the fix of the memory. > + > +5. test_clobber_redzone_free > + > + This test tests redzone functionality of SLUB cache on a freed object. > + > + First, it gets pointer to the free object with allocating and freeing and > + then corrupts the first byte after the freed object. Validation finds > + 2 errors for the bug and the fix of the memory. > + > Christoph Lameter, May 30, 2007 > Sergey Senozhatsky, October 23, 2015 > -- > 2.31.1.272.g89b43f80a5 >