53f1b1433da7eac2607a4a0898a221a4485fd732 is first bad commit
commit 53f1b1433da7eac2607a4a0898a221a4485fd732
Author: Alan Cox <[email protected]>
Date: Wed Jul 23 21:30:32 2008 -0700
rtc: push the BKL down into the driver ioctl method
This commit is breaking vmware-6.0.4. Upon booting linux (guest) on
vmware, the whole vmware environment crashed.
Reverting this commit make vmware runs again.
Thanks,
Jeff.
Here's the oops.
BUG: unable to handle kernel NULL pointer dereference at 00000000
IP: [<00000000>]
*pdpt = 000000003209b001 *pde = 0000000000000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: sg 8250 serial_core sr_mod cdrom vmnet vmmon iwl3945 mac80211
cfg80211 dummy [last unloaded: bluetooth]
Pid: 4052, comm: vmware-vmx Not tainted (2.6.26 #29)
EIP: 0060:[<00000000>] EFLAGS: 00213286 CPU: 1
EIP is at 0x0
EAX: f7483468 EBX: c03b0f04 ECX: 00007005 EDX: f2c1d880
ESI: f2c1d880 EDI: f20b4000 EBP: 000001a4 ESP: f2c99df8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process vmware-vmx (pid: 4052, ti=f2c99000 task=f2ce46c0 task.ti=f2c99000)
Stack: f99e76a1 00000000 000001a4 00000000 f99efd65 f99f3f20 000000fa 000001a4
f2c6ec00 f2cbc380 000007e6 000007e6 f99e5a87 b2d69163 00000000 f202f108
f2540820 000000a0 c0118694 00000000 00000000 f2de8a04 00000001 00203282
Call Trace:
[<f99e76a1>] HostIF_SetFastClockRate+0x8d/0x148 [vmmon]
[<f99efd65>] Vmx86_SetHostClockRate+0xad/0xd5 [vmmon]
[<f99e5a87>] LinuxDriver_Ioctl+0x4c6/0xdcd [vmmon]
[<c0118694>] kmap_atomic_prot+0x102/0x137
[<c0395846>] _spin_unlock+0x5/0x1c
[<c017bd62>] mnt_drop_write+0x64/0xdd
[<c01f0680>] rb_insert_color+0x4c/0xad
[<c013260a>] enqueue_hrtimer+0xc9/0xd4
[<c0132ba5>] hrtimer_start+0xf9/0x129
[<c011a13c>] hrtick_start_fair+0xf7/0x123
[<c0129e78>] group_send_sig_info+0x12/0x56
[<c0129eed>] kill_pid_info+0x31/0x54
[<c012a44e>] sys_kill+0x73/0x13e
[<c0172b53>] vfs_ioctl+0x47/0x5d
[<c0172db1>] do_vfs_ioctl+0x248/0x258
[<c0134a11>] do_gettimeofday+0xd/0x27
[<c0172ded>] sys_ioctl+0x2c/0x43
[<c0102cd3>] sysenter_do_call+0x12/0x33
=======================
Code: Bad EIP value.
EIP: [<00000000>] 0x0 SS:ESP 0068:f2c99df8
---[ end trace 82b56b8602667b97 ]---
On Fri, 25 Jul 2008 22:26:38 +0800
"Jeff Chua" <[email protected]> wrote:
> 53f1b1433da7eac2607a4a0898a221a4485fd732 is first bad commit
> commit 53f1b1433da7eac2607a4a0898a221a4485fd732
> Author: Alan Cox <[email protected]>
> Date: Wed Jul 23 21:30:32 2008 -0700
>
> rtc: push the BKL down into the driver ioctl method
>
>
> This commit is breaking vmware-6.0.4. Upon booting linux (guest) on
> vmware, the whole vmware environment crashed
Having reviewed the patch and the trace I believe you need to take this
up with vmware. All the patch does is slightly alter where the locking is
done. I suspect vmware are blindly calling into the rtc_fops ioctl method
directly in which case they just got burned.
One way to check this would be to add a .ioctl method back which was
simply
rtc_test_ioctl(...)
{
printk("VMWare caught with pants down\n");
}
if it prints that instead of or while crashing you know who is guilty.
Alan
Jeff Chua wrote:
> This commit is breaking vmware-6.0.4. Upon booting linux (guest) on
> vmware, the whole vmware environment crashed.
Quality hypervisor we have there...
-hpa
On Fri, Jul 25, 2008 at 11:55 PM, H. Peter Anvin <[email protected]> wrote:
> Jeff Chua wrote:
>>
>> This commit is breaking vmware-6.0.4. Upon booting linux (guest) on
>> vmware, the whole vmware environment crashed.
>
> Quality hypervisor we have there...
>
> -hpa
>
Well then, lets hope Vmware will do something to fix this and remove
the init_mm stuff.
Thanks,
Jeff.
Jeff Chua wrote:
> On Fri, Jul 25, 2008 at 11:55 PM, H. Peter Anvin <[email protected]> wrote:
>> Jeff Chua wrote:
>>> This commit is breaking vmware-6.0.4. Upon booting linux (guest) on
>>> vmware, the whole vmware environment crashed.
>> Quality hypervisor we have there...
>
> Well then, lets hope Vmware will do something to fix this and remove
> the init_mm stuff.
Well, let me clarify:
- if userspace crashes the kernel, it is a kernel problem (except for
abuse of certain specific privileged interfaces, like /dev/mem.)
- if a kernel crashes the hypervisor, it is likewise a hypervisor
problem, even if it was triggered by a bug in the kernel.
The hypervisor, after all, is supposed to provide isolation.
As far as the kernel is concerned, the hypervisor is hardware. Now, we
work around bugs in broken hardware all the time, and *if it is sane*,
we should do so here too. However, it is *still* a hypervisor problem,
and Vmware needs to fix it.
-hpa
On Fri, 25 Jul 2008, Jeff Chua wrote:
> On Fri, Jul 25, 2008 at 11:55 PM, H. Peter Anvin <[email protected]> wrote:
> > Jeff Chua wrote:
> >>
> >> This commit is breaking vmware-6.0.4. Upon booting linux (guest) on
> >> vmware, the whole vmware environment crashed.
> >
> > Quality hypervisor we have there...
> >
> > -hpa
> >
>
> Well then, lets hope Vmware will do something to fix this and remove
> the init_mm stuff.
The module fixes for 2.6.26+ kernels are in upcoming releases and should
get backported to older ones.
Thanks,
Eli
On Wed, Jul 30, 2008 at 7:21 AM, Eli Collins <[email protected]> wrote:
> The module fixes for 2.6.26+ kernels are in upcoming releases and should
> get backported to older ones.
Thanks, just let me know when it'll be available and I'll be more than
happy to test it out for you.
At the mean time, I've worked around the problem by adding back .ioctl
that vmware is can work in 2.6.27-rc1.
Thanks,
Jeff.
On Wed, 30 Jul 2008 09:19:55 +0800
"Jeff Chua" <[email protected]> wrote:
> On Wed, Jul 30, 2008 at 7:21 AM, Eli Collins <[email protected]> wrote:
>
> > The module fixes for 2.6.26+ kernels are in upcoming releases and should
> > get backported to older ones.
>
> Thanks, just let me know when it'll be available and I'll be more than
> happy to test it out for you.
>
> At the mean time, I've worked around the problem by adding back .ioctl
> that vmware is can work in 2.6.27-rc1.
Thanks for confirming this is the case. I'm intrigued to think that
vmware considers itself somehow an independant work when it goes poking
around the innards of private kernel structures in this way. I think this
breakage speaks volumes
Alan