Re: [PATCH 00/16] mm/shmem: various (urgent?) fixes

["David Hildenbrand (Arm)" <david@kernel.org>]

On 10/26/26 12:11, Baolin Wang wrote:
> 
> 
> On 10/26/26 5:40 PM, David Hildenbrand (Arm) wrote:
>> Hi,
>>
>> the fixing fun continues.
>>
>> This is a handful of fixes for shmem/tmpfs. I sneaked in a related
>> hugetlb fix that stalled upstream.
> 
> Wow, thanks David!
> 
>> Some of the stuff is more urgent (patch #1, F_SEAL_EXEC, truncation
>> hangs), others are less urgent but still rather unpleasant.
>>
>> The majority are fixes from Anthropic that I cleaned up or reworked.
>> While doing that, I found a bunch of other issues and tried to fix them
>> somewhat cleanly.
>>
>> In general, shmem + swap handling is a nightmare. shmem_undo_range() is
>> such utter garbage it makes me want to cry. I mean, really, WTF did we
>> end up creating there. Does any expert here have time to clean that up and
>> make it *actually* maintainable.
> 
> Agree. :) I'll re-read shmem_undo_range() and take a close look at the issues
> you raised, and see if I can make shmem_undo_range() more readable.
> 
>> The following things are still broken in shmem_undo_range():
>>
>> (1) Truncate/punch of a single page of a large swap-error marker
>>
>> We don't split. Consequently, read access afterwards will still fail
>> instead of returning 0s.
>>
>> I have a fix to try to split (which can fail), but I don't consider it
>> that urgent, really. So I'm not including it. Might send it later
>> separately.
>>
>> Truncate/punch of a partial page can obviously never do the right thing,
>> as we cannot poison parts of pages ...
>>
>> (2) Truncate/punch whole pages within part of a large swap entry
>>
>> We try to read the entry, but if we are out of memory that might fail.
>> Consequently, we will not free up swap space and a re-read will not give
>> us 0s but the previous content.
>>
>> AI proposed a nasty NOFAIL patch which has too many nasty side effects
>> IMHO (allowing users to force-read pages and retain them afterwards even
>> though memory.max would disallow it). This needs a proper thought. Likely,
>> support for splitting large swap entries (and large folios in the
>> swapcache, which I recall is under development  by Kairui). But splitting
>> can fail ...
>>
>> (3) Truncate/punch of a part of a base-page swap entry
>>
>> We obviously have to read the page in, in order to 0-out the parts to
>> discard. That might obviously fail.
>>
>> Maybe we should install swapin-error markers if swapping during
>> truncate/punchhole fails, to at least tell user space on later access
>> that something went wrong? We might affect unrelated data, outside the
>> requested range, though. Anyhow, these are long standing issues and
>> I don't consider them urgent.
>>
>> They need a proper solution.
>>
>> I did my best trying to test these fixes. I was able to reproduce some
>> of the things (including unkillable truncation hangs), and the fixes seemed
>> to help.
>>
>> But again, shmem_undo_range() is just an absolute mess.
>>
>> Please prioritize review of these fixes, I want to get fixes for the
>> issues in a timely manner upstream.
> 
> OK. Will review and test this serires this week.

Thanks!

If there are better simple fixes, please do suggest them. Any bigger cleanups
ideally come on top.

BTW, the next time I get a flood of these patches, would you be willing to do
the early screening+revise? But be careful, some of them are pretty, pretty awful :)

-- 
Cheers,

David