From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01DB3362156 for ; Mon, 13 Jul 2026 07:38:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783928334; cv=none; b=OIV6isxaO1qILH4gm5mN0BRs+01qDdhgrFq90XPo5GYIGFShgVNcJBRUkb/hc9UmmwF8SjjuMzIMp22JNbGhiqhBCy7FfuWckvdhnvAmmn1FX/JU7oCBeH/Ex3wj0XtgVMsQtpEGsuUDC1rXvVCCPy9srki8n6ua25Lsz6mz7tA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783928334; c=relaxed/simple; bh=63dJ/u8K8ukxzgVU1r0mHoGFR5Sn/AJ6nxR+QkSgvv0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b8If9D0V2Sh6EjjamZ5jzpzfWyhaynp3+GM6rYQaxXCgKhKts1OLhW2R0HAswt/SYfcwSW0UoBTDu5ilgyqhGyiqiWkvjvZ6jkxhFRjnQZbfv5MSW8E7YP4eowycwkKD9V3mN+2faZ6UdOi5/INffAwf4pNj1xriRm7UTy112QY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=irkwxYLp; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="irkwxYLp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 021531F000E9; Mon, 13 Jul 2026 07:38:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783928332; bh=9eGByJuvHEB+z2eH8QThZCFnk+Hl3GeYnz64gEkwk2c=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=irkwxYLpo/4GSlq8ZgR+kxtCtChgHXEvZCGUUsXjdcJJfJtdQzhs7GCTYNCMyNALI 8b134LpRmIPk0m5eKgadSrX80W13Zgwaf63Q83uB5upLUalokqeV0UQDC7BleA3LQj JxV1nPyg4BQfta4EeMDz7MiwEeut8oPvc4NWxz1uNy+xBZzW1SiLI/Qcpjae9g4Ge9 0wTOqRV/F7FTZJNUVDJ5R1vr1nwuKeH23wHF9pRh66jxC8zf26J5dGw3ivs3ZxvA/k ChA1qeKGTqeyQBGMP3Nw0fGhE7GTSWA6F71UXfSwT9iTJg5Khvoze2qxeDN6WuhmP+ MnrC7bA5Dm8WA== Date: Mon, 13 Jul 2026 08:38:38 +0100 From: Lorenzo Stoakes To: xu.xin16@zte.com.cn Cc: akpm@linux-foundation.org, david@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, chengming.zhou@linux.dev, qi.zheng@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, wang.yaxin@zte.com.cn Subject: Re: [PATCH] mm/mm_slot.h: add a helper function mm_slot_remove Message-ID: References: <178368585772.363984.12871786869575753171.b4-review@b4> <202607131344540423N-vjn1y68X614fkeZemP@zte.com.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202607131344540423N-vjn1y68X614fkeZemP@zte.com.cn> On Mon, Jul 13, 2026 at 01:44:54PM +0800, xu.xin16@zte.com.cn wrote: > > > No functional change is intended. > > > > > > Signed-off-by: xu xin > > > > In general it's fine but I want more :) see below. > > > > > > > > > > > diff --git a/mm/mm_slot.h b/mm/mm_slot.h > > > index 83f18ed1c4bd..bc3b9ae8fdbc 100644 > > > --- a/mm/mm_slot.h > > > +++ b/mm/mm_slot.h > > > @@ -52,4 +52,11 @@ static inline void mm_slot_free(struct kmem_cache *cache, void *objp) > > > hash_add(_hashtable, &_mm_slot->hash, (unsigned long)_mm); \ > > > }) > > > > > > > mm_slot.h also inexplicably implements mm_slot_lookup() and mm_slot_insert() as > > macros. Can you change these to static inline functions in the respin? > > Sorry, I looked into turning mm_slot_lookup() and mm_slot_insert() into > static inline functions, but unfortunately it’s not possible because > they rely on hash_for_each_possible() and hash_add(), which expect an > actual array instead of pointer so that sizeof() can determine the > hash table size. Passing a struct hlist_head * would make sizeof() return > the pointer size instead of the array size, leading to incorrect bucket > indexing and memory corruption. Ah that's fair enough then, explains why they're macros there :) > > > > > Also rename the horrible names from _foo -> foo too please. > > > > And we don't really need 'mm_slot' in the var name for a slot just 'slot' works > > fine. > > Ok, I can clean up these stuff. Thanks! > > > > > > +static inline void mm_slot_remove(struct mm_slot *_mm_slot) > > > > Yeah this name is gross just 'slot' please. > > > > > +{ > > > + hash_del(&_mm_slot->hash); > > > + list_del(&_mm_slot->mm_node); > > > +} > > > + > > > + > > > #endif /* _LINUX_MM_SLOT_H */ > > > > Thanks, Lorenzo > > Cheers, Lorenzo