lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <556F2EFE.9030805@intel.com>
Date:	Wed, 03 Jun 2015 17:44:46 +0100
From:	Dave Gordon <david.s.gordon@...el.com>
To:	Jani Nikula <jani.nikula@...ux.intel.com>,
	Shuah Khan <shuahkh@....samsung.com>, daniel.vetter@...el.com
CC:	intel-gfx@...ts.freedesktop.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] intel_check_page_flip() - WARN_ON(!in_interrupt())

On 29/05/15 07:26, Jani Nikula wrote:
> On Fri, 29 May 2015, Shuah Khan <shuahkh@....samsung.com> wrote:
>> I am seeing the following in the dmesg on 4.0.4 with rt patch
>>
>> [    5.720319] ------------[ cut here ]------------
>> [    5.720347] WARNING: CPU: 6 PID: 466 at
>> drivers/gpu/drm/i915/intel_display.c:9748
>> intel_check_page_flip+0xaa/0xf0 [i915]()
>> [    5.720349] WARN_ON(!in_interrupt())
>> [    5.720350] Modules linked in:
>> [    5.720376]  binfmt_misc rfcomm bnep arc4 eeepc_wmi hid_generic
>> asus_wmi sparse_keymap iwlmvm intel_powerclamp coretemp kvm_intel kvm
>> mac80211 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel
>> aes_x86_64 lrw gf128mul dm_multipath glue_helper snd_hda_codec_hdmi
>> scsi_dh ablk_helper cryptd microcode btusb iwlwifi bluetooth serio_raw
>> cfg80211 i915 snd_hda_codec_realtek snd_hda_codec_generic lpc_ich
>> snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm
>> snd_seq_midi snd_seq_midi_event snd_rawmidi drm_kms_helper snd_seq drm
>> video snd_seq_device mac_hid snd_timer snd mei_me wmi mei shpchp
>> soundcore i2c_algo_bit usbhid hid parport_pc ppdev lp parport autofs4
>> btrfs xor raid6_pq psmouse dm_mirror r8169 ahci dm_region_hash libahci
>> mii dm_log
>> [    5.720379] CPU: 6 PID: 466 Comm: irq/32-i915 Not tainted 4.0.4-rt1+ #8
>> [    5.720380] Hardware name: System76, Inc. Wild Dog
>> Performance/H87-PLUS, BIOS 0705 12/05/2013
>> [    5.720382]  0000000000000009 ffff8803ea39bc98 ffffffff817c0694
>> 0000000000000002
>> [    5.720383]  ffff8803ea39bce8 ffff8803ea39bcd8 ffffffff81073d8a
>> 0000000000000001
>> [    5.720384]  ffff8803eb184000 ffff8800d7804800 0000000000000000
>> 0000000000000000
>> [    5.720385] Call Trace:
>> [    5.720390]  [<ffffffff817c0694>] dump_stack+0x4f/0x90
>> [    5.720393]  [<ffffffff81073d8a>] warn_slowpath_common+0x8a/0xe0
>> [    5.720395]  [<ffffffff81073e26>] warn_slowpath_fmt+0x46/0x50
>> [    5.720410]  [<ffffffffa040bdba>] intel_check_page_flip+0xaa/0xf0 [i915]
>> [    5.720420]  [<ffffffffa03d7888>] ironlake_irq_handler+0x2e8/0x1000
>> [i915]
>> [    5.720423]  [<ffffffff813e7787>] ? debug_smp_processor_id+0x17/0x20
>> [    5.720424]  [<ffffffff81074512>] ? pin_current_cpu+0x92/0x1d0
>> [    5.720426]  [<ffffffff810d0690>] ? irq_thread_fn+0x50/0x50
>> [    5.720428]  [<ffffffff810d06b7>] irq_forced_thread_fn+0x27/0x80
>> [    5.720429]  [<ffffffff810d0c4f>] irq_thread+0x10f/0x160
>> [    5.720430]  [<ffffffff810d0740>] ? wake_threads_waitq+0x30/0x30
>> [    5.720432]  [<ffffffff810d0b40>] ? irq_thread_check_affinity+0x90/0x90
>> [    5.720433]  [<ffffffff81093d7b>] kthread+0xbb/0xe0
>> [    5.720434]  [<ffffffff81093cc0>] ? kthread_worker_fn+0x1a0/0x1a0
>> [    5.720436]  [<ffffffff817c6bd8>] ret_from_fork+0x58/0x90
>> [    5.720437]  [<ffffffff81093cc0>] ? kthread_worker_fn+0x1a0/0x1a0
>> [    5.720437] ---[ end trace 0000000000000002 ]---
>>
>> There seem to be few past bug reports on this issue. Has this been
>> fixed? Should I be concerned about this?
> 
> One of the old bugs [1] was about using in_irq() which didn't work for
> threaded irqs, hence the switch to in_interrupt(). The backtrace seems
> to indicate intel_check_page_flip() is being called from irq context; I
> do not know if the rt patchset has an impact on this.
> 
> BR,
> Jani.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=89321
> 
>> thanks,
>> -- Shuah
>> Shuah Khan
>> Sr. Linux Kernel Developer
>> Open Source Innovation Group
>> Samsung Research America (Silicon Valley)
>> shuahkh@....samsung.com | (970) 217-8978

This is what the RT project page says:

The RT-Preempt patch converts Linux into a fully preemptible kernel. The
magic is done with:
1. Making in-kernel locking-primitives (using spinlocks) preemptible
   though reimplementation with rtmutexes:
2. Critical sections protected by i.e. spinlock_t and rwlock_t are now
   preemptible. The creation of non-preemptible sections (in kernel) is
   still possible with raw_spinlock_t (same APIs like spinlock_t)
3. Implementing priority inheritance for in-kernel mutexes, spinlocks
   and rw_semaphores. For more information on priority inversion and
   priority inheritance please consult "Introduction to Priority
   Inversion"
4. Converting interrupt handlers into preemptible kernel threads: The
   RT-Preempt patch treats soft interrupt handlers in kernel thread
   context, which is represented by a task_struct like a common
   userspace process. However it is also possible to register an IRQ in
   kernel context.
5. Converting the old Linux timer API into separate infrastructures for
   high resolution kernel timers plus one for timeouts, leading to
   userspace POSIX timers with high resolution.

So my guess is that item (4) made the in_interrupt() and/or in_irq()
macros unreliable; with interrupts handled as threads, there isn't
really any notion of "being in interrupt context".

.Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ