- 19 Nov, 2006 15 commits
-
-
Olaf Hering authored
similar to the version in adbhid_input_register(): The '<>' key and the '^°' key on a german keyboard is swapped. Provide correct keys to userland, external USB keyboards will not work correctly when the 'badmap'/'goodmap' workarounds from xkeyboard-config are used. It is expected that distributions drop the badmap/goodmap part from keycodes/macintosh in the xkeyboard-config package. This is probably 2.6.18.x material, if major distros settle on 2.6.18. Signed-off-by:
Olaf Hering <olh@suse.de> Cc: Greg KH <greg@kroah.com> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Andi Kleen authored
This reverts an earlier patch that was found to cause FPU state corruption. I think the corruption happens because unlazy_fpu() can cause FPU exceptions and when it happens after the current switch some processing would affect the state in the wrong process. Thanks to Douglas Crosher and Tom Hughes for testing. Cc: jbeulich@novell.com Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Sergey Vlasov authored
psmouse_show_int_attr() and psmouse_set_int_attr() were accessing unsigned int fields as unsigned long, which gave garbage on x86_64. Signed-off-by:
Sergey Vlasov <vsu@altlinux.ru> Signed-off-by:
-
David Miller authored
We have seen a couple of __alloc_pages() failures due to fragmentation, there is plenty of free memory but no large order pages available. I think the problem is in sock_alloc_send_pskb(), the gfp_mask includes __GFP_REPEAT but its never used/passed to the page allocator. Shouldnt the gfp_mask be passed to alloc_skb() ? Signed-off-by:
Larry Woodman <lwoodman@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Auke Kok authored
e1000: Fix suspend/resume powerup and irq allocation From: Auke Kok <auke-jan.h.kok@intel.com> After 7.0.33/2.6.16, e1000 suspend/resume left the user with an enabled device showing garbled statistics and undetermined irq allocation state, where `ifconfig eth0 down` would display `trying to free already freed irq`. Explicitly free and allocate irq as well as powerup the PHY during resume fixes when needed. Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> [chrisw: trivial 2.6.18 backport s/err/ret_val/] Signed-off-by:
-
Daniel Ritz authored
use the endpoint address from the endpoint descriptor instead of the hardcoding it to 0x81. at least some ITM based screen use a different address and don't work without this. Signed-off-by:
Daniel Ritz <daniel.ritz@gmx.ch> Cc: Ralf Lehmann <ralf@lehmann.cc> Cc: J.P. Delport <jpdelport@csir.co.za> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Oliver Neukum authored
USB: failure in usblp's error path if urb submission fails due to a transient error here eg. ENOMEM , the driver is dead. This fixes it. Regards Oliver Signed-off-by:
Oliver Neukum <oliver@neukum.name> Signed-off-by:
-
Daniel Yeisley authored
It looks like there is a bug in init_reap_node() in slab.c that can cause multiple oops's on certain ES7000 configurations. The variable reap_node is defined per cpu, but only initialized on a single CPU. This causes an oops in next_reap_node() when __get_cpu_var(reap_node) returns the wrong value. Fix is below. Signed-off-by:
Dan Yeisley <dan.yeisley@unisys.com> Cc: Andi Kleen <ak@suse.de> Acked-by:
Christoph Lameter <clameter@engr.sgi.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: <stable@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Yvan Seth authored
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=7439 It looks like device registration in drivers/char/ipmi/ipmi_si_intf.c was cleaned up and a small error was made when setting the class_mask. The fix is simple as the correct mask value is defined in the code but is not used. Acked-by:
Corey Minyard <minyard@acm.org> Cc: <stable@kernel.org> Signed-off-by:
-
Eric Sandeen authored
ufs2 fails to mount on x86_64, claiming bad magic. This is because ufs_super_block_third's fs_un1 member is padded out by 4 bytes for 8-byte alignment, pushing down the rest of the struct. Forcing this to be packed solves it. I took a quick look over other on-disk structures and didn't immediately find other problems. I was able to mount & ls a populated ufs2 filesystem w/ this change. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: Evgeniy Dushistov <dushistov@mail.ru> Cc: <stable@kernel.org> Signed-off-by:
-
David Miller authored
When I added the robust futex syscall entries I forgot to bump NR_SYSCALLS. This is an easy mistake to make because NR_SYSCALLS lived in entry.S which is nowhere near unistd.h or syscalls.S, so while we're here move it's definition into unistd.h so this is unlikely to ever happen again. Signed-off-by:
-
Stephen Rothwell authored
sys_move_pages() uses vmalloc() to allocate an array of structures that is fills with information passed from user mode and then passes to do_stat_pages() (in the case the node list is NULL). do_stat_pages() depends on a marker in the node field of the structure to decide how large the array is and this marker is correctly inserted into the last element of the array. However, vmalloc() doesn't zero the memory it allocates and if the user passes NULL for the node list, then the node fields are not filled in (except for the end marker). If the memory the vmalloc() returned happend to have a word with the marker value in it in just the right place, do_pages_stat will fail to fill the status field of part of the array and we will return (random) kernel data to user mode. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Acked-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
David Miller authored
I copied the logic from ll/sc arch implementations, but that was wrong and makes no sense at all. Just do a straight compare-exchange instruction, just like x86. Based upon bug reports from Dennis Gilmore and Fabio Massimo. Signed-off-by:
-
Benjamin Herrenschmidt authored
The alignment exception used to only check the exception table for -EFAULT, not for other errors. That opens an oops window if we can coerce the kernel into getting an alignment exception for other reasons in what would normally be a user-protected accessor, which can be done via some of the futex ops. This fixes it by always checking the exception tables. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Martin Schwidefsky authored
The previous patch to correct the copy_from_user padding is quite broken. The execute instruction needs to be done via the register %r4, not via %r2 and 31 bit doesn't know the instructions lgr and ahji. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
- 04 Nov, 2006 25 commits
-
-
Chris Wright authored
-
Alan Stern authored
The usbfs code doesn't provide sufficient mutual exclusion among open, release, and remove. Release vs. remove is okay because they both acquire the device lock, but open is not exclusive with either one. All three routines modify the udev->filelist linked list, so they must not run concurrently. Apparently someone gave this a minimum amount of thought in the past by explicitly acquiring the BKL at the start of the usbdev_open routine. Oddly enough, there's a comment pointing out that locking is unnecessary because chrdev_open already has acquired the BKL. But this ignores the point that the files in /proc/bus/usb/* are not char device files; they are regular files and so they don't get any special locking. Furthermore it's necessary to acquire the same lock in the release and remove routines, which the code does not do. Yet another problem arises because the same file_operations structure is accessible through both the /proc/bus/usb/* and /dev/usb/usbdev* file nodes. Even when one of them has been removed, it's still possible for userspace to open the other. So simple locking around the individual remove routines is insufficient; we need to lock the entire usb_notify_remove_device notifier chain. Rather than rely on the BKL, this patch (as723) introduces a new private mutex for the purpose. Holding the BKL while invoking a notifier chain doesn't seem like a good idea. Cc: Dave Jones <davej@redhat.com> [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212952] Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
NeilBrown authored
Partitions are not limited to live within a device. So we should range check after partition mapping. Note that 'maxsector' was being used for two different things. I have split off the second usage into 'old_sector' so that maxsector can be still be used for it's primary usage later in the function. Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
James Morris authored
There's a bug in the seqfile handling for /proc/net/ip6_flowlabel, where, after finding a flowlabel, the code will loop forever not finding any further flowlabels, first traversing the rest of the hash bucket then just looping. This patch fixes the problem by breaking after the hash bucket has been traversed. Note that this bug can cause lockups and oopses, and is trivially invoked by an unpriveleged user. Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Stephen Hemminger authored
Doug Leith observed a discrepancy between the version of CUBIC described in the papers and the version in 2.6.18. A math error related to scaling causes Cubic to grow too slowly. Patch is from "Sangtae Ha" <sha2@ncsu.edu>. I validated that it does fix the problems. See the following to show behavior over 500ms 100 Mbit link. Sender (2.6.19-rc3) --- Bridge (2.6.18-rt7) ------- Receiver (2.6.19-rc3) 1G [netem] 100M http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-orig.png http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-fix.pngSigned-off-by:Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Alan Cox authored
The Jmicron JMB368 is PATA only so has the PATA on function zero. Don't therefore skip function zero on this device when probing Signed-off-by:
Alan Cox <alan@redhat.com> Cc: <stable@kernel.org> Signed-off-by:
-
Oleg Nesterov authored
1. fill_tgid() forgets to do put_task_struct(first). 2. release_task(first) can happen after fill_tgid() drops tasklist_lock, it is unsafe to dereference first->signal. This is a temporary fix, imho the locking should be reworked. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Shailabh Nagar <nagar@watson.ibm.com> Cc: Balbir Singh <balbir@in.ibm.com> Cc: Jay Lan <jlan@sgi.com> Cc: <stable@kernel.org> Signed-off-by:
-
Martin Bligh authored
If try_to_free_pages / balance_pgdat are called with a gfp_mask specifying GFP_IO and/or GFP_FS, they will reclaim the requisite number of pages, and the reset prev_priority to DEF_PRIORITY (or to some other high (ie: unurgent) value). However, another reclaimer without those gfp_mask flags set (say, GFP_NOIO) may still be struggling to reclaim pages. The concurrent overwrite of zone->prev_priority will cause this GFP_NOIO thread to unexpectedly cease deactivating mapped pages, thus causing reclaim difficulties. Fix this is to key the distress calculation not off zone->prev_priority, but also take into account the local caller's priority by using min(zone->prev_priority, sc->priority) Signed-off-by:
Martin J. Bligh <mbligh@google.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: <stable@kernel.org> Signed-off-by:
-
Martin Bligh authored
The temp_priority field in zone is racy, as we can walk through a reclaim path, and just before we copy it into prev_priority, it can be overwritten (say with DEF_PRIORITY) by another reclaimer. The same bug is contained in both try_to_free_pages and balance_pgdat, but it is fixed slightly differently. In balance_pgdat, we keep a separate priority record per zone in a local array. In try_to_free_pages there is no need to do this, as the priority level is the same for all zones that we reclaim from. Impact of this bug is that temp_priority is copied into prev_priority, and setting this artificially high causes reclaimers to set distress artificially low. They then fail to reclaim mapped pages, when they are, in fact, under severe memory pressure (their priority may be as low as 0). This causes the OOM killer to fire incorrectly. From: Andrew Morton <akpm@osdl.org> __zone_reclaim() isn't modifying zone->prev_priority. But zone->prev_priority is used in the decision whether or not to bring mapped pages onto the inactive list. Hence there's a risk here that __zone_reclaim() will fail because zone->prev_priority ir large (ie: low urgency) and lots of mapped pages end up stuck on the active list. Fix that up by decreasing (ie making more urgent) zone->prev_priority as __zone_reclaim() scans the zone's pages. This bug perhaps explains why ZONE_RECLAIM_PRIORITY was created. It should be possible to remove that now, and to just start out at DEF_PRIORITY? Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: <stable@kernel.org> Signed-off-by:
-
Trond Myklebust authored
If the open intents tell us that a given lookup is going to result in a, exclusive create, we currently optimize away the lookup call itself. The reason is that the lookup would not be atomic with the create RPC call, so why do it in the first place? A problem occurs, however, if the VFS aborts the exclusive create operation after the lookup, but before the call to create the file/directory: in this case we will end up with a hashed negative dentry in the dcache that has never been looked up. Fix this by only actually hashing the dentry once the create operation has been successfully completed. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Andy Whitcroft authored
Revert "[PATCH] Remove SPAN_OTHER_NODES config definition" This reverts commit f62859bb. Revert "[PATCH] mm: remove arch independent NODES_SPAN_OTHER_NODES" This reverts commit a94b3ab7. Also update the comments to indicate that this is still required and where its used. Signed-off-by:Andy Whitcroft <apw@shadowen.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Mike Kravetz <kravetz@us.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Mel Gorman <mel@csn.ul.ie> Acked-by:
Will Schmidt <will_schmidt@vnet.ibm.com> Cc: Christoph Lameter <clameter@sgi.com> Cc: <stable@kernel.org> Signed-off-by:
-
Karsten Wiese authored
My K8T800 mobo resumes fine from suspend to ram with and without patch applied against 2.6.18. quirk_via_abnormal_poweroff makes some boards not boot 2.6.18, so IMO patch should go to head, 2.6.18.2 and everywhere "ACPI: ACPICA 20060623" has been applied. Remove quirk_via_abnormal_poweroff Obsoleted by "ACPI: ACPICA 20060623": <snip> Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 </snip> Signed-off-by:Karsten Wiese <fzu@wemgehoertderstaat.de> Cc: Bob Moore <robert.moore@intel.com> Acked-by:
Len Brown <len.brown@intel.com> Acked-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
David Miller authored
For Hummingbird PCI controllers, we should create the root PCI memory space resource as the full 4GB area, and then allocate the IOMMU DMA translation window out of there. The old code just assumed that the IOMMU DMA translation base to the top of the 4GB area was unusable. This is not true on many systems such as SB100 and SB150, where the IOMMU DMA translation window sits at 0xc0000000->0xdfffffff. So what would happen is that any device mapped by the firmware at the top section 0xe0000000->0xffffffff would get remapped by Linux somewhere else leading to all kinds of problems and boot failures. While we're here, report more cases of OBP resource assignment conflicts. The only truly valid ones are ROM resource conflicts. Signed-off-by:
-
Jeff Garzik authored
This is a particularly ugly on-failure bug, possibly security, since the lack of error handling here is covering up another class of bug: failure to handle copy_to_user() return values. The I4L API function ->readstat() returns an integer, and by looking at several existing driver implementations, it is clear that a negative return value was meant to indicate an error. Given that several drivers already return a negative value indicating an errno-style error, the current code would blindly accept that [negative] value as a valid amount of bytes read. Obvious damage ensues. Correcting ->readstat() handling to properly notice errors fixes the existing code to work correctly on error, and enables future patches to more easily indicate errors during operation. Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Karsten Keil <kkeil@suse.de> Cc: <stable@kernel.org> Signed-off-by:
-
Jeff Garzik authored
Most of the ISDN ->readstat() implementations needed to check copy_to_user() and put_user() return values. Signed-off-by:
-
Francisco Larramendi authored
Fix October-only BCD-to-binary conversion bug: 0x08 -> 7 0x09 -> 8 0x10 -> 15 (!) 0x11 -> 19 Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7361 Cc: Raphael Assenat <raph@raphnet.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@kernel.org> Signed-off-by:
-
Thomas Gleixner authored
The integer divisions in the timer accounting code can round the result down to 0. Adding 0 is without effect and the signal delivery stops. Clamp the division result to minimum 1 to avoid this. Problem was reported by Seongbae Park <spark@google.com>, who provided also an inital patch. Roland sayeth: I have had some more time to think about the problem, and to reproduce it using Toyo's test case. For the record, if my understanding of the problem is correct, this happens only in one very particular case. First, the expiry time has to be so soon that in cputime_t units (usually 1s/HZ ticks) it's < nthreads so the division yields zero. Second, it only affects each thread that is so new that its CPU time accumulation is zero so now+0 is still zero and ->it_*_expires winds up staying zero. For the VIRT and PROF clocks when cputime_t is tick granularity (or the SCHED clock on configurations where sched_clock's value only advances on clock ticks), this is not hard to arrange with new threads starting up and blocking before they accumulate a whole tick of CPU time. That's what happens in Toyo's test case. Note that in general it is fine for that division to round down to zero, and set each thread's expiry time to its "now" time. The problem only arises with thread's whose "now" value is still zero, so that now+0 winds up 0 and is interpreted as "not set" instead of ">= now". So it would be a sufficient and more precise fix to just use max(ticks, 1) inside the loop when setting each it_*_expires value. But, it does no harm to round the division up to one and always advance every thread's expiry time. If the thread didn't already fire timers for the expiry time of "now", there is no expectation that it will do so before the next tick anyway. So I followed Thomas's patch in lifting the max out of the loops. This patch also covers the reload cases, which are harder to write a test for (and I didn't try). I've tested it with Toyo's case and it fixes that. [toyoa@mvista.com: fix: min_t -> max_t] Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Roland McGrath <roland@redhat.com> Cc: Daniel Walker <dwalker@mvista.com> Cc: Toyo Abe <toyoa@mvista.com> Cc: john stultz <johnstul@us.ibm.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Seongbae Park <spark@google.com> Cc: Peter Mattis <pmattis@google.com> Cc: Rohit Seth <rohitseth@google.com> Cc: Martin Bligh <mbligh@google.com> Cc: <stable@kernel.org> Signed-off-by:
-
Jan Beulich authored
Previously, since determination whether there was an Intel random number generator was based on a single bit, on systems with a matching bridge device but without a firmware hub, there was a 50% chance that the code would incorrectly decide that the system had an RNG. This patch adds detection of the firmware hub to better qualify the existence of an RNG. There is one issue with the patch: I was unable to determine the LPC equivalent for the PCI bridge 8086:2430 (since the old code didn't care about which of the many devices provided by the ICH/ESB it was chose to use the PCI bridge device, but the FWH settings live in the LPC device, so the device list needed to be changed). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Akinobu Mita authored
[WATCHDOG] sc1200wdt.c pnp unregister fix. If no devices found or invalid parameter is specified, scl200wdt_pnp_driver is left unregistered. It breaks global list of pnp drivers. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Clemens Ladisch authored
The calls to rtc_control() from inside the interrupt handler can deadlock the RTC code, so move our interrupt handling code to a tasklet. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Add needed includes for syscall() function, also to remove warnings spit out by GCC; they were added by previous -stable patch, and at least on my system (Ubuntu x86-64) these warnings do show up. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Ulrich Drepper authored
I need this patch to get a UML kernel to compile. This is with the kernel headers in FC6 which are automatically generated from the kernel tree. Some headers are missing but those files don't need them. At least it appears so since the resulting kernel works fine. Tested on x86-64. Signed-off-by:
Ulrich Drepper <drepper@redhat.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Andi Kleen authored
There was a typo in the C3 latency test to decide of the TSC should be used or not. It used the C2 latency threshold, not the C3 one. Fix that. This should fix the time on various dual core laptops. Acked-by:
-
Herbert Xu authored
I was looking at a RHEL5 bug report involving Xen and SCTP (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212550). It turns out that SCTP wasn't written to handle skb fragments at all. The absence of any calls to skb_may_pull is testament to that. It just so happens that Xen creates fragmented packets more often than other scenarios (header & data split when going from domU to dom0). That's what caused this bug to show up. Until someone has the time sits down and audits the entire net/sctp directory, here is a conservative and safe solution that simply linearises all packets on input. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
[NET]: Fix segmentation of linear packets skb_segment fails to segment linear packets correctly because it tries to write all linear parts of the original skb into each segment. This will always panic as each segment only contains enough space for one MSS. This was not detected earlier because linear packets should be rare for GSO. In fact it still remains to be seen what exactly created the linear packets that triggered this bug. Basically the only time this should happen is if someone enables GSO emulation on an interface that does not support SG. Signed-off-by:
-
