linux-kernel - Re: module: Ensure a module's state is set accordingly during module coming cleanup code

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: <20161109101201.GA27196@packer-debian-8-amd64.digitalocean.com>
Date:   Wed, 9 Nov 2016 05:12:01 -0500
From:   Jessica Yu <jeyu@...hat.com>
To:     Rusty Russell <rusty@...tcorp.com.au>
Cc:     Aaron Tomlin <atomlin@...hat.com>, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org
Subject: Re: module: Ensure a module's state is set accordingly during module
 coming cleanup code

+++ Rusty Russell [26/10/16 11:24 +1030]:
>Aaron Tomlin <atomlin@...hat.com> writes:
>> In load_module() in the event of an error, for e.g. unknown module
>> parameter(s) specified we go to perform some module coming clean up
>> operations. At this point the module is still in a "formed" state
>> when it is actually going away.
>>
>> This patch updates the module's state accordingly to ensure anyone on the
>> module_notify_list waiting for a module going away notification will be
>> notified accordingly.
>
>I recall a similar proposal before.
>
>I've audited all the subscribers to check they didn't look at
>mod->state; they seem OK.
>
>We actually do this in the init-failed path, so this should be OK.

We did discuss a similar proposal before:

    https://lkml.kernel.org/r/87a8m7ko6j.fsf@rustcorp.com.au

The complaint back then was that we need to be in the COMING state for
strong_try_module_get() to fail. But it will also correctly fail for GOING
modules in the module_is_live() check in the subsequent call to
try_module_get(), so I believe we are still OK here.

Jessica