linux-kernel - Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm

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] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d7e9970901291706t17fc3d9aq753f90db75396639@mail.gmail.com>
Date:	Fri, 30 Jan 2009 11:06:47 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	kerolasa@...il.com, kerolasa@....fi, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sourceforge.net, Dave Airlie <airlied@...ux.ie>,
	Laurent Pinchart <laurent.pinchart@...net.be>
Subject: Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146!

On Fri, Jan 30, 2009 at 10:30 AM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> (cc's added)
>
> On Wed, 21 Jan 2009 13:27:48 +0100
> Sami Kerola <kerolasa@....fi> wrote:
>
>> I compiled the Torvalds git kernel 2.6.29-rc2-00013 and I got an oops.
>> The oops happens when ever X starts. Initially I was booting with run
>> level 5 and it hung. I tried to use run level to 3 and an operating
>> system started just fine. When I type startx the hung happen again.
>> Please let me know if you need some more information besides oops from
>> messages file and lspci output.
>>
>>
>> Jan 21 08:53:58 lelux kernel: ------------[ cut here ]------------
>> Jan 21 08:53:58 lelux kernel: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
>
> I assume that 2.6.28 didn't do this?

This is a userspace race between udev and libdrm, I'm not sure we can do
anything in the kernel other than BUG, maybe we should just WARN instead.

Basically, libdrm creates devices nodes, the initial drm opening gets that, udev
comes along when the module is loaded and re-creates the device node,
when AIGLX opens the device
it can't figure out wtf just happened, as the inode->i_mapping we use
to store the GEM device mmap ranges is different.

I think building libdrm with --enable-udev is the correct answer, and
maybe switching this to a WARN so it doesn't blow up.

maybe we shouldn't be storing the inode mapping like this? anyone any
better idea?

Dave.
>
> Seems odd - nothing much has changed around there lately.
>
>> Jan 21 08:53:58 lelux kernel: invalid opcode: 0000 [#1] SMP
>> Jan 21 08:53:58 lelux kernel: last sysfs file:
>> /sys/devices/pci0000:00/0000:00:02.0/drm/card0/dri_library_name
>> Jan 21 08:53:58 lelux kernel: CPU 0
>> Jan 21 08:53:58 lelux kernel: Modules linked in: i915 drm i2c_algo_bit
>> ipv6 fuse acpi_cpufreq dm_multipath snd_hda_codec_idt arc4 ecb
>> snd_hda_intel snd_hda_codec iwlag
>> n snd_hwdep snd_seq_dummy snd_seq_oss iwlcore snd_seq_midi_event
>> snd_seq rfkill snd_seq_device lib80211 snd_pcm_oss mac80211
>> snd_mixer_oss snd_pcm firewire_ohci i2c_i8
>> 01 snd_timer firewire_core ppdev snd sr_mod pcspkr joydev yenta_socket
>> i2c_core video sg iTCO_wdt tg3 rsrc_nonstatic cdrom crc_itu_t
>> iTCO_vendor_support parport_pc out
>> put parport libphy soundcore cfg80211 wmi battery snd_page_alloc ac
>> pata_acpi ata_generic ata_piix libata sd_mod scsi_mod sha256_generic
>> cbc aes_x86_64 aes_generic dm_
>> crypt dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod ext3
>> jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
>> Jan 21 08:53:58 lelux kernel: Pid: 2902, comm: X Not tainted
>> 2.6.29-rc2-00013-gf3b8436-dirty #1
>> Jan 21 08:53:58 lelux kernel: RIP: 0010:[<ffffffffa0486f7b>]
>> [<ffffffffa0486f7b>] drm_open+0x4b7/0x4f0 [drm]
>> Jan 21 08:53:58 lelux kernel: RSP: 0018:ffff88006ec01cd8  EFLAGS: 00010293
>> Jan 21 08:53:58 lelux kernel: RAX: ffff88006f8e2100 RBX:
>> ffff88006f47d060 RCX: 0000000000000000
>> Jan 21 08:53:58 lelux kernel: RDX: ffff88007a016b90 RSI:
>> ffff88006ec40000 RDI: ffff88006ec01c28
>> Jan 21 08:53:58 lelux kernel: RBP: ffff88006ec01d18 R08:
>> ffff88006ec40760 R09: 00000000000002e7
>> Jan 21 08:53:58 lelux kernel: R10: ffff88006ec40000 R11:
>> 0000000000000006 R12: 0000000000000000
>> Jan 21 08:53:58 lelux kernel: R13: ffff88006f47d000 R14:
>> ffff88006f47d060 R15: ffff88006ec33918
>> Jan 21 08:53:58 lelux kernel: FS:  00007f4495429780(0000)
>> GS:ffffffff8192e000(0000) knlGS:0000000000000000
>> Jan 21 08:53:58 lelux kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> Jan 21 08:53:58 lelux kernel: CR2: 00007f4494de01a0 CR3:
>> 0000000070460000 CR4: 00000000000006e0
>> Jan 21 08:53:58 lelux kernel: DR0: 0000000000000000 DR1:
>> 0000000000000000 DR2: 0000000000000000
>> Jan 21 08:53:58 lelux kernel: DR3: 0000000000000000 DR6:
>> 00000000ffff0ff0 DR7: 0000000000000400
>> Jan 21 08:53:58 lelux kernel: Process X (pid: 2902, threadinfo
>> ffff88006ec00000, task ffff88006ec40000)
>> Jan 21 08:53:58 lelux kernel: Stack:
>> Jan 21 08:53:58 lelux kernel: ffff88006d071000 ffff88007a016b90
>> ffff88006d044000 00000000ffffffed
>> Jan 21 08:53:58 lelux kernel: ffffffffa04959d0 ffff88006d071000
>> ffff88007a016b90 ffff88007a016b90
>> Jan 21 08:53:58 lelux kernel: ffff88006ec01d48 ffffffffa0486a53
>> 0000000000000000 ffff88007c9adc00
>> Jan 21 08:53:58 lelux kernel: Call Trace:
>> Jan 21 08:53:58 lelux kernel: [<ffffffffa0486a53>]
>> drm_stub_open+0xd2/0x143 [drm]
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810df703>] chrdev_open+0x149/0x168
>> Jan 21 08:53:58 lelux kernel: [<ffffffff8114e8b9>] ?
>> selinux_dentry_open+0xeb/0xf4
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810df5ba>] ? chrdev_open+0x0/0x168
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810db03f>] __dentry_open+0x151/0x270
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810db235>] nameidata_to_filp+0x46/0x57
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810e84fb>] do_filp_open+0x44f/0x8a7
>> Jan 21 08:53:58 lelux kernel: [<ffffffff81065661>] ?
>> lock_release_holdtime+0x1c/0x173
>> Jan 21 08:53:58 lelux kernel: [<ffffffff8118a136>] ? _raw_spin_unlock+0x8e/0x94
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810f14c5>] ? alloc_fd+0x122/0x133
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810dae22>] do_sys_open+0x58/0xd8
>> Jan 21 08:53:58 lelux kernel: [<ffffffff810daed5>] sys_open+0x20/0x22
>> Jan 21 08:53:58 lelux kernel: [<ffffffff8100c42a>]
>> system_call_fastpath+0x16/0x1b
>> Jan 21 08:53:58 lelux kernel: Code: 48 89 df e8 55 e4 ea e0 48 8b 45
>> d0 83 78 04 01 75 2f 49 8b 85 00 06 00 00 48 85 c0 74 11 48 8b 55 c8
>> 48 3b 82 30 02 00 00 74 16 <0f> 0b eb fe 48 8b 55 c8 48 8b 82 30 02 00
>> 00 49 89 85 00 06 00
> --
> 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/
>
--
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/