- 13 6月, 2008 12 次提交
-
-
由 Kyle McMartin 提交于
Needed by fuse (via copy_highpage). Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
由 Kyle McMartin 提交于
And explicitly list it in vmlinux.lds... Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
由 Kyle McMartin 提交于
This reverts commit bd3bb8c1. Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
由 Kevin Winchester 提交于
Changed the call to find_e820_area_size to pass u64 instead of unsigned long. Signed-off-by: NKevin Winchester <kjwinchester@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Vegard Nossum 提交于
Alessandro Suardi reported: > Recently upgraded my FC6 desktop to Fedora 9; with the > latest nautilus RPM updates my VNC session went nuts > with nautilus pegging the CPU for everything that breathed. > > I now reverted to an earlier nautilus package, but during > the peak CPU period my kernel spat this: > > [314185.623294] ------------[ cut here ]------------ > [314185.623414] WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128() > [314185.623514] Modules linked in: iptable_filter ip_tables x_tables > sunrpc ipv6 fuse snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart > snd_rawmidi via686a hwmon parport_pc sg parport uhci_hcd ehci_hcd > [314185.623924] Pid: 12314, comm: nautilus Not tainted 2.6.26-rc5-git2 #4 > [314185.624021] [<c0115b95>] warn_on_slowpath+0x41/0x7b > [314185.624021] [<c010de70>] ? do_page_fault+0x2c1/0x5fd > [314185.624021] [<c0128396>] ? up_read+0x16/0x28 > [314185.624021] [<c010de70>] ? do_page_fault+0x2c1/0x5fd > [314185.624021] [<c012fa33>] ? __lock_acquire+0xbb4/0xbc3 > [314185.624021] [<c012d0a0>] check_flags+0x4c/0x128 > [314185.624021] [<c012fa73>] lock_acquire+0x31/0x7d > [314185.624021] [<c0128cf6>] __atomic_notifier_call_chain+0x30/0x80 > [314185.624021] [<c0128cc6>] ? __atomic_notifier_call_chain+0x0/0x80 > [314185.624021] [<c0128d52>] atomic_notifier_call_chain+0xc/0xe > [314185.624021] [<c0128d81>] notify_die+0x2d/0x2f > [314185.624021] [<c01043b0>] do_int3+0x1f/0x4d > [314185.624021] [<c02f2d3b>] int3+0x27/0x2c > [314185.624021] ======================= > [314185.624021] ---[ end trace 1923f65a2d7bb246 ]--- > [314185.624021] possible reason: unannotated irqs-off. > [314185.624021] irq event stamp: 488879 > [314185.624021] hardirqs last enabled at (488879): [<c0102d67>] > restore_nocheck+0x12/0x15 > [314185.624021] hardirqs last disabled at (488878): [<c0102dca>] > work_resched+0x19/0x30 > [314185.624021] softirqs last enabled at (488876): [<c011a1ba>] > __do_softirq+0xa6/0xac > [314185.624021] softirqs last disabled at (488865): [<c010476e>] > do_softirq+0x57/0xa6 > > I didn't seem to find it with some googling, so here it is. > > I was incidentally ltracing that process to try and find out > what was gulping down that much CPU (sorry, no idea > whether ltrace and the WARNING happened at the same > time or which came first) and: Yeah, this is extremely likely to be the source of the warning. The warning should be harmless, however. > Box is my trusty noname K7-800, 512MB RAM; if there's > anything else useful I might be able to provide, just ask. It would be interesting to see where the int3 comes from. Too bad, lockdep doesn't provide the register dump. The stacktrace also doesn't go further than the int3(), I wonder if this int3 came from userspace? The ltrace readme says "software breakpoints, like gdb", so I guess this is the case. Yep, seems like it. This looks relevant: | commit fb1dac90 | Author: Peter Zijlstra <a.p.zijlstra@chello.nl> | Date: Wed Jan 16 09:51:59 2008 +0100 | | lockdep: more hardirq annotations for notify_die() I'm attaching a similarly-looking patch for this case (DO_VM86_ERROR), though I suspect it might be missing for the other cases (DO_ERROR/DO_ERROR_INFO) as well. Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com> Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com> Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 David Howells 提交于
Fix an incompatible pointer type warning on x86_64 compilations. early_memtest() is passing a u64* to find_e820_area_size() which is expecting an unsigned long. Change t_start and t_size to unsigned long as those are also 64-bit types on x88_64. Signed-off-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Peter Zijlstra 提交于
Andrew Morton wrote: > I've been seeing the below for a long time during suspend-to-ram on the Vaio. > > > PM: Syncing filesystems ... done. > PM: Preparing system for mem sleep > Freezing user space processes ... <4>------------[ cut here ]------------ > WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x127() > Modules linked in: i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ieee1394 ehci_hcd uhci_hcd sg joydev snd_hda_intel snd_seq_dummy sr_mod snd_seq_oss cdrom snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ieee80211 pcspkr ieee80211_crypt snd_pcm i2c_i801 snd_timer i2c_core ide_pci_generic piix snd soundcore snd_page_alloc button ext3 jbd ide_disk ide_core [last unloaded: ipw2200] > Pid: 3250, comm: zsh Not tainted 2.6.26-rc5 #1 > [<c011c5f5>] warn_on_slowpath+0x41/0x6d > [<c01080e6>] ? native_sched_clock+0x82/0x96 > [<c013789c>] ? mark_held_locks+0x41/0x5c > [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58 > [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d > [<c0138637>] ? __lock_acquire+0xae3/0xb2b > [<c0313413>] ? schedule+0x39b/0x3b4 > [<c0135596>] check_flags+0x4c/0x127 > [<c01386b9>] lock_acquire+0x3a/0x86 > [<c0315075>] _spin_lock+0x26/0x53 > [<c0140660>] ? refrigerator+0x13/0xc3 > [<c0140660>] refrigerator+0x13/0xc3 > [<c012684a>] get_signal_to_deliver+0x3c/0x31e > [<c0102fe7>] do_notify_resume+0x91/0x6ee > [<c01359fd>] ? lock_release_holdtime+0x50/0x56 > [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58 > [<c0235d24>] ? read_chan+0x0/0x58c > [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d > [<c0315694>] ? _spin_unlock_irqrestore+0x42/0x58 > [<c0230afa>] ? tty_ldisc_deref+0x5c/0x63 > [<c0233104>] ? tty_read+0x66/0x98 > [<c014b3f0>] ? audit_syscall_exit+0x2aa/0x2c5 > [<c0109430>] ? do_syscall_trace+0x6b/0x16f > [<c0103a9c>] work_notifysig+0x13/0x1b > ======================= > ---[ end trace 25b49fe59a25afa5 ]--- > possible reason: unannotated irqs-off. > irq event stamp: 58919 > hardirqs last enabled at (58919): [<c0103afd>] syscall_exit_work+0x11/0x26 Joy - I so love entry.S Best I can make of it: syscall_exit_work resume_userspace DISABLE_INTERRUPTS (no TRACE_IRQS_OFF) work_pending work_notifysig do_notify_resume() do_signal() get_signal_to_deliver() try_to_freeze() refrigerator() task_lock() -> check_flags() -> BANG The normal path is: syscall_exit_work resume_userspace DISABLE_INTERRUPTS restore_all TRACE_IRQS_IRET iret No idea why that would not warn.. Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Manish Katiyar 提交于
Following patch fixes the below warning message : arch/x86/boot/a20.c:118: warning: unused variable 'loops' Signed-off-by : Manish Katiyar <mkatiyar@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Ingo Molnar 提交于
This reverts commit 6e908947. Németh Márton reported: | there is a problem in 2.6.26-rc3 which was not there in case of | 2.6.25: the CPU wakes up ~90,000 times per sec instead of ~60 per sec. | | I also "git bisected" the problem, the result is: | | 6e908947 is first bad commit | commit 6e908947 | Author: Ingo Molnar <mingo@elte.hu> | Date: Fri Mar 21 14:32:36 2008 +0100 | | x86: fix ioapic bug again the original problem is fixed by Maciej W. Rozycki in the tip/x86/apic branch (confirmed by Márton), but those changes are too intrusive for v2.6.26 so we'll go for the less intrusive (repeated) revert now. Reported-and-bisected-by: NNémeth Márton <nm127@freemail.hu> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Joe Korty 提交于
On Mon, May 19, 2008 at 04:10:02PM -0700, Linus Torvalds wrote: > It also causes these warnings on 32-bit PAE: > > AS arch/x86/kernel/head_32.o > arch/x86/kernel/head_32.S: Assembler messages: > arch/x86/kernel/head_32.S:225: Warning: left operand is a bignum; integer 0 assumed > arch/x86/kernel/head_32.S:609: Warning: left operand is a bignum; integer 0 assumed > > and I do not see why (the end result seems to be identical). Fix head_32.S gcc bignum warnings when CONFIG_PAE=y. arch/x86/kernel/head_32.S: Assembler messages: arch/x86/kernel/head_32.S:225: Warning: left operand is a bignum; integer 0 assumed arch/x86/kernel/head_32.S:609: Warning: left operand is a bignum; integer 0 assumed The assembler was stumbling over the 64-bit constant 0x100000000 in the KPMDS #define. Testing: a cmp(1) on head_32.o before and after shows the binary is unchanged. Signed-off-by: Joe Korty <joe.korty@ccur.com Cc: Hugh Dickins <hugh@veritas.com> Cc: Theodore Tso <tytso@mit.edu> Cc: Gabriel C <nix.or.die@googlemail.com> Cc: Keith Packard <keithp@keithp.com> Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com> Cc: Eric Anholt <eric@anholt.net> Cc: "Siddha Suresh B" <suresh.b.siddha@intel.com> Cc: bugme-daemon@bugzilla.kernel.org Cc: airlied@linux.ie Cc: "Barnes Jesse" <jesse.barnes@intel.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Henry Nestler 提交于
Page faults in kernel address space between PAGE_OFFSET up to VMALLOC_START should not try to map as vmalloc. Fix rarely endless page faults inside mount_block_root for root filesystem at boot time. All 32bit kernels up to 2.6.25 can fail into this hole. I can not present this under native linux kernel. I see, that the 64bit has fixed the problem. I copied the same lines into 32bit part. Recorded debugs are from coLinux kernel 2.6.22.18 (virtualisation): http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/20080410-antinx/bug16-recursive-page-fault-endless.txt The physicaly memory was trimmed down to 192MB to better catch the bug. More memory gets the bug more rarely. Details, how every x86 32bit system can fail: Start from "mount_block_root", http://lxr.linux.no/linux/init/do_mounts.c#L297 There the variable "fs_names" got one memory page with 4096 bytes. Variable "p" walks through the existing file system types. The first string is no problem. But, with the second loop in mount_block_root the offset of "p" is not at beginning of page, the offset is for example +9, if "reiserfs" is the first in list. Than calls do_mount_root, and lands in sys_mount. Remember: Variable "type_page" contains now "fs_type+9" and not contains a full page. The sys_mount copies 4096 bytes with function "exact_copy_from_user()": http://lxr.linux.no/linux/fs/namespace.c#L1540 Mostly exist pages after the buffer "fs_names+4096+9" and the page fault handler was not called. No problem. In the case, if the page after "fs_names+4096" is not mapped, the page fault handler was called from http://lxr.linux.no/linux/fs/namespace.c#L1320 The do_page_fault gots an address 0xc03b4000. It's kernel address, address >= TASK_SIZE, but not from vmalloc! It's from "__getname()" alias "kmem_cache_alloc". The "error_code" is 0. "vmalloc_fault" will be call: http://lxr.linux.no/linux/arch/i386/mm/fault.c#L332 "vmalloc_fault" tryed to find the physical page for a non existing virtual memory area. The macro "pte_present" in vmalloc_fault() got a next page fault for 0xc0000ed0 at: http://lxr.linux.no/linux/arch/i386/mm/fault.c#L282 No PTE exist for such virtual address. The page fault handler was trying to sync the physical page for the PTE lockup. This called vmalloc_fault() again for address 0xc000000, and that also was not existing. The endless began... In normal case the cpu would still loop with disabled interrrupts. Under coLinux this was catched by a stack overflow inside printk debugs. Signed-off-by: NHenry Nestler <henry.nestler@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Ingo Molnar 提交于
-tip testing found this build bug: MODPOST 331 modules ERROR: "geode_mfgpt_toggle_event" [drivers/watchdog/geodewdt.ko] undefined! ERROR: "geode_mfgpt_alloc_timer" [drivers/watchdog/geodewdt.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 with this config: http://redhat.com/~mingo/misc/config-Wed_Jun__4_18_01_59_CEST_2008.bad export those symbols. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 12 6月, 2008 2 次提交
-
-
由 Jeremy Fitzhardinge 提交于
We have a few instances of the open-coded iterative div/mod loop, used when we don't expcet the dividend to be much bigger than the divisor. Unfortunately modern gcc's have the tendency to strength "reduce" this into a full mod operation, which isn't necessarily any faster, and even if it were, doesn't exist if gcc implements it in libgcc. The workaround is to put a dummy asm statement in the loop to prevent gcc from performing the transformation. This patch creates a single implementation of this loop, and uses it to replace the open-coded versions I know about. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: john stultz <johnstul@us.ibm.com> Cc: Segher Boessenkool <segher@kernel.crashing.org> Cc: Christian Kujau <lists@nerdbynature.de> Cc: Robert Hancock <hancockr@shaw.ca> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Fenghua Yu 提交于
This is a SLIT sanity checking patch. It moves slit_valid() function to generic ACPI code and does sanity checking for both x86 and ia64. It sets up node_distance with LOCAL_DISTANCE and REMOTE_DISTANCE when hitting invalid SLIT table on ia64. It also cleans up unused variable localities in acpi_parse_slit() on x86. Signed-off-by: NFenghua Yu <fenghua.yu@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 10 6月, 2008 3 次提交
-
-
由 Segher Boessenkool 提交于
The first argument to __ctl_store() should be the array to store stuff in, not just the first element of that array. With the current code in __cpu_up(), mainline GCC dies with an internal compiler error. I didn't diagnose that further, but just fixed the kernel bug. Signed-off-by: NSegher Boessenkool <segher@kernel.crashing.org> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
-
由 Heiko Carstens 提交于
If a memory range is supposed to be added to the 1:1 mapping and it ends just below the maximum supported physical address it won't succeed. This is because a test doesn't consider that the end address is 1 smaller than start + size. Fix the comparison. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Heiko Carstens 提交于
In case of !64BIT kernel we end up with a zero sized mem_section array. This happens because NR_MEM_SECTIONS is smaller than SECTIONS_PER_ROOT but we have: #define NR_SECTION_ROOTS (NR_MEM_SECTIONS / SECTIONS_PER_ROOT) and struct mem_section *mem_section[NR_SECTION_ROOTS]; So fix this by selecting SPARSEMEM_STATIC which makes sure that SECTIONS_PER_ROOT is 1. Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 09 6月, 2008 8 次提交
-
-
由 Paul Mundt 提交于
Presently the --fdpic specifier and the --isa matching clash when building with FDPIC toolchains. As we have no interest in building the kernel with --fdpic in the first place, always try to add in -mno-fdpic to the default flags. Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Yoshihiro Shimoda 提交于
Signed-off-by: NYoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Nobuhiro Iwamatsu 提交于
SH7763's setup code use old DECLARE_INTC_DESC. There was a compile error because of this. Signed-off-by: NNobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Yusuke.Goda 提交于
Signed-off-by: NYusuke Goda <goda.yusuke@renesas.com> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Nathan Lynch 提交于
The ehea driver was recently changed[1] to use walk_memory_resource() to detect the system's memory layout. However, walk_memory_resource() is available only when memory hotplug is enabled. So CONFIG_EHEA was made to depend on MEMORY_HOTPLUG [2], but it is inappropriate for a network driver to have such a dependency. Make the declaration of walk_memory_resource() and its powerpc implementation (ehea is powerpc-specific) unconditionally available. [1] 48cfb14f "ehea: Add DLPAR memory remove support" [2] fb7b6ca2 "ehea: Add dependency to Kconfig" Signed-off-by: NNathan Lynch <ntl@pobox.com> Acked-by: NBadari Pulavarty <pbadari@us.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stephen Rothwell 提交于
During the next merge window, pci_name()'s return value will become const, so use the new dev_set_name() instead to avoid the warning (from linux-next): arch/powerpc/kernel/pci_64.c: In function 'of_create_pci_dev': arch/powerpc/kernel/pci_64.c:193: warning: passing argument 1 of 'sprintf' discards qualifiers from pointer target type Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Benjamin Herrenschmidt 提交于
When building a signal or a ucontext, we can incorrectly set the MSR_VEC bit of the kernel pt_regs->msr before returning to userspace if the task -ever- used VMX. This can lead to funny result if that stack used it in the past, then "lost" it (ie. it wasn't enabled after a context switch for example) and then called get_context. It can end up with VMX enabled and the registers containing values from some other task. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Adrian Bunk 提交于
This corrects the names of two CONFIG_ variables. Note that the CONFIG_MPC86XADS fix uncovers another bug (with mpc866_ads_defconfig) that will require fixing: <-- snip --> ... arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/mpc866ads.dtb -b 0 /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts DTC: dts->dtb on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts" WRAP arch/powerpc/boot/cuImage.mpc866ads powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such file or directory make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1 <-- snip --> Reported-by: NRobert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 07 6月, 2008 15 次提交
-
-
由 Mike Frysinger 提交于
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com> Signed-off-by: NBryan Wu <cooloney@kernel.org>
-
由 Avi Kivity 提交于
The check is only looking at one of two possible empty ptes. Signed-off-by: NAvi Kivity <avi@qumranet.com>
-
由 Avi Kivity 提交于
Signed-off-by: NAvi Kivity <avi@qumranet.com>
-
由 Avi Kivity 提交于
Shadows for large guests can take a long time to tear down, so reschedule occasionally to avoid softlockup warnings. Signed-off-by: NAvi Kivity <avi@qumranet.com>
-
由 Eli Collins 提交于
Clear CR4.VMXE in hardware_disable. There's no reason to leave it set after doing a VMXOFF. VMware Workstation 6.5 checks CR4.VMXE as a proxy for whether the CPU is in VMX mode, so leaving VMXE set means we'll refuse to power on. With this change the user can power on after unloading the kvm-intel module. I tested on kvm-67 and kvm-69. Signed-off-by: NEli Collins <ecollins@vmware.com> Signed-off-by: NAvi Kivity <avi@qumranet.com>
-
由 Jean Delvare 提交于
Change the name of the device from "rtc-ds1374" to just "ds1374", to match what all other RTC drivers do. I seem to remember that this name was chosen to avoid possible confusion with an older ds1374 driver, but that driver was removed 3 months ago. Signed-off-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NAlessandro Zummo <a.zummo@towertech.it> Acked-by: NKumar Gala <galak@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David Woodhouse 提交于
Although if people have questions about ARCnet, perhaps it's _better_ for them to be mailing dwmw2@cam.ac.uk about it... Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ingo Molnar 提交于
Include limits.h to get a definition of PATH_MAX. Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NJeff Dike <jdike@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jeff Dike 提交于
We lost the marking of SIGWINCH as being OK to receive during stub execution, causing a panic should that happen. Cc: Benedict Verheyen <benedict.verheyen@gmail.com> Signed-off-by: NJeff Dike <jdike@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jeff Dike 提交于
x86_64 defines either memcpy or __memcpy depending on the gcc version, and it looks like UML needs to follow that in its exporting. Cc: Gabriel C <nix.or.die@googlemail.com> Signed-off-by: NJeff Dike <jdike@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Tom Spink 提交于
This patch makes os_get_task_size locate the bottom of the address space, as well as the top. This is for systems which put a lower limit on mmap addresses. It works by manually scanning pages from zero onwards until a valid page is found. Because the bottom of the address space may not be zero, it's not sufficient to assume the top of the address space is the size of the address space. The size is the difference between the top address and bottom address. [jdike@addtoit.com: changed the name to reflect that this function is supposed to return the top of the process address space, not its size and changed the return value to reflect that. Also some minor formatting changes] Signed-off-by: NTom Spink <tspink@gmail.com> Signed-off-by: NJeff Dike <jdike@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Huang Weiyi 提交于
Removed duplicated include file "kern_util.h" in arch/um/drivers/ubd_kern.c. Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com> Signed-off-by: NJeff Dike <jdike@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jeff Dike 提交于
Protection against the host's time going backwards (eg, ntp activity on the host) by keeping track of the time at the last tick and if it's greater than the current time, keep time stopped until the host catches up. Cc: Nix <nix@esperi.org.uk> Signed-off-by: NJeff Dike <jdike@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Geert Uytterhoeven 提交于
As some m68k machines have plenty of libc5 binaries in active use, enable CONFIG_COMPAT_BRK by default. Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Marcelo Tosatti 提交于
Migrate the PIT timer to the physical CPU which vcpu0 is scheduled on, similarly to what is done for the LAPIC timers, otherwise PIT interrupts will be delayed until an unrelated event causes an exit. Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com> Signed-off-by: NAvi Kivity <avi@qumranet.com>
-