On Thu, Jan 13, 2022 at 02:20:45PM +0100, Borislav Petkov wrote:
> On Thu, Jan 13, 2022 at 01:59:00PM +0100, gregkh(a)linuxfoundation.org wrote:
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > x86/mce: Remove noinstr annotation from mce_setup()
> >
> > to the 5.15-stable tree which can be found at:
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
> >
> > The filename of the patch is:
> > x86-mce-remove-noinstr-annotation-from-mce_setup.patch
> > and it can be found in the queue-5.15 subdirectory.
> >
> > If you, or anyone else, feels it should not be added to the stable tree,
> > please let <stable(a)vger.kernel.org> know about it.
> >
> >
> > From 487d654db3edacc31dee86b10258cc740640fad8 Mon Sep 17 00:00:00 2001
> > From: Borislav Petkov <bp(a)suse.de>
> > Date: Tue, 5 Oct 2021 19:54:47 +0200
> > Subject: x86/mce: Remove noinstr annotation from mce_setup()
> >
> > From: Borislav Petkov <bp(a)suse.de>
> >
> > commit 487d654db3edacc31dee86b10258cc740640fad8 upstream.
> >
> > Instead, sandwitch around the call which is done in noinstr context and
> > mark the caller - mce_gather_info() - as noinstr.
> >
> > Also, document what the whole instrumentation strategy with #MC is going
> > to be in the future and where it all is supposed to be going to.
> >
> > Signed-off-by: Borislav Petkov <bp(a)suse.de>
> > Link: https://lore.kernel.org/r/20211208111343.8130-5-bp@alien8.de
> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> > ---
> > arch/x86/kernel/cpu/mce/core.c | 26 ++++++++++++++++++++------
> > 1 file changed, 20 insertions(+), 6 deletions(-)
>
> I wonder how that can ever be stable material... or are you backporting
> something else and you need this?
I was trying to get rid of this build warning I see with 5.16:
vmlinux.o: warning: objtool: mce_setup()+0x22: call to memset() leaves .noinstr.text section
vmlinux.o: warning: objtool: do_machine_check()+0x9b: call to mce_gather_info() leaves .noinstr.text section
But with this commit applied I now see this:
vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: do_machine_check()+0x183: call to memset() leaves .noinstr.text section
So it didn't help that much.
Any hints on how to get rid of this? More patches in the series this
one came from?
thanks,
greg k-h
The mapping from enum port to whatever port numbering scheme is used by
the SWSCI Display Power State Notification is odd, and the memory of it
has faded. In any case, the parameter only has space for ports numbered
[0..4], and UBSAN reports bit shift beyond it when the platform has port
F or more.
Since the SWSCI functionality is supposed to be obsolete for new
platforms (i.e. ones that might have port F or more), just bail out
early if the mapped and mangled port number is beyond what the Display
Power State Notification can support.
Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable")
Cc: <stable(a)vger.kernel.org> # v3.13+
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
---
drivers/gpu/drm/i915/display/intel_opregion.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c b/drivers/gpu/drm/i915/display/intel_opregion.c
index af9d30f56cc1..ad1afe9df6c3 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -363,6 +363,21 @@ int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,
port++;
}
+ /*
+ * The port numbering and mapping here is bizarre. The now-obsolete
+ * swsci spec supports ports numbered [0..4]. Port E is handled as a
+ * special case, but port F and beyond are not. The functionality is
+ * supposed to be obsolete for new platforms. Just bail out if the port
+ * number is out of bounds after mapping.
+ */
+ if (port > 4) {
+ drm_dbg_kms(&dev_priv->drm,
+ "[ENCODER:%d:%s] port %c (index %u) out of bounds for display power state notification\n",
+ intel_encoder->base.base.id, intel_encoder->base.name,
+ port_name(intel_encoder->port), port);
+ return -EINVAL;
+ }
+
if (!enable)
parm |= 4 << 8;
--
2.30.2
When bfqq is shared by multiple processes it can happen that one of the
processes gets moved to a different cgroup (or just starts submitting IO
for different cgroup). In case that happens we need to split the merged
bfqq as otherwise we will have IO for multiple cgroups in one bfqq and
we will just account IO time to wrong entities etc.
Similarly if the bfqq is scheduled to merge with another bfqq but the
merge didn't happen yet, cancel the merge as it need not be valid
anymore.
CC: stable(a)vger.kernel.org
Fixes: e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
block/bfq-cgroup.c | 25 ++++++++++++++++++++++++-
block/bfq-iosched.c | 2 +-
block/bfq-iosched.h | 1 +
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 24a5c5329bcd..dbc117e00783 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -730,8 +730,31 @@ static struct bfq_group *__bfq_bic_change_cgroup(struct bfq_data *bfqd,
if (sync_bfqq) {
entity = &sync_bfqq->entity;
- if (entity->sched_data != &bfqg->sched_data)
+ if (entity->sched_data != &bfqg->sched_data) {
+ /*
+ * Was the queue we use merged to a different queue?
+ * Detach process from the queue as merge need not be
+ * valid anymore. We cannot easily cancel the merge as
+ * there may be other processes scheduled to this
+ * queue.
+ */
+ if (sync_bfqq->new_bfqq) {
+ bfq_put_cooperator(sync_bfqq);
+ bfq_release_process_ref(bfqd, sync_bfqq);
+ bic_set_bfqq(bic, NULL, 1);
+ return bfqg;
+ }
+ /*
+ * Moving bfqq that is shared with another process?
+ * Split the queues at the nearest occasion as the
+ * processes can be in different cgroups now.
+ */
+ if (bfq_bfqq_coop(sync_bfqq)) {
+ bic->stably_merged = false;
+ bfq_mark_bfqq_split_coop(sync_bfqq);
+ }
bfq_bfqq_move(bfqd, sync_bfqq, bfqg);
+ }
}
return bfqg;
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 0da47f2ca781..361d321b012a 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -5184,7 +5184,7 @@ static void bfq_put_stable_ref(struct bfq_queue *bfqq)
bfq_put_queue(bfqq);
}
-static void bfq_put_cooperator(struct bfq_queue *bfqq)
+void bfq_put_cooperator(struct bfq_queue *bfqq)
{
struct bfq_queue *__bfqq, *next;
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index a73488eec8a4..6e250db2138e 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -976,6 +976,7 @@ void bfq_weights_tree_remove(struct bfq_data *bfqd,
void bfq_bfqq_expire(struct bfq_data *bfqd, struct bfq_queue *bfqq,
bool compensate, enum bfqq_expiration reason);
void bfq_put_queue(struct bfq_queue *bfqq);
+void bfq_put_cooperator(struct bfq_queue *bfqq);
void bfq_end_wr_async_queues(struct bfq_data *bfqd, struct bfq_group *bfqg);
void bfq_release_process_ref(struct bfq_data *bfqd, struct bfq_queue *bfqq);
void bfq_schedule_dispatch(struct bfq_data *bfqd);
--
2.31.1