Re: [PATCH 3/3] tools/mm/thpmaps: fix missing mapping names

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 27 Oct 2026 15:49:04 +0800 Weilin Tong <tongweilin@linux.alibaba.com> wrote:

> VMAList splits smaps lines on whitespace and only keeps the mapping
> name when there are exactly six fields. Names containing whitespace,
> including paths with a (deleted) suffix, are therefore lost.
> 
> Limit splitting to the five fixed fields and preserve the remaining
> name.
> 
> ...
>
> --- a/tools/mm/thpmaps
> +++ b/tools/mm/thpmaps
> @@ -198,7 +198,7 @@ class VMAList:
>          self.vmas = []
>          with open(f'/proc/{pid}/smaps', 'r') as file:
>              for line in file:
> -                elements = line.split()
> +                elements = line.rstrip('\n').split(maxsplit=5)
>                  if '-' in elements[0]:
>                      start, end = map(lambda x: int(x, 16), elements[0].split('-'))
>                      major, minor = map(lambda x: int(x, 16), elements[3].split(':'))

Thanks.  My pedantic reviewbot points out

: Could we also handle carriage returns and non-UTF-8 bytes in filenames?
: Both are valid filename contents.  Python's universal newline handling
: splits the former into separate records, while strict decoding raises
: UnicodeDecodeError for the latter.
: 
: I reproduced both failures with real file mappings, before and after
: this series. Opening smaps this way fixes the tested cases:
: 
:     with open(f'/proc/{pid}/smaps', 'r', newline='\n',
:               errors='surrogateescape') as file:
: 
: These are pre-existing problems, not regressions introduced here.
: They could be included in [3/3] or handled in a follow-up.

and yup, these patterns could indeed be encountered.

But let me grab the series as-is, on the grounds it's much better than
before - spaces in filenames are common whereas \r's and non-UTF8 are
not.