Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752584AbZDMU7Z (ORCPT ); Mon, 13 Apr 2009 16:59:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751731AbZDMU7L (ORCPT ); Mon, 13 Apr 2009 16:59:11 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:44420 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751626AbZDMU7J (ORCPT ); Mon, 13 Apr 2009 16:59:09 -0400 Date: Mon, 13 Apr 2009 13:59:08 -0700 From: "Paul E. McKenney" To: Luis Henriques Cc: Dave Jones , Ingo Molnar , mark.langsdorf@amd.com, linux-kernel@vger.kernel.org Subject: Re: [BUG -tip] unable to handle kernel paging request Message-ID: <20090413205908.GA15435@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20090413165913.GA4798@hades.domain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090413165913.GA4798@hades.domain.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5719 Lines: 102 On Mon, Apr 13, 2009 at 05:59:13PM +0100, Luis Henriques wrote: > Hi, > > (not sure if I'm CC'ing all the relevant persons...) > > I am hitting this bug, which occurs mainly when I am shutting down my laptop. I > took a look at the cpufreq code and found out something which I am not sure if it > is related with this bug (or even if it is an issue at all): > > void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state) > { > struct cpufreq_policy *policy; > > BUG_ON(irqs_disabled()); > > freqs->flags = cpufreq_driver->flags; > > ... > > This code accesses cpufreq_driver without using the cpufreq_driver_lock. I > believe this is the only place in the code where this lock is not obtaining > before accessing the global cpufreq_driver. > > Any ideas? Well, one thought would be that SRCU is protecting it, but when I look at the code, SRCU is instead only protecting the notifier chain itself. So SRCU is -not- a substitute for cpufreq_driver_lock in this case. But the "freqs" argument looks to be a parameter block private to the caller, so the modification of freqs->old is safe. Ditto for adjust_jiffies(). This does use per-CPU data, but it is not clear to me how preemption is disabled -- or that it is always operating on the current CPU, for that matter. And the few notifier callbacks I looked at did not have any locking either. So is the cpufreq_driver_lock acquired at a higher level, for example, by the guy who calls through the cpufreq_driver control blocks? Thanx, Paul > -- > Luis Henriques > > [ 2015.908598] BUG: unable to handle kernel paging request at 0000737463656a6f > [ 2015.908606] IP: [<0000737463656a6f>] 0x737463656a6f > [ 2015.908616] PGD 0 > [ 2015.908620] Oops: 0010 [#1] PREEMPT SMP > [ 2015.908627] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed > [ 2015.908631] CPU 0 > [ 2015.908635] Modules linked in: ipv6 powernow_k8 cpufreq_stats af_packet cpufreq_conservative cpufreq_ondemand freq_table cpufreq_powersave cpufreq_userspace sbp2 loop snd_hda_codec_atihdmi snd_hda_codec_realtek rfkill snd_hda_intel ath5k backlight snd_hda_codec evdev i2c_piix4 psmouse k8temp snd_hwdep snd_pcm snd_timer led_class snd_page_alloc input_polldev battery processor ac button sg sr_mod cdrom ata_generic pata_acpi sd_mod ohci_hcd ohci1394 ieee1394 pata_atiixp ahci libata ide_pci_generic ehci_hcd r8169 mii scsi_mod usbcore ide_core thermal fan [last unloaded: kvm] > [ 2015.908723] Pid: 3117, comm: powernowd Tainted: G M 2.6.30-rc1-tip-01567-gacf5b32 #19 Satellite A210 > [ 2015.908727] RIP: 0010:[<0000737463656a6f>] [<0000737463656a6f>] 0x737463656a6f > [ 2015.908734] RSP: 0018:ffff88007b4ffcd0 EFLAGS: 00010282 > [ 2015.908737] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffa03957b0 > [ 2015.908740] RDX: ffff88007b4ffdb8 RSI: 0000000000000000 RDI: ffffffffa03957b0 > [ 2015.908744] RBP: ffff88007b4ffd08 R08: 0000000000000000 R09: 0000000000000000 > [ 2015.908747] R10: ffffffff80274269 R11: 0000000000000000 R12: 00000000fffffffd > [ 2015.908750] R13: 0000000000000000 R14: ffff88007b4ffdb8 R15: 0000000000000000 > [ 2015.908755] FS: 00007f327af266f0(0000) GS:ffff880001042000(0000) knlGS:00000000f6b24720 > [ 2015.908758] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 2015.908762] CR2: 0000737463656a6f CR3: 000000007a4ca000 CR4: 00000000000006e0 > [ 2015.908765] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 2015.908769] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 2015.908772] Process powernowd (pid: 3117, threadinfo ffff88007b4fe000, task ffff88007d864020) > [ 2015.908776] Stack: > [ 2015.908778] ffffffff8027465f ffff88007b4ffcf8 ffffffff810113a0 0000000000000000 > [ 2015.908786] 00000000ffffffff ffffffff81011318 0000000000000000 ffff88007b4ffd58 > [ 2015.908795] ffffffff8027480e 0000000000000000 ffff88007b4ffdb8 0000000000000000 > [ 2015.908805] Call Trace: > [ 2015.908808] [] ? notifier_call_chain+0x3f/0x80 > [ 2015.908817] [] __srcu_notifier_call_chain+0x5e/0x90 > [ 2015.908824] [] srcu_notifier_call_chain+0x16/0x20 > [ 2015.908830] [] cpufreq_notify_transition+0x89/0xd0 > [ 2015.908837] [] powernowk8_target+0x285/0x7c0 [powernow_k8] > [ 2015.908845] [] ? cpufreq_set+0x32/0xc0 [cpufreq_userspace] > [ 2015.908852] [] __cpufreq_driver_target+0x3c/0x40 > [ 2015.908858] [] cpufreq_set+0x8e/0xc0 [cpufreq_userspace] > [ 2015.908865] [] store_scaling_setspeed+0x6d/0x80 > [ 2015.908871] [] store+0x6f/0xa0 > [ 2015.908876] [] sysfs_write_file+0xcf/0x140 > [ 2015.908883] [] vfs_write+0xcb/0x170 > [ 2015.908889] [] sys_write+0x55/0x90 > [ 2015.908895] [] system_call_fastpath+0x16/0x1b > [ 2015.908902] Code: Bad RIP value. > [ 2015.908907] RIP [<0000737463656a6f>] 0x737463656a6f > [ 2015.908913] RSP > [ 2015.908915] CR2: 0000737463656a6f > [ 2015.909459] ---[ end trace cefb79d041e94864 ]--- > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/