- 06 Aug, 2014 9 commits
-
-
Mathias Nyman authored
commit 3213b151 upstream. The transfer burst count (TBC) field in xhci 1.0 hosts should be set to the number of bursts needed to transfer all packets in a isoc TD. Supported values are 0-2 (1 to 3 bursts per service interval). Formula for TBC calculation is given in xhci spec section 4.11.2.3: TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1 This patch should be applied to stable kernels since 3.0 that contain the commit 5cd43e33 "xhci 1.0: Set transfer burst count field." Suggested-by:
ShiChun Ma <masc2008@qq.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Bjørn Mork authored
commit b0ebef36 upstream. Adding a couple of Olivetti modems and blacklisting the net function on a couple which are already supported. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit aea1ae87 upstream. Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28ba ("USB: ftdi_sio: fix hi-speed device packet size calculation") Reported-by:
Mike Remski <mremski@mutualink.net> Tested-by:
-
Michal Nazarewicz authored
commit f0688c8b upstream. If the descriptors do not need any strings and user space sends empty set of strings, the ffs->stringtabs field remains NULL. Thus *ffs->stringtabs in functionfs_bind leads to a NULL pointer dereferenece. The bug was introduced by commit [fd7c9a00: “use usb_string_ids_n()”]. While at it, remove double initialisation of lang local variable in that function. ffs->strings_count does not need to be checked in any way since in the above scenario it will remain zero and usb_string_ids_n() is a no-operation when colled with 0 argument. Signed-off-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Paolo Bonzini authored
commit 7cb060a9 upstream. KVM does not really do much with the PAT, so this went unnoticed for a long time. It is exposed however if you try to do rdmsr on the PAT register. Reported-by:
Valentine Sinitsyn <valentine.sinitsyn@gmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Nadav Amit authored
commit 682367c4 upstream. Recent Intel CPUs have 10 variable range MTRRs. Since operating systems sometime make assumptions on CPUs while they ignore capability MSRs, it is better for KVM to be consistent with recent CPUs. Reporting more MTRRs than actually supported has no functional implications. Signed-off-by:
Nadav Amit <namit@cs.technion.ac.il> Signed-off-by:
-
David R. Piegdon authored
commit c021f241 upstream. Fix a parser-bug in the omap2 muxing code where muxtable-entries will be wrongly selected if the requested muxname is a *prefix* of their m0-entry and they have a matching mN-entry. Fix by additionally checking that the length of the m0_entry is equal. For example muxing of "dss_data2.dss_data2" on omap32xx will fail because the prefix "dss_data2" will match the mux-entries "dss_data2" as well as "dss_data20", with the suffix "dss_data2" matching m0 (for dss_data2) and m4 (for dss_data20). Thus both are recognized as signal path candidates: Relevant muxentries from mux34xx.c: _OMAP3_MUXENTRY(DSS_DATA20, 90, "dss_data20", NULL, "mcspi3_somi", "dss_data2", "gpio_90", NULL, NULL, "safe_mode"), _OMAP3_MUXENTRY(DSS_DATA2, 72, "dss_data2", NULL, NULL, NULL, "gpio_72", NULL, NULL, "safe_mode"), This will result in a failure to mux the pin at all: _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2 Patch should apply to linus' latest master down to rather old linux-2.6 trees. Signed-off-by:
David R. Piegdon <lkml@p23q.org> [tony@atomide.com: updated description to include full description] Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Ben Hutchings authored
This reverts commit caa53449, which was commit fe6cc55f upstream. In 3.2, the transport header length is not calculated in the forwarding path, so skb_gso_network_seglen() returns an incorrect result. We also have problems due to the local_df flag not being set correctly. Signed-off-by:
-
Ben Hutchings authored
This reverts commit 59d9f389, which was commit ca6c5d4a upstream. It is a valid fix, but depends on sk_buff::local_df being set in all the right cases, which it wasn't in 3.2. We need to defer it unless and until the other fixes are also backported to 3.2.y. Signed-off-by:
-
- 11 Jul, 2014 31 commits
-
-
Ben Hutchings authored
-
Michael S. Tsirkin authored
commit 1fd819ec upstream. skb_segment copies frags around, so we need to copy them carefully to avoid accessing user memory after reporting completion to userspace through a callback. skb_segment doesn't normally happen on datapath: TSO needs to be disabled - so disabling zero copy in this case does not look like a big deal. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 3.2. As skb_segment() only supports page-frags *or* a frag list, there is no need for the additional frag_skb pointer or the preparatory renaming.] Signed-off-by:
-
Michael S. Tsirkin authored
commit dcc0fb78 upstream. Export skb_copy_ubufs so that modules can orphan frags. Signed-off-by:
-
Michael S. Tsirkin authored
commit a353e0ce upstream. Many places do if ((skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY)) skb_copy_ubufs(skb, gfp_mask); to copy and invoke frag destructors if necessary. Add an inline helper for this. Signed-off-by:
-
Tejun Heo authored
commit b9cd18de upstream. The 'sysret' fastpath does not correctly restore even all regular registers, much less any segment registers or reflags values. That is very much part of why it's faster than 'iret'. Normally that isn't a problem, because the normal ptrace() interface catches the process using the signal handler infrastructure, which always returns with an iret. However, some paths can get caught using ptrace_event() instead of the signal path, and for those we need to make sure that we aren't going to return to user space using 'sysret'. Otherwise the modifications that may have been done to the register set by the tracer wouldn't necessarily take effect. Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from arch_ptrace_stop_needed() which is invoked from ptrace_stop(). Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Andy Lutomirski <luto@amacapital.net> Acked-by:
Oleg Nesterov <oleg@redhat.com> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Geert Uytterhoeven authored
commit 98b0f811 upstream. The English and Korean translations were updated, the Chinese and Japanese weren't. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Liu Hua authored
commit 8fad87bc upstream. When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will overflow if pfn >= 0x100000 in copy_oldmem_page. So use __pfn_to_phys for converting. Signed-off-by:
Liu Hua <sdu.liu@huawei.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
David Woodhouse authored
Part of commit ea8ea460 upstream. This missing IOTLB flush was added as a minor, inconsequential bug-fix in commit ea8ea460 ("iommu/vt-d: Clean up and fix page table clear/free behaviour") in 3.15. It wasn't originally intended for -stable but a couple of users have reported issues which turn out to be fixed by adding the missing flush. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> [bwh: Backported to 3.2: - Adjust context - Use &dmar_domain->iommu_bmp, as it is a single word not an array] Signed-off-by:
-
Ben Collins authored
commit 11f8a7b3 upstream. The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to truncation of the PCI resource address, meaning this driver didn't work on 32-bit systems with 64-bit PCI adressing ranges. Signed-off-by:
Ben Collins <ben.c@servergy.com> Acked-by:
Sumit Saxena <sumit.saxena@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
James Bottomley authored
commit d555a2ab upstream. We unconditionally execute scsi_eh_get_sense() to make sure all failed commands that should have sense attached, do. However, the routine forgets that some commands, because of the way they fail, will not have any sense code ... we should not bother them with a REQUEST_SENSE command. Fix this by testing to see if we actually got a CHECK_CONDITION return and skip asking for sense if we don't. Tested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Nicholas Bellinger authored
Part of commit 4442dc8a upstream. This patch changes rd_allocate_sgl_table() to explicitly clear ramdisk_mcp backend memory pages by passing __GFP_ZERO into alloc_pages(). This addresses a potential security issue where reading from a ramdisk_mcp could return sensitive information, and follows what >= v3.15 does to explicitly clear ramdisk_mcp memory at backend device initialization time. Reported-by:
Jorge Daniel Sequeira Matias <jdsm@tecnico.ulisboa.pt> Cc: Jorge Daniel Sequeira Matias <jdsm@tecnico.ulisboa.pt> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Wei Yang authored
[ Upstream commit befdf897 ] This patch wrap up a helper function __mlx4_remove_one() which does the tear down function but preserve the drv_data. Functions like mlx4_pci_err_detected() and mlx4_restart_one() will call this one with out releasing drvdata. Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by:
-
Wei Yang authored
[ No upstream commit, this is a cherry picked backport enabler. ] That way we can check flags later on, when we've finished with the pci_device_id structure. This is a backport. Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Xufeng Zhang authored
[ Upstream commit d3217b15 ] Consider the scenario: For a TCP-style socket, while processing the COOKIE_ECHO chunk in sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check, a new association would be created in sctp_unpack_cookie(), but afterwards, some processing maybe failed, and sctp_association_free() will be called to free the previously allocated association, in sctp_association_free(), sk_ack_backlog value is decremented for this socket, since the initial value for sk_ack_backlog is 0, after the decrement, it will be 65535, a wrap-around problem happens, and if we want to establish new associations afterward in the same socket, ABORT would be triggered since sctp deem the accept queue as full. Fix this issue by only decrementing sk_ack_backlog for associations in the endpoint's list. Fix-suggested-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
Xufeng Zhang <xufeng.zhang@windriver.com> Acked-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 39c36094 ] I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery is disabled. Note how GSO/TSO packets do not have monotonically incrementing ID. 06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396) 06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212) 06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972) 06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292) 06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764) It appears I introduced this bug in linux-3.1. inet_getid() must return the old value of peer->ip_id_count, not the new one. Lets revert this part, and remove the prevention of a null identification field in IPv6 Fragment Extension Header, which is dubious and not even done properly. Fixes: 87c48fa3 ("ipv6: make fragment identifications less predictable") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Tom Gundersen authored
[ Upstream commit f98f89a0 ] Enable the module alias hookup to allow tunnel modules to be autoloaded on demand. This is in line with how most other netdev kinds work, and will allow userspace to create tunnels without having CAP_SYS_MODULE. Signed-off-by:
Tom Gundersen <teg@jklm.no> Signed-off-by:
-
Michal Schmidt authored
[ Upstream commit bfc5184b ] Any process is able to send netlink messages with leftover bytes. Make the warning rate-limited to prevent too much log spam. The warning is supposed to help find userspace bugs, so print the triggering command name to implicate the buggy program. [v2: Use pr_warn_ratelimited instead of printk_ratelimited.] Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
-
Markos Chandras authored
commit 137f7df8 upstream. Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate that the system call needs to be checked against a seccomp filter. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Reviewed-by:
Paul Burton <paul.burton@imgtec.com> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6405/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> [bwh: Backported to 3.2: various other flags are not included in _TIF_WORK_SYSCALL_ENTRY] Signed-off-by:
-
Ralf Baechle authored
commit e7f3b48a upstream. This will simplify further modifications. Signed-off-by:
-
Peter Zijlstra authored
commit 46ce0fe9 upstream. When removing a (sibling) event we do: raw_spin_lock_irq(&ctx->lock); perf_group_detach(event); raw_spin_unlock_irq(&ctx->lock); <hole> perf_remove_from_context(event); raw_spin_lock_irq(&ctx->lock); ... raw_spin_unlock_irq(&ctx->lock); Now, assuming the event is a sibling, it will be 'unreachable' for things like ctx_sched_out() because that iterates the groups->siblings, and we just unhooked the sibling. So, if during <hole> we get ctx_sched_out(), it will miss the event and not call event_sched_out() on it, leaving it programmed on the PMU. The subsequent perf_remove_from_context() call will find the ctx is inactive and only call list_del_event() to remove the event from all other lists. Hereafter we can proceed to free the event; while still programmed! Close this hole by moving perf_group_detach() inside the same ctx->lock region(s) perf_remove_from_context() has. The condition on inherited events only in __perf_event_exit_task() is likely complete crap because non-inherited events are part of groups too and we're tearing down just the same. But leave that for another patch. Most-likely-Fixes: e03a9a55 ("perf: Change close() semantics for group events") Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Tested-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140505093124.GN17778@laptop.programming.kicks-ass.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> [bwh: Backported to 3.2: drop change in perf_pmu_migrate_context()] Signed-off-by:
-
James Bottomley authored
commit f2495e22 upstream. In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while the other is still using it. In this case, because the reap checks for STARGET_CREATED and kills the target without reference counting, the second thread will do the wrong thing on reap. Fix this by reference counting even creates and doing the STARGET_CREATED check in the final put. Tested-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
James Bottomley authored
commit e63ed0d7 upstream. This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the target disappears as soon as the last device is gone rather than waiting until final release of the device (which is often too long). Reviewed-by:
-
Bart Van Assche authored
commit b485462a upstream. Avoid that the code for requeueing SCSI requests triggers a crash by making sure that that code isn't scheduled anymore after a device has been removed. Also, source code inspection of __scsi_remove_device() revealed a race condition in this function: no new SCSI requests must be accepted for a SCSI device after device removal started. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Mike Christie <michaelc@cs.wisc.edu> Acked-by:
-
Nicholas Bellinger authored
commit 83ff42fc upstream. This patch fixes a left-over se_lun->lun_sep pointer OOPs when one of the /sys/kernel/config/target/$FABRIC/$WWPN/$TPGT/lun/$LUN/alua* attributes is accessed after the $DEVICE symlink has been removed. To address this bug, go ahead and clear se_lun->lun_sep memory in core_dev_unexport(), so that the existing checks for show/store ALUA attributes in target_core_fabric_configfs.c work as expected. Reported-by:
Sebastian Herbszt <herbszt@gmx.de> Tested-by:
-
Markos Chandras authored
commit ab6c15bc upstream. Previously, the lower limit for the MIPS SC initialization loop was set incorrectly allowing one extra loop leading to writes beyond the MSC ioremap'd space. More precisely, the value of the 'imp' in the last loop increased beyond the msc_irqmap_t boundaries and as a result of which, the 'n' variable was loaded with an incorrect value. This value was used later on to calculate the offset in the MSC01_IC_SUP which led to random crashes like the following one: CPU 0 Unable to handle kernel paging request at virtual address e75c0200, epc == 8058dba4, ra == 8058db90 [...] Call Trace: [<8058dba4>] init_msc_irqs+0x104/0x154 [<8058b5bc>] arch_init_irq+0xd8/0x154 [<805897b0>] start_kernel+0x220/0x36c Kernel panic - not syncing: Attempted to kill the idle task! This patch fixes the problem Signed-off-by:
-
Alex Smith authored
commit 91ad11d7 upstream. On MIPS calls to _mcount in modules generate 2 instructions to load the _mcount address (and therefore 2 relocations). The mcount_loc table should only reference the first of these, so the second is filtered out by checking the relocation offset and ignoring ones that immediately follow the previous one seen. However if a module has an _mcount call at offset 0, the second relocation would not be filtered out due to old_r_offset == 0 being taken to mean that the current relocation is the first one seen, and both would end up in the mcount_loc table. This results in ftrace_make_nop() patching both (adjacent) instructions to branches over the _mcount call sequence like so: 0xffffffffc08a8000: 04 00 00 10 b 0xffffffffc08a8014 0xffffffffc08a8004: 04 00 00 10 b 0xffffffffc08a8018 0xffffffffc08a8008: 2d 08 e0 03 move at,ra ... The second branch is in the delay slot of the first, which is defined to be unpredictable - on the platform on which this bug was encountered, it triggers a reserved instruction exception. Fix by initializing old_r_offset to ~0 and using that instead of 0 to determine whether the current relocation is the first seen. Signed-off-by:
Alex Smith <alex.smith@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7098/Signed-off-by:
-
Zhaowei Yuan authored
commit 1539fb9b upstream. If user uses wrong ioctl command with _IOC_NONE and argument size greater than 0, it can cause NULL pointer access from memset of line 463. If _IOC_NONE, don't memset to 0 for kdata. Signed-off-by:
Zhaowei Yuan <zhaowei.yuan@samsung.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> [bwh: Backported to 3.2: adjust indentation] Signed-off-by:
-
Hugh Dickins authored
commit d05f0cdc upstream. In v2.6.34 commit 9d8cebd4 ("mm: fix mbind vma merge problem") introduced vma merging to mbind(), but it should have also changed the convention of passing start vma from queue_pages_range() (formerly check_range()) to new_vma_page(): vma merging may have already freed that structure, resulting in BUG at mm/mempolicy.c:1738 and probably worse crashes. Fixes: 9d8cebd4 ("mm: fix mbind vma merge problem") Reported-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Tested-by:
Hugh Dickins <hughd@google.com> Acked-by:
Christoph Lameter <cl@linux.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Minchan Kim <minchan.kim@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Minchan Kim authored
commit 08270807 upstream. Revert commit 0def08e3 because check_range can't fail in migrate_to_node with considering current usecases. Quote from Johannes : I think it makes sense to revert. Not because of the semantics, but I : just don't see how check_range() could even fail for this callsite: : : 1. we pass mm->mmap->vm_start in there, so we should not fail due to : find_vma() : : 2. we pass MPOL_MF_DISCONTIG_OK, so the discontig checks do not apply : and so can not fail : : 3. we pass MPOL_MF_MOVE | MPOL_MF_MOVE_ALL, the page table loops will : continue until addr == end, so we never fail with -EIO And I added a new VM_BUG_ON for checking migrate_to_node's future usecase which might pass to MPOL_MF_STRICT. Suggested-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
Minchan Kim <minchan@kernel.org> Acked-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes <rientjes@google.com> Cc: Vasiliy Kulikov <segooon@gmail.com> Acked-by:
-
Naoya Horiguchi authored
commit 4a705fef upstream. There's a race between fork() and hugepage migration, as a result we try to "dereference" a swap entry as a normal pte, causing kernel panic. The cause of the problem is that copy_hugetlb_page_range() can't handle "swap entry" family (migration entry and hwpoisoned entry) so let's fix it. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
-
Andy Lutomirski authored
commit 554086d8 upstream. The bad syscall nr paths are their own incomprehensible route through the entry control flow. Rearrange them to work just like syscalls that return -ENOSYS. This fixes an OOPS in the audit code when fast-path auditing is enabled and sysenter gets a bad syscall nr (CVE-2014-4508). This has probably been broken since Linux 2.6.27: af0575bb i386 syscall audit fast-path Cc: Roland McGrath <roland@redhat.com> Reported-by:
Toralf Förster <toralf.foerster@gmx.de> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
