* [PATCH 6.0 01/20] drm/i915/bios: Validate fp_timing terminator presence
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 02/20] drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers Greg Kroah-Hartman
` (30 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ville Syrjälä, Jani Nikula
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 4e78d6023c15c6acce8fbe42e13027c460395522 upstream.
Validate the LFP data block a bit hardwer by making sure the
fp_timing terminators (0xffff) are where we expect them to be.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_bios.c | 60 ++++++++++++++++--------------
1 file changed, 32 insertions(+), 28 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -135,18 +135,6 @@ static u32 raw_block_offset(const void *
return block - bdb;
}
-/* size of the block excluding the header */
-static u32 raw_block_size(const void *bdb, enum bdb_block_id section_id)
-{
- const void *block;
-
- block = find_raw_section(bdb, section_id);
- if (!block)
- return 0;
-
- return get_blocksize(block);
-}
-
struct bdb_block_entry {
struct list_head node;
enum bdb_block_id section_id;
@@ -231,9 +219,14 @@ static bool validate_lfp_data_ptrs(const
{
int fp_timing_size, dvo_timing_size, panel_pnp_id_size, panel_name_size;
int data_block_size, lfp_data_size;
+ const void *data_block;
int i;
- data_block_size = raw_block_size(bdb, BDB_LVDS_LFP_DATA);
+ data_block = find_raw_section(bdb, BDB_LVDS_LFP_DATA);
+ if (!data_block)
+ return false;
+
+ data_block_size = get_blocksize(data_block);
if (data_block_size == 0)
return false;
@@ -261,21 +254,6 @@ static bool validate_lfp_data_ptrs(const
if (16 * lfp_data_size > data_block_size)
return false;
- /*
- * Except for vlv/chv machines all real VBTs seem to have 6
- * unaccounted bytes in the fp_timing table. And it doesn't
- * appear to be a really intentional hole as the fp_timing
- * 0xffff terminator is always within those 6 missing bytes.
- */
- if (fp_timing_size + dvo_timing_size + panel_pnp_id_size != lfp_data_size &&
- fp_timing_size + 6 + dvo_timing_size + panel_pnp_id_size != lfp_data_size)
- return false;
-
- if (ptrs->ptr[0].fp_timing.offset + fp_timing_size > ptrs->ptr[0].dvo_timing.offset ||
- ptrs->ptr[0].dvo_timing.offset + dvo_timing_size != ptrs->ptr[0].panel_pnp_id.offset ||
- ptrs->ptr[0].panel_pnp_id.offset + panel_pnp_id_size != lfp_data_size)
- return false;
-
/* make sure the table entries have uniform size */
for (i = 1; i < 16; i++) {
if (ptrs->ptr[i].fp_timing.table_size != fp_timing_size ||
@@ -289,6 +267,23 @@ static bool validate_lfp_data_ptrs(const
return false;
}
+ /*
+ * Except for vlv/chv machines all real VBTs seem to have 6
+ * unaccounted bytes in the fp_timing table. And it doesn't
+ * appear to be a really intentional hole as the fp_timing
+ * 0xffff terminator is always within those 6 missing bytes.
+ */
+ if (fp_timing_size + 6 + dvo_timing_size + panel_pnp_id_size == lfp_data_size)
+ fp_timing_size += 6;
+
+ if (fp_timing_size + dvo_timing_size + panel_pnp_id_size != lfp_data_size)
+ return false;
+
+ if (ptrs->ptr[0].fp_timing.offset + fp_timing_size != ptrs->ptr[0].dvo_timing.offset ||
+ ptrs->ptr[0].dvo_timing.offset + dvo_timing_size != ptrs->ptr[0].panel_pnp_id.offset ||
+ ptrs->ptr[0].panel_pnp_id.offset + panel_pnp_id_size != lfp_data_size)
+ return false;
+
/* make sure the tables fit inside the data block */
for (i = 0; i < 16; i++) {
if (ptrs->ptr[i].fp_timing.offset + fp_timing_size > data_block_size ||
@@ -300,6 +295,15 @@ static bool validate_lfp_data_ptrs(const
if (ptrs->panel_name.offset + 16 * panel_name_size > data_block_size)
return false;
+ /* make sure fp_timing terminators are present at expected locations */
+ for (i = 0; i < 16; i++) {
+ const u16 *t = data_block + ptrs->ptr[i].fp_timing.offset +
+ fp_timing_size - 2;
+
+ if (*t != 0xffff)
+ return false;
+ }
+
return true;
}
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 02/20] drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 01/20] drm/i915/bios: Validate fp_timing terminator presence Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 03/20] pinctrl: amd: change dev_warn to dev_dbg for additional feature support Greg Kroah-Hartman
` (29 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ville Syrjälä, Jani Nikula
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit d3a7051841f0a4bcb1ee26a1b721c6150cc4c2b1 upstream.
The current scheme for generating the LFP data table pointers
(when the block including them is missing from the VBT) expects
the 0xffff sequence to only appear in the fp_timing terminator
entries. However some VBTs also have extra 0xffff sequences
elsewhere in the LFP data. When looking for the terminators
we may end up finding those extra sequeneces insted, which means
we deduce the wrong size for the fp_timing table. The code
then notices the inconsistent looking values and gives up on
the generated data table pointers, preventing us from parsing
the LFP data table entirely.
Let's give up on the "search for the terminators" approach
and instead just hardcode the expected size for the fp_timing
table.
We have enough sanity checks in place to make sure we
shouldn't end up parsing total garbage even if that size
should change in the future (although that seems unlikely
as the fp_timing and dvo_timing tables have been declared
obsolete as of VBT version 229).
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_bios.c | 46 +++++++++++-------------------
1 file changed, 18 insertions(+), 28 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -337,18 +337,6 @@ static bool fixup_lfp_data_ptrs(const vo
return validate_lfp_data_ptrs(bdb, ptrs);
}
-static const void *find_fp_timing_terminator(const u8 *data, int size)
-{
- int i;
-
- for (i = 0; i < size - 1; i++) {
- if (data[i] == 0xff && data[i+1] == 0xff)
- return &data[i];
- }
-
- return NULL;
-}
-
static int make_lfp_data_ptr(struct lvds_lfp_data_ptr_table *table,
int table_size, int total_size)
{
@@ -372,11 +360,22 @@ static void next_lfp_data_ptr(struct lvd
static void *generate_lfp_data_ptrs(struct drm_i915_private *i915,
const void *bdb)
{
- int i, size, table_size, block_size, offset;
- const void *t0, *t1, *block;
+ int i, size, table_size, block_size, offset, fp_timing_size;
struct bdb_lvds_lfp_data_ptrs *ptrs;
+ const void *block;
void *ptrs_block;
+ /*
+ * The hardcoded fp_timing_size is only valid for
+ * modernish VBTs. All older VBTs definitely should
+ * include block 41 and thus we don't need to
+ * generate one.
+ */
+ if (i915->vbt.version < 155)
+ return NULL;
+
+ fp_timing_size = 38;
+
block = find_raw_section(bdb, BDB_LVDS_LFP_DATA);
if (!block)
return NULL;
@@ -385,17 +384,8 @@ static void *generate_lfp_data_ptrs(stru
block_size = get_blocksize(block);
- size = block_size;
- t0 = find_fp_timing_terminator(block, size);
- if (!t0)
- return NULL;
-
- size -= t0 - block - 2;
- t1 = find_fp_timing_terminator(t0 + 2, size);
- if (!t1)
- return NULL;
-
- size = t1 - t0;
+ size = fp_timing_size + sizeof(struct lvds_dvo_timing) +
+ sizeof(struct lvds_pnp_id);
if (size * 16 > block_size)
return NULL;
@@ -413,7 +403,7 @@ static void *generate_lfp_data_ptrs(stru
table_size = sizeof(struct lvds_dvo_timing);
size = make_lfp_data_ptr(&ptrs->ptr[0].dvo_timing, table_size, size);
- table_size = t0 - block + 2;
+ table_size = fp_timing_size;
size = make_lfp_data_ptr(&ptrs->ptr[0].fp_timing, table_size, size);
if (ptrs->ptr[0].fp_timing.table_size)
@@ -428,14 +418,14 @@ static void *generate_lfp_data_ptrs(stru
return NULL;
}
- size = t1 - t0;
+ size = fp_timing_size + sizeof(struct lvds_dvo_timing) +
+ sizeof(struct lvds_pnp_id);
for (i = 1; i < 16; i++) {
next_lfp_data_ptr(&ptrs->ptr[i].fp_timing, &ptrs->ptr[i-1].fp_timing, size);
next_lfp_data_ptr(&ptrs->ptr[i].dvo_timing, &ptrs->ptr[i-1].dvo_timing, size);
next_lfp_data_ptr(&ptrs->ptr[i].panel_pnp_id, &ptrs->ptr[i-1].panel_pnp_id, size);
}
- size = t1 - t0;
table_size = sizeof(struct lvds_lfp_panel_name);
if (16 * (size + table_size) <= block_size) {
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 03/20] pinctrl: amd: change dev_warn to dev_dbg for additional feature support
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 01/20] drm/i915/bios: Validate fp_timing terminator presence Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 02/20] drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 04/20] thermal: intel_powerclamp: Use first online CPU as control_cpu Greg Kroah-Hartman
` (28 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Basavaraj Natikar, Linus Walleij,
Mario Limonciello
From: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
commit 3160b37e5cb695e866e06c3fdbc385846b569294 upstream.
Use dev_dbg instead of dev_warn for additional support of pinmux
feature.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Link: https://lore.kernel.org/r/20220830110525.1933198-1-Basavaraj.Natikar@amd.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pinctrl/pinctrl-amd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -1051,13 +1051,13 @@ static void amd_get_iomux_res(struct amd
index = device_property_match_string(dev, "pinctrl-resource-names", "iomux");
if (index < 0) {
- dev_warn(dev, "failed to get iomux index\n");
+ dev_dbg(dev, "iomux not supported\n");
goto out_no_pinmux;
}
gpio_dev->iomux_base = devm_platform_ioremap_resource(gpio_dev->pdev, index);
if (IS_ERR(gpio_dev->iomux_base)) {
- dev_warn(dev, "Failed to get iomux %d io resource\n", index);
+ dev_dbg(dev, "iomux not supported %d io resource\n", index);
goto out_no_pinmux;
}
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 04/20] thermal: intel_powerclamp: Use first online CPU as control_cpu
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 03/20] pinctrl: amd: change dev_warn to dev_dbg for additional feature support Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 05/20] io_uring/net: fail zc send when unsupported by socket Greg Kroah-Hartman
` (27 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rafael J. Wysocki, Chen Yu
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 4bb7f6c2781e46fc5bd00475a66df2ea30ef330d upstream.
Commit 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead
of smp_processor_id() to avoid crash") fixed an issue related to using
smp_processor_id() in preemptible context by replacing it with a pair
of get_cpu()/put_cpu(), but what is needed there really is any online
CPU and not necessarily the one currently running the code. Arguably,
getting the one that's running the code in there is confusing.
For this reason, simply give the control CPU role to the first online
one which automatically will be CPU0 if it is online, so one check
can be dropped from the code for an added benefit.
Link: https://lore.kernel.org/linux-pm/20221011113646.GA12080@duo.ucw.cz/
Fixes: 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/thermal/intel/intel_powerclamp.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/drivers/thermal/intel/intel_powerclamp.c
+++ b/drivers/thermal/intel/intel_powerclamp.c
@@ -531,11 +531,7 @@ static int start_power_clamp(void)
cpus_read_lock();
/* prefer BSP */
- control_cpu = 0;
- if (!cpu_online(control_cpu)) {
- control_cpu = get_cpu();
- put_cpu();
- }
+ control_cpu = cpumask_first(cpu_online_mask);
clamping = true;
schedule_delayed_work(&poll_pkg_cstate_work, 0);
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 05/20] io_uring/net: fail zc send when unsupported by socket
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 04/20] thermal: intel_powerclamp: Use first online CPU as control_cpu Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 06/20] HID: playstation: stop DualSense output work on remove Greg Kroah-Hartman
` (26 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pavel Begunkov, Jens Axboe
From: Pavel Begunkov <asml.silence@gmail.com>
commit edf81438799ccead7122948446d7e44b083e788d upstream.
If a protocol doesn't support zerocopy it will silently fall back to
copying. This type of behaviour has always been a source of troubles
so it's better to fail such requests instead.
Cc: <stable@vger.kernel.org> # 6.0
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/2db3c7f16bb6efab4b04569cd16e6242b40c5cb3.1666346426.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
io_uring/net.c | 2 ++
1 file changed, 2 insertions(+)
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -1001,6 +1001,8 @@ int io_send_zc(struct io_kiocb *req, uns
sock = sock_from_file(req->file);
if (unlikely(!sock))
return -ENOTSOCK;
+ if (!test_bit(SOCK_SUPPORT_ZC, &sock->flags))
+ return -EOPNOTSUPP;
msg.msg_name = NULL;
msg.msg_control = NULL;
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 06/20] HID: playstation: stop DualSense output work on remove.
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 05/20] io_uring/net: fail zc send when unsupported by socket Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 07/20] HID: playstation: add initial DualSense Edge controller support Greg Kroah-Hartman
` (25 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Roderick Colenbrander, Benjamin Tissoires
From: Roderick Colenbrander <roderick@gaikai.com>
commit 182934a1e93b17f4edf71f4fcc8d19b19a6fe67a upstream.
Ensure we don't schedule any new output work on removal and wait
for any existing work to complete. If we don't do this e.g. rumble
work can get queued during deletion and we trigger a kernel crash.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
CC: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221010212313.78275-2-roderick.colenbrander@sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-playstation.c | 41 ++++++++++++++++++++++++++++++++++++-----
1 file changed, 36 insertions(+), 5 deletions(-)
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -46,6 +46,7 @@ struct ps_device {
uint32_t fw_version;
int (*parse_report)(struct ps_device *dev, struct hid_report *report, u8 *data, int size);
+ void (*remove)(struct ps_device *dev);
};
/* Calibration data for playstation motion sensors. */
@@ -174,6 +175,7 @@ struct dualsense {
struct led_classdev player_leds[5];
struct work_struct output_worker;
+ bool output_worker_initialized;
void *output_report_dmabuf;
uint8_t output_seq; /* Sequence number for output report. */
};
@@ -299,6 +301,7 @@ static const struct {int x; int y; } ps_
{0, 0},
};
+static inline void dualsense_schedule_work(struct dualsense *ds);
static void dualsense_set_lightbar(struct dualsense *ds, uint8_t red, uint8_t green, uint8_t blue);
/*
@@ -792,6 +795,7 @@ err_free:
return ret;
}
+
static int dualsense_get_firmware_info(struct dualsense *ds)
{
uint8_t *buf;
@@ -881,7 +885,7 @@ static int dualsense_player_led_set_brig
ds->update_player_leds = true;
spin_unlock_irqrestore(&ds->base.lock, flags);
- schedule_work(&ds->output_worker);
+ dualsense_schedule_work(ds);
return 0;
}
@@ -925,6 +929,16 @@ static void dualsense_init_output_report
}
}
+static inline void dualsense_schedule_work(struct dualsense *ds)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&ds->base.lock, flags);
+ if (ds->output_worker_initialized)
+ schedule_work(&ds->output_worker);
+ spin_unlock_irqrestore(&ds->base.lock, flags);
+}
+
/*
* Helper function to send DualSense output reports. Applies a CRC at the end of a report
* for Bluetooth reports.
@@ -1085,7 +1099,7 @@ static int dualsense_parse_report(struct
spin_unlock_irqrestore(&ps_dev->lock, flags);
/* Schedule updating of microphone state at hardware level. */
- schedule_work(&ds->output_worker);
+ dualsense_schedule_work(ds);
}
ds->last_btn_mic_state = btn_mic_state;
@@ -1200,10 +1214,22 @@ static int dualsense_play_effect(struct
ds->motor_right = effect->u.rumble.weak_magnitude / 256;
spin_unlock_irqrestore(&ds->base.lock, flags);
- schedule_work(&ds->output_worker);
+ dualsense_schedule_work(ds);
return 0;
}
+static void dualsense_remove(struct ps_device *ps_dev)
+{
+ struct dualsense *ds = container_of(ps_dev, struct dualsense, base);
+ unsigned long flags;
+
+ spin_lock_irqsave(&ds->base.lock, flags);
+ ds->output_worker_initialized = false;
+ spin_unlock_irqrestore(&ds->base.lock, flags);
+
+ cancel_work_sync(&ds->output_worker);
+}
+
static int dualsense_reset_leds(struct dualsense *ds)
{
struct dualsense_output_report report;
@@ -1240,7 +1266,7 @@ static void dualsense_set_lightbar(struc
ds->lightbar_blue = blue;
spin_unlock_irqrestore(&ds->base.lock, flags);
- schedule_work(&ds->output_worker);
+ dualsense_schedule_work(ds);
}
static void dualsense_set_player_leds(struct dualsense *ds)
@@ -1263,7 +1289,7 @@ static void dualsense_set_player_leds(st
ds->update_player_leds = true;
ds->player_leds_state = player_ids[player_id];
- schedule_work(&ds->output_worker);
+ dualsense_schedule_work(ds);
}
static struct ps_device *dualsense_create(struct hid_device *hdev)
@@ -1302,7 +1328,9 @@ static struct ps_device *dualsense_creat
ps_dev->battery_capacity = 100; /* initial value until parse_report. */
ps_dev->battery_status = POWER_SUPPLY_STATUS_UNKNOWN;
ps_dev->parse_report = dualsense_parse_report;
+ ps_dev->remove = dualsense_remove;
INIT_WORK(&ds->output_worker, dualsense_output_worker);
+ ds->output_worker_initialized = true;
hid_set_drvdata(hdev, ds);
max_output_report_size = sizeof(struct dualsense_output_report_bt);
@@ -1470,6 +1498,9 @@ static void ps_remove(struct hid_device
ps_devices_list_remove(dev);
ps_device_release_player_id(dev);
+ if (dev->remove)
+ dev->remove(dev);
+
hid_hw_close(hdev);
hid_hw_stop(hdev);
}
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 07/20] HID: playstation: add initial DualSense Edge controller support
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 06/20] HID: playstation: stop DualSense output work on remove Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 08/20] net: flag sockets supporting msghdr originated zerocopy Greg Kroah-Hartman
` (24 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Roderick Colenbrander, Benjamin Tissoires
From: Roderick Colenbrander <roderick@gaikai.com>
commit b8a968efab301743fd659b5649c5d7d3e30e63a6 upstream.
Provide initial support for the DualSense Edge controller. The brings
support up to the level of the original DualSense, but won't yet provide
support for new features (e.g. reprogrammable buttons).
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
CC: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221010212313.78275-3-roderick.colenbrander@sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-playstation.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1142,6 +1142,7 @@
#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_2 0x09cc
#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE 0x0ba0
#define USB_DEVICE_ID_SONY_PS5_CONTROLLER 0x0ce6
+#define USB_DEVICE_ID_SONY_PS5_CONTROLLER_2 0x0df2
#define USB_DEVICE_ID_SONY_MOTION_CONTROLLER 0x03d5
#define USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER 0x042f
#define USB_DEVICE_ID_SONY_BUZZ_CONTROLLER 0x0002
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -1467,7 +1467,8 @@ static int ps_probe(struct hid_device *h
goto err_stop;
}
- if (hdev->product == USB_DEVICE_ID_SONY_PS5_CONTROLLER) {
+ if (hdev->product == USB_DEVICE_ID_SONY_PS5_CONTROLLER ||
+ hdev->product == USB_DEVICE_ID_SONY_PS5_CONTROLLER_2) {
dev = dualsense_create(hdev);
if (IS_ERR(dev)) {
hid_err(hdev, "Failed to create dualsense.\n");
@@ -1508,6 +1509,8 @@ static void ps_remove(struct hid_device
static const struct hid_device_id ps_devices[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER_2) },
{ }
};
MODULE_DEVICE_TABLE(hid, ps_devices);
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 08/20] net: flag sockets supporting msghdr originated zerocopy
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 07/20] HID: playstation: add initial DualSense Edge controller support Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 09/20] drm/amd/pm: fulfill SMU13.0.7 cstate control interface Greg Kroah-Hartman
` (23 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pavel Begunkov, Jakub Kicinski, Jens Axboe
From: Pavel Begunkov <asml.silence@gmail.com>
commit e993ffe3da4bcddea0536b03be1031bf35cd8d85 upstream.
We need an efficient way in io_uring to check whether a socket supports
zerocopy with msghdr provided ubuf_info. Add a new flag into the struct
socket flags fields.
Cc: <stable@vger.kernel.org> # 6.0
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/3dafafab822b1c66308bb58a0ac738b1e3f53f74.1666346426.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/net.h | 1 +
net/ipv4/tcp.c | 1 +
net/ipv4/udp.c | 1 +
3 files changed, 3 insertions(+)
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -41,6 +41,7 @@ struct net;
#define SOCK_NOSPACE 2
#define SOCK_PASSCRED 3
#define SOCK_PASSSEC 4
+#define SOCK_SUPPORT_ZC 5
#ifndef ARCH_HAS_SOCKET_TYPES
/**
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -457,6 +457,7 @@ void tcp_init_sock(struct sock *sk)
WRITE_ONCE(sk->sk_sndbuf, READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_wmem[1]));
WRITE_ONCE(sk->sk_rcvbuf, READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_rmem[1]));
+ set_bit(SOCK_SUPPORT_ZC, &sk->sk_socket->flags);
sk_sockets_allocated_inc(sk);
}
EXPORT_SYMBOL(tcp_init_sock);
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1620,6 +1620,7 @@ int udp_init_sock(struct sock *sk)
{
skb_queue_head_init(&udp_sk(sk)->reader_queue);
sk->sk_destruct = udp_destruct_sock;
+ set_bit(SOCK_SUPPORT_ZC, &sk->sk_socket->flags);
return 0;
}
EXPORT_SYMBOL_GPL(udp_init_sock);
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 09/20] drm/amd/pm: fulfill SMU13.0.7 cstate control interface
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 08/20] net: flag sockets supporting msghdr originated zerocopy Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 10/20] drm/amd/pm: add SMU IP v13.0.4 IF version define to V7 Greg Kroah-Hartman
` (22 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Evan Quan, Hawking Zhang, Lijo Lazar,
Alex Deucher
From: Evan Quan <evan.quan@amd.com>
commit ba2f09960e75accf757ed12b4ef61409dcc97df8 upstream.
Fulfill the functionality for cstate control.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -121,6 +121,7 @@ static struct cmn2asic_msg_mapping smu_v
MSG_MAP(Mode1Reset, PPSMC_MSG_Mode1Reset, 0),
MSG_MAP(PrepareMp1ForUnload, PPSMC_MSG_PrepareMp1ForUnload, 0),
MSG_MAP(SetMGpuFanBoostLimitRpm, PPSMC_MSG_SetMGpuFanBoostLimitRpm, 0),
+ MSG_MAP(DFCstateControl, PPSMC_MSG_SetExternalClientDfCstateAllow, 0),
};
static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
@@ -1587,6 +1588,16 @@ static bool smu_v13_0_7_is_mode1_reset_s
return true;
}
+
+static int smu_v13_0_7_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state)
+{
+ return smu_cmn_send_smc_msg_with_param(smu,
+ SMU_MSG_DFCstateControl,
+ state,
+ NULL);
+}
+
static const struct pptable_funcs smu_v13_0_7_ppt_funcs = {
.get_allowed_feature_mask = smu_v13_0_7_get_allowed_feature_mask,
.set_default_dpm_table = smu_v13_0_7_set_default_dpm_table,
@@ -1649,6 +1660,7 @@ static const struct pptable_funcs smu_v1
.mode1_reset_is_support = smu_v13_0_7_is_mode1_reset_supported,
.mode1_reset = smu_v13_0_mode1_reset,
.set_mp1_state = smu_v13_0_7_set_mp1_state,
+ .set_df_cstate = smu_v13_0_7_set_df_cstate,
};
void smu_v13_0_7_set_ppt_funcs(struct smu_context *smu)
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 10/20] drm/amd/pm: add SMU IP v13.0.4 IF version define to V7
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 09/20] drm/amd/pm: fulfill SMU13.0.7 cstate control interface Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 11/20] drm/amd/pm: disable cstate feature for gpu reset scenario Greg Kroah-Hartman
` (21 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tim Huang, Mario Limonciello, Alex Deucher
From: Tim Huang <tim.huang@amd.com>
commit 31c261a7ffb8d5bba8144e2d43db304f2bc7e81a upstream.
The pmfw has changed the driver interface version, so keep same with the
fw.
Signed-off-by: Tim Huang <tim.huang@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
@@ -28,7 +28,7 @@
#define SMU13_DRIVER_IF_VERSION_INV 0xFFFFFFFF
#define SMU13_DRIVER_IF_VERSION_YELLOW_CARP 0x04
#define SMU13_DRIVER_IF_VERSION_ALDE 0x08
-#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_4 0x05
+#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_4 0x07
#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_5 0x04
#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_0 0x30
#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_7 0x2C
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 11/20] drm/amd/pm: disable cstate feature for gpu reset scenario
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 10/20] drm/amd/pm: add SMU IP v13.0.4 IF version define to V7 Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 12/20] drm/amd/pm: fulfill SMU13.0.0 cstate control interface Greg Kroah-Hartman
` (20 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Evan Quan, Hawking Zhang, Lijo Lazar,
Alex Deucher
From: Evan Quan <evan.quan@amd.com>
commit 3059cd8c5f797ad83d2b194ae66339f5c007ca43 upstream.
Suggested by PMFW team and same as what did for gfxoff feature.
This can address some Mode1Reset failures observed on SMU13.0.0.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++++++
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 8 ++++++++
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 9 +++++++++
3 files changed, 25 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2926,6 +2926,14 @@ static int amdgpu_device_ip_suspend_phas
amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);
amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE);
+ /*
+ * Per PMFW team's suggestion, driver needs to handle gfxoff
+ * and df cstate features disablement for gpu reset(e.g. Mode1Reset)
+ * scenario. Add the missing df cstate disablement here.
+ */
+ if (amdgpu_dpm_set_df_cstate(adev, DF_CSTATE_DISALLOW))
+ dev_warn(adev->dev, "Failed to disallow df cstate");
+
for (i = adev->num_ip_blocks - 1; i >= 0; i--) {
if (!adev->ip_blocks[i].status.valid)
continue;
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -2242,9 +2242,17 @@ static void arcturus_get_unique_id(struc
static int arcturus_set_df_cstate(struct smu_context *smu,
enum pp_df_cstate state)
{
+ struct amdgpu_device *adev = smu->adev;
uint32_t smu_version;
int ret;
+ /*
+ * Arcturus does not need the cstate disablement
+ * prerequisite for gpu reset.
+ */
+ if (amdgpu_in_reset(adev) || adev->in_suspend)
+ return 0;
+
ret = smu_cmn_get_smc_version(smu, NULL, &smu_version);
if (ret) {
dev_err(smu->adev->dev, "Failed to get smu version!\n");
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -1640,6 +1640,15 @@ static bool aldebaran_is_baco_supported(
static int aldebaran_set_df_cstate(struct smu_context *smu,
enum pp_df_cstate state)
{
+ struct amdgpu_device *adev = smu->adev;
+
+ /*
+ * Aldebaran does not need the cstate disablement
+ * prerequisite for gpu reset.
+ */
+ if (amdgpu_in_reset(adev) || adev->in_suspend)
+ return 0;
+
return smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_DFCstateControl, state, NULL);
}
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 12/20] drm/amd/pm: fulfill SMU13.0.0 cstate control interface
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 11/20] drm/amd/pm: disable cstate feature for gpu reset scenario Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 13/20] drm/amd/pm: update SMU IP v13.0.4 driver interface version Greg Kroah-Hartman
` (19 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Evan Quan, Hawking Zhang, Lijo Lazar,
Alex Deucher
From: Evan Quan <evan.quan@amd.com>
commit 528c0e66e0c01a8c078d2d94431db80f9c75d2a0 upstream.
Fulfill the functionality for cstate control.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -119,6 +119,7 @@ static struct cmn2asic_msg_mapping smu_v
MSG_MAP(NotifyPowerSource, PPSMC_MSG_NotifyPowerSource, 0),
MSG_MAP(Mode1Reset, PPSMC_MSG_Mode1Reset, 0),
MSG_MAP(PrepareMp1ForUnload, PPSMC_MSG_PrepareMp1ForUnload, 0),
+ MSG_MAP(DFCstateControl, PPSMC_MSG_SetExternalClientDfCstateAllow, 0),
};
static struct cmn2asic_mapping smu_v13_0_0_clk_map[SMU_CLK_COUNT] = {
@@ -1753,6 +1754,15 @@ static int smu_v13_0_0_set_mp1_state(str
return ret;
}
+static int smu_v13_0_0_set_df_cstate(struct smu_context *smu,
+ enum pp_df_cstate state)
+{
+ return smu_cmn_send_smc_msg_with_param(smu,
+ SMU_MSG_DFCstateControl,
+ state,
+ NULL);
+}
+
static const struct pptable_funcs smu_v13_0_0_ppt_funcs = {
.get_allowed_feature_mask = smu_v13_0_0_get_allowed_feature_mask,
.set_default_dpm_table = smu_v13_0_0_set_default_dpm_table,
@@ -1822,6 +1832,7 @@ static const struct pptable_funcs smu_v1
.mode1_reset_is_support = smu_v13_0_0_is_mode1_reset_supported,
.mode1_reset = smu_v13_0_mode1_reset,
.set_mp1_state = smu_v13_0_0_set_mp1_state,
+ .set_df_cstate = smu_v13_0_0_set_df_cstate,
};
void smu_v13_0_0_set_ppt_funcs(struct smu_context *smu)
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 13/20] drm/amd/pm: update SMU IP v13.0.4 driver interface version
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 12/20] drm/amd/pm: fulfill SMU13.0.0 cstate control interface Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 14/20] dm clone: Fix typo in block_device format specifier Greg Kroah-Hartman
` (18 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tim Huang, Mario Limonciello, Alex Deucher
From: Tim Huang <tim.huang@amd.com>
commit 853fdb49160e9c30674fd8e4a2eabc06bf70b13a upstream.
Update the SMU driver interface version to V7.
Signed-off-by: Tim Huang <tim.huang@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h | 17 ++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h
@@ -27,7 +27,7 @@
// *** IMPORTANT ***
// SMU TEAM: Always increment the interface version if
// any structure is changed in this file
-#define PMFW_DRIVER_IF_VERSION 5
+#define PMFW_DRIVER_IF_VERSION 7
typedef struct {
int32_t value;
@@ -163,8 +163,8 @@ typedef struct {
uint16_t DclkFrequency; //[MHz]
uint16_t MemclkFrequency; //[MHz]
uint16_t spare; //[centi]
- uint16_t UvdActivity; //[centi]
uint16_t GfxActivity; //[centi]
+ uint16_t UvdActivity; //[centi]
uint16_t Voltage[2]; //[mV] indices: VDDCR_VDD, VDDCR_SOC
uint16_t Current[2]; //[mA] indices: VDDCR_VDD, VDDCR_SOC
@@ -199,6 +199,19 @@ typedef struct {
uint16_t DeviceState;
uint16_t CurTemp; //[centi-Celsius]
uint16_t spare2;
+
+ uint16_t AverageGfxclkFrequency;
+ uint16_t AverageFclkFrequency;
+ uint16_t AverageGfxActivity;
+ uint16_t AverageSocclkFrequency;
+ uint16_t AverageVclkFrequency;
+ uint16_t AverageVcnActivity;
+ uint16_t AverageDRAMReads; //Filtered DF Bandwidth::DRAM Reads
+ uint16_t AverageDRAMWrites; //Filtered DF Bandwidth::DRAM Writes
+ uint16_t AverageSocketPower; //Filtered value of CurrentSocketPower
+ uint16_t AverageCorePower; //Filtered of [sum of CorePower[8]])
+ uint16_t AverageCoreC0Residency[8]; //Filtered of [average C0 residency % per core]
+ uint32_t MetricsCounter; //Counts the # of metrics table parameter reads per update to the metrics table, i.e. if the metrics table update happens every 1 second, this value could be up to 1000 if the smu collected metrics data every cycle, or as low as 0 if the smu was asleep the whole time. Reset to 0 after writing.
} SmuMetrics_t;
typedef struct {
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 14/20] dm clone: Fix typo in block_device format specifier
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 13/20] drm/amd/pm: update SMU IP v13.0.4 driver interface version Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 15/20] efi: efivars: Fix variable writes without query_variable_store() Greg Kroah-Hartman
` (17 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Nikos Tsironis, Mike Snitzer
From: Nikos Tsironis <ntsironis@arrikto.com>
commit 5434ee8d28575b2e784bd5b4dbfc912e5da90759 upstream.
Use %pg for printing the block device name, instead of %pd.
Fixes: 385411ffba0c ("dm: stop using bdevname")
Cc: stable@vger.kernel.org # v5.18+
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-clone-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-clone-target.c b/drivers/md/dm-clone-target.c
index 811b0a5379d0..2f1cc66d2641 100644
--- a/drivers/md/dm-clone-target.c
+++ b/drivers/md/dm-clone-target.c
@@ -2035,7 +2035,7 @@ static void disable_passdown_if_not_supported(struct clone *clone)
reason = "max discard sectors smaller than a region";
if (reason) {
- DMWARN("Destination device (%pd) %s: Disabling discard passdown.",
+ DMWARN("Destination device (%pg) %s: Disabling discard passdown.",
dest_dev, reason);
clear_bit(DM_CLONE_DISCARD_PASSDOWN, &clone->flags);
}
--
2.38.1
^ permalink raw reply related [flat|nested] 41+ messages in thread* [PATCH 6.0 15/20] efi: efivars: Fix variable writes without query_variable_store()
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 14/20] dm clone: Fix typo in block_device format specifier Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 16/20] efi: ssdt: Dont free memory if ACPI table was loaded successfully Greg Kroah-Hartman
` (16 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel
From: Ard Biesheuvel <ardb@kernel.org>
commit 8a254d90a77580244ec57e82bca7eb65656cc167 upstream.
Commit bbc6d2c6ef22 ("efi: vars: Switch to new wrapper layer")
refactored the efivars layer so that the 'business logic' related to
which UEFI variables affect the boot flow in which way could be moved
out of it, and into the efivarfs driver.
This inadvertently broke setting variables on firmware implementations
that lack the QueryVariableInfo() boot service, because we no longer
tolerate a EFI_UNSUPPORTED result from check_var_size() when calling
efivar_entry_set_get_size(), which now ends up calling check_var_size()
a second time inadvertently.
If QueryVariableInfo() is missing, we support writes of up to 64k -
let's move that logic into check_var_size(), and drop the redundant
call.
Cc: <stable@vger.kernel.org> # v6.0
Fixes: bbc6d2c6ef22 ("efi: vars: Switch to new wrapper layer")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/vars.c | 10 +++++-----
fs/efivarfs/vars.c | 16 ----------------
include/linux/efi.h | 3 ---
3 files changed, 5 insertions(+), 24 deletions(-)
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -7,6 +7,7 @@
*/
#include <linux/types.h>
+#include <linux/sizes.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/module.h>
@@ -20,19 +21,19 @@ static struct efivars *__efivars;
static DEFINE_SEMAPHORE(efivars_lock);
-efi_status_t check_var_size(u32 attributes, unsigned long size)
+static efi_status_t check_var_size(u32 attributes, unsigned long size)
{
const struct efivar_operations *fops;
fops = __efivars->ops;
if (!fops->query_variable_store)
- return EFI_UNSUPPORTED;
+ return (size <= SZ_64K) ? EFI_SUCCESS : EFI_OUT_OF_RESOURCES;
return fops->query_variable_store(attributes, size, false);
}
-EXPORT_SYMBOL_NS_GPL(check_var_size, EFIVAR);
+static
efi_status_t check_var_size_nonblocking(u32 attributes, unsigned long size)
{
const struct efivar_operations *fops;
@@ -40,11 +41,10 @@ efi_status_t check_var_size_nonblocking(
fops = __efivars->ops;
if (!fops->query_variable_store)
- return EFI_UNSUPPORTED;
+ return (size <= SZ_64K) ? EFI_SUCCESS : EFI_OUT_OF_RESOURCES;
return fops->query_variable_store(attributes, size, true);
}
-EXPORT_SYMBOL_NS_GPL(check_var_size_nonblocking, EFIVAR);
/**
* efivars_kobject - get the kobject for the registered efivars
--- a/fs/efivarfs/vars.c
+++ b/fs/efivarfs/vars.c
@@ -651,22 +651,6 @@ int efivar_entry_set_get_size(struct efi
if (err)
return err;
- /*
- * Ensure that the available space hasn't shrunk below the safe level
- */
- status = check_var_size(attributes, *size + ucs2_strsize(name, 1024));
- if (status != EFI_SUCCESS) {
- if (status != EFI_UNSUPPORTED) {
- err = efi_status_to_err(status);
- goto out;
- }
-
- if (*size > 65536) {
- err = -ENOSPC;
- goto out;
- }
- }
-
status = efivar_set_variable_locked(name, vendor, attributes, *size,
data, false);
if (status != EFI_SUCCESS) {
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1055,9 +1055,6 @@ efi_status_t efivar_set_variable_locked(
efi_status_t efivar_set_variable(efi_char16_t *name, efi_guid_t *vendor,
u32 attr, unsigned long data_size, void *data);
-efi_status_t check_var_size(u32 attributes, unsigned long size);
-efi_status_t check_var_size_nonblocking(u32 attributes, unsigned long size);
-
#if IS_ENABLED(CONFIG_EFI_CAPSULE_LOADER)
extern bool efi_capsule_pending(int *reset_type);
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 16/20] efi: ssdt: Dont free memory if ACPI table was loaded successfully
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 15/20] efi: efivars: Fix variable writes without query_variable_store() Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 17/20] gcov: support GCC 12.1 and newer compilers Greg Kroah-Hartman
` (15 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Amadeusz Sławiński, Ard Biesheuvel
From: Ard Biesheuvel <ardb@kernel.org>
commit 4b017e59f01097f19b938f6dc4dc2c4720701610 upstream.
Amadeusz reports KASAN use-after-free errors introduced by commit
3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from
variables"). The problem appears to be that the memory that holds the
new ACPI table is now freed unconditionally, instead of only when the
ACPI core reported a failure to load the table.
So let's fix this, by omitting the kfree() on success.
Cc: <stable@vger.kernel.org> # v6.0
Link: https://lore.kernel.org/all/a101a10a-4fbb-5fae-2e3c-76cf96ed8fbd@linux.intel.com/
Fixes: 3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from variables")
Reported-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/efi.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -269,6 +269,8 @@ static __init int efivar_ssdt_load(void)
acpi_status ret = acpi_load_table(data, NULL);
if (ret)
pr_err("failed to load table: %u\n", ret);
+ else
+ continue;
} else {
pr_err("failed to get var data: 0x%lx\n", status);
}
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 17/20] gcov: support GCC 12.1 and newer compilers
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 16/20] efi: ssdt: Dont free memory if ACPI table was loaded successfully Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 18/20] io-wq: Fix memory leak in worker creation Greg Kroah-Hartman
` (14 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Martin Liska, Peter Oberparleiter,
Andrew Morton
From: Martin Liska <mliska@suse.cz>
commit 977ef30a7d888eeb52fb6908f99080f33e5309a8 upstream.
Starting with GCC 12.1, the created .gcda format can't be read by gcov
tool. There are 2 significant changes to the .gcda file format that
need to be supported:
a) [gcov: Use system IO buffering]
(23eb66d1d46a34cb28c4acbdf8a1deb80a7c5a05) changed that all sizes in
the format are in bytes and not in words (4B)
b) [gcov: make profile merging smarter]
(72e0c742bd01f8e7e6dcca64042b9ad7e75979de) add a new checksum to the
file header.
Tested with GCC 7.5, 10.4, 12.2 and the current master.
Link: https://lkml.kernel.org/r/624bda92-f307-30e9-9aaa-8cc678b2dfb2@suse.cz
Signed-off-by: Martin Liska <mliska@suse.cz>
Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/gcov/gcc_4_7.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -30,6 +30,13 @@
#define GCOV_TAG_FUNCTION_LENGTH 3
+/* Since GCC 12.1 sizes are in BYTES and not in WORDS (4B). */
+#if (__GNUC__ >= 12)
+#define GCOV_UNIT_SIZE 4
+#else
+#define GCOV_UNIT_SIZE 1
+#endif
+
static struct gcov_info *gcov_info_head;
/**
@@ -383,12 +390,18 @@ size_t convert_to_gcda(char *buffer, str
pos += store_gcov_u32(buffer, pos, info->version);
pos += store_gcov_u32(buffer, pos, info->stamp);
+#if (__GNUC__ >= 12)
+ /* Use zero as checksum of the compilation unit. */
+ pos += store_gcov_u32(buffer, pos, 0);
+#endif
+
for (fi_idx = 0; fi_idx < info->n_functions; fi_idx++) {
fi_ptr = info->functions[fi_idx];
/* Function record. */
pos += store_gcov_u32(buffer, pos, GCOV_TAG_FUNCTION);
- pos += store_gcov_u32(buffer, pos, GCOV_TAG_FUNCTION_LENGTH);
+ pos += store_gcov_u32(buffer, pos,
+ GCOV_TAG_FUNCTION_LENGTH * GCOV_UNIT_SIZE);
pos += store_gcov_u32(buffer, pos, fi_ptr->ident);
pos += store_gcov_u32(buffer, pos, fi_ptr->lineno_checksum);
pos += store_gcov_u32(buffer, pos, fi_ptr->cfg_checksum);
@@ -402,7 +415,8 @@ size_t convert_to_gcda(char *buffer, str
/* Counter record. */
pos += store_gcov_u32(buffer, pos,
GCOV_TAG_FOR_COUNTER(ct_idx));
- pos += store_gcov_u32(buffer, pos, ci_ptr->num * 2);
+ pos += store_gcov_u32(buffer, pos,
+ ci_ptr->num * 2 * GCOV_UNIT_SIZE);
for (cv_idx = 0; cv_idx < ci_ptr->num; cv_idx++) {
pos += store_gcov_u64(buffer, pos,
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 18/20] io-wq: Fix memory leak in worker creation
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 17/20] gcov: support GCC 12.1 and newer compilers Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-24 11:31 ` [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split Greg Kroah-Hartman
` (13 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rafael Mendonca, Jens Axboe
From: Rafael Mendonca <rafaelmendsr@gmail.com>
commit 996d3efeb091c503afd3ee6b5e20eabf446fd955 upstream.
If the CPU mask allocation for a node fails, then the memory allocated for
the 'io_wqe' struct of the current node doesn't get freed on the error
handling path, since it has not yet been added to the 'wqes' array.
This was spotted when fuzzing v6.1-rc1 with Syzkaller:
BUG: memory leak
unreferenced object 0xffff8880093d5000 (size 1024):
comm "syz-executor.2", pid 7701, jiffies 4295048595 (age 13.900s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000cb463369>] __kmem_cache_alloc_node+0x18e/0x720
[<00000000147a3f9c>] kmalloc_node_trace+0x2a/0x130
[<000000004e107011>] io_wq_create+0x7b9/0xdc0
[<00000000c38b2018>] io_uring_alloc_task_context+0x31e/0x59d
[<00000000867399da>] __io_uring_add_tctx_node.cold+0x19/0x1ba
[<000000007e0e7a79>] io_uring_setup.cold+0x1b80/0x1dce
[<00000000b545e9f6>] __x64_sys_io_uring_setup+0x5d/0x80
[<000000008a8a7508>] do_syscall_64+0x5d/0x90
[<000000004ac08bec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fixes: 0e03496d1967 ("io-wq: use private CPU mask")
Cc: stable@vger.kernel.org
Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com>
Link: https://lore.kernel.org/r/20221020014710.902201-1-rafaelmendsr@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
io_uring/io-wq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/io_uring/io-wq.c
+++ b/io_uring/io-wq.c
@@ -1164,10 +1164,10 @@ struct io_wq *io_wq_create(unsigned boun
wqe = kzalloc_node(sizeof(struct io_wqe), GFP_KERNEL, alloc_node);
if (!wqe)
goto err;
+ wq->wqes[node] = wqe;
if (!alloc_cpumask_var(&wqe->cpu_mask, GFP_KERNEL))
goto err;
cpumask_copy(wqe->cpu_mask, cpumask_of_node(node));
- wq->wqes[node] = wqe;
wqe->node = alloc_node;
wqe->acct[IO_WQ_ACCT_BOUND].max_workers = bounded;
wqe->acct[IO_WQ_ACCT_UNBOUND].max_workers =
^ permalink raw reply [flat|nested] 41+ messages in thread* [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 18/20] io-wq: Fix memory leak in worker creation Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-10-25 15:11 ` Hugh Dickins
2022-10-24 11:31 ` [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers() Greg Kroah-Hartman
` (12 subsequent siblings)
31 siblings, 1 reply; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mel Gorman, Matthew Wilcox (Oracle),
Yang Shi, Brian Foster, Dan Streetman, Miaohe Lin,
Oleksandr Natalenko, Seth Jennings, Vitaly Wool, Andrew Morton
From: Mel Gorman <mgorman@techsingularity.net>
commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream.
The following has been observed when running stressng mmap since commit
b653db77350c ("mm: Clear page->private when splitting or migrating a page")
watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]
CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374
Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016
RIP: 0010:xas_descend+0x28/0x80
Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2
RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246
RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002
RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0
RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0
R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000
R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88
FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
xas_load+0x3a/0x50
__filemap_get_folio+0x80/0x370
? put_swap_page+0x163/0x360
pagecache_get_page+0x13/0x90
__try_to_reclaim_swap+0x50/0x190
scan_swap_map_slots+0x31e/0x670
get_swap_pages+0x226/0x3c0
folio_alloc_swap+0x1cc/0x240
add_to_swap+0x14/0x70
shrink_page_list+0x968/0xbc0
reclaim_page_list+0x70/0xf0
reclaim_pages+0xdd/0x120
madvise_cold_or_pageout_pte_range+0x814/0xf30
walk_pgd_range+0x637/0xa30
__walk_page_range+0x142/0x170
walk_page_range+0x146/0x170
madvise_pageout+0xb7/0x280
? asm_common_interrupt+0x22/0x40
madvise_vma_behavior+0x3b7/0xac0
? find_vma+0x4a/0x70
? find_vma+0x64/0x70
? madvise_vma_anon_name+0x40/0x40
madvise_walk_vmas+0xa6/0x130
do_madvise+0x2f4/0x360
__x64_sys_madvise+0x26/0x30
do_syscall_64+0x5b/0x80
? do_syscall_64+0x67/0x80
? syscall_exit_to_user_mode+0x17/0x40
? do_syscall_64+0x67/0x80
? syscall_exit_to_user_mode+0x17/0x40
? do_syscall_64+0x67/0x80
? do_syscall_64+0x67/0x80
? common_interrupt+0x8b/0xa0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The problem can be reproduced with the mmtests config
config-workload-stressng-mmap. It does not always happen and when it
triggers is variable but it has happened on multiple machines.
The intent of commit b653db77350c patch was to avoid the case where
PG_private is clear but folio->private is not-NULL. However, THP tail
pages uses page->private for "swp_entry_t if folio_test_swapcache()" as
stated in the documentation for struct folio. This patch only clobbers
page->private for tail pages if the head page was not in swapcache and
warns once if page->private had an unexpected value.
Link: https://lkml.kernel.org/r/20221019134156.zjyyn5aownakvztf@techsingularity.net
Fixes: b653db77350c ("mm: Clear page->private when splitting or migrating a page")
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Brian Foster <bfoster@redhat.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Vitaly Wool <vitaly.wool@konsulko.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/huge_memory.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2445,7 +2445,16 @@ static void __split_huge_page_tail(struc
page_tail);
page_tail->mapping = head->mapping;
page_tail->index = head->index + tail;
- page_tail->private = 0;
+
+ /*
+ * page->private should not be set in tail pages with the exception
+ * of swap cache pages that store the swp_entry_t in tail pages.
+ * Fix up and warn once if private is unexpectedly set.
+ */
+ if (!folio_test_swapcache(page_folio(head))) {
+ VM_WARN_ON_ONCE_PAGE(page_tail->private != 0, head);
+ page_tail->private = 0;
+ }
/* Page flags must be visible before we make the page non-compound. */
smp_wmb();
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
2022-10-24 11:31 ` [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split Greg Kroah-Hartman
@ 2022-10-25 15:11 ` Hugh Dickins
2022-10-25 15:58 ` Greg Kroah-Hartman
0 siblings, 1 reply; 41+ messages in thread
From: Hugh Dickins @ 2022-10-25 15:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Mel Gorman, Matthew Wilcox (Oracle),
Yang Shi, Brian Foster, Dan Streetman, Miaohe Lin,
Oleksandr Natalenko, Seth Jennings, Vitaly Wool, Andrew Morton,
Tvrtko Ursulin
On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote:
> From: Mel Gorman <mgorman@techsingularity.net>
>
> commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream.
>
> The following has been observed when running stressng mmap since commit
> b653db77350c ("mm: Clear page->private when splitting or migrating a page")
>
> watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]
> CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374
> Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016
> RIP: 0010:xas_descend+0x28/0x80
> Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2
> RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246
> RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002
> RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0
> RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0
> R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000
> R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88
> FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> xas_load+0x3a/0x50
> __filemap_get_folio+0x80/0x370
> ? put_swap_page+0x163/0x360
> pagecache_get_page+0x13/0x90
> __try_to_reclaim_swap+0x50/0x190
> scan_swap_map_slots+0x31e/0x670
> get_swap_pages+0x226/0x3c0
> folio_alloc_swap+0x1cc/0x240
> add_to_swap+0x14/0x70
> shrink_page_list+0x968/0xbc0
> reclaim_page_list+0x70/0xf0
> reclaim_pages+0xdd/0x120
> madvise_cold_or_pageout_pte_range+0x814/0xf30
> walk_pgd_range+0x637/0xa30
> __walk_page_range+0x142/0x170
> walk_page_range+0x146/0x170
> madvise_pageout+0xb7/0x280
> ? asm_common_interrupt+0x22/0x40
> madvise_vma_behavior+0x3b7/0xac0
> ? find_vma+0x4a/0x70
> ? find_vma+0x64/0x70
> ? madvise_vma_anon_name+0x40/0x40
> madvise_walk_vmas+0xa6/0x130
> do_madvise+0x2f4/0x360
> __x64_sys_madvise+0x26/0x30
> do_syscall_64+0x5b/0x80
> ? do_syscall_64+0x67/0x80
> ? syscall_exit_to_user_mode+0x17/0x40
> ? do_syscall_64+0x67/0x80
> ? syscall_exit_to_user_mode+0x17/0x40
> ? do_syscall_64+0x67/0x80
> ? do_syscall_64+0x67/0x80
> ? common_interrupt+0x8b/0xa0
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> The problem can be reproduced with the mmtests config
> config-workload-stressng-mmap. It does not always happen and when it
> triggers is variable but it has happened on multiple machines.
>
> The intent of commit b653db77350c patch was to avoid the case where
> PG_private is clear but folio->private is not-NULL. However, THP tail
> pages uses page->private for "swp_entry_t if folio_test_swapcache()" as
> stated in the documentation for struct folio. This patch only clobbers
> page->private for tail pages if the head page was not in swapcache and
> warns once if page->private had an unexpected value.
>
> Link: https://lkml.kernel.org/r/20221019134156.zjyyn5aownakvztf@techsingularity.net
> Fixes: b653db77350c ("mm: Clear page->private when splitting or migrating a page")
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: Yang Shi <shy828301@gmail.com>
> Cc: Brian Foster <bfoster@redhat.com>
> Cc: Dan Streetman <ddstreet@ieee.org>
> Cc: Miaohe Lin <linmiaohe@huawei.com>
> Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
> Cc: Seth Jennings <sjenning@redhat.com>
> Cc: Vitaly Wool <vitaly.wool@konsulko.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg, this patch from Mel is important,
but introduces a warning which is giving Tvrtko trouble - see linux-mm
https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/
We already have the fix for the warning, it's making its way through the
system, and is marked for stable, but it has not reached Linus's tree yet.
Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know
when the fix does reach Linus's tree - hopefully the two can go together
in the next 6.0-stable.
I apologize for not writing yesterday: gmail had gathered together
different threads with the same subject, I thought you and stable
were Cc'ed on the linux-mm mail and you would immediately drop it
yourself, but in fact you were not on that thread at all.
Thanks,
Hugh
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
2022-10-25 15:11 ` Hugh Dickins
@ 2022-10-25 15:58 ` Greg Kroah-Hartman
2022-10-30 3:33 ` Hugh Dickins
0 siblings, 1 reply; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-25 15:58 UTC (permalink / raw)
To: Hugh Dickins
Cc: linux-kernel, stable, Mel Gorman, Matthew Wilcox (Oracle),
Yang Shi, Brian Foster, Dan Streetman, Miaohe Lin,
Oleksandr Natalenko, Seth Jennings, Vitaly Wool, Andrew Morton,
Tvrtko Ursulin
On Tue, Oct 25, 2022 at 08:11:44AM -0700, Hugh Dickins wrote:
> On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote:
> > From: Mel Gorman <mgorman@techsingularity.net>
> >
> > commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream.
> >
> > The following has been observed when running stressng mmap since commit
> > b653db77350c ("mm: Clear page->private when splitting or migrating a page")
> >
> > watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]
> > CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374
> > Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016
> > RIP: 0010:xas_descend+0x28/0x80
> > Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2
> > RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246
> > RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002
> > RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0
> > RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0
> > R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000
> > R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88
> > FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <TASK>
> > xas_load+0x3a/0x50
> > __filemap_get_folio+0x80/0x370
> > ? put_swap_page+0x163/0x360
> > pagecache_get_page+0x13/0x90
> > __try_to_reclaim_swap+0x50/0x190
> > scan_swap_map_slots+0x31e/0x670
> > get_swap_pages+0x226/0x3c0
> > folio_alloc_swap+0x1cc/0x240
> > add_to_swap+0x14/0x70
> > shrink_page_list+0x968/0xbc0
> > reclaim_page_list+0x70/0xf0
> > reclaim_pages+0xdd/0x120
> > madvise_cold_or_pageout_pte_range+0x814/0xf30
> > walk_pgd_range+0x637/0xa30
> > __walk_page_range+0x142/0x170
> > walk_page_range+0x146/0x170
> > madvise_pageout+0xb7/0x280
> > ? asm_common_interrupt+0x22/0x40
> > madvise_vma_behavior+0x3b7/0xac0
> > ? find_vma+0x4a/0x70
> > ? find_vma+0x64/0x70
> > ? madvise_vma_anon_name+0x40/0x40
> > madvise_walk_vmas+0xa6/0x130
> > do_madvise+0x2f4/0x360
> > __x64_sys_madvise+0x26/0x30
> > do_syscall_64+0x5b/0x80
> > ? do_syscall_64+0x67/0x80
> > ? syscall_exit_to_user_mode+0x17/0x40
> > ? do_syscall_64+0x67/0x80
> > ? syscall_exit_to_user_mode+0x17/0x40
> > ? do_syscall_64+0x67/0x80
> > ? do_syscall_64+0x67/0x80
> > ? common_interrupt+0x8b/0xa0
> > entry_SYSCALL_64_after_hwframe+0x63/0xcd
> >
> > The problem can be reproduced with the mmtests config
> > config-workload-stressng-mmap. It does not always happen and when it
> > triggers is variable but it has happened on multiple machines.
> >
> > The intent of commit b653db77350c patch was to avoid the case where
> > PG_private is clear but folio->private is not-NULL. However, THP tail
> > pages uses page->private for "swp_entry_t if folio_test_swapcache()" as
> > stated in the documentation for struct folio. This patch only clobbers
> > page->private for tail pages if the head page was not in swapcache and
> > warns once if page->private had an unexpected value.
> >
> > Link: https://lkml.kernel.org/r/20221019134156.zjyyn5aownakvztf@techsingularity.net
> > Fixes: b653db77350c ("mm: Clear page->private when splitting or migrating a page")
> > Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> > Cc: Mel Gorman <mgorman@techsingularity.net>
> > Cc: Yang Shi <shy828301@gmail.com>
> > Cc: Brian Foster <bfoster@redhat.com>
> > Cc: Dan Streetman <ddstreet@ieee.org>
> > Cc: Miaohe Lin <linmiaohe@huawei.com>
> > Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
> > Cc: Seth Jennings <sjenning@redhat.com>
> > Cc: Vitaly Wool <vitaly.wool@konsulko.com>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Greg, this patch from Mel is important,
> but introduces a warning which is giving Tvrtko trouble - see linux-mm
> https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/
>
> We already have the fix for the warning, it's making its way through the
> system, and is marked for stable, but it has not reached Linus's tree yet.
>
> Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know
> when the fix does reach Linus's tree - hopefully the two can go together
> in the next 6.0-stable.
>
> I apologize for not writing yesterday: gmail had gathered together
> different threads with the same subject, I thought you and stable
> were Cc'ed on the linux-mm mail and you would immediately drop it
> yourself, but in fact you were not on that thread at all.
No worries, now dropped, thanks.
greg k-h
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
2022-10-25 15:58 ` Greg Kroah-Hartman
@ 2022-10-30 3:33 ` Hugh Dickins
2022-10-31 6:44 ` Greg Kroah-Hartman
0 siblings, 1 reply; 41+ messages in thread
From: Hugh Dickins @ 2022-10-30 3:33 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Hugh Dickins, linux-kernel, stable, Mel Gorman,
Matthew Wilcox (Oracle),
Yang Shi, Brian Foster, Dan Streetman, Miaohe Lin,
Oleksandr Natalenko, Seth Jennings, Vitaly Wool, Andrew Morton,
Tvrtko Ursulin
On Tue, 25 Oct 2022, Greg Kroah-Hartman wrote:
> On Tue, Oct 25, 2022 at 08:11:44AM -0700, Hugh Dickins wrote:
> > On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote:
> > > From: Mel Gorman <mgorman@techsingularity.net>
> > >
> > > commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream.
> > >...
> >
> > Greg, this patch from Mel is important,
> > but introduces a warning which is giving Tvrtko trouble - see linux-mm
> > https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/
> >
> > We already have the fix for the warning, it's making its way through the
> > system, and is marked for stable, but it has not reached Linus's tree yet.
> >
> > Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know
> > when the fix does reach Linus's tree - hopefully the two can go together
> > in the next 6.0-stable.
> >
> > I apologize for not writing yesterday: gmail had gathered together
> > different threads with the same subject, I thought you and stable
> > were Cc'ed on the linux-mm mail and you would immediately drop it
> > yourself, but in fact you were not on that thread at all.
>
> No worries, now dropped, thanks.
Thanks Greg. Linus's tree now contains my fix
5aae9265ee1a ("mm: prep_compound_tail() clear page->private")
to Mel's fix
71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split")
so they can now go on together into 6.0 stable.
They would also have been good in 5.19 stable: but too late now, it's EOL.
Hugh
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
2022-10-30 3:33 ` Hugh Dickins
@ 2022-10-31 6:44 ` Greg Kroah-Hartman
0 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-31 6:44 UTC (permalink / raw)
To: Hugh Dickins
Cc: linux-kernel, stable, Mel Gorman, Matthew Wilcox (Oracle),
Yang Shi, Brian Foster, Dan Streetman, Miaohe Lin,
Oleksandr Natalenko, Seth Jennings, Vitaly Wool, Andrew Morton,
Tvrtko Ursulin
On Sat, Oct 29, 2022 at 08:33:01PM -0700, Hugh Dickins wrote:
> On Tue, 25 Oct 2022, Greg Kroah-Hartman wrote:
> > On Tue, Oct 25, 2022 at 08:11:44AM -0700, Hugh Dickins wrote:
> > > On Mon, 24 Oct 2022, Greg Kroah-Hartman wrote:
> > > > From: Mel Gorman <mgorman@techsingularity.net>
> > > >
> > > > commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream.
> > > >...
> > >
> > > Greg, this patch from Mel is important,
> > > but introduces a warning which is giving Tvrtko trouble - see linux-mm
> > > https://lore.kernel.org/linux-mm/1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com/
> > >
> > > We already have the fix for the warning, it's making its way through the
> > > system, and is marked for stable, but it has not reached Linus's tree yet.
> > >
> > > Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know
> > > when the fix does reach Linus's tree - hopefully the two can go together
> > > in the next 6.0-stable.
> > >
> > > I apologize for not writing yesterday: gmail had gathered together
> > > different threads with the same subject, I thought you and stable
> > > were Cc'ed on the linux-mm mail and you would immediately drop it
> > > yourself, but in fact you were not on that thread at all.
> >
> > No worries, now dropped, thanks.
>
> Thanks Greg. Linus's tree now contains my fix
> 5aae9265ee1a ("mm: prep_compound_tail() clear page->private")
> to Mel's fix
> 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split")
> so they can now go on together into 6.0 stable.
>
> They would also have been good in 5.19 stable: but too late now, it's EOL.
Thanks, both now queued up for 6.0
greg k-h
^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers()
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split Greg Kroah-Hartman
@ 2022-10-24 11:31 ` Greg Kroah-Hartman
2022-11-01 8:42 ` Boris V.
2022-10-24 15:47 ` [PATCH 6.0 00/20] 6.0.4-rc1 review Luna Jernberg
` (11 subsequent siblings)
31 siblings, 1 reply; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24 11:31 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Zimmermann, Javier Martinez Canillas
From: Thomas Zimmermann <tzimmermann@suse.de>
commit 9d69ef1838150c7d87afc1a87aa658c637217585 upstream.
Remove remove_conflicting_pci_framebuffers() and implement similar
functionality in aperture_remove_conflicting_pci_device(), which was
the only caller. Removes an otherwise unused interface and streamlines
the aperture helper. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-5-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/aperture.c | 30 ++++++++++++++----------
drivers/video/fbdev/core/fbmem.c | 48 ---------------------------------------
include/linux/fb.h | 2 -
3 files changed, 18 insertions(+), 62 deletions(-)
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin
*/
int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *name)
{
+ bool primary = false;
resource_size_t base, size;
int bar, ret;
- /*
- * WARNING: Apparently we must kick fbdev drivers before vgacon,
- * otherwise the vga fbdev driver falls over.
- */
-#if IS_REACHABLE(CONFIG_FB)
- ret = remove_conflicting_pci_framebuffers(pdev, name);
- if (ret)
- return ret;
+#ifdef CONFIG_X86
+ primary = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
#endif
- ret = vga_remove_vgacon(pdev);
- if (ret)
- return ret;
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
+
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- aperture_detach_devices(base, size);
+ ret = aperture_remove_conflicting_devices(base, size, primary, name);
+ if (ret)
+ break;
}
+ if (ret)
+ return ret;
+
+ /*
+ * WARNING: Apparently we must kick fbdev drivers before vgacon,
+ * otherwise the vga fbdev driver falls over.
+ */
+ ret = vga_remove_vgacon(pdev);
+ if (ret)
+ return ret;
+
return 0;
}
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1788,54 +1788,6 @@ int remove_conflicting_framebuffers(stru
EXPORT_SYMBOL(remove_conflicting_framebuffers);
/**
- * remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices
- * @pdev: PCI device
- * @name: requesting driver name
- *
- * This function removes framebuffer devices (eg. initialized by firmware)
- * using memory range configured for any of @pdev's memory bars.
- *
- * The function assumes that PCI device with shadowed ROM drives a primary
- * display and so kicks out vga16fb.
- */
-int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const char *name)
-{
- struct apertures_struct *ap;
- bool primary = false;
- int err, idx, bar;
-
- for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
- if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
- continue;
- idx++;
- }
-
- ap = alloc_apertures(idx);
- if (!ap)
- return -ENOMEM;
-
- for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
- if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
- continue;
- ap->ranges[idx].base = pci_resource_start(pdev, bar);
- ap->ranges[idx].size = pci_resource_len(pdev, bar);
- pci_dbg(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar,
- (unsigned long)pci_resource_start(pdev, bar),
- (unsigned long)pci_resource_end(pdev, bar));
- idx++;
- }
-
-#ifdef CONFIG_X86
- primary = pdev->resource[PCI_ROM_RESOURCE].flags &
- IORESOURCE_ROM_SHADOW;
-#endif
- err = remove_conflicting_framebuffers(ap, name, primary);
- kfree(ap);
- return err;
-}
-EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
-
-/**
* register_framebuffer - registers a frame buffer device
* @fb_info: frame buffer info structure
*
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in
/* drivers/video/fbmem.c */
extern int register_framebuffer(struct fb_info *fb_info);
extern void unregister_framebuffer(struct fb_info *fb_info);
-extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
- const char *name);
extern int remove_conflicting_framebuffers(struct apertures_struct *a,
const char *name, bool primary);
extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers()
2022-10-24 11:31 ` [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers() Greg Kroah-Hartman
@ 2022-11-01 8:42 ` Boris V.
2022-11-01 10:34 ` Thomas Zimmermann
0 siblings, 1 reply; 41+ messages in thread
From: Boris V. @ 2022-11-01 8:42 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Thomas Zimmermann, Javier Martinez Canillas
On 24/10/2022 13:31, Greg Kroah-Hartman wrote:
> From: Thomas Zimmermann <tzimmermann@suse.de>
>
> commit 9d69ef1838150c7d87afc1a87aa658c637217585 upstream.
>
> Remove remove_conflicting_pci_framebuffers() and implement similar
> functionality in aperture_remove_conflicting_pci_device(), which was
> the only caller. Removes an otherwise unused interface and streamlines
> the aperture helper. No functional changes.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-5-tzimmermann@suse.de
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/video/aperture.c | 30 ++++++++++++++----------
> drivers/video/fbdev/core/fbmem.c | 48 ---------------------------------------
> include/linux/fb.h | 2 -
> 3 files changed, 18 insertions(+), 62 deletions(-)
>
> --- a/drivers/video/aperture.c
> +++ b/drivers/video/aperture.c
> @@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin
> */
> int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *name)
> {
> + bool primary = false;
> resource_size_t base, size;
> int bar, ret;
>
> - /*
> - * WARNING: Apparently we must kick fbdev drivers before vgacon,
> - * otherwise the vga fbdev driver falls over.
> - */
> -#if IS_REACHABLE(CONFIG_FB)
> - ret = remove_conflicting_pci_framebuffers(pdev, name);
> - if (ret)
> - return ret;
> +#ifdef CONFIG_X86
> + primary = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
> #endif
> - ret = vga_remove_vgacon(pdev);
> - if (ret)
> - return ret;
>
> for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
> continue;
> +
> base = pci_resource_start(pdev, bar);
> size = pci_resource_len(pdev, bar);
> - aperture_detach_devices(base, size);
> + ret = aperture_remove_conflicting_devices(base, size, primary, name);
> + if (ret)
> + break;
> }
>
> + if (ret)
> + return ret;
> +
> + /*
> + * WARNING: Apparently we must kick fbdev drivers before vgacon,
> + * otherwise the vga fbdev driver falls over.
> + */
> + ret = vga_remove_vgacon(pdev);
> + if (ret)
> + return ret;
> +
> return 0;
>
> }
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1788,54 +1788,6 @@ int remove_conflicting_framebuffers(stru
> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>
> /**
> - * remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices
> - * @pdev: PCI device
> - * @name: requesting driver name
> - *
> - * This function removes framebuffer devices (eg. initialized by firmware)
> - * using memory range configured for any of @pdev's memory bars.
> - *
> - * The function assumes that PCI device with shadowed ROM drives a primary
> - * display and so kicks out vga16fb.
> - */
> -int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const char *name)
> -{
> - struct apertures_struct *ap;
> - bool primary = false;
> - int err, idx, bar;
> -
> - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
> - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
> - continue;
> - idx++;
> - }
> -
> - ap = alloc_apertures(idx);
> - if (!ap)
> - return -ENOMEM;
> -
> - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
> - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
> - continue;
> - ap->ranges[idx].base = pci_resource_start(pdev, bar);
> - ap->ranges[idx].size = pci_resource_len(pdev, bar);
> - pci_dbg(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar,
> - (unsigned long)pci_resource_start(pdev, bar),
> - (unsigned long)pci_resource_end(pdev, bar));
> - idx++;
> - }
> -
> -#ifdef CONFIG_X86
> - primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> - IORESOURCE_ROM_SHADOW;
> -#endif
> - err = remove_conflicting_framebuffers(ap, name, primary);
> - kfree(ap);
> - return err;
> -}
> -EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
> -
> -/**
> * register_framebuffer - registers a frame buffer device
> * @fb_info: frame buffer info structure
> *
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in
> /* drivers/video/fbmem.c */
> extern int register_framebuffer(struct fb_info *fb_info);
> extern void unregister_framebuffer(struct fb_info *fb_info);
> -extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
> - const char *name);
> extern int remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary);
> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
>
>
>
>
Hello,
this patch seems to disable console/framebuffer when vfio-pci is used.
I hava 2 nvidia GPUs one is used for host and other is passed through to VM.
Now after this patch, when vfio-pci module is loaded with parameter
ids=10de:2486,10de:228b,
console is lost/frozen, last message is that vfio-pci module was loaded
and then there is no more output.
This PCI IDs (10de:2486,10de:228b) are for secondary GPU, primary/boot
GPU is used for host and boot messages are displayed on primary/boot GPU.
Using dmesg I see this messages after vfio-pci is loaded:
[ 3.993601] VFIO - User Level meta-driver version: 0.3
[ 4.020239] Console: switching to colour dummy device 80x25
[ 4.020335] vfio-pci 0000:1a:00.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=none:owns=none
[ 4.020722] vfio_pci: add [10de:2486[ffffffff:ffffffff]] class
0x000000/00000000
[ 4.116616] vfio_pci: add [10de:228b[ffffffff:ffffffff]] class
0x000000/00000000
I guess the problem here is "Console: switching to colour dummy device
80x25", but I don't know why this happens.
Last working kernel is 6.0.3, after upgrading to 6.0.4 (and 6.0.5,
6.0.6), console is no longer working.
By git bisecting it seems bad commit is
af9ac541e88390d97b01d5e8c77309d2637c1d4c.
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers()
2022-11-01 8:42 ` Boris V.
@ 2022-11-01 10:34 ` Thomas Zimmermann
2022-11-01 11:34 ` Boris V.
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Zimmermann @ 2022-11-01 10:34 UTC (permalink / raw)
To: Boris V., Greg Kroah-Hartman, linux-kernel, Alex Williamson
Cc: stable, Javier Martinez Canillas
[-- Attachment #1.1: Type: text/plain, Size: 7686 bytes --]
(cc: Alex Williamson)
Hi
Am 01.11.22 um 09:42 schrieb Boris V.:
> On 24/10/2022 13:31, Greg Kroah-Hartman wrote:
>> From: Thomas Zimmermann <tzimmermann@suse.de>
>>
>> commit 9d69ef1838150c7d87afc1a87aa658c637217585 upstream.
>>
>> Remove remove_conflicting_pci_framebuffers() and implement similar
>> functionality in aperture_remove_conflicting_pci_device(), which was
>> the only caller. Removes an otherwise unused interface and streamlines
>> the aperture helper. No functional changes.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>> Link:
>> https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-5-tzimmermann@suse.de
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>> drivers/video/aperture.c | 30 ++++++++++++++----------
>> drivers/video/fbdev/core/fbmem.c | 48
>> ---------------------------------------
>> include/linux/fb.h | 2 -
>> 3 files changed, 18 insertions(+), 62 deletions(-)
>>
>> --- a/drivers/video/aperture.c
>> +++ b/drivers/video/aperture.c
>> @@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin
>> */
>> int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev,
>> const char *name)
>> {
>> + bool primary = false;
>> resource_size_t base, size;
>> int bar, ret;
>> - /*
>> - * WARNING: Apparently we must kick fbdev drivers before vgacon,
>> - * otherwise the vga fbdev driver falls over.
>> - */
>> -#if IS_REACHABLE(CONFIG_FB)
>> - ret = remove_conflicting_pci_framebuffers(pdev, name);
>> - if (ret)
>> - return ret;
>> +#ifdef CONFIG_X86
>> + primary = pdev->resource[PCI_ROM_RESOURCE].flags &
>> IORESOURCE_ROM_SHADOW;
>> #endif
>> - ret = vga_remove_vgacon(pdev);
>> - if (ret)
>> - return ret;
>> for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
>> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
>> continue;
>> +
>> base = pci_resource_start(pdev, bar);
>> size = pci_resource_len(pdev, bar);
>> - aperture_detach_devices(base, size);
>> + ret = aperture_remove_conflicting_devices(base, size,
>> primary, name);
>> + if (ret)
>> + break;
>> }
>> + if (ret)
>> + return ret;
>> +
>> + /*
>> + * WARNING: Apparently we must kick fbdev drivers before vgacon,
>> + * otherwise the vga fbdev driver falls over.
>> + */
>> + ret = vga_remove_vgacon(pdev);
>> + if (ret)
>> + return ret;
>> +
>> return 0;
>> }
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1788,54 +1788,6 @@ int remove_conflicting_framebuffers(stru
>> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>> /**
>> - * remove_conflicting_pci_framebuffers - remove firmware-configured
>> framebuffers for PCI devices
>> - * @pdev: PCI device
>> - * @name: requesting driver name
>> - *
>> - * This function removes framebuffer devices (eg. initialized by
>> firmware)
>> - * using memory range configured for any of @pdev's memory bars.
>> - *
>> - * The function assumes that PCI device with shadowed ROM drives a
>> primary
>> - * display and so kicks out vga16fb.
>> - */
>> -int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const
>> char *name)
>> -{
>> - struct apertures_struct *ap;
>> - bool primary = false;
>> - int err, idx, bar;
>> -
>> - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
>> - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
>> - continue;
>> - idx++;
>> - }
>> -
>> - ap = alloc_apertures(idx);
>> - if (!ap)
>> - return -ENOMEM;
>> -
>> - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
>> - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
>> - continue;
>> - ap->ranges[idx].base = pci_resource_start(pdev, bar);
>> - ap->ranges[idx].size = pci_resource_len(pdev, bar);
>> - pci_dbg(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar,
>> - (unsigned long)pci_resource_start(pdev, bar),
>> - (unsigned long)pci_resource_end(pdev, bar));
>> - idx++;
>> - }
>> -
>> -#ifdef CONFIG_X86
>> - primary = pdev->resource[PCI_ROM_RESOURCE].flags &
>> - IORESOURCE_ROM_SHADOW;
>> -#endif
>> - err = remove_conflicting_framebuffers(ap, name, primary);
>> - kfree(ap);
>> - return err;
>> -}
>> -EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
>> -
>> -/**
>> * register_framebuffer - registers a frame buffer device
>> * @fb_info: frame buffer info structure
>> *
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in
>> /* drivers/video/fbmem.c */
>> extern int register_framebuffer(struct fb_info *fb_info);
>> extern void unregister_framebuffer(struct fb_info *fb_info);
>> -extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
>> - const char *name);
>> extern int remove_conflicting_framebuffers(struct apertures_struct *a,
>> const char *name, bool primary);
>> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
>>
>>
>>
>>
>
> Hello,
>
> this patch seems to disable console/framebuffer when vfio-pci is used.
> I hava 2 nvidia GPUs one is used for host and other is passed through to
> VM.
Vfio uses this helper to unload the driver before passing it to a VM
AFAIU. But unless you're using nouveau, you're on your own.
Best regards
Thomas
> Now after this patch, when vfio-pci module is loaded with parameter
> ids=10de:2486,10de:228b,
> console is lost/frozen, last message is that vfio-pci module was loaded
> and then there is no more output.
> This PCI IDs (10de:2486,10de:228b) are for secondary GPU, primary/boot
> GPU is used for host and boot messages are displayed on primary/boot GPU.
>
> Using dmesg I see this messages after vfio-pci is loaded:
>
> [ 3.993601] VFIO - User Level meta-driver version: 0.3
> [ 4.020239] Console: switching to colour dummy device 80x25
> [ 4.020335] vfio-pci 0000:1a:00.0: vgaarb: changed VGA decodes:
> olddecodes=io+mem,decodes=none:owns=none
> [ 4.020722] vfio_pci: add [10de:2486[ffffffff:ffffffff]] class
> 0x000000/00000000
> [ 4.116616] vfio_pci: add [10de:228b[ffffffff:ffffffff]] class
> 0x000000/00000000
>
> I guess the problem here is "Console: switching to colour dummy device
> 80x25", but I don't know why this happens.
> Last working kernel is 6.0.3, after upgrading to 6.0.4 (and 6.0.5,
> 6.0.6), console is no longer working.
> By git bisecting it seems bad commit is
> af9ac541e88390d97b01d5e8c77309d2637c1d4c.
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers()
2022-11-01 10:34 ` Thomas Zimmermann
@ 2022-11-01 11:34 ` Boris V.
0 siblings, 0 replies; 41+ messages in thread
From: Boris V. @ 2022-11-01 11:34 UTC (permalink / raw)
To: Thomas Zimmermann, Greg Kroah-Hartman, linux-kernel, Alex Williamson
Cc: stable, Javier Martinez Canillas
On 01/11/2022 11:34, Thomas Zimmermann wrote:
> (cc: Alex Williamson)
>
> Hi
>
> Am 01.11.22 um 09:42 schrieb Boris V.:
>> On 24/10/2022 13:31, Greg Kroah-Hartman wrote:
>>> From: Thomas Zimmermann <tzimmermann@suse.de>
>>>
>>> commit 9d69ef1838150c7d87afc1a87aa658c637217585 upstream.
>>>
>>> Remove remove_conflicting_pci_framebuffers() and implement similar
>>> functionality in aperture_remove_conflicting_pci_device(), which was
>>> the only caller. Removes an otherwise unused interface and streamlines
>>> the aperture helper. No functional changes.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Link:
>>> https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-5-tzimmermann@suse.de
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> ---
>>> drivers/video/aperture.c | 30 ++++++++++++++----------
>>> drivers/video/fbdev/core/fbmem.c | 48
>>> ---------------------------------------
>>> include/linux/fb.h | 2 -
>>> 3 files changed, 18 insertions(+), 62 deletions(-)
>>>
>>> --- a/drivers/video/aperture.c
>>> +++ b/drivers/video/aperture.c
>>> @@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin
>>> */
>>> int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev,
>>> const char *name)
>>> {
>>> + bool primary = false;
>>> resource_size_t base, size;
>>> int bar, ret;
>>> - /*
>>> - * WARNING: Apparently we must kick fbdev drivers before vgacon,
>>> - * otherwise the vga fbdev driver falls over.
>>> - */
>>> -#if IS_REACHABLE(CONFIG_FB)
>>> - ret = remove_conflicting_pci_framebuffers(pdev, name);
>>> - if (ret)
>>> - return ret;
>>> +#ifdef CONFIG_X86
>>> + primary = pdev->resource[PCI_ROM_RESOURCE].flags &
>>> IORESOURCE_ROM_SHADOW;
>>> #endif
>>> - ret = vga_remove_vgacon(pdev);
>>> - if (ret)
>>> - return ret;
>>> for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
>>> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
>>> continue;
>>> +
>>> base = pci_resource_start(pdev, bar);
>>> size = pci_resource_len(pdev, bar);
>>> - aperture_detach_devices(base, size);
>>> + ret = aperture_remove_conflicting_devices(base, size,
>>> primary, name);
>>> + if (ret)
>>> + break;
>>> }
>>> + if (ret)
>>> + return ret;
>>> +
>>> + /*
>>> + * WARNING: Apparently we must kick fbdev drivers before vgacon,
>>> + * otherwise the vga fbdev driver falls over.
>>> + */
>>> + ret = vga_remove_vgacon(pdev);
>>> + if (ret)
>>> + return ret;
>>> +
>>> return 0;
>>> }
>>> --- a/drivers/video/fbdev/core/fbmem.c
>>> +++ b/drivers/video/fbdev/core/fbmem.c
>>> @@ -1788,54 +1788,6 @@ int remove_conflicting_framebuffers(stru
>>> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>>> /**
>>> - * remove_conflicting_pci_framebuffers - remove firmware-configured
>>> framebuffers for PCI devices
>>> - * @pdev: PCI device
>>> - * @name: requesting driver name
>>> - *
>>> - * This function removes framebuffer devices (eg. initialized by
>>> firmware)
>>> - * using memory range configured for any of @pdev's memory bars.
>>> - *
>>> - * The function assumes that PCI device with shadowed ROM drives a
>>> primary
>>> - * display and so kicks out vga16fb.
>>> - */
>>> -int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const
>>> char *name)
>>> -{
>>> - struct apertures_struct *ap;
>>> - bool primary = false;
>>> - int err, idx, bar;
>>> -
>>> - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
>>> - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
>>> - continue;
>>> - idx++;
>>> - }
>>> -
>>> - ap = alloc_apertures(idx);
>>> - if (!ap)
>>> - return -ENOMEM;
>>> -
>>> - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
>>> - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
>>> - continue;
>>> - ap->ranges[idx].base = pci_resource_start(pdev, bar);
>>> - ap->ranges[idx].size = pci_resource_len(pdev, bar);
>>> - pci_dbg(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar,
>>> - (unsigned long)pci_resource_start(pdev, bar),
>>> - (unsigned long)pci_resource_end(pdev, bar));
>>> - idx++;
>>> - }
>>> -
>>> -#ifdef CONFIG_X86
>>> - primary = pdev->resource[PCI_ROM_RESOURCE].flags &
>>> - IORESOURCE_ROM_SHADOW;
>>> -#endif
>>> - err = remove_conflicting_framebuffers(ap, name, primary);
>>> - kfree(ap);
>>> - return err;
>>> -}
>>> -EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
>>> -
>>> -/**
>>> * register_framebuffer - registers a frame buffer device
>>> * @fb_info: frame buffer info structure
>>> *
>>> --- a/include/linux/fb.h
>>> +++ b/include/linux/fb.h
>>> @@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in
>>> /* drivers/video/fbmem.c */
>>> extern int register_framebuffer(struct fb_info *fb_info);
>>> extern void unregister_framebuffer(struct fb_info *fb_info);
>>> -extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
>>> - const char *name);
>>> extern int remove_conflicting_framebuffers(struct apertures_struct
>>> *a,
>>> const char *name, bool primary);
>>> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
>>>
>>>
>>>
>>>
>>
>> Hello,
>>
>> this patch seems to disable console/framebuffer when vfio-pci is used.
>> I hava 2 nvidia GPUs one is used for host and other is passed through
>> to VM.
>
> Vfio uses this helper to unload the driver before passing it to a VM
> AFAIU. But unless you're using nouveau, you're on your own.
>
> Best regards
> Thomas
>
But this happens at boot, when vfio-pci module is loaded. Not when VM is
started.
And console/framebuffer is unloaded for primary/boot GPU, not the one
passed to VM.
Also no GPU driver is loaded at this point. And there was no problem
before, it stopped working with 6.0.4 kernel.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2022-10-24 11:31 ` [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers() Greg Kroah-Hartman
@ 2022-10-24 15:47 ` Luna Jernberg
2022-10-24 19:10 ` Rudi Heitbaum
` (10 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Luna Jernberg @ 2022-10-24 15:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Luna Jernberg
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
Works on my Arch Linux Server with Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
Tested-by: Luna Jernberg <droidbittin@gmail.com>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2022-10-24 15:47 ` [PATCH 6.0 00/20] 6.0.4-rc1 review Luna Jernberg
@ 2022-10-24 19:10 ` Rudi Heitbaum
2022-10-24 19:21 ` Jon Hunter
` (9 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Rudi Heitbaum @ 2022-10-24 19:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On Mon, Oct 24, 2022 at 01:31:02PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
>
Hi Greg,
6.0.4-rc1 tested.
Run tested on:
- Intel Alder Lake x86_64 (nuc12 i7-1260P)
In addition - build tested for:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- Allwinner H6
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos5422
Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
--
Rudi
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2022-10-24 19:10 ` Rudi Heitbaum
@ 2022-10-24 19:21 ` Jon Hunter
2022-10-24 19:28 ` Florian Fainelli
` (8 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Jon Hunter @ 2022-10-24 19:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, f.fainelli, sudipm.mukherjee, srw, linux-tegra
On 24/10/2022 12:31, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
No new regressions for Tegra ...
Test results for stable-v6.0:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 128 pass, 2 fail
Linux version: 6.0.4-rc1-gd4150c7b49be
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Test failures: tegra194-p2972-0000: boot.py
tegra210-p3450-0000: devices
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2022-10-24 19:21 ` Jon Hunter
@ 2022-10-24 19:28 ` Florian Fainelli
2022-10-24 20:48 ` Shuah Khan
` (7 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Florian Fainelli @ 2022-10-24 19:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, sudipm.mukherjee, srw
On 10/24/22 04:31, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2022-10-24 19:28 ` Florian Fainelli
@ 2022-10-24 20:48 ` Shuah Khan
2022-10-24 21:55 ` Ron Economos
` (6 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Shuah Khan @ 2022-10-24 20:48 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, Shuah Khan
On 10/24/22 05:31, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2022-10-24 20:48 ` Shuah Khan
@ 2022-10-24 21:55 ` Ron Economos
2022-10-25 0:20 ` Slade Watkins
` (5 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Ron Economos @ 2022-10-24 21:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On 10/24/22 4:31 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <re@w6rz.net>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2022-10-24 21:55 ` Ron Economos
@ 2022-10-25 0:20 ` Slade Watkins
2022-10-25 9:08 ` Bagas Sanjaya
` (4 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Slade Watkins @ 2022-10-25 0:20 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee
On 10/24/22 7:31 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
6.0.4-rc1 compiled and booted on my x86_64 test system. No errors or
regressions.
Tested-by: Slade Watkins <srw@sladewatkins.net>
All the best,
-srw
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2022-10-25 0:20 ` Slade Watkins
@ 2022-10-25 9:08 ` Bagas Sanjaya
2022-10-25 12:33 ` Naresh Kamboju
` (3 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Bagas Sanjaya @ 2022-10-25 9:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
On Mon, Oct 24, 2022 at 01:31:02PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and
powerpc (ps3_defconfig, GCC 12.1.0).
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2022-10-25 9:08 ` Bagas Sanjaya
@ 2022-10-25 12:33 ` Naresh Kamboju
2022-10-25 15:32 ` Guenter Roeck
` (2 subsequent siblings)
31 siblings, 0 replies; 41+ messages in thread
From: Naresh Kamboju @ 2022-10-25 12:33 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On Mon, 24 Oct 2022 at 17:02, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro's test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 6.0.4-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.0.y
* git commit: [None, 'd4150c7b49be8290e2a00c80f2bb2a534a627ad6']
* git describe: v6.0.3-22-gd4150c7b49be
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.0.y/build/v6.0.3-22-gd4150c7b49be
## No sTest Regressions (compared to v6.0.3)
## No Metric Regressions (compared to v6.0.3)
## No Test Fixes (compared to v6.0.3)
## No Metric Fixes (compared to v6.0.3)
## Test result summary
total: 144226, pass: 123359, fail: 5726, skip: 14716, xfail: 425
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 329 total, 325 passed, 4 failed
* arm64: 61 total, 61 passed, 0 failed
* i386: 53 total, 53 passed, 0 failed
* mips: 54 total, 53 passed, 1 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 67 total, 61 passed, 6 failed
* riscv: 26 total, 26 passed, 0 failed
* s390: 14 total, 14 passed, 0 failed
* sh: 23 total, 23 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 58 total, 58 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-at
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2022-10-25 12:33 ` Naresh Kamboju
@ 2022-10-25 15:32 ` Guenter Roeck
2022-10-25 22:43 ` Justin Forbes
2022-10-26 6:36 ` Ernst Herzberg
31 siblings, 0 replies; 41+ messages in thread
From: Guenter Roeck @ 2022-10-25 15:32 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On Mon, Oct 24, 2022 at 01:31:02PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
>
Teest results are for 6.0.3-22-gd4150c7.
Build results:
total: 152 pass: 152 fail: 0
Qemu test results:
total: 499 pass: 499 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2022-10-25 15:32 ` Guenter Roeck
@ 2022-10-25 22:43 ` Justin Forbes
2022-10-26 6:36 ` Ernst Herzberg
31 siblings, 0 replies; 41+ messages in thread
From: Justin Forbes @ 2022-10-25 22:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On Mon, Oct 24, 2022 at 01:31:02PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.0.4 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le,
s390x, x86_64), and boot tested x86_64. No regressions noted.
Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-24 11:31 [PATCH 6.0 00/20] 6.0.4-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2022-10-25 22:43 ` Justin Forbes
@ 2022-10-26 6:36 ` Ernst Herzberg
2022-10-26 6:59 ` Greg Kroah-Hartman
31 siblings, 1 reply; 41+ messages in thread
From: Ernst Herzberg @ 2022-10-26 6:36 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
Missed a patch?
Problematic patch in v6.0.3 :
> commit 3ea7c50339859394dd667184b5b16eee1ebb53bc
> Author: Josef Bacik <josef@toxicpanda.com>
> Date: Mon Aug 8 16:10:26 2022 -0400
>
> btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure
> [ Upstream commit 8a1ae2781dee9fc21ca82db682d37bea4bd074ad ]
> Now that lockdep is staying enabled through our entire CI runs I started
> seeing the following stack in generic/475
See:
https://lore.kernel.org/stable/Y1aeWdHd4%2FluzhAu@localhost.localdomain/
>
> Well I definitely fucked this patch up, because I should have used the _locked
> variant, but this was part of a series where I did the correct thing in the next
> patch
>
> btrfs: remove use btrfs_remove_free_space_cache instead of variant
>
> so this problem doesn't exist in linus. So either we need to pull that back
> into stable as well, or drop this patch from stable. I'm good either way, this
> was just to fix a lockdep splat so it's not really stable material, but I'll
> leave that decision up to y'all. Thanks,
>
> Josef
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
2022-10-26 6:36 ` Ernst Herzberg
@ 2022-10-26 6:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 41+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-26 6:59 UTC (permalink / raw)
To: Ernst Herzberg
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw
On Wed, Oct 26, 2022 at 08:36:55AM +0200, Ernst Herzberg wrote:
> Missed a patch?
>
> Problematic patch in v6.0.3 :
>
> > commit 3ea7c50339859394dd667184b5b16eee1ebb53bc
> > Author: Josef Bacik <josef@toxicpanda.com>
> > Date: Mon Aug 8 16:10:26 2022 -0400
> >
> > btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure
> > [ Upstream commit 8a1ae2781dee9fc21ca82db682d37bea4bd074ad ]
> > Now that lockdep is staying enabled through our entire CI runs I started
> > seeing the following stack in generic/475
>
>
> See:
>
> https://lore.kernel.org/stable/Y1aeWdHd4%2FluzhAu@localhost.localdomain/
That will be resolved in the next release, give us a chance to get this
one out first...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 41+ messages in thread