Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 4月, 2009 2 次提交
    • R
      lguest: fix guest crash on non-linear addresses in gdt pvops · a489f0b5
      由 Rusty Russell 提交于 
      Fixes guest crash 'lguest: bad read address 0x4800000 len 256'

The new per-cpu allocator ends up handing a non-linear address to
write_gdt_entry.  We do __pa() on it, and hand it to the host, which
kills us.

I've long wanted to make the hypercall "LOAD_GDT_ENTRY" to match the IDT
code, but had no pressing reason until now.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: lguest@ozlabs.org
      a489f0b5
    • M
      lguest: fix crash on vmlinux images · 88df781a
      由 Matias Zabaljauregui 提交于 
      Typical message: 'lguest: unhandled trap 6 at 0x418726 (0x0)'

vmlinux guests were broken by 4cd8b5e2
'lguest: use KVM hypercalls', which rewrites guest text from kvm hypercalls
to trap 31.

The Launcher mmaps the kernel image.  The Guest executes and
immediately faults in the first text page (read-only).  Then it hits a
hypercall, and we rewrite that hypercall, causing a copy-on-write.
But the Guest pagetables still refer to the old page: we fault again,
but as Host we see the hypercall already rewritten, and pass the fault
back to the Guest.  The Guest hasn't set up an IDT yet, so we kill it.

This doesn't happen with bzImages: they unpack themselves and so the
text pages are already read-write.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Tested-by: NPatrick McHardy <kaber@trash.net>
      88df781a
  3. 30 3月, 2009 1 次提交
  5. 29 7月, 2008 1 次提交
  7. 26 6月, 2008 1 次提交
  9. 20 6月, 2008 1 次提交
    • S
      x86: fix NULL pointer deref in __switch_to · 54481cf8
      由 Suresh Siddha 提交于 
      I am able to reproduce the oops reported by Simon in __switch_to() with
lguest.

My debug showed that there is at least one lguest specific
issue (which should be present in 2.6.25 and before aswell) and it got
exposed with a kernel oops with the recent fpu dynamic allocation patches.

In addition to the previous possible scenario (with fpu_counter), in the
presence of lguest, it is possible that the cpu's TS bit it still set and the
lguest launcher task's thread_info has TS_USEDFPU still set.

This is because of the way the lguest launcher handling the guest's TS bit.
(look at lguest_set_ts() in lguest_arch_run_guest()). This can result
in a DNA fault while doing unlazy_fpu() in __switch_to(). This will
end up causing a DNA fault in the context of new process thats
getting context switched in (as opossed to handling DNA fault in the context
of lguest launcher/helper process).

This is wrong in both pre and post 2.6.25 kernels. In the recent
2.6.26-rc series, this is showing up as NULL pointer dereferences or
sleeping function called from atomic context(__switch_to()), as
we free and dynamically allocate the FPU context for the newly
created threads. Older kernels might show some FPU corruption for processes
running inside of lguest.

With the appended patch, my test system is running for more than 50 mins
now. So atleast some of your oops (hopefully all!) should get fixed.
Please give it a try. I will spend more time with this fix tomorrow.
Reported-by: NSimon Holm Thøgersen <odie@cs.aau.dk>
Reported-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      54481cf8
  11. 28 3月, 2008 1 次提交
  13. 31 1月, 2008 1 次提交
  15. 30 1月, 2008 14 次提交
  17. 26 1月, 2008 1 次提交
    • G
      cpu-hotplug: replace lock_cpu_hotplug() with get_online_cpus() · 86ef5c9a
      由 Gautham R Shenoy 提交于 
      Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead as it highlights the
refcount semantics in these operations.

The new API guarantees protection against the cpu-hotplug operation, but
it doesn't guarantee serialized access to any of the local data
structures. Hence the changes needs to be reviewed.

In case of pseries_add_processor/pseries_remove_processor, use
cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
cpu_present_map there.
Signed-off-by: NGautham R Shenoy <ego@in.ibm.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      86ef5c9a
  19. 25 10月, 2007 2 次提交
  21. 23 10月, 2007 8 次提交