0

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.

Simon
  • 31
  • 1
  • 4
  • 1
    You can export necessary methods from the module and use them in another module. Not a big deal at all. Also you can use an introspection (as kprobe or tracing mechanisms do). But I believe you are trying to solve something (which is unknown from your Q) from a very wrong side. – 0andriy Dec 18 '22 at 14:40
  • I don't like the idea of patching kcov. There is a patch to do that already. You're telling something is unclear from my question, I don't really understand what that is. I need to interact with kcov from another kernel module, without changing kcov. The only thing it provides is the character device. Of course, I described my previous attempts, and they are certainly wrong. And in fact I'm new to kernel development and need to gain an overview, yet. I am not determined to use fs facilities or not, I'm just looking for a way to get the pointers from kcov's `file_operations`. – Simon Dec 18 '22 at 16:29
  • "which has a member `i_fop`, but it cannot be accessed, probably due to the fact that it is a user space address." - No, all "operations" structs are stored in the kernel space. So it is clear what is your problem. Also, files can still be opened in the kernel space: https://stackoverflow.com/questions/1184274/read-write-files-within-a-linux-kernel-module – Tsyvarev Dec 18 '22 at 17:01
  • I can only tell that, e.g. `i_fop->open` segfaults. What do you mean by "it is clear what your problem is"? Regarding the linked question, I've read a couple of similar ones, but there is [a problem](https://lwn.net/Articles/832121/) with `set_fs` – Simon Dec 18 '22 at 18:54
  • Oops, I meant that your problem is NOT clear. BTW, your answer describes how to fix the code which is not even contained in the question post (the **call** of the `open` method). – Tsyvarev Dec 19 '22 at 18:37
  • Calling `open` is intended as a representative of the more general _interaction_ I asked for. I was under the impression this is sufficiently clear. I'm not an experienced SO participant, though. I'd be glad if you'd give me some pointers how to put that better. – Simon Dec 19 '22 at 20:17
  • It's unclear what you are trying to do that prevents you a) to patch `kcov`, and b) find a better way than ugly hacking in the kernel. I.o.w. try to look at this outside the box. – 0andriy Dec 20 '22 at 09:16
  • a) `kcov` is just an example. It could be anything. People were asking the same question already, when `set_fs` was still a thing. b) If you tell me there is no proper way, that's still a valid answer, but I can't imagine that might be the case. – Simon Dec 20 '22 at 10:21
  • 2
    There is no proper way because the kernel is written to provide independent, self-contained services to program logic in userspace. Putting logic in the kernel is not the way Linux works. – stark Dec 20 '22 at 14:01
  • In that case I have to vote to close this question as it's unclear what do you want. `set_fs()` was a hack that had been eventually removed, thanks god! – 0andriy Dec 27 '22 at 18:15

0 Answers0