Rusty Russell wrote:
> On Tue, 2007-09-25 at 12:36 +0900, Tejun Heo wrote:
>> Rusty Russell wrote:
>>> As stated you cannot protect arbitrary code this way, as you are trying
>>> to do. I do not think you've broken any of the current code, but I
>>> cannot tell. You're certainly going to surprise unsuspecting future
>>> authors.
>> Can you elaborate a bit? Why can't it protect the code?
>
> Because you don't know what that code does. After all, it's assumed
> that module code doesn't get called after exit and you're deliberately
> violating that assumption.
What I meant by protecting 'code' was the 'code' itself. Those pages
containing instructions that cpu executes. It of course can't protect
against all the things they do.
>>> Can you really not figure out the module owner of the sysfs entry to inc
>>> its use count during this procedure? (__module_get()).
>> I can but I don't think it's worth the effort. It will involve passing
>> @owner parameter down through kobject to sysfs but the path is pretty
>> obscure and thus difficult to test.
>
> Have you tested that *this* path works? Let's take your first change as
> an example:
>
> + mutex_lock(&gdev->reg_mutex);
> + __ccwgroup_remove_symlinks(gdev);
> + device_unregister(dev);
> + mutex_unlock(&gdev->reg_mutex);
>
> Now, are you sure that calling cleanup_ccwgroup just after
> device_unregister() works?
>
> static void __exit
> cleanup_ccwgroup (void)
> {
> bus_unregister (&ccwgroup_bus_type);
> }
It should. After ->exit() is called, there can't be any object left
behind. If a module is hosting objects which can't be destroyed from
->exit(), its module ref count shouldn't be zero. So, either 1.
refcount != 0 or 2. ->exit() can destroy all objects. As Cornelia
explains, for ccwgroup, it's #1. Note that unload inhibition doesn't
change anything about this.
>> I think it's too much work for the
>> users of the API and it will be easy to pass the wrong @owner and go
>> unnoticed.
>
> But your shortcut insists that all module authors be aware that
> functions can be running after exit() is called. That's a recipe for
> instability and disaster.
No, it doesn't change that at all. All unload inhibition does is
postponing removal of code (and data too of course) section a bit so
that a module can host code which issues unloading of itself. Object
synchronization rules remain exactly the same. Formerly broken code is
still broken and I don't even think unload inhibition would mask them
too much either.
I think the naming is too ambiguous. Maybe it should be named something
like "hold_module_for_suicide".
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
