- 13 Oct, 2009 9 commits
-
-
Thomas Gleixner authored
-
Thomas Gleixner authored
commit e31b7991 (x86: highmem: Remove leftover function prototypes) removed kmap_atomic_prot_pfn() which is not a leftover, but should have been left where it was. Restore it. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.31.y into rt/2.6.31 Conflicts: Makefile Signed-off-by:
-
Thomas Gleixner authored
-
Peter Zijlstra authored
The numa aliens tear down is not covered by the per cpu locked changes which we did to slab. Fix that. Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Thomas Gleixner authored
The futex code does not handle spurious wake up in futex_wait and futex_wait_requeue_pi. The code assumes that any wake up which was not caused by futex_wake / requeue or by a timeout was caused by a signal wake up and returns one of the syscall restart error codes. In case of a spurious wake up the signal delivery code which deals with the restart error codes is not invoked and we return that error code to user space. That causes applications which actually check the return codes to fail. Blaise reported that on preempt-rt a python test program run into a exception trap. -rt exposed that due to a built in spurious wake up accelerator :) Solve this by checking signal_pending(current) in the wake up path and handle the spurious wake up case w/o returning to user space. Reported-by:
Blaise Gassend <blaise@willowgarage.com> Debugged-by:
Darren Hart <dvhltc@us.ibm.com> Signed-off-by:
-
Thomas Gleixner authored
Remy Bohmer pointed out that we create the hrtimer softirq thread even when CONFIG_HIGH_RES_TIMERS is off. That results in a softirq-NULL name for the thread. The thread is needed on -rt Signed-off-by: -
Thomas Gleixner authored
This reverts commit d69c5d37. The softirq is necessary even in the CONFIG_HIGH_RES_TIMERS=n case. Signed-off-by:
-
Thomas Gleixner authored
This reverts commit 928686b7. The patch was an optimization of the old futex wake code where we woke the waiter and then set q->lock_ptr to NULL. When the waiter preempted the waker then we run into lock contention on q->lock_ptr aka. hb->lock. commit f1a11e (futex: remove the wait queue) changes the wakeup logic by setting q->lock_ptr to NULL _before_ waking the task. It keeps a reference on the task struct of the to be woken task to avoid an exit race. The combination of both patches resulted in different race on -RT: A is blocked on futex B calls futex_wake B sets q(A)->lock_ptr to NULL and puts A on the wake list B is preempted ... A wakes up (e.g. timer, signal) A detects q->lock_ptr = NULL and returns A waits on a different futex B is scheduled back in B wakes A A sees a spurious wake up Reported-by:
-
- 12 Oct, 2009 31 commits
-
-
Greg Kroah-Hartman authored
-
Sascha Hlusiak authored
[ Upstream commit 298bf12d ] When requesting all prl entries (kprl.addr == INADDR_ANY) and there are more prl entries than there is space passed from userspace, the existing code would always copy cmax+1 entries, which is more than can be handled. This patch makes the kernel copy only exactly cmax entries. Signed-off-by:
Sascha Hlusiak <contact@saschahlusiak.de> Acked-By:
Fred L. Templin <Fred.L.Templin@boeing.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Eric Dumazet authored
[ Upstream commit 407fc5cf ] rcv_q & snd_q initializations were reversed in commit 31e6d363 (net: correct off-by-one write allocations reports) Signed-off-by:
Jan Rafaj <jr+netfilter-devel@cedric.unob.cz> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit 8c185ab6 ] In ax25_make_new, if kmemdup of digipeat returns an error, there would be an oops in sk_free while calling sk_destruct, because sk_protinfo is NULL at the moment; move sk->sk_destruct initialization after this. BTW of reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit ffcfb8db ] And also do a better job of returning proper NET_{RX,XMIT}_ values. Based on a patch by Mark Smith. This fixes CVE-2009-2903 Reported-by:
Mark Smith <lk-netdev@lk-netdev.nosense.org> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Mike McCormack authored
[ Upstream commit 74a61ebf ] The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(), before being set later in sky2_up(). Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set should avoid this problem recurring. Signed-off-by:
Mike McCormack <mikem@ring3k.org> Acked-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Steve Glendinning authored
[ Upstream commit ec475623 ] Usbnet framework assumes USB hardware doesn't handle zero length packets, but SMSC LAN95xx requires these to be sent for correct operation. This patch fixes an easily reproducible tx lockup when sending a frame that results in exactly 512 bytes in a USB transmission (e.g. a UDP frame with 458 data bytes, due to IP headers and our USB headers). It adds an extra flag to usbnet for the hardware driver to indicate that it can handle and requires the zero length packets. This patch should not affect other usbnet users, please also consider for -stable. Signed-off-by:
Steve Glendinning <steve.glendinning@smsc.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit d99927f4 ] Commit 2b85a34e (net: No more expensive sock_hold()/sock_put() on each tx) opens a window in sock_wfree() where another cpu might free the socket we are working on. A fix is to call sk->sk_write_space(sk) while still holding a reference on sk. Reported-by:
Jike Song <albcamus@gmail.com> Signed-off-by:
-
Robert Varga authored
[ Upstream commit 657e9649 ] I have recently came across a preemption imbalance detected by: <4>huh, entered ffffffff80644630 with preempt_count 00000102, exited with 00000101? <0>------------[ cut here ]------------ <2>kernel BUG at /usr/src/linux/kernel/timer.c:664! <0>invalid opcode: 0000 [1] PREEMPT SMP with ffffffff80644630 being inet_twdr_hangman(). This appeared after I enabled CONFIG_TCP_MD5SIG and played with it a bit, so I looked at what might have caused it. One thing that struck me as strange is tcp_twsk_destructor(), as it calls tcp_put_md5sig_pool() -- which entails a put_cpu(), causing the detected imbalance. Found on 2.6.23.9, but 2.6.31 is affected as well, as far as I can tell. Signed-off-by:
Robert Varga <nite@hq.alert.sk> Signed-off-by:
-
Kusanagi Kouichi authored
[ Upstream commit 36989b90 ] After commit 2b980dbd ("lsm: Add hooks to the TUN driver") tun_set_iff doesn't return -EINVAL though neither IFF_TUN nor IFF_TAP is set. Signed-off-by:
Kusanagi Kouichi <slash@ma.neweb.ne.jp> Reviewed-by:
Paul Moore <paul.moore@hp.com> Signed-off-by:
-
Miklos Szeredi authored
[ Upstream commit 8ba69ba6 ] Kalle Olavi Niemitalo reported that: "..., when one process calls sendmsg once to send 43804 bytes of data and one file descriptor, and another process then calls recvmsg three times to receive the 16032+16032+11740 bytes, each of those recvmsg calls returns the file descriptor in the ancillary data. I confirmed this with strace. The behaviour differs from Linux 2.6.26, where reportedly only one of those recvmsg calls (I think the first one) returned the file descriptor." This bug was introduced by a patch from me titled "net: unix: fix inflight counting bug in garbage collector", commit 6209344f. And the reason is, quoting Kalle: "Before your patch, unix_attach_fds() would set scm->fp = NULL, so that if the loop in unix_stream_sendmsg() ran multiple iterations, it could not call unix_attach_fds() again. But now, unix_attach_fds() leaves scm->fp unchanged, and I think this causes it to be called multiple times and duplicate the same file descriptors to each struct sk_buff." Fix this by introducing a flag that is cleared at the start and set when the fds attached to the first buffer. The resulting code should work equivalently to the one on 2.6.26. Reported-by:
Kalle Olavi Niemitalo <kon@iki.fi> Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 81bbb3d4 ] Since commit 9b22ea56 ( net: fix packet socket delivery in rx irq handler ) We lost rx timestamping of packets received on accelerated vlans. Effect is that tcpdump on real dev can show strange timings, since it gets rx timestamps too late (ie at skb dequeueing time, not at skb queueing time) 14:47:26.986871 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 1 14:47:26.986786 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 1 14:47:27.986888 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 2 14:47:27.986781 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 2 14:47:28.986896 IP 192.168.20.110 > 192.168.20.141: icmp 64: echo request seq 3 14:47:28.986780 IP 192.168.20.141 > 192.168.20.110: icmp 64: echo reply seq 3 Signed-off-by:
-
Zhao Yakui authored
commit 3e2ada58 upstream. Don't disable ARB_DISABLE when the familary ID is 0x0F. http://bugzilla.kernel.org/show_bug.cgi?id=14211 This was a 2.6.31 regression, and so this patch needs to be applied to 2.6.31.stable Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Jean Delvare authored
commit 14f03343 upstream. The message "ACPI: Device needs an ACPI driver" is misleading. The device _may_ need an ACPI driver, if the BIOS implemented a custom API for the device in question (which, AFAIK, can't be checked.) If not, then either a generic ACPI driver may be used (for example "thermal"), or nothing can be done (other than a white list). I propose to reword the message to: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver which I think is more correct. Comments and suggestions welcome. I also added a message warning about possible problems and system instability when users pass acpi_enforce_resources=lax, as suggested by Len. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Thomas Renninger <trenn@suse.de> Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com> Signed-off-by:
-
Mimi Zohar authored
commit 6c1488fd upstream. When creating a new file, ima_path_check() assumed the new file was being opened for write. Call ima_path_check() with the appropriate acc_mode so that the read/write counters are incremented correctly. Signed-off-by:
Mimi Zohar <zohar@us.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
john stultz authored
Resolved differently upstream in commit 8cab02dc Ondrej Zary reported a suspend/resume hang with 2.6.31 in bug #14222. http://bugzilla.kernel.org/show_bug.cgi?id=14222 The hang was bisected to c7121843 however, that was really just the last straw that caused the issue. The problem was that on suspend, the PIT is removed as a clocksource, and was using the mult value essentially as a is_enabled() flag. The mult adjustments done in the commit above caused that usage to break, causing bad list manipulation and the oops. Further, on resume, the PIT clocksource is never restored, causing the system to run in a degraded mode with jiffies as the clocksource. This issue has since been resolved in 2.6.32-rc by commit 8cab02dc which removes the clocksource disabling on suspend. Testing shows no issues there. So the following patch rectifies the situation for 2.6.31 users of the PIT clocksource that use suspend and resume (which is probably not that many). Many thanks to Ondrej for helping narrow down what was happening, what caused it, and verifying the fix. --------------- Avoid using the unprotected clocksource.mult value as an "is_registered" flag, instead us an explicit flag variable. This avoids possible list corruption if the clocksource is double-unregistered. Also re-register the PIT clocksource on resume so folks don't have to use jiffies after suspend. Signed-off-by:
John Stultz <johnstul@us.ibm.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit e13ee546 upstream. Clear prefetch setting before potentially (re-)enabling it in config_drive_art_rwp() so the transition of the device type on the port from ATA to ATAPI (i.e. during warm-plug operation) is handled correctly. This is a really old bug (it probably goes back to very early days of the driver) but it was only affecting warm-plug operation until the recent "ide: try to use PIO Mode 0 during probe if possible" change (commit 60293364). Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Tested-by:
David Fries <david@fries.net> Signed-off-by:
-
Daisuke Nishimura authored
commit 31a56396 upstream. After commit 355cfa73 ("mm: modify swap_map and add SWAP_HAS_CACHE flag"), read_swap_cache_async() will busy-wait while a entry doesn't exist in swap cache but it has SWAP_HAS_CACHE flag. Such entries can exist on add/delete path of swap cache. On add path, add_to_swap_cache() is called soon after SWAP_HAS_CACHE flag is set, and on delete path, swapcache_free() will be called (SWAP_HAS_CACHE flag is cleared) soon after __delete_from_swap_cache() is called. So, the busy-wait works well in most cases. But this mechanism can cause soft lockup if add_to_swap_cache() sleeps and read_swap_cache_async() tries to swap-in the same entry on the same cpu. This patch calls radix_tree_preload() before swapcache_prepare() and divides add_to_swap_cache() into two part: radix_tree_preload() part and radix_tree_insert() part(define it as __add_to_swap_cache()). Signed-off-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jean Delvare authored
commit b607bd90 upstream. Which is why I have always preferred sizeof(struct foo) over sizeof(var). Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Joerg Roedel authored
commit 20824f30 upstream. When running nested we need to touch the l1 guests tsc_offset. Otherwise changes will be lost or a wrong value be read. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Joerg Roedel authored
commit 77b1ab17 upstream. When svm_vcpu_load is called while the vcpu is running in guest mode the tsc adjustment made there is lost on the next emulated #vmexit. This causes the tsc running backwards in the guest. This patch fixes the issue by also adjusting the tsc_offset in the emulated hsave area so that it will not get lost. Signed-off-by:
-
Aurelien Jarno authored
commit b2d83cfa upstream. Don't overflow when computing the 64-bit period from 32-bit registers. Fixes sourceforge bug #2826486. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
-
Marcelo Tosatti authored
commit eb5109e3 upstream. It is possible that stale EPTP-tagged mappings are used, if a vcpu migrates to a different pcpu. Set KVM_REQ_TLB_FLUSH in vmx_vcpu_load, when switching pcpus, which will invalidate both VPID and EPT mappings on the next vm-entry. Signed-off-by:
-
Avi Kivity authored
commit 6a544355 upstream. The number of entries is multiplied by the entry size, which can overflow on 32-bit hosts. Bound the entry count instead. Reported-by:
David Wagner <daw@cs.berkeley.edu> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Mark Brown authored
commit 5b7dde34 upstream. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Clemens Ladisch authored
commit 2fb930b5 upstream. The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface. Commit b452e08e in 2.6.30 broke the restoring of these volumes by "alsactl restore" that most distributions use; the renaming in this patch cures that regression by preventing alsactl from applying the old, wrong volume levels to the new controls. http://bugzilla.kernel.org/show_bug.cgi?id=14151 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Tejun Heo authored
commit 3b761d3d upstream. While trying to work around spurious detection retries for non-existent devices on slave links, commit 816ab897 incorrectly added link offline check logic before ata_eh_thaw() was called. This means that if an occupied link goes down briefly at the time that offline check was performed, device class will be cleared to ATA_DEV_NONE and libata wouldn't retry thus failing detection of the device. The offline check should be done after the port is thawed together with online check so that such link glitches can be detected by the interrupt handler and handled properly. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Tim Blechmann <tim@klingt.org> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Mimi Zohar authored
commit 36520be8 upstream. The unencrypted files are being measured. Update the counters to get rid of the ecryptfs imbalance message. (http://bugzilla.redhat.com/519737) Reported-by: Sachin Garg Cc: Eric Paris <eparis@redhat.com> Cc: Dustin Kirkland <kirkland@canonical.com> Cc: James Morris <jmorris@namei.org> Cc: David Safford <safford@watson.ibm.com> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Eero Nurkkala authored
commit fdc6f192 upstream. Commit f2e21c96 had unfortunate side effects with cpufreq governors on some systems. If the system did not switch into NOHZ mode ts->inidle is not set when tick_nohz_stop_sched_tick() is called from the idle routine. Therefor all subsequent calls from irq_exit() to tick_nohz_stop_sched_tick() fail to call tick_nohz_start_idle(). This results in bogus idle accounting information which is passed to cpufreq governors. Set the inidle flag unconditionally of the NOHZ active state to keep the idle time accounting correct in any case. [ tglx: Added comment and tweaked the changelog ] Reported-by:
Steven Noonan <steven@uplinklabs.net> Signed-off-by:
Eero Nurkkala <ext-eero.nurkkala@nokia.com> Cc: Rik van Riel <riel@redhat.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Steven Noonan <steven@uplinklabs.net> LKML-Reference: <1254907901.30157.93.camel@eenurkka-desktop> Signed-off-by:
-
Thomas Gleixner authored
commit eaaea803 upstream. Rich reported a lock imbalance in the futex code: http://bugzilla.kernel.org/show_bug.cgi?id=14288 It's caused by the displacement of the retry_private label in futex_wake_op(). The code unlocks the hash bucket locks in the error handling path and retries without locking them again which makes the next unlock fail. Move retry_private so we lock the hash bucket locks when we retry. Reported-by:
Rich Ercolany <rercola@acm.jhu.edu> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Peter Zijlstra authored
commit fc6b177d upstream. The robust list pointers of user space held futexes are kept intact over an exec() call. When the exec'ed task exits exit_robust_list() is called with the stale pointer. The risk of corruption is minimal, but still it is incorrect to keep the pointers valid. Actually glibc should uninstall the robust list before calling exec() but we have to deal with it anyway. Nullify the pointers after [compat_]exit_robust_list() has been called. Reported-by:
Anirban Sinha <ani@anirban.org> Signed-off-by:
-
