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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 15 Feb 2021 07:22:51 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "hdegoede@...hat.com" <hdegoede@...hat.com>,
        "linux@...ck-us.net" <linux@...ck-us.net>
CC:     "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "wim@...ux-watchdog.org" <wim@...ux-watchdog.org>,
        "sre@...nel.org" <sre@...nel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "mgross@...ux.intel.com" <mgross@...ux.intel.com>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "wens@...e.org" <wens@...e.org>,
        "saravanak@...gle.com" <saravanak@...gle.com>,
        "heikki.krogerus@...ux.intel.com" <heikki.krogerus@...ux.intel.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "jroedel@...e.de" <jroedel@...e.de>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "agross@...nel.org" <agross@...nel.org>,
        "cw00.choi@...sung.com" <cw00.choi@...sung.com>
Subject: Re: [RFC PATCH 1/7] drivers: base: Add resource managed version of
 delayed work init


On Sat, 2021-02-13 at 16:59 +0100, Hans de Goede wrote:
> Hi,
> 
> On 2/13/21 4:27 PM, Guenter Roeck wrote:
> > On 2/13/21 7:03 AM, Hans de Goede wrote:
> > [ ... ]
> > > I think something like this should work:
> > > 
> > > static int devm_delayed_work_autocancel(struct device *dev,
> > > struct delayed_work *w,
> > > 					void (*worker)(struct
> > > work_struct *work)) {
> > > 	INIT_DELAYED_WORK(w, worker);
> > > 	return devm_add_action(dev, (void (*action)(void
> > > *))cancel_delayed_work_sync, w);
> > > }
> > > 
> > > I'm not sure about the cast, that may need something like this
> > > instead:
> > > 
> > > typedef void (*devm_action_func)(void *);
> > > 
> > > static int devm_delayed_work_autocancel(struct device *dev,
> > > struct delayed_work *w,
> > > 					void (*worker)(struct
> > > work_struct *work)) {
> > > 	INIT_DELAYED_WORK(w, worker);
> > > 	return devm_add_action(dev,
> > > (devm_action_func)cancel_delayed_work_sync, w);
> > 
> > Unfortunately, you can not type cast function pointers in C. It is
> > against the C ABI.
> > I am sure it is done in a few places in the kernel anyway, but
> > those are wrong.
> 
> I see, bummer.

I think using devm_add_action() is still a good idea.

> 
> If we add a devm_clk_prepare_enable() helper that should probably be
> added
> to drivers/clk/clk-devres.c and not to drivers/base/devres.c .
> 
> I also still wonder if we cannot find a better place for this new
> devm_delayed_work_autocancel() helper but nothing comes to mind.

I don't like the idea of including device.h from workqueue.h - and I
think this would be necessary if we added
devm_delayed_work_autocancel() as inline in workqueue.h, right?

I also see strong objection towards the devm managed clean-ups.

How about adding some devm-helpers.c in drivers/base - where we could
collect devm-based helpers - and which could be enabled by own CONFIG -
and left out by those who dislike it?

I know I wrote that the devm_delayed_work_autocancel() does probably
not warrant own file - but if you can foresee devm_work_autocancel()
and few other generally useful helpers - then we would have a place for
those. The devm stuff should in my opinion live under drivers/.

Best Regards
	Matti Vaittinen

Powered by blists - more mailing lists