From: Peter Zijlstra <peterz@infradead.org>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
amd-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, jani.nikula@intel.com,
ville.syrjala@linux.intel.com, daniel.vetter@ffwll.ch,
seanpaul@chromium.org, robdclark@gmail.com, jbaron@akamai.com,
gregkh@linuxfoundation.org
Subject: Re: [PATCH v2 20/20] jump_label: RFC - tolerate toggled state
Date: Tue, 17 Jan 2023 12:57:39 +0100 [thread overview]
Message-ID: <Y8aNMxHpvZ8qecSc@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230113193016.749791-21-jim.cromie@gmail.com>
On Fri, Jan 13, 2023 at 12:30:16PM -0700, Jim Cromie wrote:
> __jump_label_patch currently will "crash the box" if it finds a
> jump_entry not as expected. ISTM this overly harsh; it doesn't
> distinguish between "alternate/opposite" state, and truly
> "insane/corrupted".
>
> The "opposite" (but well-formed) state is a milder mis-initialization
> problem, and some less severe mitigation seems practical. ATM this
> just warns about it; a range/enum of outcomes: warn, crash, silence,
> ok, fixup-continue, etc, are possible on a case-by-case basis.
>
> Ive managed to create this mis-initialization condition with
> test_dynamic_debug.ko & _submod.ko. These replicate DRM's regression
> on DRM_USE_DYNAMIC_DEBUG=y; drm.debug callsites in drivers/helpers
> (dependent modules) are not enabled along with those in drm.ko itself.
>
> Ive hit this case a few times, but havent been able to isolate the
> when and why.
>
> warn-only is something of a punt, and I'm still left with remaining
> bugs which are likely related; I'm able to toggle the p-flag on
> callsites in the submod, but their enablement still doesn't yield
> logging activity.
Right; having been in this is state is bad since it will generate
inconsistent code-flow. Full on panic *might* not be warranted (as it
does for corrupted text) but it is still a fairly bad situation -- so
I'm not convinced we want to warn and carry on.
It would be really good to figure out why the site was skipped over and
got out of skew.
Given it's all module stuff, the 'obvious' case would be something like
a race between adding the new sites and flipping it, but I'm not seeing
how -- things are rather crudely serialized by jump_label_mutex.
The only other option I can come up with is that somehow the update
condition in jump_label_add_module() is somehow wrong.
next prev parent reply other threads:[~2023-01-17 11:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 19:29 [PATCH v2 00/20] DRM_USE_DYNAMIC_DEBUG regression Jim Cromie
2023-01-13 19:29 ` [PATCH v2 01/20] test-dyndbg: fixup CLASSMAP usage error Jim Cromie
2023-01-13 19:29 ` [PATCH v2 02/20] test-dyndbg: show that DEBUG enables prdbgs at compiletime Jim Cromie
2023-01-13 19:29 ` [PATCH v2 03/20] dyndbg: replace classmap list with a vector Jim Cromie
2023-01-13 19:30 ` [PATCH v2 04/20] dyndbg: make ddebug_apply_class_bitmap more selective Jim Cromie
2023-01-13 19:30 ` [PATCH v2 05/20] dyndbg: split param_set_dyndbg_classes to inner/outer Jim Cromie
2023-01-13 19:30 ` [PATCH v2 06/20] dyndbg: drop NUM_TYPE_ARRAY Jim Cromie
2023-01-13 19:30 ` [PATCH v2 07/20] dyndbg: reduce verbose/debug clutter Jim Cromie
2023-01-13 19:30 ` [PATCH v2 08/20] dyndbg: tighten ddebug_class_name() 1st arg Jim Cromie
2023-01-13 19:30 ` [PATCH v2 09/20] dyndbg: constify ddebug_apply_class_bitmap args Jim Cromie
2023-01-13 19:30 ` [PATCH v2 10/20] dyndbg-API: split DECLARE_(DYNDBG_CLASSMAP) to $1(_DEFINE|_USE) Jim Cromie
2023-01-13 19:30 ` [PATCH v2 11/20] dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE) Jim Cromie
2023-01-13 19:30 ` [PATCH v2 12/20] dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args Jim Cromie
2023-01-13 19:30 ` [PATCH v2 13/20] dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements Jim Cromie
2023-01-13 19:30 ` [PATCH v2 14/20] drm_print: fix stale macro-name in comment Jim Cromie
2023-01-13 19:30 ` [PATCH v2 15/20] test-dyndbg: build test_dynamic_debug_submod Jim Cromie
2023-01-13 19:30 ` [PATCH v2 16/20] test-dyndbg: rename DD_SYS_WRAP to DYNDBG_CLASSMAP_PARAM Jim Cromie
2023-01-13 19:30 ` [PATCH v2 17/20] test-dyndbg: disable WIP dyndbg-trace params Jim Cromie
2023-01-13 19:30 ` [PATCH v2 18/20] test-dyndbg: tune sub-module behavior Jim Cromie
2023-01-13 19:30 ` [PATCH v2 19/20] dyndbg: unwrap __ddebug_add_module inner function NOTYET Jim Cromie
2023-01-13 19:30 ` [PATCH v2 20/20] jump_label: RFC - tolerate toggled state Jim Cromie
2023-01-17 11:57 ` Peter Zijlstra [this message]
2023-02-16 17:21 ` Jason Baron
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=Y8aNMxHpvZ8qecSc@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jbaron@akamai.com \
--cc=jim.cromie@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=seanpaul@chromium.org \
--cc=ville.syrjala@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox