- 12 Jul, 2006 20 commits
-
-
Alan Cox authored
Prior to 2.6.18rc1 you could install with devices on a JMicron chipset using the "all-generic-ide" option. As of this kernel the AHCI driver grabs the controller and rams it into AHCI mode losing the PATA ports and making CD drives and the like vanish. The all-generic-ide option fails because the AHCI driver grabbed the PCI device and reconfigured it. To fix this three things are needed. #1 We must put the chip into dual function mode #2 The AHCI driver must grab only function 0 (already in your rc1 tree) #3 Something must grab the PATA ports The attached patch is the minimal risk edition of this. It puts the chip into dual function mode so that AHCI will grab the SATA ports without losing the PATA ports. To keep the risk as low as possible the third patch adds the PCI identifiers for the PATA port and the FN check to the ide-generic driver. There is a more featured jmicron driver on its way but that adds risk and the ide-generic support is sufficient to install and run a system. The actual chip setup done by the quirk is the precise setup recommended by the vendor. (The JMB368 appears only in the ide-generic entry as it has no AHCI so does not need the quirk) Signed-off-by:
Alan Cox <alan@redhat.com> Acked-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Chase Venters authored
During the recent discussion of taking 'volatile' off of the spinlock, I noticed that while most arches #define cpu_relax() such that it implies barrier(), some arches define cpu_relax() to be empty. This patch changes the definition of cpu_relax() for frv, h8300, m68knommu, sh, sh64, v850 and xtensa from an empty while(0) to the compiler barrier(). Signed-off-by:
Chase Venters <chase.venters@clientec.com> Acked-by:
Arjan van de Ven <arjan@Linux.intel.com> Signed-off-by:
-
Ingo Molnar authored
Joseph Fannin reported that hpet_rtc_interrupt() enables hardirqs in irq context: [ 25.628000] [<c014af4e>] trace_hardirqs_on+0xce/0x200 [ 25.628000] [<c036cf21>] _spin_unlock_irq+0x31/0x70 [ 25.628000] [<c0296584>] rtc_get_rtc_time+0x44/0x1a0 [ 25.628000] [<c01198bb>] hpet_rtc_interrupt+0x21b/0x280 [ 25.628000] [<c0161141>] handle_IRQ_event+0x31/0x70 [ 25.628000] [<c0162d37>] handle_edge_irq+0xe7/0x210 [ 25.628000] [<c0106192>] do_IRQ+0x92/0x120 [ 25.628000] [<c0104121>] common_interrupt+0x25/0x2c the call of rtc_get_rtc_time() is highly suspect. At a minimum we need the patch below to save/restore hardirq state. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Joseph Fannin <jfannin@gmail.com> Cc: John Stultz <johnstul@us.ibm.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Andrew Morton authored
We're supposed to go the next power of two if nfds==nr. Of `nr', not of `nfsd'. Spotted by Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by:
-
Eric W. Biederman authored
It looks like someone confused kmem_cache_create with a different allocator and was attempting to give it knowledge of how many cache entries there were. With the unfortunate result that each slab entry was big enough to hold every irq. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Adam B. Jerome authored
Address a potential 'larger than buffer size' memory access by clear_user(). Without this patch, this call to clear_user() can attempt to clear too many (tsz) bytes resulting in a wrong (-EFAULT) return code by read_kcore(). Signed-off-by:
Adam B. Jerome <abj@novell.com> Signed-off-by:
-
Arjan van de Ven authored
sysfs has a different i_mutex lock order behavior for i_mutex than the other filesystems; sysfs i_mutex is called in many places with subsystem locks held. At the same time, many of the VFS locking rules do not apply to sysfs at all (cross directory rename for example). To untangle this mess (which gives false positives in lockdep), we're giving sysfs inodes their own class for i_mutex. Signed-off-by:
-
Kirill Korotaev authored
When found, it is obvious. nfds calculated when allocating fdsets is rewritten by calculation of size of fdtable, and when we are unlucky, we try to free fdsets of wrong size. Found due to OpenVZ resource management (User Beancounters). Signed-off-by:
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:
Kirill Korotaev <dev@openvz.org> Cc: <stable@kernel.org> Signed-off-by:
-
Marcel Holtmann authored
Based on a patch from Ernie Petrides During security research, Red Hat discovered a behavioral flaw in core dump handling. A local user could create a program that would cause a core file to be dumped into a directory they would not normally have permissions to write to. This could lead to a denial of service (disk consumption), or allow the local user to gain root privileges. The prctl() system call should never allow to set "dumpable" to the value 2. Especially not for non-privileged users. This can be split into three cases: 1) running as root -- then core dumps will already be done as root, and so prctl(PR_SET_DUMPABLE, 2) is not useful 2) running as non-root w/setuid-to-root -- this is the debatable case 3) running as non-root w/setuid-to-non-root -- then you definitely do NOT want "dumpable" to get set to 2 because you have the privilege escalation vulnerability With case #2, the only potential usefulness is for a program that has designed to run with higher privilege (than the user invoking it) that wants to be able to create root-owned root-validated core dumps. This might be useful as a debugging aid, but would only be safe if the program had done a chdir() to a safe directory. There is no benefit to a production setuid-to-root utility, because it shouldn't be dumping core in the first place. If this is true, then the same debugging aid could also be accomplished with the "suid_dumpable" sysctl. Signed-off-by:Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
git://git390.osdl.marist.edu/pub/scm/linux-2.6Linus Torvalds authored
* 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6: [S390] Fix sparse warnings. [S390] path grouping and path verifications fixes. [S390] xpram module parameter parsing. [S390] cpu_relax() is supposed to have barrier() semantics. [S390] fix futex_atomic_cmpxchg_inatomic [S390] subchannel register/unregister mutex. [S390] raw_local_save_flags/raw_local_irq_restore type check [S390] __builtin_trap() and gcc version.
-
Linus Torvalds authored
This is confirmed to fix a hang due to PCI resource conflicts with setting up the Cardbus bridge on old laptops with the 440MX chipsets. Original report by Alessio Sangalli, lspci debugging help by Pekka Enberg, and trial patch suggested by Daniel Ritz: "From the docs available i would _guess_ this thing is really similar to the 82443BX/82371AB combination. at least the SMBus base address register is hidden at the very same place (32bit at 0x90 in function 3 of the "south" brigde)" The dang thing is largely undocumented, but the patch was corroborated by Asit Mallick: "I am trying to find the register information. 440MX is an integration of 440BX north-bridge without AGP and PIIX4E (82371EB). PIIX4 quirk should cover the ACPI and SMBus related I/O registers." and verified to fix the problem by Alessio. Cc: Daniel Ritz <daniel.ritz-ml@swissonline.ch> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Dmitry Torokhov <dtor_core@ameritech.net> Tested-by:
Alessio Sangalli <alesan@manoweb.com> Signed-off-by:
-
git://brick.kernel.dk/data/git/linux-2.6-blockLinus Torvalds authored
* 'splice' of git://brick.kernel.dk/data/git/linux-2.6-block: [PATCH] splice: fix problems with sys_tee()
-
Heiko Carstens authored
Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Cornelia Huck authored
1. Multipath devices for which SetPGID is not supported are not handled well. Use NOP ccws for path verification (sans path grouping) when SetPGID is not supported. 2. Check for PGIDs already set with SensePGID on _all_ paths (not just the first one) and try to find a common one. Moan if no common PGID can be found (and use NOP verification). If no PGIDs have been set, use the css global PGID (as before). (Rationale: SetPGID will get a command reject if the PGID it tries to set does not match the already set PGID.) 3. Immediately before reboot, issue RESET CHANNEL PATH (rcp) on all chpids. This will remove the old PGIDs. rcp will generate solicited CRWs which can be savely ignored by the machine check handler (all other actions create unsolicited CRWs). Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
The module parameters for xpram are not or in a wrong way parsed. The xpram module uses the module_param_array directive with an int parameter which causes the kernel to automatically parse the passed numbers. This will cause errors if arguments are omitted or cause wrong results if arguments have size qualifiers. Use module_param_array with charp and parse the arguments later. Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Martin Schwidefsky authored
futex_atomic_cmpxchg_inatomic has the same bug as the other atomic futex operations: the operation needs to be done in the user address space, not the kernel address space. Add the missing sacf 256 & sacf 0. Signed-off-by: -
Cornelia Huck authored
Add a reg_mutex to prevent unregistering a subchannel before it has been registered. Since 2.6.17, we've seen oopses in kslowcrw when a device is found to be not operational during sense id when doing initial device recognition; it is not clear yet why that particular problem was not (yet) observed with earlier kernels... Signed-off-by:
-
Heiko Carstens authored
Make sure that raw_local_save_flags and raw_local_irq_restore always get an unsigned long parameter. raw_irqs_disabled should call raw_local_save_flags instead of local_save_flags. Signed-off-by:
-
Heiko Carstens authored
__builtin_trap() has the archictecture defined backend in gcc since gcc 3.3. To make sure the kernel builds with gcc 3.2 as well, use the old style BUG() statement if compiled with older gcc versions. Signed-off-by:
-
- 11 Jul, 2006 1 commit
-
-
Linus Torvalds authored
The MacMini board table seems to largely look like any bog-standard Intel 945 board. Signed-off-by:
-
- 10 Jul, 2006 19 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: ACPI: ACPI_DOCK: Initialize the atomic notifier list ACPI: acpi_os_allocate() fixes ACPI: SBS: fix initialization, sem2mutex ACPI: add 'const' to several ACPI file_operations ACPI: delete some defaults from ACPI Kconfig ACPI: "Device `[%s]' is not power manageable" make message debug only ACPI: ACPI_DOCK Kconfig Revert "Revert "ACPI: dock driver"" ACPI: acpi_os_get_thread_id() returns current ACPI: ACPICA 20060707
-
Linus Torvalds authored
* HEAD: [DCCP]: Fix sparse warnings. [TCP]: Remove TCP Compound [BPQ] lockdep: fix false positive [IPV4] inetpeer: Get rid of volatile from peer_total [AX.25]: Get rid of the last volatile.
-
Andi Kleen authored
We can't safely directly access an compat_alloc_user_space() pointer with the siginfo copy functions. Bounce it through the stack. Noticed by Al Viro using sparse [ This was only added post 2.6.17, not in any released kernel ] Cc: Al Viro <viro@ftp.linux.org.uk> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
Add it for P4 model 6 - reported to work and have a similar PMU to earlier P4s. Add an p4force=1 module override parameter for future use. We had a discussion about that earlier - it's a trade off between the PMU staying compatible or not. I think the force parameter is a reasonable compromise. Cc: oprofile-list@lists.sf.net Cc: Asit Mallick <asit.k.mallick@intel.com> Signed-off-by:
-
Andi Kleen authored
No need for video to be always in No need for smart battery driver to be always in Acked-by:
Len Brown <len.brown@intel.com> Cc: linux-acpi@vger.kernel.org Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by:
Jon Mason <jdmason@us.ibm.com> Signed-off-by:
-
Muli Ben-Yehuda authored
Signed-off-by:
-
Jacob Shin authored
Signed-off-by:
Jacob Shin <jacob.shin@amd.com> Signed-off-by:
-
Markus Schoder authored
Currently ia32 binaries behave differently with respect to enabling READ_IMPLIES_EXEC. On i386 a binary with the exec_stack flag set is executed with READ_IMPLIES_EXEC enabled as well. The same binary executes without READ_IMPLIES_EXEC on x86-64. This causes binaries that work on i386 to fail on x86-64 which goes somewhat against the whole 32 bit emulation idea. It has been argued that READ_IMPLIES_EXEC should not be enabled at all for binaries that have the exec_stack flag. Which is probably a valid point. However until this is clarified I think x86-64 should behave the same for ia32 binaries as i386. The following patch brings x86-64 in sync with i386 for ia32 binaries. Signed-off-by:
Markus Schoder <lists@gammarayburst.de> Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Alan Cox authored
No actual bugs that I can see just a couple of unmarked casts getting annoying in my debug log files. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
This reverts: f890f921 The inclusion of TCP Compound needs to be reverted at this time because it is not 100% certain that this code conforms to the requirements of Developer's Certificate of Origin 1.1 paragraph (b). Signed-off-by:
-
Ralf Baechle authored
Bpqether is encapsulating AX.25 frames into ethernet frames. There is a virtual bpqether device paired with each ethernet devices, so it's normal to pass through dev_queue_xmit twice for each frame which triggers the locking detector. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Herbert Xu authored
The variable peer_total is protected by a lock. The volatile marker makes no sense. This shaves off 20 bytes on i386. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Ralf Baechle authored
This volatile makes no sense - not even wearing pink shades ... Signed-off-by:
-
Shankar Anand authored
Add an nfs4 operations count array to nfsd_stats structure. The count is incremented in nfsd4_proc_compound() where all the operations are handled by the nfsv4 server. This count of individual nfsv4 operations is also entered into /proc filesystem. Signed-off-by: Shankar Anand<shanand@novell.com> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Eric Sesterhenn authored
Signed-off-by:
Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Arjan van de Ven authored
Disable lockdep debugging in two situations where the integrity of the kernel no longer is guaranteed: when oopsing and when hitting a tainting-condition. The goal is to not get weird lockdep traces that don't make sense or are otherwise undebuggable, to not waste time. Lockdep assumes that the previous state it knows about is valid to operate, which is why lockdep turns itself off after the first violation it reports, after that point it can no longer make that assumption. A kernel oops means that the integrity of the kernel compromised; in addition anything lockdep would report is of lesser importance than the oops. All the tainting conditions are of similar integrity-violating nature and also make debugging/diagnosing more difficult. Signed-off-by:
-
Andrew Morton authored
Update Documentation/SubmitChecklist. - Mention lockdep coverage - Describe documentation requirements - Number the various items to simplify the composition of caustic emails. Signed-off-by:
-
