linux-kernel - Re: [PATCH 4/4] mm: introduce per-node proactive reclaim interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250717162637.xz77hsj2byamivgm@offworld>
Date: Thu, 17 Jul 2025 09:26:37 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: akpm@...ux-foundation.org, mhocko@...nel.org, hannes@...xchg.org,
	shakeel.butt@...ux.dev, yosryahmed@...gle.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] mm: introduce per-node proactive reclaim interface

On Wed, 16 Jul 2025, Roman Gushchin wrote:

>Davidlohr Bueso <dave@...olabs.net> writes:
>> @@ -7792,11 +7792,29 @@ int user_proactive_reclaim(char *buf, struct mem_cgroup *memcg, pg_data_t *pgdat
>>			reclaim_options = MEMCG_RECLAIM_MAY_SWAP |
>>					  MEMCG_RECLAIM_PROACTIVE;
>>			reclaimed = try_to_free_mem_cgroup_pages(memcg,
>> -						 batch_size, GFP_KERNEL,
>> +						 batch_size, gfp_mask,
>>						 reclaim_options,
>>						 swappiness == -1 ? NULL : &swappiness);
>>		} else {
>> -			return -EINVAL;
>> +			struct scan_control sc = {
>> +				.gfp_mask = current_gfp_context(gfp_mask),
>> +				.reclaim_idx = gfp_zone(gfp_mask),
>> +				.proactive_swappiness = swappiness == -1 ? NULL : &swappiness,
>> +				.priority = DEF_PRIORITY,
>> +				.may_writepage = !laptop_mode,
>> +				.nr_to_reclaim = max(batch_size, SWAP_CLUSTER_MAX),
>> +				.may_unmap = 1,
>> +				.may_swap = 1,
>> +				.proactive = 1,
>> +			};
>> +
>> +			if (test_and_set_bit_lock(PGDAT_RECLAIM_LOCKED,
>> +						  &pgdat->flags))
>> +				return -EAGAIN;
>
>Isn't EBUSY a better choice here?
>At least to distinguish between no reclaimable memory left and
>somebody else is abusing the same interface cases.

Yes, I agree.

Thanks,
Davidlohr