aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2005-09-16[PATCH] USB: ftdi_sio: custom baud rate fixIan Abbott
ftdi_sio: I messed up the baud_base for custom baud rate support in 2.6.13. The attached one-liner patch fixes it. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] Fix up more strange byte writes to the PCI_ROM_ADDRESS config wordLinus Torvalds
It's a dword thing, and the value we write is a dword. Doing a byte write to it is nonsensical, and writes only the low byte, which only contains the enable bit. So we enable a nonsensical address (usually zero), which causes the controller no end of problems. Trivial fix, but nasty to find. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] Fix MPOL_F_VERIFYAndi Kleen
There was a pretty bad bug in there that the code would always check the full VMA, not the range the user requested. When the VMA to be checked was merged with the previous VMA this could lead to spurious failures. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] jfs: jfs_delete_inode must call clear_inodeDave Kleikamp
JFS: jfs_delete_inode should always call clear_inode. > From Chuck Ebbert: I'm submitting this patch for -stable: - it reportedly fixes an oops - it's already in 2.6.13-git Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] Fix DHCP + MASQUERADE problemPatrick McHardy
In 2.6.13-rcX the MASQUERADE target was changed not to exclude local packets for better source address consistency. This breaks DHCP clients using UDP sockets when the DHCP requests are caught by a MASQUERADE rule because the MASQUERADE target drops packets when no address is configured on the outgoing interface. This patch makes it ignore packets with a source address of 0. Thanks to Rusty for this suggestion. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] Sun HME: enable and map PCI ROM properlyWilly Tarreau
This ports the Sun GEM ROM mapping/enable fixes it sunhme (which used the same PCI ROM mapping code). Without this, I get NULL MAC addresses for all 4 ports (it's a SUN QFE). With it, I get the correct addresses (the ones printed on the label on the card). Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] Sun GEM ethernet: enable and map PCI ROM properlyLinus Torvalds
This same patch was reported to fix the MAC address detection on sunhme (next patch). Most people seem to be running this on Sparcs or PPC machines, where we get the MAC address from their respective firmware rather than from the (previously broken) ROM mapping routines. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] hpt366: write the full 4 bytes of ROM address, not just low 1 byteLinus Torvalds
This is one heck of a confused driver. It uses a byte write to a dword register to enable a ROM resource that it doesn't even seem to be using. "Lost and wandering in the desert of confusion" Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] forcedeth: Initialize link settings in every nv_open()Manfred Spraul
R�diger found a bug in nv_open that explains some of the reports with duplex mismatches: nv_open calls nv_update_link_speed for initializing the hardware link speed registers. If current link setting matches the values in np->linkspeed and np->duplex, then the function does nothing. Usually, doing nothing is the right thing, but not in nv_open: During nv_open, the registers must be initialized because the nic was reset. The attached patch fixes that by setting np->linkspeed to an invalid value before calling nv_update_link_speed from nv_open. Signed-Off-By: Manfred Spraul <manfred@colorfullife.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] Lost sockfd_put() in routing_ioctl()Maxim Giryaev
This patch adds lost sockfd_put() in 32bit compat rounting_ioctl() on 64bit platforms, bug found by Vasiliy Averin <vvs@sw.ru>. I believe this is a security issues, since user can fget() file as many times as he wants to. So file refcounter can be overlapped and first fput() will free resources though there will be still structures pointing to the file, mnt, dentry etc. Also fput() sets f_dentry and f_vfsmnt to NULL, so other file users will OOPS. The oops can be done under files_lock and others, so this can be an exploitable DoS on SMP. Didn't checked it on practice actually. Signed-Off-By: Kirill Korotaev <dev@sw.ru> Signed-Off-By: Maxim Giryaev <gem@sw.ru> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-16[PATCH] lost fput in 32bit ioctl on x86-64Maxim Giryaev
This patch adds lost fput in 32bit tiocgdev ioctl on x86-64 I believe this is a security issues, since user can fget() file as many times as he wants to. So file refcounter can be overlapped and first fput() will free resources though there will be still structures pointing to the file, mnt, dentry etc. Also fput() sets f_dentry and f_vfsmnt to NULL, so other file users will OOPS. The oops can be done under files_lock and others, so this is really exploitable DoS on SMP. Didn't checked it on practice actually. (chrisw: Update to use fget_light/fput_light) Signed-Off-By: Kirill Korotaev <dev@sw.ru> Signed-Off-By: Maxim Giryaev <gem@sw.ru> Signed-off-by: Chris Wright <chrisw@osdl.org>
2005-09-09Linux 2.6.13.1v2.6.13.1Chris Wright
2005-09-09[PATCH] raw_sendmsg DoS (CAN-2005-2492)Al Viro
Fix unchecked __get_user that could be tricked into generating a memory read on an arbitrary address. The result of the read is not returned directly but you may be able to divine some information about it, or use the read to cause a crash on some architectures by reading hardware state. CAN-2005-2492. Fix from Al Viro, ack from Dave Miller. Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] 32bit sendmsg() flaw (CAN-2005-2490)David Woodhouse
When we copy 32bit ->msg_control contents to kernel, we walk the same userland data twice without sanity checks on the second pass. Second version of this patch: the original broke with 64-bit arches running 32-bit-compat-mode executables doing sendmsg() syscalls with unaligned CMSG data areas Another thing is that we use kmalloc() to allocate and sock_kfree_s() to free afterwards; less serious, but also needs fixing. Patch by Al Viro, David Miller, David Woodhouse (sparc64 clean compile fix from David Miller) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] Reassembly trim not clearing CHECKSUM_HWStephen Hemminger
[IPV4]: Reassembly trim not clearing CHECKSUM_HW This was found by inspection while looking for checksum problems with the skge driver that sets CHECKSUM_HW. It did not fix the problem, but it looks like it is needed. If IP reassembly is trimming an overlapping fragment, it should reset (or adjust) the hardware checksum flag on the skb. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] Use SA_SHIRQ in sparc specific code.David S. Miller
Based upon a report from Jason Wever. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] Fix boundary check in standard multi-block cipher processorsHerbert Xu
[CRYPTO] Fix boundary check in standard multi-block cipher processors Fixes Bug 5194 (IPSec related Oops in 2.6.13). The boundary check in the standard multi-block cipher processors are broken when nbytes is not a multiple of bsize. In those cases it will always process an extra block. This patch corrects the check so that it processes at most nbytes of data. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] 2.6.13 breaks libpcap (and tcpdump)Herbert Xu
[NET]: 2.6.13 breaks libpcap (and tcpdump) Patrick McHardy says: Never mind, I got it, we never fall through to the second switch statement anymore. I think we could simply break when load_pointer returns NULL. The switch statement will fall through to the default case and return 0 for all cases but 0 > k >= SKF_AD_OFF. Here's a patch to do just that. I left BPF_MSH alone because it's really a hack to calculate the IP header length, which makes no sense when applied to the special data. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] x86: pci_assign_unassigned_resources() updateIvan Kokshaysky
I had some time to think about PCI assign issues in 2.6.13-rc series. The major problem here is that we call pci_assign_unassigned_resources() way too early - at subsys_initcall level. Therefore we give no chances to ACPI and PnP routines (called at fs_initcall level) to reserve their respective resources properly, as the comments in drivers/pnp/system.c and drivers/acpi/motherboard.c suggest: /** * Reserve motherboard resources after PCI claim BARs, * but before PCI assign resources for uninitialized PCI devices */ So I moved the pci_assign_unassigned_resources() call to pcibios_assign_resources() (fs_initcall), which should hopefully fix a lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary. Other changes: - remove resource assignment code from pcibios_assign_resources(), since it duplicates pci_assign_unassigned_resources() functionality and actually does nothing in 2.6.13; - modify ROM assignment code as per Ben's suggestion: try to use firmware settings by default (if PCI_ASSIGN_ROMS is not set); - set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for various setups. Confirmed by Tero Roponen <teanropo@cc.jyu.fi> (who had problems with the 4kB CardBus IO size previously). Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] Fix PCI ROM mappingBenjamin Herrenschmidt
This fixes a problem with pci_map_rom() which doesn't properly update the ROM BAR value with the address thas allocated for it by the PCI code. This problem, among other, breaks boot on Mac laptops. It'ss a new version based on Linus latest one with better error checking. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] aacraid: 2.6.13 aacraid bad BUG_ON fixMark Haverkamp
This was noticed by Doug Bazamic and the fix found by Mark Salyzyn at Adaptec. There was an error in the BUG_ON() statement that validated the calculated fib size which can cause the driver to panic. Signed-off-by: Mark Haverkamp <markh@osdl.org> Acked-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-09[PATCH] Kconfig: saa7134-dvb must select tda1004xMichael Krufky
I wish I had seen this before 2.6.13 was released... I guess this only goes to show that there haven't been any testers using saa7134-hybrid dvb/v4l boards that depend on the tda1004x module, during the 2.6.13-rc series :-( Please apply this to 2.6.14, and also to 2.6.13.1 -stable. Without this patch, users will have to EXPLICITLY select tda1004x in Kconfig. This SHOULD be done automatically when saa7134-dvb is selected. This patch corrects this problem. saa7134-dvb must select tda1004x Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-08-28Linux v2.6.13v2.6.13Linus Torvalds
2005-08-28[PATCH] zfcp: bugfix and compile fixesHeiko Carstens
Bugfix (usage of uninitialized pointer in zfcp_port_dequeue) and compile fixes for the zfcp device driver. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-28[PATCH] zfcp: fix compilation due to rports changesAlexey Dobriyan
struct zfcp_port::scsi_id was removed by commit 3859f6a248cbdfbe7b41663f3a2b51f48e30b281 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27Merge refs/heads/upstream-fixes from ↵Linus Torvalds
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
2005-08-27[PATCH] Remove race between con_open and con_closePaul Mackerras
[ Same race and same patch also by Steven Rostedt <rostedt@goodmis.org> ] I have a laptop (G3 powerbook) which will pretty reliably hit a race between con_open and con_close late in the boot process and oops in vt_ioctl due to tty->driver_data being NULL. What happens is this: process A opens /dev/tty6; it comes into con_open() (drivers/char/vt.c) and assign a non-NULL value to tty->driver_data. Then process A closes that and concurrently process B opens /dev/tty6. Process A gets through con_close() and clears tty->driver_data, since tty->count == 1. However, before process A can decrement tty->count, we switch to process B (e.g. at the down(&tty_sem) call at drivers/char/tty_io.c line 1626). So process B gets to run and comes into con_open with tty->count == 2, as tty->count is incremented (in init_dev) before con_open is called. Because tty->count != 1, we don't set tty->driver_data. Then when the process tries to do anything with that fd, it oopses. The simple and effective fix for this is to test tty->driver_data rather than tty->count in con_open. The testing and setting of tty->driver_data is serialized with respect to the clearing of tty->driver_data in con_close by the console_sem. We can't get a situation where con_open sees tty->driver_data != NULL and then con_close on a different fd clears tty->driver_data, because tty->count is incremented before con_open is called. Thus this patch eliminates the race, and in fact with this patch my laptop doesn't oops. Signed-off-by: Paul Mackerras <paulus@samba.org> [ Same patch Signed-off-by: Steven Rostedt <rostedt@goodmis.org> in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ] Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27[PATCH] zfcp: add rports to enable scsi_add_device to work againAndreas Herrmann
This patch fixes a severe problem with 2.6.13-rc7. Due to recent SCSI changes it is not possible to add any LUNs to the zfcp device driver anymore. With registration of remote ports this is fixed. Signed-off-by: Andreas Herrmann <aherrman@de.ibm.com> Acked-by: James Bottomley <jejb@steeleye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27[PATCH] sg.c: fix a memory leak in devices seq_file implementationJan Blunck
I know that scsi procfs is legacy code but this is a fix for a memory leak. While reading through sg.c I realized that the implementation of /proc/scsi/sg/devices with seq_file is leaking memory due to freeing the pointer returned by the next() iterator method. Since next() might return NULL or an error this is wrong. This patch fixes it through using the seq_files private field for holding the reference to the iterator object. Here is a small bash script to trigger the leak. Use slabtop to watch the size-32 usage grow and grow. #!/bin/sh while true; do cat /proc/scsi/sg/devices > /dev/null done Signed-off-by: Jan Blunck <j.blunck@tu-harburg.de> Acked-by: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27[PATCH] fix for race problem in DVB USB drivers (dibusb)Patrick Boettcher
Fixed race between submitting streaming URBs in the driver and starting the actual transfer in hardware (demodulator and USB controller) which sometimes lead to garbled data transfers. URBs are now submitted first, then the transfer is enabled. Dibusb devices and clones are now fully functional again. Signed-off-by: Patrick Boettcher <pb@linuxtv.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27[PATCH] Fix capifs bug in initialization error path.James Morris
This fixes a bug in the capifs initialization code, where the filesystem is not unregistered if kern_mount() fails. Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Karsten Keil <kkeil@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27[PATCH] acpi_shutdown: Only prepare for power off on power_offEric W. Biederman
When acpi_sleep_prepare was moved into a shutdown method we started calling it for all shutdowns. It appears this triggers some systems to power off on reboot. Avoid this by only calling acpi_sleep_prepare if we are going to power off the system. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27[PATCH] mmaper_kern.c fixes [buffer overruns]Al Viro
- copy_from_user() can fail; ->write() must check its return value. - severe buffer overruns both in ->read() and ->write() - lseek to the end (i.e. to mmapper_size) and if (count + *ppos > mmapper_size) count = count + *ppos - mmapper_size; will do absolutely nothing. Then it will call copy_to_user(buf,&v_buf[*ppos],count); with obvious results (similar for ->write()). Fixed by turning read to simple_read_from_buffer() and by doing normal limiting of count in ->write(). - gratitious lock_kernel() in ->mmap() - it's useless there. - lots of gratuitous includes. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27[PATCH] Fix 6pack setting of MAC addressRalf Baechle
Don't check type of sax25_family; dev_set_mac_address has already done that before and anyway, the type to check against would have been ARPHRD_AX25. We only got away because AF_AX25 and ARPHRD_AX25 both happen to be defined to the same value. Don't check sax25_ndigis either; it's value is insignificant for the purpose of setting the MAC address and the check has shown to break some application software for no good reason. Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-08-27[PATCH] 6pack Timer initializationRalf Baechle
I dropped the timer initialization bits by accident when sending the p-persistence fix. This patch gets the driver to work again on halfduplex links. Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-08-26[PATCH] Fix oops in sysfs_hash_and_remove_file()James Bottomley
The problem arises if an entity in sysfs is created and removed without ever having been made completely visible. In SCSI this is triggered by removing a device while it's initialising. The problem appears to be that because it was never made visible in sysfs, the sysfs dentry has a null d_inode which oopses when a reference is made to it. The solution is simply to check d_inode and assume the object was never made visible (and thus doesn't need deleting) if it's NULL. (akpm: possibly a stopgap for 2.6.13 scsi problems. May not be the long-term fix) Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] md: clear the 'recovery' flags when starting an md array.NeilBrown
It's possible for this to still have flags in it and a previous instance has been stopped, and that confused the new array using the same mddev. Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] md: create a MODULE_ALIAS for md corresponding to its block major ↵NeilBrown
number. I just discovered this is needed for module auto-loading. Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] IB: fix use-after-free in user verbs cleanupRoland Dreier
Fix a use-after-free bug in userspace verbs cleanup: we can't touch mr->device after we free mr by calling ib_dereg_mr(). Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] arm: fix IXP4xx flash resource rangeDeepak Saxena
We are currently reserving one byte more than actually needed by the flash device and overlapping into the next I/O expansion bus window. This a) causes us to allocate an extra page of VM due to ARM ioremap() alignment code and b) could cause problems if another driver tries to request the next expansion bus window. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] x86_64: Tell VM about holes in nodesAndi Kleen
Some nodes can have large holes on x86-64. This fixes problems with the VM allowing too many dirty pages because it overestimates the number of available RAM in a node. In extreme cases you can end up with all RAM filled with dirty pages which can lead to deadlocks and other nasty behaviour. This patch just tells the VM about the known holes from e820. Reserved (like the kernel text or mem_map) is still not taken into account, but that should be only a few percent error now. Small detail is that the flat setup uses the NUMA free_area_init_node() now too because it offers more flexibility. (akpm: lotsa thanks to Martin for working this problem out) Cc: Martin Bligh <mbligh@mbligh.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] I2C hwmon: kfree fixesMark M. Hoffman
This patch fixes several instances of hwmon drivers kfree'ing the "wrong" pointer; the existing code works somewhat by accident. (akpm: plucked from Greg's queue based on lkml discussion. Finishes off the patch from Jon Corbet) Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] ppc64: Fix issue with gcc 4.0 compiled kernelsAnton Blanchard
I recently had a BUG_ON() go off spuriously on a gcc 4.0 compiled kernel. It turns out gcc-4.0 was removing a sign extension while earlier gcc versions would not. Thinking this to be a compiler bug, I submitted a report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23422 It turns out we need to cast the input in order to tell gcc to sign extend it. Thanks to Andrew Pinski for his help on this bug. Signed-off-by: Anton Blanchard <anton@samba.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] completely disable cpu_exclusive sched domainPaul Jackson
At the suggestion of Nick Piggin and Dinakar, totally disable the facility to allow cpu_exclusive cpusets to define dynamic sched domains in Linux 2.6.13, in order to avoid problems first reported by John Hawkes (corrupt sched data structures and kernel oops). This has been built for ppc64, i386, ia64, x86_64, sparc, alpha. It has been built, booted and tested for cpuset functionality on an SN2 (ia64). Dinakar or Nick - could you verify that it for sure does avoid the problems Hawkes reported. Hawkes is out of town, and I don't have the recipe to reproduce what he found. Signed-off-by: Paul Jackson <pj@sgi.com> Acked-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] undo partial cpu_exclusive sched domain disablingPaul Jackson
The partial disabling of Dinakar's new facility to allow cpu_exclusive cpusets to define dynamic sched domains doesn't go far enough. At the suggestion of Nick Piggin and Dinakar, let us instead totally disable this facility for 2.6.13, in order to avoid problems first reported by John Hawkes (corrupt sched data structures and kernel oops). This patch removes the partial disabling code in 2.6.13-rc7, in anticipation of the next patch, which will totally disable it instead. Signed-off-by: Paul Jackson <pj@sgi.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26Merge HEAD from master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git Linus Torvalds
2005-08-26[PATCH] hwmon: Off-by-one error in fscpos driverJean Delvare
Coverity uncovered an off-by-one error in the fscpos driver, in function set_temp_reset(). Writing to the temp3_reset sysfs file will lead to an array overrun, in turn causing an I2C write to a random register of the FSC Poseidon chip. Additionally, writing to temp1_reset and temp2_reset will not work as expected. The fix is straightforward. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] ppc32 8xx: fix m8xx_ide_init() #ifdefMarcelo Tosatti
Be more precise on deciding whether to call m8xx_ide_init() at m8xx_setup.c:platform_init(). Compilation fails if CONFIG_BLK_DEV_IDE is defined but CONFIG_BLK_DEV_MPC8xx_IDE isnt. Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] late spinlock initialization in ieee1394/ohciAl Viro
spinlock used in irq handler should be initialized before registering irq, even if we know that our device has interrupts disabled; handler is registered shared and taking spinlock is done unconditionally. As it is, we can and do get oopsen on boot for some configuration, depending on irq routing - I've got a reproducer. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Ben Collins <bcollins@debian.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-26[PATCH] bogus function type in qdioAl Viro
In qdio_get_micros() volatile in return type is plain noise (even with old gccisms it would make no sense - noreturn function returning __u64 is a bit odd ;-) Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>