linux-kernel - Re: [PATCH 2/2] lib: Remove module auto-unloading which encourages inconsistent behaviour

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VdyyqVk_gwX007j3SiSe2nJwou+pa9=FT_EBnFT+VEbmQ@mail.gmail.com>
Date:   Fri, 29 Dec 2017 18:47:04 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Pravin Shedge <pravin.shedge4linux@...il.com>
Cc:     dave@...olabs.net, Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] lib: Remove module auto-unloading which encourages
 inconsistent behaviour

On Sat, Dec 23, 2017 at 5:28 PM, Pravin Shedge
<pravin.shedge4linux@...il.com> wrote:
> The module auto-unload might seem like a nice optimization, but
> it encourages inconsistent behaviour. And behaviour that is
> different from all other normal modules.
>
> rbtree_test.c and percpu_test.c returns -EAGAIN from module_init()
> on successful completion. Normal module return 0 on success but
> returning -EAGAIN perform auto module unloading which seem like
> a nice optimization but it brings inconsistent behaviour as well.
>
> I face the similar problem in my previous patch, "Paul Gortmaker"
> gives nice review comment on module auto-unloading brings
> inconsistent behaviour.
>
> Imagine something as simple as this:
>
>         for i in $LIST ; do
>                 modprobe $i
>                 lsmod | grep -q $i
>                 if [ $? != 0 ]; then echo Module $i is not present! ; fi
>         done
>
> OK, not ideal code, ignoring the modprobe return -- but what it reports
> is true --
> rbtree_test.c and percpu_test.c test module (if it passed) will NOT be
> present.
>
> All other modules from linux/lib/* follow the same semantics that
> module_init() returns 0 on successful completion & let external entity
> like rmmod do the module unloading task.
>

Suggested-by: Andrew ... ?

> Signed-off-by: Pravin Shedge <pravin.shedge4linux@...il.com>
> ---
>  lib/percpu_test.c | 3 ++-
>  lib/rbtree_test.c | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/percpu_test.c b/lib/percpu_test.c
> index 0b5d14d..57a637b 100644
> --- a/lib/percpu_test.c
> +++ b/lib/percpu_test.c
> @@ -123,7 +123,8 @@ static int __init percpu_test_init(void)
>         preempt_enable();
>
>         pr_info("percpu test done\n");
> -       return -EAGAIN;  /* Fail will directly unload the module */
> +
> +       return 0;
>  }
>
>  static void __exit percpu_test_exit(void)
> diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
> index 7d36c1e..5c52112 100644
> --- a/lib/rbtree_test.c
> +++ b/lib/rbtree_test.c
> @@ -394,7 +394,7 @@ static int __init rbtree_test_init(void)
>
>         kfree(nodes);
>
> -       return -EAGAIN; /* Fail will directly unload the module */
> +       return 0;
>  }
>
>  static void __exit rbtree_test_exit(void)
> --
> 2.7.4
>



-- 
With Best Regards,
Andy Shevchenko