On Mon, Oct 02, 2023 at 08:21:43AM +0100, Al Viro wrote: > On Mon, Oct 02, 2023 at 08:14:01AM +0100, Al Viro wrote: > > On Mon, Oct 02, 2023 at 08:49:12AM +0200, Christoph Hellwig wrote: > > > Instead of all this duplicatio in the file system, can we please just > > > add a > > > > > > struct nls_table *s_nls; > > > > > > to struct super_block and RCU free it in common code and drop all the > > > code in the file systems? > > > > It makes no sense for most of the filesystems, for one thing (note that > > any use in ->lookup() does not warrant rcu delays). What's more, > > how do you formulate the rules for what goes in that field when filesystem > > uses more than one nls_table? > > Consider e.g. HFS; two separate nls_table (nls_disk, nls_io), neither needs > RCU delays of any sort. On VFAT, for that matter - again, two tables, > one needs RCU delay, another doesn't (both get dropped from the same > helper, so both get it). BTW, is there any reason not to have synchronize_rcu() in delete_module(2), just before calling ->exit()? It's not a hot path, unless something really weird is going on, and it would get rid of the need to delay unload_nls() calls...
