- 04 Aug, 2007 17 commits
-
-
Tony Jones authored
Removing a watched file will oops if audit is disabled (auditctl -e 0). To reproduce: - auditctl -e 1 - touch /tmp/foo - auditctl -w /tmp/foo - auditctl -e 0 - rm /tmp/foo (or mv) Signed-off-by:
Tony Jones <tonyj@suse.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Gleixner authored
The return value of futex_find_get_task() needs to be -ESRCH in case that the search fails. This was part of the original futex fixes and got accidentally dropped, when the futex-tidy-up patch was split out. Results in a NULL pointer dereference in case the search fails. Restore it. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by:
-
Thomas Gleixner authored
posix-timers which deliver an ignored signal are currently rearmed in the timer softirq: This is necessary because the timer needs to be delivered again when SIG_IGN is removed. This is not a problem, when the interval is reasonable. With high resolution timers enabled one might arm a posix timer with a very small interval and ignore the signal. This might lead to a softirq starvation when the interval is so small that the timer is requeued onto the softirq pending list right away. This problem was pointed out by Jan Kiszka. Thanks Jan ! The correct solution would be to stop the timer, when the signal is ignored and rearm it when SIG_IGN is removed. Unfortunately this requires modification in sigaction and involves non trivial sighand locking. It's too late in the release cycle for such a change. For now we just keep the timer running and enforce that the timer only fires every jiffie. This does not break anything as we keep the overrun counter correct. It adds a little inaccuracy to the timer_gettime() interface, but... The more complex change is necessary anyway to fix another short coming of the current implementation, which I discovered while looking at this problem: A pending signal is discarded when SIG_IGN is set. In case that a posixtimer signal is pending then it is discarded as well, but when SIG_IGN is removed later nothing rearms the timer. This is not new, it's that way since posix timers have been merged. So nothing to worry about right now. I have a working solution to fix all of this, but the impact is too large for both stable and 2.6.22. I'm going to send it out for review in the next days. This should go into 2.6.21.stable as well. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Jan Kiszka <jan.kiszka@web.de> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by:
-
Christoph Lameter authored
Fix massive SMP imbalance on NUMA nodes observed on 2.6.21.5 with CFS. (and later on reproduced without CFS as well). The intervals of domains that do not have SD_BALANCE_NEWIDLE must be considered for the calculation of the time of the next balance. Otherwise we may defer rebalancing forever and nodes might stay idle for very long times. Siddha also spotted that the conversion of the balance interval to jiffies is missing. Fix that to. From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> also continue the loop if !(sd->flags & SD_LOAD_BALANCE). Tested-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> It did in fact trigger under all three of mainline, CFS, and -rt including CFS -- see below for a couple of emails from last Friday giving results for these three on the AMD box (where it happened) and on a single-quad NUMA-Q system (where it did not, at least not with such severity). Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Adam Litke authored
Here's another breakage as a result of shared memory stacked files :( The NUMA policy for a VMA is determined by checking the following (in the order given): 1) vma->vm_ops->get_policy() (if defined) 2) vma->vm_policy (if defined) 3) task->mempolicy (if defined) 4) Fall back to default_policy By switching to stacked files for shared memory, get_policy() is now always set to shm_get_policy which is a wrapper function. This causes us to stop at step 1, which yields NULL for hugetlb instead of task->mempolicy which was the previous (and correct) result. This patch modifies the shm_get_policy() wrapper to maintain steps 1-3 for the wrapped vm_ops. (akpm: the refcounting of mempolicies is busted and this patch does nothing to improve it) Signed-off-by:
Adam Litke <agl@us.ibm.com> Acked-by:
William Irwin <bill.irwin@oracle.com> Cc: dean gaudet <dean@arctic.org> Cc: Christoph Lameter <clameter@sgi.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Olaf Kirch authored
Get rid of first_clone in dm-crypt This gets rid of first_clone, which is not really needed. Apparently, cloned bios used to share their bvec some time way in the past - this is no longer the case. Contrarily, this even hurts us if we try to create a clone off first_clone after it has completed, and crypt_endio has destroyed its bvec. Signed-off-by:
Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Olaf Kirch authored
Do not access the bio after generic_make_request We should never access a bio after generic_make_request - there's no guarantee it still exists. Signed-off-by:
-
Olaf Kirch authored
Call clone_init early We need to call clone_init as early as possible - at least before call bio_put(clone) in any error path. Otherwise, the destructor will try to dereference bi_private, which may still be NULL. Signed-off-by:
-
Milan Broz authored
Disable barriers in dm-crypt because of current workqueue processing can reorder requests. This must be addresed later but for now disabling barriers is needed to prevent data corruption. Signed-off-by:
Milan Broz <mbroz@redhat.com> Signed-off-by:
-
Mike Accetta authored
If raid1/repair (which reads all block and fixes any differences it finds) hits a read error, it doesn't reset the bio for writing before writing correct data back, so the read error isn't fixed, and the device probably gets a zero-length write which it might complain about. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
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:
-
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 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 21 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:
-
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:
-
