linux.git/fs/unicode, branch v6.18.21

unicode: kunit: change tests filename and path

2025-02-12T22:00:11+00:00

Change utf8 kunit test filename and path to follow the style
convention on Documentation/dev-tools/kunit/style.rst

Co-developed-by: Pedro Orlando 
Signed-off-by: Pedro Orlando 
Co-developed-by: Danilo Pereira 
Signed-off-by: Danilo Pereira 
Signed-off-by: Gabriela Bittencourt 
Reviewed-by: David Gow 
Acked-by: Gabriel Krisman Bertazi 
Reviewed-by: Shuah Khan 
Reviewed-by: Rae Moar 
Link: https://lore.kernel.org/r/20241202075545.3648096-7-davidgow@google.com
Signed-off-by: Kees Cook

unicode: kunit: refactor selftest to kunit tests

2025-02-11T02:25:39+00:00

Refactoring 'test' functions into kunit tests, to test utf-8 support in
unicode subsystem.

This allows the utf8 tests to be run alongside the KUnit test suite
using kunit-tool, quickly compiling and running all desired tests as
part of the KUnit test suite, instead of compiling the selftest module
and loading it.

The refactoring kept the original testing logic intact, while adopting a
testing pattern across different kernel modules and leveraging KUnit's
benefits.

Co-developed-by: Pedro Orlando 
Signed-off-by: Pedro Orlando 
Co-developed-by: Danilo Pereira 
Signed-off-by: Danilo Pereira 
Signed-off-by: Gabriela Bittencourt 
Reviewed-by: David Gow 
Acked-by: Gabriel Krisman Bertazi 
Reviewed-by: Rae Moar 
Link: https://lore.kernel.org/r/20241202075545.3648096-6-davidgow@google.com
Signed-off-by: Kees Cook

Revert "unicode: Don't special case ignorable code points"

2024-12-11T22:11:23+00:00

This reverts commit 5c26d2f1d3f5e4be3e196526bead29ecb139cf91.

It turns out that we can't do this, because while the old behavior of
ignoring ignorable code points was most definitely wrong, we have
case-folding filesystems with on-disk hash values with that wrong
behavior.

So now you can't look up those names, because they hash to something
different.

Of course, it's also entirely possible that in the meantime people have
created *new* files with the new ("more correct") case folding logic,
and reverting will just make other things break.

The correct solution is to not do case folding in filesystems, but
sadly, people seem to never really understand that.  People still see it
as a feature, not a bug.

Reported-by: Qi Han 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219586
Cc: Gabriel Krisman Bertazi 
Requested-by: Jaegeuk Kim 
Signed-off-by: Linus Torvalds

Merge tag 'unicode-next-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/krisman/unicode

2024-11-23T04:50:55+00:00

Pull unicode updates from Gabriel Krisman Bertazi:

 - constify a read-only struct (Thomas Weißschuh)

 - fix the error path of unicode_load, avoiding a possible kernel oops
   if it fails to find the unicode module (André Almeida)

 - documentation fix, updating a filename in the README (Gan Jie)

 - add the link of my tree to MAINTAINERS (André Almeida)

* tag 'unicode-next-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/krisman/unicode:
  MAINTAINERS: Add Unicode tree
  unicode: change the reference of database file
  unicode: Fix utf8_load() error path
  unicode: constify utf8 data table

unicode: Recreate utf8_parse_version()

2024-10-28T12:36:54+00:00

All filesystems that currently support UTF-8 casefold can fetch the
UTF-8 version from the filesystem metadata stored on disk. They can get
the data stored and directly match it to a integer, so they can skip the
string parsing step, which motivated the removal of this function in the
first place.

However, for tmpfs, the only way to tell the kernel which UTF-8 version
we are about to use is via mount options, using a string. Re-introduce
utf8_parse_version() to be used by tmpfs.

This version differs from the original by skipping the intermediate step
of copying the version string to an auxiliary string before calling
match_token(). This versions calls match_token() in the argument string.
The paramenters are simpler now as well.

utf8_parse_version() was created by 9d53690f0d4 ("unicode: implement
higher level API for string handling") and later removed by 49bd03cc7e9
("unicode: pass a UNICODE_AGE() tripple to utf8_load").

Signed-off-by: André Almeida 
Link: https://lore.kernel.org/r/20241021-tonyk-tmpfs-v8-4-f443d5814194@igalia.com
Reviewed-by: Theodore Ts'o 
Reviewed-by: Gabriel Krisman Bertazi 
Signed-off-by: Christian Brauner

unicode: Export latest available UTF-8 version number

2024-10-28T12:36:54+00:00

Export latest available UTF-8 version number so filesystems can easily
load the newest one.

Signed-off-by: André Almeida 
Link: https://lore.kernel.org/r/20241021-tonyk-tmpfs-v8-3-f443d5814194@igalia.com
Acked-by: Gabriel Krisman Bertazi 
Signed-off-by: Christian Brauner

unicode: Don't special case ignorable code points

2024-10-09T17:34:01+00:00

We don't need to handle them separately. Instead, just let them
decompose/casefold to themselves.

Signed-off-by: Gabriel Krisman Bertazi

unicode: change the reference of database file

2024-09-13T15:23:01+00:00

Commit 2b3d04787012 ("unicode: Add utf8-data module") changed
the database file from 'utf8data.h' to 'utf8data.c' to build
separate module, but it seems forgot to update README.utf8data
, which may causes confusion. Update the README.utf8data and
the default 'UTF8_NAME' in 'mkutf8data.c'.

Signed-off-by: Gan Jie 
Reviewed-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/20240912031932.1161-1-ganjie182@gmail.com
Signed-off-by: Gabriel Krisman Bertazi

unicode: Fix utf8_load() error path

2024-09-03T16:45:07+00:00

utf8_load() requests the symbol "utf8_data_table" and then checks if the
requested UTF-8 version is supported. If it's unsupported, it tries to
put the data table using symbol_put(). If an unsupported version is
requested, symbol_put() fails like this:

 kernel BUG at kernel/module/main.c:786!
 RIP: 0010:__symbol_put+0x93/0xb0
 Call Trace:
  
  ? __die_body.cold+0x19/0x27
  ? die+0x2e/0x50
  ? do_trap+0xca/0x110
  ? do_error_trap+0x65/0x80
  ? __symbol_put+0x93/0xb0
  ? exc_invalid_op+0x51/0x70
  ? __symbol_put+0x93/0xb0
  ? asm_exc_invalid_op+0x1a/0x20
  ? __pfx_cmp_name+0x10/0x10
  ? __symbol_put+0x93/0xb0
  ? __symbol_put+0x62/0xb0
  utf8_load+0xf8/0x150

That happens because symbol_put() expects the unique string that
identify the symbol, instead of a pointer to the loaded symbol. Fix that
by using such string.

Fixes: 2b3d04787012 ("unicode: Add utf8-data module")
Signed-off-by: André Almeida 
Reviewed-by: Theodore Ts'o 
Link: https://lore.kernel.org/r/20240902225511.757831-2-andrealmeid@igalia.com
Signed-off-by: Gabriel Krisman Bertazi

unicode: constify utf8 data table

2024-08-13T19:21:50+00:00

All users already handle the table as const data.
Move the table itself into .rodata to guard against accidental or
malicious modifications.

Signed-off-by: Thomas Weißschuh 
Reviewed-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/20240809-unicode-const-v1-1-69968a258092@weissschuh.net
Signed-off-by: Gabriel Krisman Bertazi