- 26 Jan, 2007 28 commits
-
-
NeilBrown authored
When 'repair' finds a block that is different one the various parts of the mirror. it is meant to write a chosen good version to the others. However it currently writes out the original data to each. The memcpy to make all the data the same is missing. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
NeilBrown authored
Signed-off-by:
-
Peter Staubach authored
NFS V3 (and V4) support exclusive create by passing a 'cookie' which can get stored with the file. If the file exists but has exactly the right cookie stored, then we assume this is a retransmit and the exclusive create was successful. The cookie is 64bits and is traditionally stored in the mtime and atime fields. This causes a problem with Solaris7 as negative mtime or atime confuse it. So we moved two bits into the mode word instead. But inherited ACLs sometimes overwrite the mode word on create, so this is a problem. So we give up and just store 62 of the 64 bits and assume that is close enough. Signed-off-by:
-
NeilBrown authored
A couple of the warnings will be followed by an Oops if they ever fire, so may as well be BUG_ON. Another isn't obviously fatal but has never been known to fire, so make it a WARN_ON. Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
NeilBrown authored
NFSd assumes that largest number of pages that will be needed for a request+response is 2+N where N pages is the size of the largest permitted read/write request. The '2' are 1 for the non-data part of the request, and 1 for the non-data part of the reply. However, when a read request is not page-aligned, and we choose to use ->sendfile to send it directly from the page cache, we may need N+1 pages to hold the whole reply. This can overflow and array and cause an Oops. This patch increases size of the array for holding pages by one and makes sure that entry is NULL when it is not in use. Signed-off-by:
-
NeilBrown authored
Due to silly typos, if the nfs versions are explicitly set, no NFSACL versions get enabled. Also improve an error message that would have made this bug a little easier to find. Signed-off-by:
-
NeilBrown authored
Signed-off-by:
-
Tilman Schmidt authored
Fix several flaws in the error handling of the Siemens Gigaset ISDN driver, including one that would cause an Oops when connecting more than one device of the same type. Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
-
Ingo Molnar authored
Recently cpufreq support on my laptop (Lenovo T60) broke completely: when it's plugged into AC it would never go higher than 1 GHz - neither 1.3 GHz nor 1.83 GHz is possible - no matter which governor (userspace, speed or ondemand) is used. After some cpufreq debugging i tracked the regression back to the following (totally correct) bug-fix commit: commit 0916bd3e Author: Dave Jones <davej@redhat.com> Date: Wed Nov 22 20:42:01 2006 -0500 [PATCH] Correct bound checking from the value returned from _PPC method. This bugfix, which makes other laptops work, made a previously hidden (BIOS) bug visible on my laptop. The bug is the following: if the _PPC (Performance Present Capabilities) optional ACPI object is queried /after/ bootup then the BIOS reports an incorrect value of '2'. My laptop (Lenovo T60) has the following performance states supported: 0: 1833000 1: 1333000 2: 1000000 Per ACPI specification, a _PPC value of '0' means that all 3 performance states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a value of '2' means only state '2' (slowest) is usable. now, the _PPC object is optional, and it also comes with notification. Furthermore, when a CPU object is initialized, the _PPC object is initialized as well. So the following evaluation of the _PPC object is superfluous: [<c028ba5f>] acpi_processor_get_platform_limit+0xa1/0xaf [<c028c040>] acpi_processor_register_performance+0x3b9/0x3ef [<c0111a85>] acpi_cpufreq_cpu_init+0xb7/0x596 [<c03dab74>] cpufreq_add_dev+0x160/0x4a8 [<c02bed90>] sysdev_driver_register+0x5a/0xa0 [<c03d9c4c>] cpufreq_register_driver+0xb4/0x176 [<c068ac08>] acpi_cpufreq_init+0xe5/0xeb [<c010056e>] init+0x14f/0x3dd And this is the point where my laptop's BIOS returns the incorrect value of '2'. Note that it has not sent any notification event, so the value is probably not really intentional (possibly spurious), and Windows likely doesnt query it after bootup either. Maybe the value is kept at '2' normally, and is only set to the real value when a true asynchronous event (such as AC plug event, battery switch, etc.) occurs. So i /think/ this is a grey area of the ACPI spec: per the letter of the spec the _PPC value only changes when notified, so there's no reason to query it after the system has booted up. So in my opinion the best (and most compatible) strategy would be to do the change below, and to not evaluate the _PPC object in the acpi_processor_get_performance_info() call, but only evaluate it if _PPC is present during CPU object init, or if it's notified during an asynchronous event. This change is more permissive than the previous logic, so it definitely shouldnt break any existing system. This also happens to fix my laptop, which is merrily chugging along at 1.83 GHz now. Yay! Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Dave Jones <davej@redhat.com> Acked-by:
Len Brown <lenb@kernel.org> Signed-off-by:
-
Atsushi Nemoto authored
If a SPI master device exists, udev (udevtrigger) causes kernel crash, due to wrong kobj pointer in kobject_uevent_env(). This problem was not in 2.6.19. The backtrace (on MIPS) was: [<8024db6c>] kobject_uevent_env+0x54c/0x5e8 [<802a8264>] store_uevent+0x1c/0x3c (in drivers/class.c) [<801cb14c>] subsys_attr_store+0x2c/0x50 [<801cb80c>] flush_write_buffer+0x38/0x5c [<801cb900>] sysfs_write_file+0xd0/0x190 [<80181444>] vfs_write+0xc4/0x1a0 [<80181cdc>] sys_write+0x54/0xa0 [<8010dae4>] stack_done+0x20/0x3c flush_write_buffer() passes kobject of spi_master_class.subsys to subsys_addr_store(), then subsys_addr_store() passes a pointer to a struct subsystem to store_uevent() which expects a pointer to a struct class_device. The problem seems subsys_attr_store() called instead of class_device_attr_store(). This mismatch was caused by commit 3bd0f694, which overrides kset of master class. This made spi_master_class.subsys.kset.ktype NULL so subsys_sysfs_ops is used instead of class_dev_sysfs_ops. The commit was to fix spi_busnum_to_master(). Here is a patch fixes this function in other way, just searching children list of class_device. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Alexey Dobriyan authored
/proc/*/mounstats was fixed, all right, but... To reproduce: while true; do find /proc -type f 2>/dev/null | xargs cat 1>/dev/null 2>/dev/null; done BUG: unable to handle kernel NULL pointer dereference at virtual address 0000000c printing eip: c01754df *pde = 00000000 Oops: 0000 [#28] Modules linked in: af_packet ohci_hcd e1000 ehci_hcd uhci_hcd usbcore xfs CPU: 0 EIP: 0060:[<c01754df>] Not tainted VLI EFLAGS: 00010286 (2.6.20-rc5 #1) EIP is at mounts_open+0x1c/0xac eax: 00000000 ebx: d5898ac0 ecx: d1d27b18 edx: d1d27a50 esi: e6083e10 edi: d3c87f38 ebp: d5898ac0 esp: d3c87ef0 ds: 007b es: 007b ss: 0068 Process cat (pid: 18071, ti=d3c86000 task=f7d5f070 task.ti=d3c86000) Stack: d5898ac0 e6083e10 d3c87f38 c01754c3 c0147c91 c18c52c0 d343f314 d5898ac0 00008000 d3c87f38 ffffff9c c0147e09 d5898ac0 00000000 00000000 c0147e4b 00000000 d3c87f38 d343f314 c18c52c0 c015e53e 00001000 08051000 00000101 Call Trace: [<c01754c3>] mounts_open+0x0/0xac [<c0147c91>] __dentry_open+0xa1/0x18c [<c0147e09>] nameidata_to_filp+0x31/0x3a [<c0147e4b>] do_filp_open+0x39/0x40 [<c015e53e>] seq_read+0x128/0x2aa [<c0147e8c>] do_sys_open+0x3a/0x6d [<c0147efa>] sys_open+0x1c/0x20 [<c0102b76>] sysenter_past_esp+0x5f/0x85 [<c02a0033>] unix_stream_recvmsg+0x3bf/0x4bf ======================= Code: 5d c3 89 d8 e8 06 e0 f9 ff eb bd 0f 0b eb fe 55 57 56 53 89 d5 8b 40 f0 31 d2 e8 02 c1 fa ff 89 c2 85 c0 74 5c 8b 80 48 04 00 00 <8b> 58 0c 85 db 74 02 ff 03 ff 4a 08 0f 94 c0 84 c0 75 74 85 db EIP: [<c01754df>] mounts_open+0x1c/0xac SS:ESP 0068:d3c87ef0 A race with do_exit()'s call to exit_namespaces(). Signed-off-by:Alexey Dobriyan <adobriyan@openvz.org> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
-
Roland McGrath authored
This patch makes x86_64 define arch_vma_name for CONFIG_IA32_EMULATION. This makes the ia32 vDSO mapping appear in /proc/PID/maps with "[vdso]" for ia32 processes, as it does on native i386. Signed-off-by:
Roland McGrath <roland@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Roland McGrath authored
This patch fixes core dumps to include the vDSO vma, which is left out now. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Roland McGrath authored
This patch fixes ia32 core dumps on x86_64 to include just one phdr for the vDSO vma. Currently it writes a confused format with two phdrs for the address, one without contents and one with. This patch removes the special-case core writing macros for the ia32 vDSO. Instead, it uses VM_ALWAYSDUMP in the vma. This changes core dumps so they no longer include the non-PT_LOAD phdrs from the vDSO, consistent with fixed native i386 core dumps. Signed-off-by:
-
Roland McGrath authored
This patch fixes core dumps to include the vDSO vma, which is left out now. It removes the special-case core writing macros, which were not doing the right thing for the vDSO vma anyway. Instead, it uses VM_ALWAYSDUMP in the vma; there is no need for the fixmap page to be installed. It handles the CONFIG_COMPAT_VDSO case by making elf_core_dump use the fake vma from get_gate_vma after real vmas in the same way the /proc/PID/maps code does. This changes core dumps so they no longer include the non-PT_LOAD phdrs from the vDSO. I made the change to add them in the first place, but in turned out that nothing ever wanted them there since the advent of NT_AUXV. It's cleaner to leave them out, and just let the phdrs inside the vDSO image speak for themselves. Signed-off-by:
-
Roland McGrath authored
This patch adds the VM_ALWAYSDUMP flag for vm_flags in vm_area_struct. This provides a clean explicit way to have a vma always included in core dumps, as is needed for vDSO's. Signed-off-by:
-
Roland McGrath authored
This patch fixes the initialization of gate_vma.vm_flags and gate_vma.vm_page_prot to reflect reality. This makes the "[vdso]" line in /proc/PID/maps correctly show r-xp instead of ---p, when gate_vma is used (CONFIG_COMPAT_VDSO on i386). Signed-off-by:
-
Roland McGrath authored
I wouldn't mind if CONFIG_COMPAT_VDSO went away entirely. But if it's there, it should work properly. Currently it's quite haphazard: both real vma and fixmap are mapped, both are put in the two different AT_* slots, sysenter returns to the vma address rather than the fixmap address, and core dumps yet are another story. This patch makes CONFIG_COMPAT_VDSO disable the real vma and use the fixmap area consistently. This makes it actually compatible with what the old vdso implementation did. Signed-off-by:
-
Justin Clacherty authored
Currently the spi mode can be set to the wrong mode if you are switching from any mode other than mode 0. This is because the mode is set using a bitwise or on uncleared bits. The following patch clears the mode bits before setting the new mode. I've also modified it to use the appropriate defines from pxa-regs.h for readability. Signed-off-by:
Justin Clacherty <justin@redfish-group.com> Signed-off-by:
-
Ben Dooks authored
It turns out that the spi chipselect was not being passed to the set_cs routine if one was specified in the platform data. As part of the fix, change to using a set_cs field in the controller state, and put a default gpio routine in if the data passed does not specify it. Also remove the //#define DEBUG Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
-
Joerg Roedel authored
This patch implements forwarding of SHUTDOWN intercepts from the guest on to userspace on AMD SVM. A SHUTDOWN event occurs when the guest produces a triple fault (e.g. on reboot). This also fixes the bug that a guest reboot actually causes a host reboot under some circumstances. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Avi Kivity authored
With the recent guest page fault change, we perform access checks on our own instead of relying on the cpu. This means we have to perform the nx checks as well. Software like the google toolbar on windows appears to rely on this somehow. Signed-off-by:
-
Avi Kivity authored
Check pte permission bits in walk_addr(), instead of scattering the checks all over the code. This has the following benefits: 1. We no longer set the accessed bit for accessed which fail permission checks. 2. Setting the accessed bit is simplified. 3. Under some circumstances, we used to pretend a page fault was fixed when it would actually fail the access checks. This caused an unnecessary vmexit. 4. The error code for guest page faults is now correct. The fix helps netbsd further along booting, and allows kvm to pass the new mmu testsuite. Signed-off-by:
-
Avi Kivity authored
This allows netbsd 3.1 i386 to get further along installing. Signed-off-by:
-
Leonard Norrgard authored
There's an obvious typo in svm_{get,set}_idt, causing it to access the ldt instead. Because these functions are only called for save/load on AMD, the bug does not impact normal operation. With the fix, save/load works as expected on AMD hosts. Signed-off-by:Uri Lublin <uril@qumranet.com> Signed-off-by:
-
Linus Torvalds authored
In __writeback_single_inode(), when we find a locked inode and we're not doing a data-integrity sync, we used to just skip writing entirely, since we didn't want to wait for the inode to unlock. However, there's really no reason to skip writing the data pages, which are likely to be the the bulk of the dirty state anyway (and the main reason why writeback was started for the non-data-integrity case, of course!) Acked-by:
Nick Piggin <nickpiggin@yahoo.com.au> Cc: Andrew Morton <akpm@osdl.org>, Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Hugh Dickins <hugh@veritas.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Linus Torvalds authored
It's not pretty, but it appears that ext3 with data=journal will clean pages without ever actually telling the VM that they are clean. This, in turn, will result in the VM (and balance_dirty_pages() in particular) to never realize that the pages got cleaned, and wait forever for an event that already happened. Technically, this seems to be a problem with ext3 itself, but it used to be hidden by 'try_to_free_buffers()' noticing this situation on its own, and just working around the filesystem problem. This commit re-instates that hack, in order to avoid a regression for the 2.6.20 release. This fixes bugzilla 7844: http://bugzilla.kernel.org/show_bug.cgi?id=7844 Peter Zijlstra points out that we should probably retain the debugging code that this removes from cancel_dirty_page(), and I agree, but for the imminent release we might as well just silence the warning too (since it's not a new bug: anything that triggers that warning has been around forever). Acked-by:
Randy Dunlap <rdunlap@xenotime.net> Acked-by:
Jens Axboe <jens.axboe@oracle.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Roland McGrath authored
On x86-64, a put_user call using a 64-bit pointer and a constant value that is > 0xffffffff will produce code that doesn't assemble. This patch fixes the asm construct to use the Z constraint for 32-bit constants. Signed-off-by:
-
- 25 Jan, 2007 1 commit
-
-
Linus Torvalds authored
-
- 24 Jan, 2007 11 commits
-
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] Fix wrong checksum calculation on 64-bit MIPS [MIPS] VPE loader: Initialize lists before they're actually being used ... [MIPS] Fix reported amount of freed memory - it's in kB not bytes [MIPS] vr41xx: need one more nop with mtc0_tlbw_hazard() [MIPS] SMTC: Fix module build by exporting symbol [MIPS] SMTC: Fix TLB sizing bug for TLB of 64 >= entries [MIPS] Fix APM build [MIPS] There is no __GNUC_MAJOR__
-
Trond Myklebust authored
Prevent the call to invalidate_inode_pages2() from racing with file writes by taking the inode->i_mutex across the page cache flush and invalidate. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
Fix the Oops in http://bugzilla.linux-nfs.org/show_bug.cgi?id=138 We shouldn't be calling rpc_release_task() for tasks that are not active. Signed-off-by:
-
Atsushi Nemoto authored
The commit 8e3d8433 ([NET]: MIPS checksum annotations and cleanups) broke 64-bit MIPS. The problem is the commit replaces some unsigned long with __be32. On 64bit MIPS, a __be32 (i.e. unsigned int) value is represented as a sign-extented 32-bit value in a 64-bit argument register. So the address 192.168.0.1 (0xc0a80001) is passed as 0xffffffffc0a80001 to csum_tcpudp_nofold() but the asm code in the function expects 0x00000000c0a80001, therefore it returns a wrong checksum. Explicit cast to unsigned long is needed to drop high 32bit. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
kspd which due to makefile order happens to be initialized before the vpe loader causes references to vpecontrol lists before they're actually been initialized. Signed-off-by: -
Thiemo Seufer authored
While at it, change message on DEC for consistency. Signed-off-by:
Thiemo Seufer <ths@networkno.de> Signed-off-by:
-
Yoichi Yuasa authored
NEC VR4111 and VR4121 need one more nop with mtc0_tlbw_hazard(). Signed-off-by:
Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Definitions for TIF_FREEZE and _TIF_FREEZE were missing. Signed-off-by: -
Alexey Dobriyan authored
Gcc major version number is in __GNUC__. As side effect fix checking with sparse if sparse was built with gcc 4.1 and mips cross-compiler is 3.4. Sparse will inherit version 4.1, __GNUC__ won't be filtered from "-dM -E -xc" output, sparse will pick only new major, effectively becoming gcc version 3.1 which is unsupported. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
