From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (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 052882C80 for ; Mon, 3 Jan 2022 17:56:24 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id CFB7D21108; Mon, 3 Jan 2022 17:56:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1641232582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CWXmfQBKbsotJ+DKTiOu/dBjpnMA9AO60pYklnpK268=; b=RhtzrMx8l25Gp/dHfXaSGxIrVaiGPT1oHmkDlXhSWyOvA3XmL4u7MKmkETxcTTsnSdyvu2 2jQ+42aJxQsIJcy8XiqzBTF5lvvMOIEw62rvN/I2Cv3SEGwEYtC0RgDlqOLKfcdrrpJrAI TwUGB6+/291CiiyPqlt5NX4O2jOPKt4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1641232582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CWXmfQBKbsotJ+DKTiOu/dBjpnMA9AO60pYklnpK268=; b=t8qwh7PKelubXDsAPcP//m32DqwLxiSz3osyPqIC0+7efv+uVAzzP9TnLLkkHY3hH0TlrX HpPoN6SxQtgI3lBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 40BC413B0C; Mon, 3 Jan 2022 17:56:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Wx1+DsY402GiJQAAMHmgww (envelope-from ); Mon, 03 Jan 2022 17:56:22 +0000 Message-ID: Date: Mon, 3 Jan 2022 18:56:21 +0100 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Matthew Wilcox , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , linux-mm@kvack.org, Andrew Morton , patches@lists.linux.dev, Alexander Potapenko , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , cgroups@vger.kernel.org, Dave Hansen , David Woodhouse , Dmitry Vyukov , "H. Peter Anvin" , Ingo Molnar , iommu@lists.linux-foundation.org, Joerg Roedel , Johannes Weiner , Julia Lawall , kasan-dev@googlegroups.com, Lu Baolu , Luis Chamberlain , Marco Elver , Michal Hocko , Minchan Kim , Nitin Gupta , Peter Zijlstra , Sergey Senozhatsky , Suravee Suthikulpanit , Thomas Gleixner , Vladimir Davydov , Will Deacon , x86@kernel.org, Roman Gushchin References: <20211201181510.18784-1-vbabka@suse.cz> <4c3dfdfa-2e19-a9a7-7945-3d75bc87ca05@suse.cz> From: Vlastimil Babka Subject: Re: [PATCH v2 00/33] Separate struct slab from struct page In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/29/21 12:22, Hyeonggon Yoo wrote: > On Wed, Dec 22, 2021 at 05:56:50PM +0100, Vlastimil Babka wrote: >> On 12/14/21 13:57, Vlastimil Babka wrote: >> > On 12/1/21 19:14, Vlastimil Babka wrote: >> >> Folks from non-slab subsystems are Cc'd only to patches affecting them, and >> >> this cover letter. >> >> >> >> Series also available in git, based on 5.16-rc3: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-struct_slab-v2r2 >> > >> > Pushed a new branch slab-struct-slab-v3r3 with accumulated fixes and small tweaks >> > and a new patch from Hyeonggon Yoo on top. To avoid too much spam, here's a range diff: >> >> Hi, I've pushed another update branch slab-struct_slab-v4r1, and also to >> -next. I've shortened git commit log lines to make checkpatch happier, >> so no range-diff as it would be too long. I believe it would be useless >> spam to post the whole series now, shortly before xmas, so I will do it >> at rc8 time, to hopefully collect remaining reviews. But if anyone wants >> a mailed version, I can do that. >> > > Hello Matthew and Vlastimil. > it's part 3 of review. > > # mm: Convert struct page to struct slab in functions used by other subsystems > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > # mm/slub: Convert most struct page to struct slab by spatch > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > with a question below. > > -static int check_slab(struct kmem_cache *s, struct page *page) > +static int check_slab(struct kmem_cache *s, struct slab *slab) > { > int maxobj; > > - if (!PageSlab(page)) { > - slab_err(s, page, "Not a valid slab page"); > + if (!folio_test_slab(slab_folio(slab))) { > + slab_err(s, slab, "Not a valid slab page"); > return 0; > } > > Can't we guarantee that struct slab * always points to a slab? Normally, yes. > for struct page * it can be !PageSlab(page) because struct page * > can be other than slab. but struct slab * can only be slab > unlike struct page. code will be simpler if we guarantee that > struct slab * always points to a slab (or NULL). That's what the code does indeed. But check_slab() is called as part of various consistency checks, so there we on purpose question all assumptions in order to find a bug (e.g. memory corruption) - such as a page that's still on the list of slabs while it was already freed and reused and thus e.g. lacks the slab page flag. But it's nice how using struct slab makes such a check immediately stand out as suspicious, right? > # mm/slub: Convert pfmemalloc_match() to take a struct slab > It's confusing to me because the original pfmemalloc_match() is removed > and pfmemalloc_match_unsafe() was renamed to pfmemalloc_match() and > converted to use slab_test_pfmemalloc() helper. > > But I agree with the resulting code. so: > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > # mm/slub: Convert alloc_slab_page() to return a struct slab > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > # mm/slub: Convert print_page_info() to print_slab_info() > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > I hope to review rest of patches in a week. Thanks for your reviews/tests! 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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 412FCC433F5 for ; Mon, 3 Jan 2022 17:56:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C6C5E40146; Mon, 3 Jan 2022 17:56:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtqHa8owPAeL; Mon, 3 Jan 2022 17:56:32 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id 46E65400C1; Mon, 3 Jan 2022 17:56:30 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1F09DC0030; Mon, 3 Jan 2022 17:56:30 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 26149C001E for ; Mon, 3 Jan 2022 17:56:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 051E8812E4 for ; Mon, 3 Jan 2022 17:56:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=suse.cz header.b="RhtzrMx8"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=suse.cz header.b="t8qwh7PK" Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qL1s7twhWUZ for ; Mon, 3 Jan 2022 17:56:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0A52080D8C for ; Mon, 3 Jan 2022 17:56:25 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id CFB7D21108; Mon, 3 Jan 2022 17:56:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1641232582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CWXmfQBKbsotJ+DKTiOu/dBjpnMA9AO60pYklnpK268=; b=RhtzrMx8l25Gp/dHfXaSGxIrVaiGPT1oHmkDlXhSWyOvA3XmL4u7MKmkETxcTTsnSdyvu2 2jQ+42aJxQsIJcy8XiqzBTF5lvvMOIEw62rvN/I2Cv3SEGwEYtC0RgDlqOLKfcdrrpJrAI TwUGB6+/291CiiyPqlt5NX4O2jOPKt4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1641232582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CWXmfQBKbsotJ+DKTiOu/dBjpnMA9AO60pYklnpK268=; b=t8qwh7PKelubXDsAPcP//m32DqwLxiSz3osyPqIC0+7efv+uVAzzP9TnLLkkHY3hH0TlrX HpPoN6SxQtgI3lBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 40BC413B0C; Mon, 3 Jan 2022 17:56:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Wx1+DsY402GiJQAAMHmgww (envelope-from ); Mon, 03 Jan 2022 17:56:22 +0000 Message-ID: Date: Mon, 3 Jan 2022 18:56:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> References: <20211201181510.18784-1-vbabka@suse.cz> <4c3dfdfa-2e19-a9a7-7945-3d75bc87ca05@suse.cz> From: Vlastimil Babka Subject: Re: [PATCH v2 00/33] Separate struct slab from struct page In-Reply-To: Cc: Peter Zijlstra , Dave Hansen , Michal Hocko , linux-mm@kvack.org, Andrey Ryabinin , Alexander Potapenko , kasan-dev@googlegroups.com, "H. Peter Anvin" , Christoph Lameter , Will Deacon , Julia Lawall , Sergey Senozhatsky , x86@kernel.org, Luis Chamberlain , Matthew Wilcox , Ingo Molnar , Vladimir Davydov , David Rientjes , Nitin Gupta , Marco Elver , Borislav Petkov , Andy Lutomirski , cgroups@vger.kernel.org, Thomas Gleixner , Joonsoo Kim , Dmitry Vyukov , Andrey Konovalov , patches@lists.linux.dev, Pekka Enberg , Minchan Kim , iommu@lists.linux-foundation.org, Johannes Weiner , Andrew Morton , David Woodhouse , Roman Gushchin X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 12/29/21 12:22, Hyeonggon Yoo wrote: > On Wed, Dec 22, 2021 at 05:56:50PM +0100, Vlastimil Babka wrote: >> On 12/14/21 13:57, Vlastimil Babka wrote: >> > On 12/1/21 19:14, Vlastimil Babka wrote: >> >> Folks from non-slab subsystems are Cc'd only to patches affecting them, and >> >> this cover letter. >> >> >> >> Series also available in git, based on 5.16-rc3: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-struct_slab-v2r2 >> > >> > Pushed a new branch slab-struct-slab-v3r3 with accumulated fixes and small tweaks >> > and a new patch from Hyeonggon Yoo on top. To avoid too much spam, here's a range diff: >> >> Hi, I've pushed another update branch slab-struct_slab-v4r1, and also to >> -next. I've shortened git commit log lines to make checkpatch happier, >> so no range-diff as it would be too long. I believe it would be useless >> spam to post the whole series now, shortly before xmas, so I will do it >> at rc8 time, to hopefully collect remaining reviews. But if anyone wants >> a mailed version, I can do that. >> > > Hello Matthew and Vlastimil. > it's part 3 of review. > > # mm: Convert struct page to struct slab in functions used by other subsystems > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > # mm/slub: Convert most struct page to struct slab by spatch > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > with a question below. > > -static int check_slab(struct kmem_cache *s, struct page *page) > +static int check_slab(struct kmem_cache *s, struct slab *slab) > { > int maxobj; > > - if (!PageSlab(page)) { > - slab_err(s, page, "Not a valid slab page"); > + if (!folio_test_slab(slab_folio(slab))) { > + slab_err(s, slab, "Not a valid slab page"); > return 0; > } > > Can't we guarantee that struct slab * always points to a slab? Normally, yes. > for struct page * it can be !PageSlab(page) because struct page * > can be other than slab. but struct slab * can only be slab > unlike struct page. code will be simpler if we guarantee that > struct slab * always points to a slab (or NULL). That's what the code does indeed. But check_slab() is called as part of various consistency checks, so there we on purpose question all assumptions in order to find a bug (e.g. memory corruption) - such as a page that's still on the list of slabs while it was already freed and reused and thus e.g. lacks the slab page flag. But it's nice how using struct slab makes such a check immediately stand out as suspicious, right? > # mm/slub: Convert pfmemalloc_match() to take a struct slab > It's confusing to me because the original pfmemalloc_match() is removed > and pfmemalloc_match_unsafe() was renamed to pfmemalloc_match() and > converted to use slab_test_pfmemalloc() helper. > > But I agree with the resulting code. so: > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > # mm/slub: Convert alloc_slab_page() to return a struct slab > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > # mm/slub: Convert print_page_info() to print_slab_info() > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > I hope to review rest of patches in a week. Thanks for your reviews/tests! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlastimil Babka Subject: Re: [PATCH v2 00/33] Separate struct slab from struct page Date: Mon, 3 Jan 2022 18:56:21 +0100 Message-ID: References: <20211201181510.18784-1-vbabka@suse.cz> <4c3dfdfa-2e19-a9a7-7945-3d75bc87ca05@suse.cz> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1641232582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CWXmfQBKbsotJ+DKTiOu/dBjpnMA9AO60pYklnpK268=; b=RhtzrMx8l25Gp/dHfXaSGxIrVaiGPT1oHmkDlXhSWyOvA3XmL4u7MKmkETxcTTsnSdyvu2 2jQ+42aJxQsIJcy8XiqzBTF5lvvMOIEw62rvN/I2Cv3SEGwEYtC0RgDlqOLKfcdrrpJrAI TwUGB6+/291CiiyPqlt5NX4O2jOPKt4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1641232582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CWXmfQBKbsotJ+DKTiOu/dBjpnMA9AO60pYklnpK268=; b=t8qwh7PKelubXDsAPcP//m32DqwLxiSz3osyPqIC0+7efv+uVAzzP9TnLLkkHY3hH0TlrX HpPoN6SxQtgI3lBg== Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Matthew Wilcox , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Andrew Morton , patches-cunTk1MwBs/YUNznpcFYbw@public.gmane.org, Alexander Potapenko , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dave Hansen , David Woodhouse , Dmitry Vyukov , "H. Peter Anvin" , Ingo Molnar , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Joerg Roedel , Johannes Weiner On 12/29/21 12:22, Hyeonggon Yoo wrote: > On Wed, Dec 22, 2021 at 05:56:50PM +0100, Vlastimil Babka wrote: >> On 12/14/21 13:57, Vlastimil Babka wrote: >> > On 12/1/21 19:14, Vlastimil Babka wrote: >> >> Folks from non-slab subsystems are Cc'd only to patches affecting them, and >> >> this cover letter. >> >> >> >> Series also available in git, based on 5.16-rc3: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-struct_slab-v2r2 >> > >> > Pushed a new branch slab-struct-slab-v3r3 with accumulated fixes and small tweaks >> > and a new patch from Hyeonggon Yoo on top. To avoid too much spam, here's a range diff: >> >> Hi, I've pushed another update branch slab-struct_slab-v4r1, and also to >> -next. I've shortened git commit log lines to make checkpatch happier, >> so no range-diff as it would be too long. I believe it would be useless >> spam to post the whole series now, shortly before xmas, so I will do it >> at rc8 time, to hopefully collect remaining reviews. But if anyone wants >> a mailed version, I can do that. >> > > Hello Matthew and Vlastimil. > it's part 3 of review. > > # mm: Convert struct page to struct slab in functions used by other subsystems > Reviewed-by: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > # mm/slub: Convert most struct page to struct slab by spatch > Reviewed-by: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Tested-by: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > with a question below. > > -static int check_slab(struct kmem_cache *s, struct page *page) > +static int check_slab(struct kmem_cache *s, struct slab *slab) > { > int maxobj; > > - if (!PageSlab(page)) { > - slab_err(s, page, "Not a valid slab page"); > + if (!folio_test_slab(slab_folio(slab))) { > + slab_err(s, slab, "Not a valid slab page"); > return 0; > } > > Can't we guarantee that struct slab * always points to a slab? Normally, yes. > for struct page * it can be !PageSlab(page) because struct page * > can be other than slab. but struct slab * can only be slab > unlike struct page. code will be simpler if we guarantee that > struct slab * always points to a slab (or NULL). That's what the code does indeed. But check_slab() is called as part of various consistency checks, so there we on purpose question all assumptions in order to find a bug (e.g. memory corruption) - such as a page that's still on the list of slabs while it was already freed and reused and thus e.g. lacks the slab page flag. But it's nice how using struct slab makes such a check immediately stand out as suspicious, right? > # mm/slub: Convert pfmemalloc_match() to take a struct slab > It's confusing to me because the original pfmemalloc_match() is removed > and pfmemalloc_match_unsafe() was renamed to pfmemalloc_match() and > converted to use slab_test_pfmemalloc() helper. > > But I agree with the resulting code. so: > Reviewed-by: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > # mm/slub: Convert alloc_slab_page() to return a struct slab > Reviewed-by: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Tested-by: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > # mm/slub: Convert print_page_info() to print_slab_info() > Reviewed-by: Hyeonggon Yoo <42.hyeyoo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > I hope to review rest of patches in a week. Thanks for your reviews/tests!