From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-21.mta0.migadu.com [91.218.175.21]) (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 31CE23E1723 for ; Mon, 7 Sep 2026 03:18:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.21 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788751085; cv=none; b=NkvQHrRMwbvasC4MN1yFBxWV8rdKGyHHo+dJ7zg9OplNbjSLT9HlY0xMVfs/MpRySkR94ZIbu5ZwDa3wF0rDhTKFIskBQzsojVrJkIkzMS7qTghXEufW3LZyATVWlmYntsubQ2fFNOeiZDQCgFYf5eDnw2WLhFjwaL73BYGDmxw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788751085; c=relaxed/simple; bh=4NwIip7/KPKLo7TJlw7Cq9K17+JHbn+jGgJ7eRNJyU0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uIcFZkvdMKMs7DmWsUhHxU7MqPUcaAEdMukoHLfX6hcqguVmW42x7r/kgf7TPCxr4lbSOCTRamRGb36AWTtt/89WYbjpZzRN55N7vrLbSBGhfT1oMRj5bK7WcKlq4kOqpx6Tk4YzsbVtyHmK93Z9SDJgo55lec4E/rvpf+fpbkw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=XoH3rQxV; arc=none smtp.client-ip=91.218.175.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="XoH3rQxV" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=4NwIip7/KPKLo7TJlw7Cq9K17+JHbn+jGgJ7eRNJyU0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788751080; v=1; x=1789355880; b=XoH3rQxVvtuIH7YZpNDAHgio5/F4WQsDsrj8RjgmAC10i7CcIlUmwP8bUuqy+LE3zPIcbj04 IYLPnM5exsQpB6aWrbShgAicYDAcFxlT0NrwXT9CkxeMUCHSBGE+86fLTrj/ZsT+fVqzdHni+bQ 1eKKrZXMfRktIHDLCqB1UHQs= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 557dbd025e9566f7; Mon, 07 Sep 2026 03:17:50 +0000 X-Mizu-Trace-ID: 557dbd025e9566f7 X-Migadu-Flow: FLOW_OUT Message-ID: <4525fdf8-def6-4f24-abe8-1948eab54d6e@linux.dev> Date: Mon, 7 Sep 2026 11:17:43 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Betterbird (macOS/Intel) Subject: Re: [PATCH bpf-next v7 1/2] mm/bpf: Add bpf_proactive_reclaim kfunc To: Shakeel Butt , Kumar Kartikeya Dwivedi Cc: Andrew Morton , Roman Gushchin , JP Kobryn , Andrii Nakryiko , Eduard Zingerman , Ihor Solodrai , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Shuah Khan , Barry Song , Geliang Tang , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Hui Zhu References: <7d8b77dc99ffe99a7bef874a257472fdaaf07e1c.1788516769.git.zhuhui@kylinos.cn> <20260904110308.4473cde499e91aab14dbd5fc@linux-foundation.org> Content-Language: en-US From: Hui Zhu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > On Sat, Sep 05, 2026 at 01:23:39PM +0200, Kumar Kartikeya Dwivedi wrote: >> On Fri Sep 4, 2026 at 8:03 PM CEST, Andrew Morton wrote: >>> On Fri, 4 Sep 2026 18:20:19 +0800 "Hui Zhu" wrote: >>> >>>> @@ -159,6 +160,74 @@ __bpf_kfunc void bpf_mem_cgroup_flush_stats(struct mem_cgroup *memcg) >>>> mem_cgroup_flush_stats(memcg); >>>> } >>>> >>>> +/* >>>> + * Reclaim must not recurse: try_to_free_mem_cgroup_pages() overwrites >>>> + * current->reclaim_state, so a nested call would corrupt the outer >>>> + * reclaim state. Reclaim windows are marked with PF_MEMALLOC; >>>> + * reclaim_state is also checked because it is installed slightly >>>> + * before PF_MEMALLOC. >>>> + */ >>>> +static bool bpf_in_reclaim_context(void) >>>> +{ >>>> + return (current->flags & PF_MEMALLOC) || current->reclaim_state; >>>> +} >>>> + >>> Would life improve if try_to_free_mem_cgroup_pages() didn't do that? >>> If try_to_free_mem_cgroup_pages() (or some variant of it) were to >>> permit nesting? >>> >>> rs = new_thing(current, &sc.reclaim_state); >>> ... >>> set_task_reclaim_state(current, rs); >>> >> My understanding is that given the current restrictions on where this kfunc can >> be called, this is mostly a defensive and shouldn't be firing (?). Given that, >> we can probably revisit this when such reentrancy is necessary, even though I >> doubt it would be the case in the future. It will at most be invoked from a wq >> callback or a kthread, so should be fine. >> > If with the current restrictions, this recursion can not happen then let's not > add this check here. We never want recursion/reentrancy here. Will remove it in the next version. Best, Hui