Re: [PATCH v2] rust: place generated init_module() function in .init.text

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Tue, Feb 6, 2024 at 11:50 AM Greg KH <greg@kroah.com> wrote:
>
> Cool, but has anyone tested it?

Yeah, in C, I see some warnings from modpost (section mismatch, plus
the explicitly exported symbol), but it does not seem to catch all
cases under `defconfig` at least.

In Rust, similarly, I also get the warning in some cases, but not all;
e.g. I had to force the function to be non-inline so that modpost can
notice.

Anyway, the "unsafe" approach (or hiding the functions completely
inside a `const` if possible, but IIRC from a previous discussion that
required rearranging things a bit due to the global asm block --
ideally Rust would provide anonymous modules) would be even better.

> It's not "unsafe" at all!  It's totally normal, and "safe" and should be
> used for many types of modules.  If you get it "wrong" the linker will
> catch the issue, so what is unsafe?

In Rust's terminology, "unsafe function" does not mean "wrong" or
"broken" or "always triggers UB", it just means there are safety
preconditions, i.e. "it is UB if you break my preconditions;
otherwise, there isn't UB".

In other words, it means that callers need to be careful (and cannot
call the function without using unsafe Rust) and they also are
required (via a comment) why their call is correct.

So if we do not want any Rust caller to call this function, we could
say "Rust callers must not call this function". Even if the function
could be obviously called in other cases.

Put another way, as a function writer, you can hide "use cases" if you
do not want to support them. Even if they happen to work today. You
can think of it as opaque/private members in structs, but for
functions, i.e. contracts.

So if it is an unintended use case, it is better to catch it as early
as possible, even assuming there is another safety net somewhere else
that catches that too.

Cheers,
Miguel