On Mon, 2023-06-05 at 23:42 +0300, Mike Rapoport wrote: > > I tried this technique previously [0], and I thought it was not too > > bad. In most of the callers it looks similar to what you have in > > do_text_poke(). Sometimes less, sometimes more. It might need > > enlightening of some of the stuff currently using text_poke() > > during > > module loading, like jump labels. So that bit is more intrusive, > > yea. > > But it sounds so much cleaner and well controlled. Did you have a > > particular trouble spot in mind? > > Nothing in particular, except the intrusive part. Except the changes > in > modules.c we'd need to teach alternatives to deal with a writable > copy. I didn't think alternatives piece looked too bad on the caller side (if that's what you meant): https://lore.kernel.org/lkml/20201120202426.18009-7-rick.p.edgecombe@xxxxxxxxx/ The ugly part was in the (poorly named) module_adjust_writable_addr(): +static inline void *module_adjust_writable_addr(void *addr) +{ + unsigned long laddr = (unsigned long)addr; + struct module *mod; + + mutex_lock(&module_mutex); + mod = __module_address(laddr); + if (!mod) { + mutex_unlock(&module_mutex); + return addr; + } + mutex_unlock(&module_mutex); + /* The module shouldn't be going away if someone is trying to write to it */ + + return (void *)perm_writable_addr(module_get_allocation(mod, laddr), laddr); +} + It took module_mutex and looked up the module in order to find the writable buffer from just the executable address. Basically all the loading code external to modules had to go through that interface. But now I'm wondering what I was thinking, it seems this could just be an RCU read lock. That doesn't seem to bad...
