Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190204220952.30761-1-TheSven73@googlemail.com>
 <CAGXu5jJ0g1FUd3mX=RkJCN=BazaWWybAuapvjngpLcWtz3FQGw@mail.gmail.com>
 <CAGngYiUTJ0TjdTu=UB9yXRJ_mXG8LPmcuBQBDha+T5RHoRUvcQ@mail.gmail.com>
 <CAKdAkRS3mxXO9+60Lu7_3gqN9XN1CYQJGM5fcta1pG8qXm9wqw@mail.gmail.com>
 <CAGngYiWBdXc0VzpjBQmVyKi+E2rVaO2WsoiPLho0bxHnrdiDKw@mail.gmail.com>
 <CANiq72kw1=XhGhy8Ac2R9y3ws_jjo0YogoQ5D=tO+7oat=8swA@mail.gmail.com> <CAGngYiUwaWPp7=TTAN3tqPz+D+1GsPDM7uFNYY1XSTYMMm+=aA@mail.gmail.com>
In-Reply-To: <CAGngYiUwaWPp7=TTAN3tqPz+D+1GsPDM7uFNYY1XSTYMMm+=aA@mail.gmail.com>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Thu, 14 Feb 2019 02:11:09 +0100
Message-ID: <CANiq72=1f7NtehzbzL0G-qHSvORAfeyYXYHjzfBkBQX46VBxsQ@mail.gmail.com>
Subject: Re: [RFC v1 0/3] Address potential user-after-free on module unload
To:     Sven Van Asbroeck <thesven73@gmail.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Kees Cook <keescook@chromium.org>, Tejun Heo <tj@kernel.org>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Sebastian Reichel <sre@kernel.org>,
        Greg KH <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Sven,

On Sun, Feb 10, 2019 at 7:05 PM Sven Van Asbroeck <thesven73@gmail.com> wrote:
>
> For relatively straightforward problems, I'd say yes.
>
> However, the problems flagged by this script are not trivial at all.
> In many cases, the missing _sync is just a symptom of general
> synchronization issues on disconnect(), and simply adding it
> will not fix the problem. Sometimes, it's just a false positive.

Indeed! Note that I didn't mean to say they are trivial issues or that
the solution is simply to replace cancel_delayed_work() with the
_sync() version in all cases -- only that it might be a good idea to
suggest its existence (instead of only suggesting devm_, because in
cases like drivers/auxdisplay/ht16k33.c it may be the simplest fix).

Cheers,
Miguel