I've edited this question to generalize it a big deal.
Questions about opening/interacting with a file from kernel space have been asked a number of times already, e.g. here or here. Especially this one had a very useful answer to me, with pointers to other resources why it's usually a bad idea and how to do it anyway. Any of these solutions ("how to do it anyway") date back a few years, before set_fs() was deprecated. Now this question can be read in two parts.
First, out of curiosity, because I couldn't find any explanation, is there another technique to still do what above resources did using set_fs()?
And second, there might be use cases, where a kernel module only provides a file-based interface and doesn't export anything else. It might still be useful to interact with it from another kernel module. Assuming I can't patch the original module, I'd need to communicate with this file then, from within the kernel. Let's take kcov as an example, it uses a debugfs file for its IO, but doesn't do much more with it than to store its central struct kcov in filp->private_data. In such cases it seems like a full-featured open etc. might not even be necessary, it could suffice to get the pointers from struct file_operations and to get/assemble file/inode/dentry to have appropriate parameters for these functions.
Why don't you simply patch the original thing? - I might still do this when the answer to this question tells me there is no reasonable other option.