Since 0b63accf87225b5eb7e52814c374cf02d733d4bb, the test includes a
verification of time passage that is unstable as it is prone to
different results based on the system load.
Other investigations led to disabling this test in various other
places/projects. For example, Linaro also disabled it[1].
We have chosen to keep this test but to force its result unconditionally
successful as opposed to reverting the aforementioned commit because:
1. it keeps running the test with results and data that we can use in
the future for any "smarter" way to deal with it - eg. statistical
approach
2. it minimizes the maintenance burden of this patch kept in our kernel
trees
It is worth mentioning that upstream was contacted via the mailing list
with no feedback[2]. The request was to increase the current tolerance
set at 10%.
UBUNTU: SAUCE: mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type
spi_nor_set_erase_type() was used either to set or to mask out an erase
type. When we used it to mask out an erase type a shift-out-of-bounds
was hit:
UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
shift exponent 4294967295 is too large for 32-bit type 'int'
The setting of the size_{shift, mask} and of the opcode are unnecessary
when the erase size is zero, as throughout the code just the erase size
is considered to determine whether an erase type is supported or not.
Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF
is an unused opcode. Thus when masking out an erase type, just set the
erase size to zero. This will fix the shift-out-of-bounds.
Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories")
Cc: <email address hidden>
Reported-by: Alexander Stein <email address hidden>
Signed-off-by: Louis Rannou <email address hidden>
Tested-by: Alexander Stein <email address hidden>
Link: https://<email address hidden>
[ta: refine changes, new commit message, fix compilation error]
Signed-off-by: Tudor Ambarus <email address hidden>
(cherry picked from https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/commit/?h=spi-nor/next&id=f0f0cfdc3a024e21161714f2e05f0df3b84d42ad)
Signed-off-by: Andrea Righi <email address hidden>
It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU
mask internally in UAPI format") exposed a potential out-of-bounds
access, reported by UBSAN as following on a laptop with a gen 11 i915
card:
UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27
index 6 is out of range for type 'u16 [6]'
CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu
Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022
Call Trace:
<TASK>
show_stack+0x4e/0x61
dump_stack_lvl+0x4a/0x6f
dump_stack+0x10/0x18
ubsan_epilogue+0x9/0x3a
__ubsan_handle_out_of_bounds.cold+0x42/0x47
gen11_compute_sseu_info+0x121/0x130 [i915]
intel_sseu_info_init+0x15d/0x2b0 [i915]
intel_gt_init_mmio+0x23/0x40 [i915]
i915_driver_mmio_probe+0x129/0x400 [i915]
? intel_gt_probe_all+0x91/0x2e0 [i915]
i915_driver_probe+0xe1/0x3f0 [i915]
? drm_privacy_screen_get+0x16d/0x190 [drm]
? acpi_dev_found+0x64/0x80
i915_pci_probe+0xac/0x1b0 [i915]
...
According to the definition of sseu_dev_info, eu_mask->hsw is limited to
a maximum of GEN_MAX_SS_PER_HSW_SLICE (6) sub-slices, but
gen11_sseu_info_init() can potentially set 8 sub-slices, in the
!IS_JSL_EHL(gt->i915) case.
Fix this by reserving up to 8 slots for max_subslices in the eu_mask
struct.
Reported-by: Emil Renner Berthing <email address hidden>
(cherry-picked from https://<email address hidden>/T/#u)
Signed-off-by: Andrea Righi <email address hidden>
