mountinfo: implement unescape() using strings.Replacer()

[thaJeztah]

• follow-up to / stacked on update to go1.18, and use strings.Cut #142

mountinfo: add benchmark for unescape

go test -v -test.benchmem -count=10 -run ^$ -bench BenchmarkUnescape .
go: downloading golang.org/x/sys v0.1.0
goos: linux
goarch: arm64
pkg: github.com/moby/sys/mountinfo
BenchmarkUnescape
BenchmarkUnescape-10 1000000 1068 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 992292 1082 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1050 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1038 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1034 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1045 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1071 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1033 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1032 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1070 ns/op 640 B/op 31 allocs/op
PASS
ok github.com/moby/sys/mountinfo 10.653s

mountinfo: implement unescape() using strings.Replacer()

So, this mostly was because I saw this approach in another projefct, and liked
how simple/clean it was.

There are some downsides though;

• performance looks to be slightly less
• we're no longer bothering with invalid escape sequences

For the latter, I'm actually wondering how much validation we should do; should
we take invalid escape sequences as literal strings? What does Linux itself do
with these?

I know in the past we added too much complication at times, and sometimes were
validating things we should not care about (or even validating inconsistent with
the host itself).

Comparison between old unescape() and the new, using fstabUnescape.Replace():

Before:

go test -v -test.benchmem -count=10 -run ^$ -bench BenchmarkUnescape .
go: downloading golang.org/x/sys v0.1.0
goos: linux
goarch: arm64
pkg: github.com/moby/sys/mountinfo
BenchmarkUnescape
BenchmarkUnescape-10 1000000 1068 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 992292 1082 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1050 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1038 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1034 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1045 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1071 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1033 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1032 ns/op 640 B/op 31 allocs/op
BenchmarkUnescape-10 1000000 1070 ns/op 640 B/op 31 allocs/op
PASS
ok github.com/moby/sys/mountinfo 10.653s

After

go test -v -test.benchmem -count=10 -run ^$ -bench BenchmarkUnescape .
goos: linux
goarch: arm64
pkg: github.com/moby/sys/mountinfo
BenchmarkUnescape
BenchmarkUnescape-10 1000000 1141 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 977841 1132 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 1000000 1160 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 901806 1131 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 980247 1137 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 988596 1135 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 975658 1139 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 934603 1161 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 997353 1123 ns/op 520 B/op 32 allocs/op
BenchmarkUnescape-10 986551 1131 ns/op 520 B/op 32 allocs/op
PASS
ok github.com/moby/sys/mountinfo	11.245s

From the above:

• new version is ~100 ns/op slower
• new version has one more allocation (32 vs 31)
• new version uses 120B less memory (520B vs 640B)

[thaJeztah]

Just cleaning up some old branches; not 100% sure about this one; wasn't sure how strict we wanted to be, and if simplifying the code is worth the slightly reduced performance

[kolyshkin]

This is interesting. I like the way it simplifies the code, and it seems the additional overhead is insignificant.

One small concern is current function interprets all escape sequences, while the new one is more limited. Need to take a look at the modern kernel, hope they haven't added more codes.

[kolyshkin]

OK, we unescape the following fields:

• (4) root: root of the mount within the filesystem
• (5) mount point: mount point relative to the process's root
• (9) filesystem type: name of filesystem of the form "type[.subtype]"
• (10) mount source: filesystem specific information or "none"

In general, I would not rely on man pages in such a delicate subject. We have to drink raw and unfiltered C code from the kernel source tree.

It looks like mountinfo is shown by show_mountinfo. Let's only look at the fields we're interested in:

• Root is shown via show_path -> seq_dentry -> mangle_path, the characters being escaped are \, \n, \t and (space). Note that some filesystems have their own implementation of show_path and may escape different characters, although I can't find any fss doing that in the vanilla kernel source tree.
• Mount point is shown via seq_path_root -> mangle_path, same escape characters as above.
• FS type is shown by show_type -> mangle, which escapes (space), \t, \n, \\ and #. NOTE the #.
• Mount source (aka "device") is shown either via fs-specific show_devname function, or via mangle with same rules as for the FS type above (i.e. it also includes #).

Looking into fs-specific show_devname, I found this:

• afs: no escaping
• bcachefs: no escaping
• btrfs: escapes " \t\n\\" (as usual)
• nfs[4]: escapes " \t\n\\" (as usual)
• cifs: escapes " \t" only

Now, these analysis might be wrong and they are definitely incomplete as there are filesystems which source code is not in the vanilla kernel source tree (e.g. aufs), and they may have their own escaping rules.

At the very least, this patch should add # to the replace list.

[kolyshkin]

should we take invalid escape sequences as literal strings? What does Linux itself do
with these?

It looks like kernel uses string_unescape(..., UNESCAPE_OCTAL). Apparently it just replaces any \NNN with a character which octal value is NNN (NNN can be 1 to 3 digits long), with no error reporting (if it can not convert something it just leaves it as is).

Note though that the kernel always outputs 3 octal digits.

I will see if I can simplify my code.

[kolyshkin]

I ended up with #144, PTAL

[thaJeztah]

I like the way it simplifies the code, and it seems the additional overhead is insignificant.

Yes! I honestly don't recall where I found this approach, but I saw it somewhere and thought "if it doesn't add a lot of overhead, then it might be an option".

FWIW: I don't really mind the existing code (it's still fairly readable, and if it's for performance, sometimes it's ok to have more verbose code for that), but thought I'd give it a try.

I ended up with #144, PTAL

Thx! Will give it a look 👍

[thaJeztah]

Closing in favour of #144