Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add required SECURITY.md file for OSSF Scorecard compliance #237

Open
wants to merge 39 commits into
base: gvt-staging
Choose a base branch
from

Conversation

rdower
Copy link

@rdower rdower commented May 3, 2024

add required SECURITY.md file for OSSF Scorecard compliance

drvgithubuser and others added 30 commits January 31, 2023 16:48
Remove the extra semicolon at end. Issue identified using
semicolon.cocci Coccinelle semantic patch.

Signed-off-by: Deepak R Varma <drv@mailo.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/Y8LNbzgTf/1kYJX/@ubun2204.myguest.virtualbox.org
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
As a lockmap takes a reference for every ww_mutex used together, this
can be an arbitrarily large number and under control of userspace --
easily overflowing the arbitrary limit of 4096. However, the pin_count
(used for detecting unexpected lock dropping) is a full 32b despite
nesting being extremely rare (see lockdep_pin_lock).

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8028
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190425092004.9995-33-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
We have recently turned on ftrace-dump-on-oops for i915's CI and an
issue we have encountered is that the trace buffer size greatly exceeds
the pstore capabilities; we get the tail of the oops but not the
introduction.

Currently the global buffer size is controllable on the cmdline, but at
the request of our CI sysadmin, we would like to add a control to the
Kconfig as well. The rationale being the cmdline carries the temporary
hacks that we want to eradicate, and we want to track the permanent
configuration in .config.

I have kept the Kconfig option hidden from the user as the default
should suffice for the majority of users; reserving the configuration
for those that eschew the cmdline option.

v2: Add an expert prompt to stop the default value overriding .config
changes.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8029
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Steven Rostedt <srostedt@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Most systems keep the last messages from the panic, and we value the
stacktrace most, so dump it last in order to preserve it for
post-mortems.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8030
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Martin Peres <martin.peres@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180903131745.30593-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Under CI testing, it is common for the cpus to overheat with the
continuous workloads and end up being throttled. As the cpus still
function, it is less of a critical error meriting urgent action, but an
expected yet significant condition (pr_note).

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8031
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8032
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
[danvet: Rebase]
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Work around the following boot time crash:

[   10.456056] CPU: 1 PID: 220 Comm: systemd-udevd Tainted: G        W         4.17.0-rc7-CI-CI_DRM_4040+ intel#182
[   10.465828] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS
+ICLSFWR1.R00.2204.A00.1805172221 05/17/2018
[   10.479168] RIP: 0010:acpi_ps_complete_this_op+0xa7/0x22a
[   10.484627] RSP: 0018:ffffc900003a7578 EFLAGS: 00010202
[   10.489881] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8804abeda9c8 RCX: 0000000000000020
[   10.497045] RDX: 0000000000000000 RSI: ffff88049e604a68 RDI: 0000000000000000
[   10.504213] RBP: 0000000000000000 R08: ffff8804abeda9c8 R09: 0000000000000000
[   10.511376] R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000e
[   10.518542] R13: ffff88049e604a68 R14: ffff88049e604a68 R15: ffffffffa00263c2
[   10.525713] FS:  00007ff6d85f18c0(0000) GS:ffff8804be880000(0000) knlGS:0000000000000000
[   10.533839] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   10.539616] CR2: 00007ff6d73cff40 CR3: 000000049f794001 CR4: 0000000000760ee0
[   10.546783] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   10.553949] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   10.561112] PKRU: 55555554
[   10.563849] Call Trace:
[   10.566323]  acpi_ps_complete_op+0x49/0x3f1
[   10.570537]  acpi_ps_parse_loop+0x94c/0x9bb
[   10.574754]  ? acpi_ds_delete_walk_state+0x113/0x131
[   10.579750]  acpi_ps_parse_aml+0x1a2/0x4af
[   10.583875]  acpi_ps_execute_method+0x1e9/0x2a5
[   10.588435]  acpi_ns_evaluate+0x2e4/0x42c
[   10.592473]  acpi_evaluate_object+0x1fd/0x3a8
[   10.596873]  usb_acpi_find_companion+0xee/0x1f0 [usbcore]
[   10.602319]  acpi_platform_notify+0x33/0xa0
[   10.606532]  device_add+0x197/0x600
[   10.610048]  ? __init_waitqueue_head+0x36/0x50
[   10.614529]  usb_hub_create_port_device+0x11d/0x340 [usbcore]
[   10.620314]  hub_probe+0x9a5/0x1010 [usbcore]
[   10.624701]  ? _raw_spin_unlock_irqrestore+0x51/0x60
[   10.629730]  usb_probe_interface+0x13f/0x300 [usbcore]
[   10.634900]  driver_probe_device+0x302/0x470
[   10.639198]  ? __driver_attach+0xe0/0xe0
[   10.643147]  bus_for_each_drv+0x59/0x90
[   10.647013]  __device_attach+0xb7/0x130
[   10.650878]  bus_probe_device+0x9c/0xb0
[   10.654745]  device_add+0x3c5/0x600
[   10.658270]  usb_set_configuration+0x540/0x880 [usbcore]
[   10.663621]  generic_probe+0x28/0x80 [usbcore]
[   10.668097]  driver_probe_device+0x302/0x470
[   10.672393]  ? __driver_attach+0xe0/0xe0
[   10.676346]  bus_for_each_drv+0x59/0x90
[   10.680211]  __device_attach+0xb7/0x130
[   10.684076]  bus_probe_device+0x9c/0xb0
[   10.687940]  device_add+0x3c5/0x600
[   10.691464]  usb_new_device+0x269/0x490 [usbcore]
[   10.696206]  usb_add_hcd+0x558/0x850 [usbcore]
[   10.700682]  xhci_pci_probe+0x13d/0x240 [xhci_pci]
[   10.705534]  pci_device_probe+0xa1/0x130
[   10.709484]  driver_probe_device+0x302/0x470
[   10.713784]  __driver_attach+0xb9/0xe0
[   10.717562]  ? driver_probe_device+0x470/0x470
[   10.722033]  ? driver_probe_device+0x470/0x470
[   10.726505]  bus_for_each_dev+0x64/0x90
[   10.730370]  ? preempt_count_sub+0x92/0xd0
[   10.734495]  bus_add_driver+0x164/0x260
[   10.738362]  ? 0xffffffffa004e000
[   10.741704]  driver_register+0x57/0xc0
[   10.745482]  ? 0xffffffffa004e000
[   10.748824]  do_one_initcall+0x4a/0x350
[   10.752690]  ? do_init_module+0x22/0x20a
[   10.756643]  ? rcu_read_lock_sched_held+0x74/0x80
[   10.761377]  ? kmem_cache_alloc_trace+0x284/0x2e0
[   10.766114]  do_init_module+0x5b/0x20a
[   10.769895]  load_module+0x250d/0x2b20
[   10.773678]  ? kernel_read+0x2c/0x40
[   10.777285]  ? __se_sys_finit_module+0xaa/0xc0
[   10.781759]  __se_sys_finit_module+0xaa/0xc0
[   10.786061]  do_syscall_64+0x54/0x190
[   10.789752]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   10.794831] RIP: 0033:0x7ff6d74664d9
[   10.798430] RSP: 002b:00007ffd91e7dd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   10.806033] RAX: ffffffffffffffda RBX: 0000560519bfae20 RCX: 00007ff6d74664d9
[   10.813195] RDX: 0000000000000000 RSI: 00007ff6d795ce23 RDI: 000000000000000e
[   10.820360] RBP: 00007ff6d795ce23 R08: 0000000000000000 R09: 0000000000000000
[   10.827523] R10: 000000000000000e R11: 0000000000000246 R12: 0000000000000000
[   10.834690] R13: 0000560519bf9a30 R14: 0000000000020000 R15: 000000000aba9500
[   10.841862] Code: c2 10 5f ea 81 48 c7 c6 f0 5e ea 81 bf 7c 00 00 00 e8 0d 7c 00 00 31 ed e9 88 01 00 00 48 8b 03 31 ed 48 85 c0
+0f 84 e9 00 00 00 <4c> 8b 60 28 4d 85 e4 0f 84 dc 00 00 00 0f b7 78 0a e8 62 fe ff
[   10.860832] RIP: acpi_ps_complete_this_op+0xa7/0x22a RSP: ffffc900003a7578
[   10.867907] ---[ end trace 3a0d2ee1129bc71e ]---

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8033
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180702135756.12159-1-imre.deak@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
There's the hung_task_panic sysctl, but that's a bit an extreme measure.
As a fallback taint at least the machine.

Our CI uses this to decide when a reboot is necessary, plus to figure
out whether the kernel is still happy.

v2: Works much better when I put the else { add_taint() } at the right
place.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8034
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "Liu, Chuansheng" <chuansheng.liu@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (for core-for-CI)
Link: https://patchwork.freedesktop.org/patch/msgid/20190502204648.5537-1-daniel.vetter@ffwll.ch
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
There's the soft/hardlookup_panic sysctls, but that's a bit an extreme
measure. As a fallback taint at least the machine.

Our CI uses this to decide when a reboot is necessary, plus to figure
out whether the kernel is still happy.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8035
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: Laurence Oberman <loberman@redhat.com>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Sinan Kaya <okaya@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (for core-for-CI)
Link: https://patchwork.freedesktop.org/patch/msgid/20190502194208.3535-2-daniel.vetter@ffwll.ch
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
We can't allow spam in CI.

Update 26th June 2018: This is still an issue:
Update 23rd May 2019: You guessed it, still ocurring.

[  224.739686] ------------[ cut here ]------------
[  224.739712] WARNING: CPU: 3 PID: 2982 at net/sched/sch_generic.c:461 dev_watchdog+0x1fd/0x210
[  224.739714] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm i915 asix usbnet mii mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel btusb btrtl btbcm btintel bluetooth ecdh_generic
[  224.739775] CPU: 3 PID: 2982 Comm: gem_exec_suspen Tainted: G     U  W         4.18.0-rc2-CI-Patchwork_9414+ intel#1
[  224.739777] Hardware name: Dell Inc. XPS 13 9350/, BIOS 1.4.12 11/30/2016
[  224.739780] RIP: 0010:dev_watchdog+0x1fd/0x210
[  224.739781] Code: 49 63 4c 24 f0 eb 92 4c 89 ef c6 05 21 46 ad 00 01 e8 77 ee fc ff 89 d9 48 89 c2 4c 89 ee 48 c7 c7 88 4c 14 82 e8 a3 fe 84 ff <0f> 0b eb be 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 47
[  224.739866] RSP: 0018:ffff88027dd83e40 EFLAGS: 00010286
[  224.739869] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000102
[  224.739871] RDX: 0000000080000102 RSI: ffffffff820c8c6c RDI: 00000000ffffffff
[  224.739873] RBP: ffff8802644c1540 R08: 0000000071be9b33 R09: 0000000000000000
[  224.739874] R10: ffff88027dd83dc0 R11: 0000000000000000 R12: ffff8802644c1588
[  224.739876] R13: ffff8802644c1160 R14: 0000000000000001 R15: ffff88026a5dc728
[  224.739878] FS:  00007f18f4887980(0000) GS:ffff88027dd80000(0000) knlGS:0000000000000000
[  224.739880] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  224.739881] CR2: 00007f4c627ae548 CR3: 000000022ca1a002 CR4: 00000000003606e0
[  224.739883] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  224.739885] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  224.739886] Call Trace:
[  224.739888]  <IRQ>
[  224.739892]  ? qdisc_reset+0xe0/0xe0
[  224.739894]  ? qdisc_reset+0xe0/0xe0
[  224.739897]  call_timer_fn+0x93/0x360
[  224.739903]  expire_timers+0xc1/0x1d0
[  224.739908]  run_timer_softirq+0xc7/0x170
[  224.739916]  __do_softirq+0xd9/0x505
[  224.739923]  irq_exit+0xa9/0xc0
[  224.739926]  smp_apic_timer_interrupt+0x9c/0x2d0
[  224.739929]  apic_timer_interrupt+0xf/0x20
[  224.739931]  </IRQ>
[  224.739934] RIP: 0010:delay_tsc+0x2e/0xb0
[  224.739936] Code: 49 89 fc 55 53 bf 01 00 00 00 e8 6d 2c 78 ff e8 88 9d b6 ff 41 89 c5 0f ae e8 0f 31 48 c1 e2 20 48 09 c2 48 89 d5 eb 16 f3 90 <bf> 01 00 00 00 e8 48 2c 78 ff e8 63 9d b6 ff 44 39 e8 75 36 0f ae
[  224.740021] RSP: 0018:ffffc900002f7d48 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
[  224.740024] RAX: 0000000080000000 RBX: 0000000649565ca9 RCX: 0000000000000001
[  224.740026] RDX: 0000000080000001 RSI: ffffffff820c8c6c RDI: 00000000ffffffff
[  224.740027] RBP: 00000006493ea9ce R08: 000000005e81e2ee R09: 0000000000000000
[  224.740029] R10: 0000000000000120 R11: 0000000000000000 R12: 00000000002ad8d6
[  224.740030] R13: 0000000000000003 R14: 0000000000000004 R15: ffff88025caf5408
[  224.740040]  ? delay_tsc+0x66/0xb0
[  224.740045]  hibernation_debug_sleep+0x1c/0x30
[  224.740048]  hibernation_snapshot+0x2c1/0x690
[  224.740053]  hibernate+0x142/0x2a4
[  224.740057]  state_store+0xd0/0xe0
[  224.740063]  kernfs_fop_write+0x104/0x190
[  224.740068]  __vfs_write+0x31/0x180
[  224.740072]  ? rcu_read_lock_sched_held+0x6f/0x80
[  224.740075]  ? rcu_sync_lockdep_assert+0x29/0x50
[  224.740078]  ? __sb_start_write+0x152/0x1f0
[  224.740080]  ? __sb_start_write+0x168/0x1f0
[  224.740084]  vfs_write+0xbd/0x1a0
[  224.740088]  ksys_write+0x50/0xc0
[  224.740094]  do_syscall_64+0x55/0x190
[  224.740097]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  224.740099] RIP: 0033:0x7f18f400a281
[  224.740100] Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
[  224.740186] RSP: 002b:00007fffd1f4fec8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  224.740189] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f18f400a281
[  224.740190] RDX: 0000000000000004 RSI: 00007f18f448069a RDI: 0000000000000006
[  224.740192] RBP: 00007fffd1f4fef0 R08: 0000000000000000 R09: 0000000000000000
[  224.740194] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e795d03400
[  224.740195] R13: 00007fffd1f50500 R14: 0000000000000000 R15: 0000000000000000
[  224.740205] irq event stamp: 1582591
[  224.740207] hardirqs last  enabled at (1582590): [<ffffffff810f9f9c>] vprintk_emit+0x4bc/0x4d0
[  224.740210] hardirqs last disabled at (1582591): [<ffffffff81a0111c>] error_entry+0x7c/0x100
[  224.740212] softirqs last  enabled at (1582568): [<ffffffff81c0034f>] __do_softirq+0x34f/0x505
[  224.740215] softirqs last disabled at (1582571): [<ffffffff8108c959>] irq_exit+0xa9/0xc0
[  224.740218] WARNING: CPU: 3 PID: 2982 at net/sched/sch_generic.c:461 dev_watchdog+0x1fd/0x210
[  224.740219] ---[ end trace 6e41d690e611c338 ]---

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8037
References: https://bugzilla.kernel.org/show_bug.cgi?id=196399
Acked-by: Martin Peres <martin.peres@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170718082110.12524-1-daniel.vetter@ffwll.ch
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Since the kernel now used hashed pointers for raw addresses, it is very
hard to guage the relative placement within a section, and since the
hash value will never match up with any contents, using it provides no
information relevant for slab debugging. Show the relative offset into
each section, so that some reference for the hexdump is provided.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8038
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Remove copious amounts of
./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000000000000000 becomes 0)
as they are drowning out our warnings.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8039
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190727121750.20882-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This reverts commit cea35f5.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8040
References: https://lists.freedesktop.org/archives/intel-gfx/2019-November/218878.html
Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
If the MSI is already enabled, trying to enable it again results in an
-EINVAL and on the first attempt a WARN. That WARN causes our CI to
abort the run [on each first attempt to suspend]:

<4> [463.142025] WARNING: CPU: 0 PID: 2225 at drivers/pci/msi.c:1074 __pci_enable_msi_range+0x3cb/0x420
<4> [463.142026] Modules linked in: snd_hda_intel i915 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_dspcfg ghash_clmulni_intel snd_hda_codec btusb btrtl btbcm btintel e1000e bluetooth snd_hwdep snd_hda_core ptp ecdh_generic snd_pcm ecc pps_core mei_me mei prime_numbers [last unloaded: i915]
<4> [463.142045] CPU: 0 PID: 2225 Comm: kworker/u8:14 Tainted: G     U            5.7.0-rc2-CI-CI_DRM_8350+ intel#1
<4> [463.142046] Hardware name: Intel Corporation NUC7i5BNH/NUC7i5BNB, BIOS BNKBL357.86A.0060.2017.1214.2013 12/14/2017
<4> [463.142049] Workqueue: events_unbound async_run_entry_fn
<4> [463.142051] RIP: 0010:__pci_enable_msi_range+0x3cb/0x420
<4> [463.142053] Code: 76 58 49 8d 56 48 48 89 df e8 31 73 fd ff e9 20 fe ff ff 31 f6 48 89 df e8 c2 e9 fd ff e9 d6 fe ff ff 45 89 fc e9 1a ff ff ff <0f> 0b 41 bc ea ff ff ff e9 0d ff ff ff 41 bc ea ff ff ff e9 02 ff
<4> [463.142054] RSP: 0018:ffffc90000593cd0 EFLAGS: 00010202
<4> [463.142056] RAX: 0000000000000010 RBX: ffff888274051000 RCX: 0000000000000000
<4> [463.142057] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff888274051000
<4> [463.142058] RBP: ffff888238aa1018 R08: 0000000000000001 R09: 0000000000000001
<4> [463.142060] R10: ffffc90000593d90 R11: 00000000c79cdfd5 R12: ffff8882740510b0
<4> [463.142061] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
<4> [463.142062] FS:  0000000000000000(0000) GS:ffff888276c00000(0000) knlGS:0000000000000000
<4> [463.142064] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [463.142065] CR2: 000055706f347d80 CR3: 0000000005610003 CR4: 00000000003606f0
<4> [463.142066] Call Trace:
<4> [463.142073]  pci_enable_msi+0x11/0x20
<4> [463.142077]  azx_resume+0x1ab/0x200 [snd_hda_intel]
<4> [463.142080]  ? pci_pm_thaw+0x80/0x80
<4> [463.142084]  dpm_run_callback+0x64/0x280
<4> [463.142089]  device_resume+0xd4/0x1c0
<4> [463.142093]  ? dpm_watchdog_set+0x60/0

While this would appear to be a bug in snd-hda, it does appear
inconsequential, at least for gfx-ci.

Downgrade the warning to an info, like the other already-enabled error
for MSI-X.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8041
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1687
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423082753.3899018-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
We inadvertently create a dependency on mmap_sem with a whole chain.

This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:

<4> [604.892532] ======================================================
<4> [604.892534] WARNING: possible circular locking dependency detected
<4> [604.892536] 5.6.0-rc7-CI-Patchwork_17096+ intel#1 Tainted: G     U
<4> [604.892537] ------------------------------------------------------
<4> [604.892538] kms_frontbuffer/2595 is trying to acquire lock:
<4> [604.892540] ffffffff8264a558 (rcu_state.barrier_mutex){+.+.}, at: rcu_barrier+0x23/0x190
<4> [604.892547]
but task is already holding lock:
<4> [604.892547] ffff888484716050 (reservation_ww_class_mutex){+.+.}, at: i915_gem_object_pin_to_display_plane+0x89/0x270 [i915]
<4> [604.892592]
which lock already depends on the new lock.
<4> [604.892593]
the existing dependency chain (in reverse order) is:
<4> [604.892594]
-> intel#6 (reservation_ww_class_mutex){+.+.}:
<4> [604.892597]        __ww_mutex_lock.constprop.15+0xc3/0x1090
<4> [604.892598]        ww_mutex_lock+0x39/0x70
<4> [604.892600]        dma_resv_lockdep+0x10e/0x1f5
<4> [604.892602]        do_one_initcall+0x58/0x300
<4> [604.892604]        kernel_init_freeable+0x17b/0x1dc
<4> [604.892605]        kernel_init+0x5/0x100
<4> [604.892606]        ret_from_fork+0x24/0x50
<4> [604.892607]
-> intel#5 (reservation_ww_class_acquire){+.+.}:
<4> [604.892609]        dma_resv_lockdep+0xec/0x1f5
<4> [604.892610]        do_one_initcall+0x58/0x300
<4> [604.892610]        kernel_init_freeable+0x17b/0x1dc
<4> [604.892611]        kernel_init+0x5/0x100
<4> [604.892612]        ret_from_fork+0x24/0x50
<4> [604.892613]
-> intel#4 (&mm->mmap_sem#2){++++}:
<4> [604.892615]        __might_fault+0x63/0x90
<4> [604.892617]        _copy_to_user+0x1e/0x80
<4> [604.892619]        perf_read+0x200/0x2b0
<4> [604.892621]        vfs_read+0x96/0x160
<4> [604.892622]        ksys_read+0x9f/0xe0
<4> [604.892623]        do_syscall_64+0x4f/0x220
<4> [604.892624]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [604.892625]
-> intel#3 (&cpuctx_mutex){+.+.}:
<4> [604.892626]        __mutex_lock+0x9a/0x9c0
<4> [604.892627]        perf_event_init_cpu+0xa4/0x140
<4> [604.892629]        perf_event_init+0x19d/0x1cd
<4> [604.892630]        start_kernel+0x362/0x4e4
<4> [604.892631]        secondary_startup_64+0xa4/0xb0
<4> [604.892631]
-> intel#2 (pmus_lock){+.+.}:
<4> [604.892633]        __mutex_lock+0x9a/0x9c0
<4> [604.892633]        perf_event_init_cpu+0x6b/0x140
<4> [604.892635]        cpuhp_invoke_callback+0x9b/0x9d0
<4> [604.892636]        _cpu_up+0xa2/0x140
<4> [604.892637]        do_cpu_up+0x61/0xa0
<4> [604.892639]        smp_init+0x57/0x96
<4> [604.892639]        kernel_init_freeable+0x87/0x1dc
<4> [604.892640]        kernel_init+0x5/0x100
<4> [604.892642]        ret_from_fork+0x24/0x50
<4> [604.892642]
-> intel#1 (cpu_hotplug_lock.rw_sem){++++}:
<4> [604.892643]        cpus_read_lock+0x34/0xd0
<4> [604.892644]        rcu_barrier+0xaa/0x190
<4> [604.892645]        kernel_init+0x21/0x100
<4> [604.892647]        ret_from_fork+0x24/0x50
<4> [604.892647]
-> #0 (rcu_state.barrier_mutex){+.+.}:
<4> [604.892649]        __lock_acquire+0x1328/0x15d0
<4> [604.892650]        lock_acquire+0xa7/0x1c0
<4> [604.892651]        __mutex_lock+0x9a/0x9c0
<4> [604.892652]        rcu_barrier+0x23/0x190
<4> [604.892680]        i915_gem_object_unbind+0x29d/0x3f0 [i915]
<4> [604.892707]        i915_gem_object_pin_to_display_plane+0x141/0x270 [i915]
<4> [604.892737]        intel_pin_and_fence_fb_obj+0xec/0x1f0 [i915]
<4> [604.892767]        intel_plane_pin_fb+0x3f/0xd0 [i915]
<4> [604.892797]        intel_prepare_plane_fb+0x13b/0x5c0 [i915]
<4> [604.892798]        drm_atomic_helper_prepare_planes+0x85/0x110
<4> [604.892827]        intel_atomic_commit+0xda/0x390 [i915]
<4> [604.892828]        drm_atomic_helper_set_config+0x57/0xa0
<4> [604.892830]        drm_mode_setcrtc+0x1c4/0x720
<4> [604.892830]        drm_ioctl_kernel+0xb0/0xf0
<4> [604.892831]        drm_ioctl+0x2e1/0x390
<4> [604.892833]        ksys_ioctl+0x7b/0x90
<4> [604.892835]        __x64_sys_ioctl+0x11/0x20
<4> [604.892835]        do_syscall_64+0x4f/0x220
<4> [604.892836]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [604.892837]

Changes since v1:
- Use (*values)[n++] in perf_read_one().
Changes since v2:
- Centrally allocate values.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8042
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200502171413.9133-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8043
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Since Tigerlake seems to have inherited its cstates and other rapl power
caps from Icelake, assume it also follows Icelake for its rapl events.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8044
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Audio component in i915 is not hooked up yet causing long timeouts and
angry abortive CI.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8045
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This reverts commit ac9a5d5.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8048
Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
[ Lucas: iommu maintainers/developers were informed about the
  regression. A proper fix is required. For now, just reverting to see
  if CI recovers and then also proves this commit is indeed the culprit
  here, now that our other iommu-related commits were removed from
  topic/core-for-CI ]
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220913063918.422492-1-karolina.drobnik@intel.com
Manual revert of commit f598a49 ("iova: Add CPU hotplug handler to
flush rcaches").  It is trying to instantiate a cpuhp notifier from inside
a cpuhp callback.  That code replaced intel_iommu implementation of
flushing per-IOVA domain CPU rcaches which used a single instance of cpuhp
held for the module lifetime.

<4>[    6.928112] ======================================================
<4>[    6.928621] WARNING: possible circular locking dependency detected
<4>[    6.929225] 6.0.0-rc6-CI_DRM_12164-ga1f63e144e54+ intel#1 Not tainted
<4>[    6.929818] ------------------------------------------------------
<4>[    6.930415] cpuhp/0/15 is trying to acquire lock:
<4>[    6.931011] ffff888100e02a78 (&(&priv->bus_notifier)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x20/0x50
<4>[    6.931533]
                  but task is already holding lock:
<4>[    6.931534] ffffffff826490c0 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x48/0x1f0
<4>[    6.933069]
                  which lock already depends on the new lock.

<4>[    6.933070]
                  the existing dependency chain (in reverse order) is:
<4>[    6.933071]
                  -> intel#2 (cpuhp_state-up){+.+.}-{0:0}:
<4>[    6.933076]        lock_acquire+0xd3/0x310
<4>[    6.933079]        cpuhp_thread_fun+0xa6/0x1f0
<4>[    6.933082]        smpboot_thread_fn+0x1b5/0x260
<4>[    6.933084]        kthread+0xed/0x120
<4>[    6.933086]        ret_from_fork+0x1f/0x30
<4>[    6.933089]
                  -> intel#1 (cpu_hotplug_lock){++++}-{0:0}:
<4>[    6.933092]        lock_acquire+0xd3/0x310
<4>[    6.933094]        __cpuhp_state_add_instance+0x43/0x1c0
<4>[    6.933096]        iova_domain_init_rcaches+0x199/0x1c0
<4>[    6.933099]        iommu_setup_dma_ops+0x104/0x3d0
<4>[    6.933101]        iommu_probe_device+0xa4/0x180
<4>[    6.933103]        iommu_bus_notifier+0x2d/0x40
<4>[    6.933105]        notifier_call_chain+0x31/0x90
<4>[    6.933108]        blocking_notifier_call_chain+0x3a/0x50
<4>[    6.933110]        device_add+0x3c1/0x900
<4>[    6.933112]        pci_device_add+0x255/0x580
<4>[    6.933115]        pci_scan_single_device+0xa6/0xd0
<4>[    6.933117]        p2sb_bar+0x7f/0x220
<4>[    6.933120]        i801_add_tco_spt.isra.18+0x2b/0xca [i2c_i801]
<4>[    6.933124]        i801_add_tco+0xb1/0xfe [i2c_i801]
<4>[    6.933126]        i801_probe.cold.25+0xa9/0x3a7 [i2c_i801]
<4>[    6.933129]        pci_device_probe+0x95/0x110
<4>[    6.933132]        really_probe+0xd6/0x350
<4>[    6.933134]        __driver_probe_device+0x73/0x170
<4>[    6.933137]        driver_probe_device+0x1a/0x90
<4>[    6.933140]        __driver_attach+0xbc/0x190
<4>[    6.933141]        bus_for_each_dev+0x72/0xc0
<4>[    6.933143]        bus_add_driver+0x1bb/0x210
<4>[    6.933146]        driver_register+0x66/0xc0
<4>[    6.933147]        wmi_bmof_probe+0x3b/0xac [wmi_bmof]
<4>[    6.933150]        do_one_initcall+0x53/0x2f0
<4>[    6.933152]        do_init_module+0x45/0x1c0
<4>[    6.933154]        load_module+0x1cd5/0x1ec0
<4>[    6.933156]        __do_sys_finit_module+0xaf/0x120
<4>[    6.933158]        do_syscall_64+0x37/0x90
<4>[    6.933160]        entry_SYSCALL_64_after_hwframe+0x63/0xcd
<4>[    6.953757]
                  -> #0 (&(&priv->bus_notifier)->rwsem){++++}-{3:3}:
<4>[    6.953779]        validate_chain+0xb3f/0x2000
<4>[    6.953785]        __lock_acquire+0x5a4/0xb70
<4>[    6.953786]        lock_acquire+0xd3/0x310
<4>[    6.953787]        down_read+0x39/0x140
<4>[    6.953790]        blocking_notifier_call_chain+0x20/0x50
<4>[    6.953794]        device_add+0x3c1/0x900
<4>[    6.953797]        platform_device_add+0x108/0x240
<4>[    6.953799]        coretemp_cpu_online+0xe1/0x15e [coretemp]
<4>[    6.953805]        cpuhp_invoke_callback+0x181/0x8a0
<4>[    6.958244]        cpuhp_thread_fun+0x188/0x1f0
<4>[    6.958267]        smpboot_thread_fn+0x1b5/0x260
<4>[    6.958270]        kthread+0xed/0x120
<4>[    6.958272]        ret_from_fork+0x1f/0x30
<4>[    6.958274]
                  other info that might help us debug this:

<4>[    6.958275] Chain exists of:
                    &(&priv->bus_notifier)->rwsem --> cpu_hotplug_lock --> cpuhp_state-up

<4>[    6.961037]  Possible unsafe locking scenario:

<4>[    6.961038]        CPU0                    CPU1
<4>[    6.961038]        ----                    ----
<4>[    6.961039]   lock(cpuhp_state-up);
<4>[    6.961040]                                lock(cpu_hotplug_lock);
<4>[    6.961041]                                lock(cpuhp_state-up);
<4>[    6.961042]   lock(&(&priv->bus_notifier)->rwsem);
<4>[    6.961044]
                   *** DEADLOCK ***

<4>[    6.961044] 2 locks held by cpuhp/0/15:
<4>[    6.961046]  #0: ffffffff82648f10 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x48/0x1f0
<4>[    6.961053]  intel#1: ffffffff826490c0 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x48/0x1f0
<4>[    6.961058]
                  stack backtrace:
<4>[    6.961059] CPU: 0 PID: 15 Comm: cpuhp/0 Not tainted 6.0.0-rc6-CI_DRM_12164-ga1f63e144e54+ intel#1
<4>[    6.961062] Hardware name: Intel Corporation NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0047.2018.0718.1706 07/18/2018
<4>[    6.961063] Call Trace:
<4>[    6.961064]  <TASK>
<4>[    6.961065]  dump_stack_lvl+0x56/0x7f
<4>[    6.961069]  check_noncircular+0x132/0x150
<4>[    6.961078]  validate_chain+0xb3f/0x2000
<4>[    6.961083]  __lock_acquire+0x5a4/0xb70
<4>[    6.961087]  lock_acquire+0xd3/0x310
<4>[    6.961088]  ? blocking_notifier_call_chain+0x20/0x50
<4>[    6.961093]  down_read+0x39/0x140
<4>[    6.961097]  ? blocking_notifier_call_chain+0x20/0x50
<4>[    6.961099]  blocking_notifier_call_chain+0x20/0x50
<4>[    6.961102]  device_add+0x3c1/0x900
<4>[    6.961106]  ? dev_set_name+0x4e/0x70
<4>[    6.961109]  platform_device_add+0x108/0x240
<4>[    6.961112]  coretemp_cpu_online+0xe1/0x15e [coretemp]
<4>[    6.961117]  ? create_core_data+0x550/0x550 [coretemp]
<4>[    6.961120]  cpuhp_invoke_callback+0x181/0x8a0
<4>[    6.961124]  cpuhp_thread_fun+0x188/0x1f0
<4>[    6.961129]  ? smpboot_thread_fn+0x1e/0x260
<4>[    6.961131]  smpboot_thread_fn+0x1b5/0x260
<4>[    6.961134]  ? sort_range+0x20/0x20
<4>[    6.961135]  kthread+0xed/0x120
<4>[    6.961137]  ? kthread_complete_and_exit+0x20/0x20
<4>[    6.961139]  ret_from_fork+0x1f/0x30
<4>[    6.961145]  </TASK>

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8049
Closes: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928085826.243721-2-janusz.krzysztofik@linux.intel.com
…ion"

This reverts commit bc79ef6d5a22 ("Revert "iommu/dma: Fix race condition
during iova_domain initialization"") that reverted commit ac9a5d5
("iommu/dma: Fix race condition during iova_domain initialization").
That revert is no longer needed with "iommu: Remove iova cpu hotplugging
flushing" in place that breaks more instances of the same lockdep loop.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8050
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928085826.243721-3-janusz.krzysztofik@linux.intel.com
CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for
(at least modular) drm drivers. The debug prints can
be reinstated by manually frobbing /sys/module/drm/parameters/debug
after the fact, but at that point the damage is done
and all debugs from driver probe are lost. This makes
drivers totally undebuggable.

Mark the feature as broken and disable it by default.
Maybe someone can still salvage it later...

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8051
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
… held

We're hitting this WARN sporadically in intel gfx CI but
so far no idea who is the culprit. Dump more info.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8052
References: https://lore.kernel.org/all/Y1LVYaPCCP3BBS4g@intel.com/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
vsyrjala and others added 9 commits March 16, 2023 00:29
…drm-tip

# Conflicts:
#	drivers/gpu/drm/i915/gt/intel_workarounds.c
This patch uses the already existing IDR mechanism to simplify
and improve the dmabuf code.

Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
or 'idr_for_each_entry'.

Signed-off-by: Cai Huoqing <cai.huoqing@linux.dev>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20230303140718.25355-1-cai.huoqing@linux.dev
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.