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>
 <20190204220952.30761-2-TheSven73@googlemail.com> <20190208170656.GL50184@devbig004.ftw2.facebook.com>
In-Reply-To: <20190208170656.GL50184@devbig004.ftw2.facebook.com>
From:   Sven Van Asbroeck <thesven73@gmail.com>
Date:   Fri, 8 Feb 2019 13:15:20 -0500
Message-ID: <CAGngYiUFQKpTUQKJtWvDftmntueb=e2AXqX=OhJLaRDKxzKxYg@mail.gmail.com>
Subject: Re: [RFC v1 1/3] workqueue: Add resource-managed version of INIT_[DELAYED_]WORK()
To:     Tejun Heo <tj@kernel.org>
Cc:     Lai Jiangshan <jiangshanlai@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Sebastian Reichel <sre@kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Kees Cook <keescook@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Tejun,

On Fri, Feb 8, 2019 at 12:07 PM Tejun Heo <tj@kernel.org> wrote:
>
> I don't object to the basic idea but cancel_[delayed_]work_sync()
> works iff queueing is disabled already, so there can be situations
> where this can lead to surprising / subtle failures.  Given that, it
> *might* not be a bad idea to keep this explicit unless there is a way
> to reliably block future queueing.
>

Yes, I'm "coming around" to your opinion myself.

There's also the question of which one is appropriate for clean-up:
cancel_work_sync() or flush_work().

And what about work scheduled on more than one workqueue?
Or work scheduled on multi-threaded workqueues?

The workqueue API sounds too complicated to have a devm_
helper. It would lull developers into a false sense of security.