- 22 Oct, 2009 1 commit
-
-
Hannes Reinecke authored
commit 6e883b0e upstream. A target reset when I/O is ongoing might result an eventual device offline, as scsi_eh_completed_normally() might return ADD_TO_MLQUEUE in addition to the advertised SUCCESS, FAILED, and NEEDS_RETRY. Which is unfortunate as scsi_send_eh_cmnd() will therefore map ADD_TO_MLQUEUE to FAILED instead of the more appropriate NEEDS_RETRY. Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 12 Oct, 2009 39 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:
-
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 <tglx@linutronix.de> 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:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Thomas Gleixner authored
commit 322a2c10 upstream. exit_pi_state() is called from do_exit() but not from do_execve(). Move it to release_mm() so it gets called from do_execve() as well. Signed-off-by:
-
Darren Hart authored
commit da085681 upstream. If futex_wait_requeue_pi() wakes prior to requeue, we drop the reference to the source futex_key twice, once in handle_early_requeue_pi_wakeup() and once on our way out. Remove the drop from the handle_early_requeue_pi_wakeup() and keep the get/drops together in futex_wait_requeue_pi(). Reported-by:
Helge Bahmann <hcb@chaoticmind.net> Signed-off-by:
Darren Hart <dvhltc@us.ibm.com> Cc: Helge Bahmann <hcb@chaoticmind.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Dinakar Guniguntala <dino@in.ibm.com> Cc: John Stultz <johnstul@us.ibm.com> LKML-Reference: <4ACCE21E.5030805@us.ibm.com> Signed-off-by:
-
Steven Rostedt authored
commit 3279ba37 upstream. Due to legacy code from back when the dynamic tracer used a daemon, only core kernel code was checking for failures. This is no longer the case. We must check for failures any time we perform text modifications. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
jolsa@redhat.com authored
commit e7247a15 upstream. When the module is about the unload we release its call records. The ftrace_release function was given wrong values representing the module core boundaries, thus not releasing its call records. Plus making ftrace_release function module specific. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> LKML-Reference: <1254934835-363-3-git-send-email-jolsa@redhat.com> Signed-off-by:
-
Manoj Iyer authored
commit 3db6c037 upstream. Patch was tested on Toshiba NB200 and is found to enable sound. Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by:
-
Jan Beulich authored
commit 24e35800 upstream. While 32-bit processes can't directly access R8...R15, they can gain access to these registers by temporarily switching themselves into 64-bit mode. Therefore, registers not preserved anyway by called C functions (i.e. R8...R11) must be cleared prior to returning to user mode. Signed-off-by:
Jan Beulich <jbeulich@novell.com> LKML-Reference: <4AC34D73020000780001744A@vpn.id2.novell.com> Signed-off-by:
-
Linus Torvalds authored
commit 0b5759c6 upstream. A couple of people have hit the WARN_ON() in drivers/char/tty_io.c, tty_open() that is unhappy about seeing the tty line discipline go away during the tty hangup. See for example http://bugzilla.kernel.org/show_bug.cgi?id=14255 and the reason is that we do the tty_ldisc_halt() outside the ldisc_mutex in order to be able to flush the scheduled work without a deadlock with vhangup_work. However, it turns out that we can solve this particular case by - using "cancel_delayed_work_sync()" in tty_ldisc_halt(), which waits for just the particular work, rather than synchronizing with any random outstanding pending work. This won't deadlock, since the buf.work we synchronize with doesn't care about the ldisc_mutex, it just flushes the tty ldisc buffers. - realize that for this particular case, we don't need to wait for any hangup work, because we are inside the hangup codepaths ourselves. so as a result we can just drop the flush_scheduled_work() entirely, and then move the tty_ldisc_halt() call to inside the mutex. That way we never expose the partially torn down ldisc state to tty_open(), and hold the ldisc_mutex over the whole sequence. Reported-by:
Heinz Diehl <htd@fancy-poultry.org> Signed-off-by:
-
Samuel Thibault authored
commit 392d814d upstream. Just like ip_fast_csum, the assembly snippet in csum_ipv6_magic needs a memory clobber, as it is only passed the address of the buffer, not a memory reference to the buffer itself. This caused failures in Hurd's pfinetv4 when we tried to compile it with gcc-4.3 (bogus checksums). Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by:
-
