From: Johannes Berg <johannes@sipsolutions.net>
To: Christian Lamparter <chunkeey@googlemail.com>,
Andrey Konovalov <andreyknvl@google.com>
Cc: Kalle Valo <kvalo@codeaurora.org>,
linux-wireless@vger.kernel.org, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
Kostya Serebryany <kcc@google.com>,
syzkaller <syzkaller@googlegroups.com>,
Stephen Boyd <sboyd@codeaurora.org>, Tejun Heo <tj@kernel.org>,
Yong Zhang <yong.zhang0@gmail.com>
Subject: Re: [RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds
Date: Sun, 24 Sep 2017 16:13:38 +0200 [thread overview]
Message-ID: <1506262418.2909.1.camel@sipsolutions.net> (raw)
In-Reply-To: <2589427.Vd4nrgaY4N@debian64> (sfid-20170923_213736_879752_15E98466)
On Sat, 2017-09-23 at 21:37 +0200, Christian Lamparter wrote:
> But this also begs the question: Is this really working then?
> From what I can tell, if CONFIG_LOCKDEP is not set then there's no
> BUG no WARN, no other splat or any other odd system behaviour. Does
> [cancel | flush]_[delayed_]work[_sync] really "just work" by
> *accident*, as long the delayed_work | work_struct is zeroed out?
It looks like it does, but I'm not sure it's not more or less by
accident. Look at get_work_pool() for example, it might actually return
non-NULL in this case, and then in start_flush_work() you'll probably
fall into one of the few "already_gone" cases.
> And should it work in the future as well?
I guess it's not really guaranteed, the API doesn't state anything to
that effect. Not that I'm looking forward to a new workqueue rewrite ;)
johannes
next prev parent reply other threads:[~2017-09-24 14:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 18:37 usb/net/p54: trying to register non-static key in p54_unregister_leds Andrey Konovalov
2017-09-20 19:27 ` Christian Lamparter
2017-09-20 19:55 ` Johannes Berg
2017-09-21 18:22 ` Andrey Konovalov
2017-09-23 19:37 ` [RESEND] " Christian Lamparter
2017-09-24 14:13 ` Johannes Berg [this message]
2017-09-26 15:06 ` Andrey Konovalov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1506262418.2909.1.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=andreyknvl@google.com \
--cc=chunkeey@googlemail.com \
--cc=dvyukov@google.com \
--cc=kcc@google.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sboyd@codeaurora.org \
--cc=syzkaller@googlegroups.com \
--cc=tj@kernel.org \
--cc=yong.zhang0@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.