- 30 May, 2012 11 commits
-
-
James Bottomley authored
commit 5e185581 upstream. All PA1.1 systems have been oopsing on boot since commit f311847c Author: James Bottomley <James.Bottomley@HansenPartnership.com> Date: Wed Dec 22 10:22:11 2010 -0600 parisc: flush pages through tmpalias space because a PA2.0 instruction was accidentally introduced into the PA1.1 TLB insertion interruption path when it was consolidated with the do_alias macro. Fix the do_alias macro only to use PA2.0 instructions if compiled for 64 bit. Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Tejun Heo authored
commit 05c69d29 upstream. 6d1d8050 "block, partition: add partition_meta_info to hd_struct" added part_unpack_uuid() which assumes that the passed in buffer has enough space for sprintfing "%pU" - 37 characters including '\0'. Unfortunately, b5af921e "init: add support for root devices specified by partition UUID" supplied 33 bytes buffer to the function leading to the following panic with stackprotector enabled. Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e [<ffffffff815e226b>] panic+0xba/0x1c6 [<ffffffff81b14c7e>] ? printk_all_partitions+0x259/0x26xb [<ffffffff810566bb>] __stack_chk_fail+0x1b/0x20 [<ffffffff81b15c7e>] printk_all_paritions+0x259/0x26xb [<ffffffff81aedfe0>] mount_block_root+0x1bc/0x27f [<ffffffff81aee0fa>] mount_root+0x57/0x5b [<ffffffff81aee23b>] prepare_namespace+0x13d/0x176 [<ffffffff8107eec0>] ? release_tgcred.isra.4+0x330/0x30 [<ffffffff81aedd60>] kernel_init+0x155/0x15a [<ffffffff81087b97>] ? schedule_tail+0x27/0xb0 [<ffffffff815f4d24>] kernel_thread_helper+0x5/0x10 [<ffffffff81aedc0b>] ? start_kernel+0x3c5/0x3c5 [<ffffffff815f4d20>] ? gs_change+0x13/0x13 Increase the buffer size, remove the dangerous part_unpack_uuid() and use snprintf() directly from printk_all_partitions(). Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Szymon Gruszczynski <sz.gruszczynski@googlemail.com> Cc: Will Drewry <wad@chromium.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Bernd Schubert authored
commit f908ee94 upstream. The number of bio_get_nr_vecs() is passed down via bio_alloc() to bvec_alloc_bs(), which fails the bio allocation if nr_iovecs > BIO_MAX_PAGES. For the underlying caller this causes an unexpected bio allocation failure. Limiting to queue_max_segments() is not sufficient, as max_segments also might be very large. bvec_alloc_bs(gfp_mask, nr_iovecs, ) => NULL when nr_iovecs > BIO_MAX_PAGES bio_alloc_bioset(gfp_mask, nr_iovecs, ...) bio_alloc(GFP_NOIO, nvecs) xfs_alloc_ioend_bio() Signed-off-by:
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Signed-off-by:
-
Kent Overstreet authored
commit 5abebfdd upstream. There were two places bio_get_nr_vecs() could overflow: First, it did a left shift to convert from sectors to bytes immediately before dividing by PAGE_SIZE. If PAGE_SIZE ever was less than 512 a great many things would break, so dividing by PAGE_SIZE >> 9 is safe and will generate smaller code too. The nastier overflow was in the DIV_ROUND_UP() (that's what the code was effectively doing, anyways). If n + d overflowed, the whole thing would return 0 which breaks things rather effectively. bio_get_nr_vecs() doesn't claim to give an exact value anyways, so the DIV_ROUND_UP() is silly; we could do a straight divide except if a device's queue_max_sectors was less than PAGE_SIZE we'd return 0. So we just add 1; this should always be safe - things will break badly if bio_get_nr_vecs() returns > BIO_MAX_PAGES (bio_alloc() will suddenly start failing) but it's queue_max_segments that must guard against this, if queue_max_sectors is preventing this from happen things are going to explode on architectures with different PAGE_SIZE. Signed-off-by:
Kent Overstreet <koverstreet@google.com> Cc: Tejun Heo <tj@kernel.org> Acked-by:
Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Christian Borntraeger authored
(cherry picked from commit 85175587) commit 7eef87dc (KVM: s390: fix register setting) added a load of the floating point control register to the KVM_SET_FPU path. Lets make sure that the fpc is valid. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jens Freimann authored
(cherry picked from commit 9e0d5473) In handle_stop() handle the stop bit before doing the store status as described for "Stop and Store Status" in the Principles of Operation. We have to give up the local_int.lock before calling kvm store status since it calls gmap_fault() which might sleep. Since local_int.lock only protects local_int.* and not guest memory we can give up the lock. Signed-off-by:
Jens Freimann <jfrei@linux.vnet.ibm.com> Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit 7a4f5ad0) vmx_set_cr0 is called from vcpu run context, therefore it expects kvm->srcu to be held (for setting up the real-mode TSS). Signed-off-by:
-
Nadav Har'El authored
(cherry picked from commit 95871901) The code which checks whether to inject a pagefault to L1 or L2 (in nested VMX) was wrong, incorrect in how it checked the PF_VECTOR bit. Thanks to Dan Carpenter for spotting this. Signed-off-by:
Nadav Har'El <nyh@il.ibm.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Alex Williamson authored
(cherry picked from commit 21a1416a) As pointed out by Jason Baron, when assigning a device to a guest we first set the iommu domain pointer, which enables mapping and unmapping of memory slots to the iommu. This leaves a window where this path is enabled, but we haven't synchronized the iommu mappings to the existing memory slots. Thus a slot being removed at that point could send us down unexpected code paths removing non-existent pinnings and iommu mappings. Take the slots_lock around creating the iommu domain and initial mappings as well as around iommu teardown to avoid this race. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Avi Kivity authored
(cherry picked from commit 3e515705) If some vcpus are created before KVM_CREATE_IRQCHIP, then irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading to potential NULL pointer dereferences. Fix by: - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP This is somewhat long winded because vcpu->arch.apic is created without kvm->lock held. Based on earlier patch by Michael Ellerman. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
Takuya Yoshikawa authored
(cherry picked from commit 565f3be2 Other threads may process the same page in that small window and skip TLB flush and then return before these functions do flush. Signed-off-by:
Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp> Signed-off-by:
-
- 20 May, 2012 29 commits
-
-
Ben Hutchings authored
-
Eric Dumazet authored
commit d4b11335 upstream. commit c57b5468 (pktgen: fix crash at module unload) did a very poor job with list primitives. 1) list_splice() arguments were in the wrong order 2) list_splice(list, head) has undefined behavior if head is not initialized. 3) We should use the list_splice_init() variant to clear pktgen_threads list. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
commit c57b5468 upstream. commit 7d3d43da (net: In unregister_netdevice_notifier unregister the netdevices.) makes pktgen crashing at module unload. [ 296.820578] BUG: spinlock bad magic on CPU#6, rmmod/3267 [ 296.820719] lock: ffff880310c38000, .magic: ffff8803, .owner: <none>/-1, .owner_cpu: -1 [ 296.820943] Pid: 3267, comm: rmmod Not tainted 3.4.0-rc5+ #254 [ 296.821079] Call Trace: [ 296.821211] [<ffffffff8168a715>] spin_dump+0x8a/0x8f [ 296.821345] [<ffffffff8168a73b>] spin_bug+0x21/0x26 [ 296.821507] [<ffffffff812b4741>] do_raw_spin_lock+0x131/0x140 [ 296.821648] [<ffffffff8169188e>] _raw_spin_lock+0x1e/0x20 [ 296.821786] [<ffffffffa00cc0fd>] __pktgen_NN_threads+0x4d/0x140 [pktgen] [ 296.821928] [<ffffffffa00ccf8d>] pktgen_device_event+0x10d/0x1e0 [pktgen] [ 296.822073] [<ffffffff8154ed4f>] unregister_netdevice_notifier+0x7f/0x100 [ 296.822216] [<ffffffffa00d2a0b>] pg_cleanup+0x48/0x73 [pktgen] [ 296.822357] [<ffffffff8109528e>] sys_delete_module+0x17e/0x2a0 [ 296.822502] [<ffffffff81699652>] system_call_fastpath+0x16/0x1b Hold the pktgen_thread_lock while splicing pktgen_threads, and test pktgen_exiting in pktgen_device_event() to make unload faster. Signed-off-by:
-
Stefan Roese authored
commit 1dd8117e upstream. Fix this error: CC drivers/net/ethernet/stmicro/stmmac/mmc_core.o drivers/net/ethernet/stmicro/stmmac/mmc_core.c: In function 'dwmac_mmc_ctrl': drivers/net/ethernet/stmicro/stmmac/mmc_core.c:143:2: error: implicit declaration of function 'pr_debug' [-Werror=implicit-function-declaration] Signed-off-by:
Stefan Roese <sr@denx.de> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by:
Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by:
-
Artem Bityutskiy authored
commit 4a422438 upstream. This patch fixes the following build failure: In file included from include/linux/mtd/qinfo.h:4:0, from include/linux/mtd/pfow.h:7, from drivers/mtd/lpddr/lpddr_cmds.c:27: include/linux/mtd/map.h: In function 'inline_map_read': include/linux/mtd/map.h:409:3: error: implicit declaration of function 'BUILD_BUG_ON' [-Werror=implicit-function-declaration] Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Tushar Dave authored
commit 8ce6909f upstream. Killing reset task while adapter is resetting causes deadlock. Only kill reset task if adapter is not resetting. Ref bug #43132 on bugzilla.kernel.org Signed-off-by:
Tushar Dave <tushar.n.dave@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Willy Tarreau authored
commit bad115cf upstream. Since recent changes on TCP splicing (starting with commits 2f533844 "tcp: allow splice() to build full TSO packets" and 35f9c09f "tcp: tcp_sendpages() should call tcp_push() once"), I started seeing massive stalls when forwarding traffic between two sockets using splice() when pipe buffers were larger than socket buffers. Latest changes (net: netdev_alloc_skb() use build_skb()) made the problem even more apparent. The reason seems to be that if do_tcp_sendpages() fails on out of memory condition without being able to send at least one byte, tcp_push() is not called and the buffers cannot be flushed. After applying the attached patch, I cannot reproduce the stalls at all and the data rate it perfectly stable and steady under any condition which previously caused the problem to be permanent. The issue seems to have been there since before the kernel migrated to git, which makes me think that the stalls I occasionally experienced with tux during stress-tests years ago were probably related to the same issue. This issue was first encountered on 3.0.31 and 3.2.17, so please backport to -stable. Signed-off-by:
Willy Tarreau <w@1wt.eu> Acked-by:
-
Nicholas Bellinger authored
commit cd9323fd upstream. This patch fixes a bug in the handling of FILEIO w/ underlying block_device resize operations where the original fd_dev->fd_dev_size was incorrectly being used in fd_get_blocks() for READ_CAPACITY response payloads. This patch avoids using fd_dev->fd_dev_size for FILEIO devices with an underlying block_device, and instead changes fd_get_blocks() to get the sector count directly from i_size_read() as recommended by hch. Reported-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Jonathan Brassow authored
commit 0d9f4f13 upstream. Use del_timer_sync to remove timer before mddev_suspend finishes. We don't want a timer going off after an mddev_suspend is called. This is especially true with device-mapper, since it can call the destructor function immediately following a suspend. This results in the removal (kfree) of the structures upon which the timer depends - resulting in a very ugly panic. Therefore, we add a del_timer_sync to mddev_suspend to prevent this. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Chris Metcalf authored
commit a134d228 upstream. This passes siginfo and mcontext to tilegx32 signal handlers that don't have SA_SIGINFO set just as we have been doing for tilegx64. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Russell King authored
commit 9b61a4d1 upstream. Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Dan Williams authored
commit 4e6304b8 upstream. Needs to be tagged with FLAG_WWAN, which since it has generic descriptors, won't happen if we don't override the generic driver info. Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
Dan Williams <dcbw@redhat.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Ming Lei authored
commit 5b6e9bcd upstream. Commit 4231d47e(net/usbnet: avoid recursive locking in usbnet_stop()) fixes the recursive locking problem by releasing the skb queue lock before unlink, but may cause skb traversing races: - after URB is unlinked and the queue lock is released, the refered skb and skb->next may be moved to done queue, even be released - in skb_queue_walk_safe, the next skb is still obtained by next pointer of the last skb - so maybe trigger oops or other problems This patch extends the usage of entry->state to describe 'start_unlink' state, so always holding the queue(rx/tx) lock to change the state if the referd skb is in rx or tx queue because we need to know if the refered urb has been started unlinking in unlink_urbs. The other part of this patch is based on Huajun's patch: always traverse from head of the tx/rx queue to get skb which is to be unlinked but not been started unlinking. Signed-off-by:
Huajun Li <huajun.li.lee@gmail.com> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Mark Brown authored
commit c7f5f238 upstream. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Takashi Iwai authored
commit b0791dda upstream. BIOS on some HP laptops don't set the speaker-pins as fixed but expose as jacks, and this confuses the driver as if these pins are jack-detectable. As a result, the machine doesn't get sounds from speakers because the driver prepares the power-map update via jack unsol events which never come up in reality. The bug was introduced in some time in 3.2 for enabling the power-mapping feature. This patch fixes the problem by replacing the check of the persistent power-map bits with a proper is_jack_detectable() call. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43240Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Alexander Clouter authored
commit 1ebfefcf upstream. Without CRYPTO_HASH being selected, mv_cesa has a lot of hooks into undefined exports. ---- MODPOST 81 modules Kernel: arch/arm/boot/Image is ready AS arch/arm/boot/compressed/head.o GZIP arch/arm/boot/compressed/piggy.gzip CC arch/arm/boot/compressed/misc.o CC arch/arm/boot/compressed/decompress.o ERROR: "crypto_ahash_type" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_final" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_register_ahash" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_unregister_ahash" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_update" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_digest" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_shash_setkey" [drivers/crypto/mv_cesa.ko] undefined! ERROR: "crypto_alloc_shash" [drivers/crypto/mv_cesa.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 make: *** Waiting for unfinished jobs.... ---- Signed-off-by:
Alexander Clouter <alex@digriz.org.uk> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Bernhard Kohl authored
commit edc318d9 upstream. This patch addresses a bug in a special case for target core SPC-2 RELEASE logic where the same physical client (eg: iSCSI InitiatorName) with differing iSCSI session identifiers (ISID) is allowed to incorrectly release the same client's SPC-2 reservation from the non reservation holding path. Note this bug is specific to iscsi-target w/ SPC-2 reservations, and with the default enforce_pr_isids=1 device attr setting in target-core controls if a InitiatorName + different ISID reservations are handled the same as a single iSCSI client entity. Signed-off-by:
Bernhard Kohl <bernhard.kohl@gmx.net> Signed-off-by:
-
Will Deacon authored
commit 998de4ac upstream. The vfp_enable function enables access to the VFP co-processor register space (cp10 and cp11) on the current CPU and must be called with preemption disabled. Unfortunately, the vfp_init late initcall does not disable preemption and can lead to an oops during boot if thread migration occurs at the wrong time and we end up attempting to access the FPSID on a CPU with VFP access disabled. This patch fixes the initcall to call vfp_enable from a non-preemptible context on each CPU and adds a BUG_ON(preemptible) to ensure that any similar problems are easily spotted in the future. Reported-by:
Hyungwoo Yang <hwoo.yang@gmail.com> Signed-off-by:
Hyungwoo Yang <hyungwooy@nvidia.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Arend van Spriel authored
commit 5e379203 upstream. The A-MPDU code checked against a retry limit, but it was using the wrong variable to do so. This patch fixes this to assure proper retry mechanism. This problem had a side-effect causing the mac80211 flush callback to remain waiting forever as well. That side effect has been fixed by commit by Stanislaw Gruszka: commit f96b08a7 Date: Tue Jan 17 12:38:50 2012 +0100 brcmsmac: fix tx queue flush infinite loop Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42576 Cc: Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Alwin Beukers <alwin@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Émeric Maschino authored
commit 65cc21b4 upstream. While debugging udev > 170 failure on Debian Wheezy (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears that the issue was in fact due to missing accept4() in ia64. This patch simply adds accept4() to ia64. Signed-off-by:
Émeric Maschino <emeric.maschino@gmail.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Eric Sandeen authored
commit c1bb05a6 upstream. Processes hang forever on a sync-mounted ext2 file system that is mounted with the ext4 module (default in Fedora 16). I can reproduce this reliably by mounting an ext2 partition with "-o sync" and opening a new file an that partition with vim. vim will hang in "D" state forever. The same happens on ext4 without a journal. I am attaching a small patch here that solves this issue for me. In the sync mounted case without a journal, ext4_handle_dirty_metadata() may call sync_dirty_buffer(), which can't be called with buffer lock held. Also move mb_cache_entry_release inside lock to avoid race fixed previously by 8a2bfdcb ext[34]: EA block reference count racing fix Note too that ext2 fixed this same problem in 2006 with b2f49033 [PATCH] fix deadlock in ext2 Signed-off-by: Martin.Wilck@ts.fujitsu.com [sandeen@redhat.com: move mb_cache_entry_release before unlock, edit commit msg] Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Tomoya MORINAGA authored
commit 0f57e168 upstream. Currently, pch_spi_start_transfer failure is not anticipated. This patch adds the processing. Signed-off-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Tomoya MORINAGA authored
commit f258b44e upstream. This patch supports a spi mode setup and bit order setup by IO control. spi mode: mode 0 to mode 3 bit order: LSB first, MSB first Signed-off-by:
-
Tomoya MORINAGA authored
commit 7d05b3e8 upstream. Currently, when spi-topcliff-pch receives transmit request over 4KByte, this driver can't process correctly. This driver needs to divide the data into 4Kbyte unit. This patch fixes the issue. Signed-off-by:
-
Tomoya MORINAGA authored
commit ee2ece52 upstream. Signed-off-by:
-
Axel Lin authored
commit 7e3a70fb upstream. This bug was introduced by commit 54be5663 "gpio-ml-ioh: Support interrupt function" which adds a spinlock to struct ioh_gpio but never init the spinlock. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit a5a737e0 ] %g2 is meant to hold the CPUID number throughout this routine, since at the very beginning, and at the very end, we use %g2 to calculate indexes into per-cpu arrays. However we erroneously clobber it in order to hold the %cwp register value mid-stream. Fix this code to use %g3 for the %cwp read and related calulcations instead. Reported-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
-
Mike Snitzer authored
commit 510193a2 upstream. If the requested scsi_dh module is already loaded then skip request_module(). Multipath table loads can hang in an unnecessary __request_module. Reported-by:
Ben Marzinski <bmarzins@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Sylwester Nawrocki authored
commit e985dbf7 upstream. When setting TRY crop on the sub-device the mutex was erroneously acquired rather than released on exit path. This bug is present in kernels starting from v3.2. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
