- 04 Aug, 2007 7 commits
-
-
NeilBrown authored
1/ When resyncing a degraded raid10 which has more than 2 copies of each block, garbage can get synced on top of good data. 2/ We round the wrong way in part of the device size calculation, which can cause confusion. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sergei Shtylyov authored
Eliminate UltraATA/133 support for HPT374 -- the chip isn't capable of this mode according to the manual, and doesn't even seem to tolerate 66 MHz DPLL clock... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Geller Sandor <wildy@petra.hos.u-szeged.hu> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
Alexey Kuznetsov authored
1. New entries can be added to tsk->pi_state_list after task completed exit_pi_state_list(). The result is memory leakage and deadlocks. 2. handle_mm_fault() is called under spinlock. The result is obvious. 3. results in self-inflicted deadlock inside glibc. Sometimes futex_lock_pi returns -ESRCH, when it is not expected and glibc enters to for(;;) sleep() to simulate deadlock. This problem is quite obvious and I think the patch is right. Though it looks like each "if" in futex_lock_pi() got some stupid special case "else if". :-) 4. sometimes futex_lock_pi() returns -EDEADLK, when nobody has the lock. The reason is also obvious (see comment in the patch), but correct fix is far beyond my comprehension. I guess someone already saw this, the chunk: if (rt_mutex_trylock(&q.pi_state->pi_mutex)) ret = 0; is obviously from the same opera. But it does not work, because the rtmutex is really taken at this point: wake_futex_pi() of previous owner reassigned it to us. My fix works. But it looks very stupid. I would think about removal of shift of ownership in wake_futex_pi() and making all the work in context of process taking lock. From: Thomas Gleixner <tglx@linutronix.de> Fix 1) Avoid the tasklist lock variant of the exit race fix by adding an additional state transition to the exit code. This fixes also the issue, when a task with recursive segfaults is not able to release the futexes. Fix 2) Cleanup the lookup_pi_state() failure path and solve the -ESRCH problem finally. Fix 3) Solve the fixup_pi_state_owner() problem which needs to do the fixup in the lock protected section by using the in_atomic userspace access functions. This removes also the ugly lock drop / unqueue inside of fixup_pi_state() Fix 4) Fix a stale lock in the error path of futex_wake_pi() Added some error checks for verification. The -EDEADLK problem is solved by the rtmutex fixups. Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Thomas Gleixner authored
Alexey Kuznetsov found some problems in the pi-futex code. One of the root causes is: When a wakeup happens, we do not to stop the chain walk so we we follow a non existing locking chain. Drop out when this happens. Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:
-
Thomas Gleixner authored
Alexey Kuznetsov found some problems in the pi-futex code. The major problem is a stale return value in rt_mutex_slowlock(): When the pi chain walk returns -EDEADLK, but the waiter was woken up during the phases where the locks were dropped, the rtmutex could be acquired, but due to the stale return value -EDEADLK returned to the caller. Reset the return value in the woken up path. Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:
-
Bob Picco authored
We aren't sampling for holes in memory. Thus we encounter a section hole with empty section map pointer for SPARSEMEM and OOPs for show_mem. This issue has been seen in 2.6.21, current git and current mm. This patch is for 2.6.21 stable. It was tested against sparsemem. Previous to commit f0a5a58a memory_present was called for node_start_pfn to node_end_pfn. This would cover the hole(s) with reserved pages and valid sections. Most SPARSEMEM supported arches do a pfn_valid check in show_mem before computing the page structure address. This issue was brought to my attention on IRC by Arnaldo Carvalho de Melo at acme@redhat.com. Thanks to Arnaldo for testing. Signed-off-by:
Bob Picco <bob.picco@hp.com> Signed-off-by:
-
Michael Chan authored
There's a bug in the driver that only initializes half of the context memory on the 5708. Surprisingly, this works most of the time except for some occasional netdev watchdogs when sending a lot of 64-byte packets. This fix is to add the missing code to initialize the 2nd half of the context memory. Update version to 1.5.8.2. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
- 07 Jul, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Jing Min Zhao authored
[NETFILTER]: nf_conntrack_h323: add checking of out-of-range on choices' index values Choices' index values may be out of range while still encoded in the fixed length bit-field. This bug may cause access to undefined types (NULL pointers) and thus crashes (Reported by Zhongling Wen). This patch also adds checking of decode flag when decoding SEQUENCEs. Signed-off-by:
Jing Min Zhao <zhaojingmin@vivecode.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
- 11 Jun, 2007 31 commits
-
-
Chris Wright authored
-
Satyam Sharma authored
We presently use lock_sock() to acquire a lock on a socket in hci_sock_dev_event(), but this goes BUG because lock_sock() can sleep and we're already holding a read-write spinlock at that point. So, we must use the non-sleeping BH version, bh_lock_sock(). However, hci_sock_dev_event() is called from user context and hence using simply bh_lock_sock() will deadlock against a concurrent softirq that tries to acquire a lock on the same socket. Hence, disabling BH's before acquiring the socket lock and enable them afterwards, is the proper solution to fix socket locking in hci_sock_dev_event(). Signed-off-by:
Satyam Sharma <ssatyam@cse.iitk.ac.in> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Mark Glines authored
This diff changes the default port range used for outgoing connections, from "use 32768-61000 in most cases, but use N-4999 on small boxes (where N is a multiple of 1024, depending on just *how* small the box is)" to just "use 32768-61000 in all cases". I don't believe there are any drawbacks to this change, and it keeps outgoing connection ports farther away from the mess of IANA-registered ports. Signed-off-by:
Mark Glines <mark@glines.org> Signed-off-by:
-
David Miller authored
Handle arbitrary base and length values as long as they are multiples of IO_PAGE_SIZE. Bug found by Arun Kumar Rao. Signed-off-by:
-
David Miller authored
It was using an immediate _PAGE_EXEC_4U value in an 'and' instruction to perform the test. This doesn't work because the immediate field is signed 13-bit, this the mask being tested against the PTE was 0x1000 sign-extended to 32-bits instead of just plain 0x1000. Signed-off-by:
-
David S. Miller authored
1) The TSB lookup was not using the correct hash mask. 2) It was not aligned on a boundary equal to it's size, which is required by the sun4v Hypervisor. wasn't having it's return value checked, and that bug will be fixed up as well in a subsequent changeset. Signed-off-by:
-
Vasily Averin authored
sys_setsockopt() do not check properly timeout values for SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout values. POSIX do not defines behaviour for sys_setsockopt in case negative timeouts, but requires that setsockopt() shall fail with -EDOM if the send and receive timeout values are too big to fit into the timeout fields in the socket structure. In current implementation negative timeout can lead to error messages like "schedule_timeout: wrong timeout value". Proposed patch: - checks tv_usec and returns -EDOM if it is wrong - do not allows to set negative timeout values (sets 0 instead) and outputs ratelimited information message about such attempts. Signed-off-By:
Vasily Averin <vvs@sw.ru> Signed-off-by:
-
Jan Engelhardt authored
The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in my case). This was because mode_prop remained "ttyX-mode" (expected: "ttya-mode") due to the constness of string literals when used with "char *". Since there is no "ttyX-mode" property in the PROM, Linux always used the default 9600. [ Investigation of the suncore.s assembler reveals that gcc optimizied away the stores, yet did not emit a warning, which is a pretty anti-social thing to do and is the only reason this bug lived for so long -DaveM ] Signed-off-by:
Jan Engelhardt <jengelh@gmx.de> Signed-off-by:
-
Dave Jones authored
As mentioned in http://bugzilla.kernel.org/show_bug.cgi?id=5015 The helptext implies that this is on by default. This may be true on some distros (Fedora/RHEL have it enabled in /etc/sysctl.conf), but the kernel defaults to it off. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Stephen Hemminger authored
Kenji Kaneshige found this race between device removal and registration. On unregister it is possible for the old device to exist, because sysfs file is still open. A new device with 'eth%d' will select the same name, but sysfs kobject register will fial. The following changes the shutdown order slightly. It hold a removes the sysfs entries earlier (on unregister_netdevice), but holds a kobject reference. Then when todo runs the actual last put free happens. Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
David Miller authored
Noticed by Matvejchikov Ilya. Signed-off-by:
-
YOSHIFUJI Hideaki authored
We do not need to handle ::/0 routes specially any longer. This should fix BUG #8349. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Acked-by:
Yuji Sekiya <sekiya@wide.ad.jp> Signed-off-by:
-
Kazunori MIYAZAWA authored
Signed-off-by:
Kazunori MIYAZAWA <kazunori@miyazawa.org> Signed-off-by:
-
Jerome Borsboom authored
in4_pton converts a textual representation of an ip4 address into an integer representation. However, when the textual representation is of in the form ip:port, e.g. 192.168.1.1:5060, and 'delim' is set to -1, the function bails out with an error when reading the colon. It makes sense to allow the colon as a delimiting character without explicitly having to set it through the 'delim' variable as there can be no ambiguity in the point where the ip address is completely parsed. This function is indeed called from nf_conntrack_sip.c in this way to parse textual ip:port combinations which fails due to the reason stated above. Signed-off-by:
Jerome Borsboom <j.borsboom@erasmusmc.nl> Signed-off-by:
-
David Miller authored
Currently when icmp_errors_use_inbound_ifaddr is set and an ICMP error is sent after the packet passed through ip_output(), an address from the outgoing interface is chosen as ICMP source address since skb->dev doesn't point to the incoming interface anymore. Fix this by doing an interface lookup on rt->dst.iif and using that device. Signed-off-by:
-
David Miller authored
This combines two upstream commits to fix an OOPS with AF_UNIX and SELINUX. Basically, sk->sk_socket can become NULL because we access a peer socket without any locking, so it can be shut down and released in another thread. Commit: d410b81b4eef2e4409f9c38ef201253fbbcc7d94 [AF_UNIX]: Make socket locking much less confusing. The unix_state_*() locking macros imply that there is some rwlock kind of thing going on, but the implementation is actually a spinlock which makes the code more confusing than it needs to be. So use plain unix_state_lock and unix_state_unlock. Signed-off-by:
-
Tim Gardner authored
Force Dell E520 to use the BIOS to shutdown/reboot. I have at least one report that this patch fixes shutdown/reboot problems on the Dell E520 platform. (Andi says: People can always set the boot option. It hardly seems like a critical issue needing a backport.) Signed-off-by:
Tim Gardner <tim.gardner@ubuntu.com> Acked-by:
Andi Kleen <ak@suse.de> Acked-by:
Matt Domsch <Matt_Domsch@dell.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Gerald Britton authored
Fix an Oops in the cciss driver caused by system shutdown while a filesystem on a cciss device is still active. The cciss_remove_one function only properly removes the device if the device has been cleanly released by its users, which is not the case when the pci_driver.shutdown method is called. This patch adds a new cciss_shutdown function to better match the pattern used by various SCSI drivers: deactivate device interrupts and flush caches. It also alters the cciss_remove_one function to match and readds the __devexit annotation that was removed when cciss_remove_one was serving as the pci_driver.shutdown method. Signed-off-by:
Gerald Britton <gbritton@alum.mit.edu> Acked-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
-
Salyzyn, Mark authored
[PATCH] SCSI: aacraid: Correct sa platform support. (Was: [Bug 8469] Bad EIP value on pentium3 SMP kernel-2.6.21.1) http://bugzilla.kernel.org/show_bug.cgi?id=8469 As discussed in the bugzilla outlined below, we have an sa based (Mustang) RAID adapter on the system, a Dell PERC2/QC. Affected controllers are HP NetRAID, Adaptec AAC-364, Dell PERC2/QC or Adaptec 5400S. This problem coincides with the introduction of the adapter_comm and adapter_deliver platform functions (Message [PATCH 1/4] aacraid: rework communication support code, January 23 2007, which initially migrated to 2.6.21) The panic occurs with an uninitialized adapter_deliver platform function pointer. The enclosed patch, unmodified as tested by Rainer, solves the problem. Signed-off-by:
Mark Salyzyn <aacraid@adaptec.com> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Aaron Durbin authored
Strip __cpuinit[data] from Node <-> PXM routines and supporting data structures. Also make pxm_to_node_map and node_to_pxm_map local to the numa acpi module. This fixes a bug triggered by the following conditions: - boot on a machine with a SLIT table defined - kernel is configured w/ CONFIG_HOTPLUG_CPU=n - cat /sys/devices/system/node/node*/distance This will cause an oops by calling into a freed memory section. In particular, on x86_64, __node_distance calls node_to_pxm(). Signed-off-by:
Aaron Durbin <adurbin@google.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by:
-
Alan Stern authored
This patch (as902) fixes a mistake I introduced into usb_bulk_msg(). usb_fill_int_urb() already does the bit-shifting calculation for high-speed Interrupt intervals; it shouldn't be done twice. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Chris Wright authored
Chuck reports that the recent fix from Andi to oprofile 6c977aad introduces a double free. Each cpu's cpu_msrs is setup to point to cpu 0's, which causes free_msrs to free cpu 0's pointers for_each_possible_cpu. Rather than copy the pointers, do a deep copy instead. [acme@redhat.com: allocate_msrs() was using for_each_online_cpu()] Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Jeff Dike authored
Make the PTRACE_SYSEMU checking more robust. It will make sure that system call numbers are reported correctly. If there is a problem, it will disable PTRACE_SYSEMU use and use PTRACE_SYSCALL instead. This fixes a hang on boot on FC6 hosts with a broken PTRACE_SYSEMU. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Signed-off-by:
-
Michael Chan authored
The bug is caused by code that always set (TG3_FLAG_USE_MI_INTERRUPT | TG3_FLAG_USE_LINKCHG_REG) on all Dell's onboard devices. With these 2 flags set, the link status is polled by tg3_timer() and will only work when the PHY is set up to interrupt the MAC on link changes. This breaks 5906 because the 5906 PHY does not support TG3_FLAG_USE_MI_INTERRUPT the same as other PHYs. For correctness, only 5701 on Dell systems needs these 2 flags to be set. This change will fix the 5906 problem and will change other Dell devices except 5700 and 5701 to use the more efficient interrupt-driven link changes. Update version to 3.75.2. Signed-off-by:
-
Antonino A. Daplas authored
The pseudo_palette has room for 16 entries only, but in truecolor mode, it attempts to write 256. Signed-off-by:
Antonino Daplas <adaplas@gmail.com> Acked-by:
Tero Roponen <teanropo@jyu.fi> Signed-off-by:
-
Andrew Morton authored
I quuestion the testing status of that patch! Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Signed-off-by:
-
Ingo Molnar authored
Make timer-stats have almost zero overhead when enabled in the config but not used. (this way distros can enable it more easily) Also update the documentation about overhead of timer_stats - it was written for the first version which had a global lock and a linear list walk based lookup ;-) Andrew says: And this. Not a bugfix, but trivial and obvious and apparently some distros don't want to enable timer_stats because of the performance issue, but powertop uses timer_stats. Ingo replies: seconded. I have tested this with and without CONFIG_TIMER_STATS, with and without timer_stats collection activated. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Bjorn Steinbrink authored
Fix two races in the timer stats lookup code. One by ensuring that the initialization of a new entry is finished upon insertion of that entry. The other by cleaning up the hash table when the entries array is cleared, so that we don't have any "pre-inserted" entries. Thanks to Eric Dumazet for reminding me of the memory barriers. Signed-off-by:
Bjorn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by:
Ian Kumlien <pomac@vapor.com> Acked-by:
-
Oleg Nesterov authored
Spotted by Satoru Takeuchi. kill_pgrp(task_pgrp(current)) sends the signal to the current's thread group, but can choose any sub-thread as a target for signal_wake_up(). This means that job_control() and tty_check_change() may return -ERESTARTSYS without signal_pending(). Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Cc: Roland McGrath <roland@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: <stable@kernel.org> Signed-off-by:
-
Zou Nan hai authored
On systems with huge amount of physical memory, VFS cache and memory memmap may eat all available system memory under 4G, then the system may fail to allocate swiotlb bounce buffer. There was a fix for this issue in arch/x86_64/mm/numa.c, but that fix dose not cover sparsemem model. This patch add fix to sparsemem model by first try to allocate memmap above 4G. Signed-off-by:
Zou Nan hai <nanhai.zou@intel.com> Acked-by:
Suresh Siddha <suresh.b.siddha@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: <stable@kernel.org> Signed-off-by:
-
Jason Gaston authored
This patch updates the Intel ICH9M LPC Controller DID's, due to a specification change. Signed-off-by:
Jason Gaston <jason.d.gaston@intel.com> Cc: <stable@kernel.org> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
