Re: [PATCH] mm/execmem: check execmem_restore_rox() failure in execmem_cache_free()

[Lorenzo Stoakes (ARM)]

On Sun, Nov 15, 2026 at 12:47:04AM +0800, shao.mingyin@xxxxxxxxxx wrote:
> From: Shao Mingyin <shao.mingyin@xxxxxxxxxx>
>
> mm/execmem: check execmem_restore_rox() failure in execmem_cache_free()
>
> __execmem_cache_free() checks execmem_force_rw(), but ignores the
> matching execmem_restore_rox() result before adding the block to the
> free ROX cache. A failed restore can leave permissions only partially
> updated, so a later cache allocation can return memory that is not ROX.
> The cache allocation path does not reapply permissions.
>
> Check the restore result and return the error. The existing callers keep
> failed frees pending and retry them through delayed work. This prevents
> a block whose ROX restoration failed from entering the free cache, and
> matches the error handling in execmem_vmalloc_rox().
>
> Fixes: 187fd8521dd8 ("execmem: rework execmem_cache_free()")
> Cc: stable@xxxxxxxxxxxxxxx # 6.17
> Signed-off-by: Shao Mingyin <shao.mingyin@xxxxxxxxxx>

NAK.

this is generated by some AI slopper's script, spamming the kernel. The
patches I looked at were wrong/broken, so no to anything from this person.

They've sent 300 mails in under four weeks spanniing: ata, scsi, target,
ufs, nvme/nvmet, ubifs, ublk, zloop, dm, md, mmc, virtio-blk, mfd, gpio,
pwm, spi, PCI, ASoC, ACPI, net, vfs mount, block partitions, and now mm.

and 17 series across 7 subsystems over the past 23 hours.

We need a way to ban emails from people like this...

--
Cheers, Lorenzo